16:47 KungFuJesus: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1167 This can be closed (I'm the original filer)
16:58 KungFuJesus: well this is interesting. What does it mean when vsync causes flicker?
17:06 KungFuJesus: without it enabled I still get stuttery / jerky looking playback with the glsl based deinterlacer, like it's jumping back a previous frame or something
17:14 karolherbst: KungFuJesus: are you on X?
17:15 karolherbst: if so... you want to enable DRI3 if using the nouveau DDX
17:15 karolherbst: or just use modesetting instead
17:31 KungFuJesus: given that I'm using efifb I'm not sure modesetting is an option
17:31 KungFuJesus: errr, sorry, openfirmware fb
17:32 karolherbst: should work with simpledrmfb afaik
17:33 KungFuJesus: cool, well forcing on DRI 3 in the xorg options seemed to stop the flicker. Still a weird stutter going on, though
17:33 KungFuJesus: wonder if that's a potential bug
17:34 karolherbst: or just the GPU overloaded or something :/
17:34 karolherbst: or it's indeed a bug
17:35 KungFuJesus: also get a blank screen in legacy doom when trilinear filtering is enabled
17:35 KungFuJesus: I've seen some weird behavior with the way SDL and SDL2 play with glx's fb setting functions
17:39 KungFuJesus: stutter looks to happen with double rate deinterlacing - I suspect you're correct in that the GPU can't keep up
17:43 KungFuJesus: hah, or it's a bug in double rate deinterlacing where it's displaying a frame behind. I tend to use VDPAU / nvdec on x86 systems but as of late I've had weird issues with that stuff too
17:54 KungFuJesus: Maybe by the end of the year I can get the open source doom3 engine to run atop of nouveau with nv47, hah. It is contemporary hardware with that game's release date though from what i remember the 7800 GT was dominated by 7800 GTX's flashed to work on powermacs
18:16 KungFuJesus: I do wonder how much of that was cpu bound bottlenecks in the proprietary nvidia drivers
19:06 KungFuJesus: hah, also looks like whoever was not confident that their changes in nouveau_fence were safe on nv30 was correct (might have been imirkin, maybe karolherbst, can't remember). I'm seeing a segfault in there
19:08 KungFuJesus: interesting, an assertion failure
19:47 KungFuJesus: anholt: eh, why'd marge fail on that?
19:48 anholt: mali lab fail
19:52 KungFuJesus: any idea why this assert would fail and what it's checking for? https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/drivers/nouveau/nv30/nv30_screen.c#L529
19:53 KungFuJesus: seems to be looking for space remaining in a buffer given the pointer subtraction that occurs
19:57 KungFuJesus: I suspect that pushbuf is probably pointing to the wrong place (maybe another buffer offset issue?) but the assertion kills things before I can get to asan to figure out when and where that buffer was allocated.
20:16 KungFuJesus: both of those pointers are null
20:21 KungFuJesus: ahh, push_datah _maybe_ doesn't look so endian safe?
20:40 KungFuJesus: interestingly returning early if that's null seems to make things work again but I suspect it being called regardless of a null value is the real bug
22:26 KungFuJesus: anholt: https://www.youtube.com/watch?v=ae8t-QKPVY4
23:09 KungFuJesus: yeah so there's no way anv tests are at _all_ affected by this MR unless somehow someone has the very first and only big endian intel CPU that's not like an i960 or something
23:09 KungFuJesus: or I dunno, an ARC GPU is being used on a big endian platform, I guess