00:15imirkin: pmoreau: yeah, i just didn't have the patience to look up all the new names
04:26pabs3: 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:32annadane: supposedly the 4.15 kernel in debian fixes a number of nouveau freezing issues
04:32annadane: i've yet to try it as it's not in backports yet
04:35annadane: well, 4.15 kernel in general, i meant
04:36pabs3: I was using 4.16
08:48pmoreau: annadane: 4.15 did introduce some regressions as well, some of which should be fixed in >=4.15.11 or >=4.16-rc6.
10:55karolherbst: imirkin: only 4 regressions left :)
10:55karolherbst: + bindless
10:56karolherbst: 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:13karolherbst: imirkin: if you want to fix two glsl to tgsi crashes: spec@arb_gpu_shader5@compiler@email@example.com and spec@arb_gpu_shader5@compiler@firstname.lastname@example.org
14:14karolherbst: 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:44imirkin_: karolherbst: makes sense
14:45karolherbst: the asserts?
15:04None4U: de project is ded
22:34pendingchaos: what do PUSH_REFN()/nouveau_pushbuf_refn and nouveau_bo_wait() do?
22:34pendingchaos: does nouveau_bo_wait() wait for a fence added at the next pushbuf flush after PUSHBUF_REFN()?
22:36plutoo: bo_wait() submits the current pushbuf
22:36plutoo: not sure if it waits for completion... would assume so
22:37pendingchaos: only when the buffer specified in bo_wait() was previously specified in PUSH_REFN()?
22:38imirkin_: pendingchaos: it's all a bit subtle
22:38imirkin_: and by "a bit", i really mean "extremely"
22:38imirkin_: here's the idea... you build up a list of commands, which do things to various objects
22:39imirkin_: you want to ensure those objects are in vram (or sysram) while the gpu is executing that list of commands
22:39imirkin_: 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:39imirkin_: so then the question is ... well when are they done
22:40imirkin_: nouveau_bo_wait() will ask the kernel to wait until a bo is no longer referenced by such a running command list
22:40imirkin_: in practice, the kernel adds on fences
22:40imirkin_: and the nouveau_bo_wait is just a wait for such a fence to be hit
22:40imirkin_: does that clear things up a bit?
22:40pendingchaos: I think so
22:41imirkin_: any time the kernel processes a userspace command list, it creates a new fence, and attaches it to all the referenced bo's
22:41imirkin_: (so the kernel is actually secretly throwing extra commands onto the channel)
22:41imirkin_: but it's not that many, and for semi-modern gpu's, no object even has to be bound to the subchannel
22:42imirkin_: (G84+ iirc?)
22:42imirkin_: has to jump through some hoops for the nv4's of the world :)
22:42imirkin_: all 3 that are left...