10:27Wolf480pl: RSpliet, so I guess this will take a while... let me know when you have some experimental patches/git branches I could test to test
10:28imirkin_: Wolf480pl: you have the hub_init timeout issue?
10:28imirkin_: if so, you should expect it to take quite a while. we've known about the problem for over a year already.
10:29imirkin_: i think we even had the fix for a fraction of the users as long as a year ago, but more brokenness remains
10:55mlankhorst: gnurou: is the video encoding/decoding stuff done in the graphics driver or somewhere else?
10:55imirkin_: def not in nouveau... those hw blocks aren't tehre
10:56mlankhorst: was curious because it required some custom egl stuff for gstreamer
10:56imirkin_: there *are* vdec (and maybe venc?) hw blocks, just elsewhere
10:56imirkin_: and yeah, looks like all the android people have a major crush on gst, so you're probably stuck with that pile of junk
10:57mlankhorst: actually openmax
10:57imirkin_: and gst is the only thing that touches openmax :)
10:58imirkin_: no clue if the openmax st in mesa works with nouveau btw...
10:58imirkin_: it'd require me to use gst to find out, so that's right out.
10:59mlankhorst: I think if uvcvideo could use dma-buf I could capture raw h264 on my beaglebone, but right now I need to brute force it on tegra
11:01mlankhorst: well problem is sending it to the network with reasonable bitrate :)
11:02imirkin_: gbit isn't good enough you?
11:02mlankhorst: not sure
11:02imirkin_: i doubt the venc units on any consumer hw can even produce a bitstream that fast
11:02mlankhorst: well its uvcvideo that can create h264 :)
11:03imirkin_: uvcvideo = webcam right?
11:10imirkin_: what does it output? yuv420 frames?
11:10imirkin_: or h264?
11:11mlankhorst: raw h264 bitstream
11:12mlankhorst: pipeline is webcam -> h264parse -> rtp -> multicast
11:13mlankhorst: but was hoping to use openmax or someothing to do h264 | tee multicast and decode h264, re-encode at lower bitstream -> upload to some webserver
11:16imirkin_: you could always have a local multicast listener
11:17mlankhorst: was hoping to not create any extra copy in memory
11:18imirkin_: anyways, i don't think the vdec/venc are available upstream
11:18imirkin_: but check in #tegra?
11:22mlankhorst: yeah might
15:27RSpliet: Wolf480pl: I made a start yesterday, but not quite there yet
15:29RSpliet: https://github.com/RSpliet/kernel-nouveau-nv50-pm/commit/b63228cd74ceb1a891c608927f27cdf09da05f3d <- proof :-P
15:29RSpliet: but that's not going to fix any of your problems
15:29imirkin_: highly unrelated :)
15:29imirkin_: esp as he's on a gk10x
15:30RSpliet: then I have no idea why he targeted his remark to me :-P
15:31imirkin_: because you mentioned that he should upload a trace
15:31RSpliet: oh right
15:31RSpliet: fair enough
15:32RSpliet: that's just the standard "make sure to put this information in standard places, so it doesn't get lost in IRC history
15:32imirkin_: no good deed goes unpunished
15:33RSpliet: at the same time... who was it that came up the other day on GDDR 3 reclocking and the highest perflvl not working? :-P
15:34imirkin_: don't remember =/
15:35RSpliet: there's logs for that
15:35RSpliet: but meh, let's not wake up sleeping hounsd
15:35imirkin_: did you change anything wrt the gt21x logic?
15:35imirkin_: or was it more of a refactor for nv50?
15:36imirkin_: your patch
15:36imirkin_: that you linked to
15:36RSpliet: that one, that makes gt215 look more like nv50s GPIO impl
15:36imirkin_: but you never had a gt21x with that property
15:36RSpliet: which is mandatory if you have more than one GPIO line to drive :-)
15:37RSpliet: I don't, but mystery user X pointed me to a previously unseen bit in the VBIOS that makes my GPU do this :-)
15:37imirkin_: the 33rd bit? :)
15:38RSpliet: *counts*... errrrr
15:38imirkin_: (aka i guess you didn't fuzz enough back then)
15:38RSpliet: almost, bit 36!
15:38imirkin_: well, i meant out of a 32-bit word :p
15:38imirkin_: nm. joking. mostly.
15:38RSpliet: oh yes, no, I didn't fuzz every bit in the tables :-)
16:31mupuf: imirkin_: hey, want the nv50 and maxwell, right?
16:31imirkin_: mupuf: sort of. i won't be able to look at it for a while
16:32imirkin_: like... not until mid next week
16:32imirkin_: oh, i might be able to tomorrow.
16:32imirkin_: anyways, if hakzsam is done with his stuff, sure, plop them in. otherwise, leave it with his things.
16:32mupuf: well, they are plugged
16:32mupuf: and yes, he is gone
16:33imirkin_: double-check that it boots though
16:33mupuf: and I have a friend over for the week end
16:33imirkin_: iirc both the g80 and maxwell have independently had booting issues
16:33imirkin_: so with their powers combined....
16:33mupuf: on reator?
16:34mupuf: 0: 0000:01:00.0 G80 450300a2
16:34mupuf: 1: 0000:05:00.0 GM107 117010a2
16:34mupuf: just remember, the ATX power buttons do not work anymore
16:34mupuf: I need to fix those
16:34imirkin_: good to know
16:34imirkin_: but "press power button" works?
16:34mupuf: my parents brought me my electronic equipment
16:34imirkin_: coz that's the only way i can shut it off
16:34imirkin_: running 'halt' doesn't turn the box off =/
16:34mupuf: and use force off to make sure it actually shuts down
16:34mupuf: stupid bios
16:35imirkin_: (thanks, systemd)
16:35mupuf: nah, it is the bios
16:35imirkin_: then why does it work for you
16:35imirkin_: when you do it locally
16:35mupuf: halt works on this machine
16:35imirkin_: ssh in and try it
16:35mupuf: it does not when I do it locally
16:35mupuf: same problem
16:35imirkin_: ah. you said it worked locally before
16:36mupuf: well, I do have the problem even locally...
16:36mupuf: that sucks
16:36mupuf: anyway, going to bed :)
16:36imirkin_: perhaps your bios update finished it off ;)
16:36mupuf: take care
17:04imirkin: calim: can i interest you in a rendering bug? depth is somehow messed up, but... how? https://bugs.freedesktop.org/show_bug.cgi?id=91247
17:24calim: imirkin: generally yes, but I can't test this now
17:25calim: I guess glDepthFunc(GL_EQUAL) is fine under certain circumstances
17:25calim: maybe we handle glDepthRange wrongly though
17:27calim: but unlikely, I seriously hope piglit would cry if that was the case ... maybe it's just a bug in the shader
17:27calim: does the fragment shader write depth ?
17:28calim: also, try killing http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state_validate.c#n305
17:28calim: I don't remember what it does
17:30calim: (depth range is handled by viewport scale/translate, this is just some kind of clipping or clamping)
17:32calim: it might require different values than we use, too, for e.g. float depth buffers
17:33calim: I think it clips the final z value after the fragment shader