03:51pabs3: RSpliet: is that firmware something that could be reverse engineered?
10:24filipdevuan_: hey is there anybody who could tell me how to configure nvidia optimus on non systemd distro???
12:29pendingchaos: imirkin: do I have your R-b for "nvc0: handle user buffers without any data"?
12:29pendingchaos: or should the behaviour of the state tracker be reverted instead (with something like https://hastebin.com/wojebukefi.diff)
12:32karolherbst: pendingchaos: did you verify that your patch helps and doesn't cause other regressions?
12:33pendingchaos: I can't remember
12:33pendingchaos: I guess I'll run piglit with it sometime
12:34karolherbst: pendingchaos: I think ilia asked you to dig up the past and see what's the actual deal here?
12:37pendingchaos: yeah, seems 19a91841c34 ('st/mesa: Use Array._DrawVAO in st_atom_array.c.') changed the behaviour of the state tracker so that it always set is_user_buffer for user buffers even if the user pointer is NULL
12:37pendingchaos: not sure if it was an oversight or not
12:40pendingchaos: I think the original behaviour of setting is_user_buffer to false for NULL user pointers was intentional though
12:40karolherbst: pendingchaos: did you check up on other drivers how they handle that?
12:41pendingchaos: IIRC the stuff in u_vbuf.c sets is_user_buffer to false for NULL user pointers
12:48pendingchaos: I think nouveau is the only gallium driver that supports user buffers but doesn't work with NULL user pointers
12:49pendingchaos: seems r300 supports them for some hardware and probably handles NULL user pointers
12:53pendingchaos: ah seems softpipe and llvmpipe supports them too
12:55imirkin: pendingchaos: sorry, i can't look at it now. will try to remember to tonight.
12:55karolherbst: pendingchaos: seems like it should be fine to handle that inside nouveau then.. but maybe it makes sense to ask in #dri-devel about that? Maybe fixing it in gallium won't hurt the other drivers, or maybe it would.
12:55pendingchaos: seems llvmpipe handles NULL user pointers and softpipe and r300 share some common code for this
17:46RSpliet: pabs3: it is. You can disassemble the binary using envydis
17:47RSpliet: It's "just" fμc, I think with some added vector instructions. mwk probably knows most about how well these videodec-specific instructions have been REd
17:49mwk: just pure falcon
17:49mwk: but it controls the special video decoding hw
17:49mwk: which is not known
17:50mwk: and on some gpus has another weirdo firmware of its own
17:50mwk: which I have also cracked
17:50mwk: but it, in turn, controls *another* piece of special video decoding hw
17:50mwk: and how that works is not known
17:51Sarayan: it's firmwares all the way down?
17:55HdkR:starts stacking turtles