00:15 imirkin: pmoreau: yeah, i just didn't have the patience to look up all the new names
04:26 pabs3: pmoreau, imirkin: with nouveau.debug="debug,disp=trace" couldn't see anything strange apart from the lockup. https://people.debian.org/~pabs/tmp/nouveau.log.xz
04:32 annadane: supposedly the 4.15 kernel in debian fixes a number of nouveau freezing issues
04:32 annadane: i've yet to try it as it's not in backports yet
04:35 annadane: well, 4.15 kernel in general, i meant
04:36 pabs3: I was using 4.16
08:48 pmoreau: annadane: 4.15 did introduce some regressions as well, some of which should be fixed in >=4.15.11 or >=4.16-rc6.
10:55 karolherbst: imirkin: only 4 regressions left :)
10:55 karolherbst: + bindless
10:56 karolherbst: somehow I fixed something without knowing it and it fixed some tests, must have been something silly like treating bit ops as unsigned or something like that
14:13 karolherbst: imirkin: if you want to fix two glsl to tgsi crashes: spec@arb_gpu_shader5@compiler@builtin-functions@fs-gatheroffset-uniform-offset.frag and spec@arb_gpu_shader5@compiler@builtin-functions@fs-gatheroffset-uniform-offset.frag
14:13 karolherbst: uhm
14:13 karolherbst: spec@arb_gpu_shader5@compiler@builtin-functions@vs-gatheroffset-uniform-offset.vert
14:14 karolherbst: both hit "glslparsertest: ../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:5846: tgsi_texture_offset translate_tex_offset(st_translate*, const st_src_reg*): Assertion `!src.Dimension' failed."
14:44 imirkin_: karolherbst: makes sense
14:45 karolherbst: the asserts?
14:45 imirkin_: yea
15:04 None4U: de project is ded
22:34 pendingchaos: what do PUSH_REFN()/nouveau_pushbuf_refn and nouveau_bo_wait() do?
22:34 pendingchaos: does nouveau_bo_wait() wait for a fence added at the next pushbuf flush after PUSHBUF_REFN()?
22:36 plutoo: bo_wait() submits the current pushbuf
22:36 plutoo: not sure if it waits for completion... would assume so
22:37 pendingchaos: only when the buffer specified in bo_wait() was previously specified in PUSH_REFN()?
22:38 imirkin_: pendingchaos: it's all a bit subtle
22:38 imirkin_: and by "a bit", i really mean "extremely"
22:38 imirkin_: here's the idea... you build up a list of commands, which do things to various objects
22:39 imirkin_: you want to ensure those objects are in vram (or sysram) while the gpu is executing that list of commands
22:39 imirkin_: so the pushbuf_refn thing links an object to a command list. the guarantee (by the kernel) is that these objects won't be evicted until those commands are done
22:39 imirkin_: so then the question is ... well when are they done
22:40 imirkin_: nouveau_bo_wait() will ask the kernel to wait until a bo is no longer referenced by such a running command list
22:40 imirkin_: in practice, the kernel adds on fences
22:40 imirkin_: and the nouveau_bo_wait is just a wait for such a fence to be hit
22:40 imirkin_: does that clear things up a bit?
22:40 pendingchaos: I think so
22:41 imirkin_: any time the kernel processes a userspace command list, it creates a new fence, and attaches it to all the referenced bo's
22:41 imirkin_: (so the kernel is actually secretly throwing extra commands onto the channel)
22:41 imirkin_: but it's not that many, and for semi-modern gpu's, no object even has to be bound to the subchannel
22:42 imirkin_: (G84+ iirc?)
22:42 imirkin_: has to jump through some hoops for the nv4's of the world :)
22:42 imirkin_: all 3 that are left...