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