16:47KungFuJesus: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1167 This can be closed (I'm the original filer)
16:58KungFuJesus: well this is interesting. What does it mean when vsync causes flicker?
17:06KungFuJesus: 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:14karolherbst: KungFuJesus: are you on X?
17:15karolherbst: if so... you want to enable DRI3 if using the nouveau DDX
17:15karolherbst: or just use modesetting instead
17:31KungFuJesus: given that I'm using efifb I'm not sure modesetting is an option
17:31KungFuJesus: errr, sorry, openfirmware fb
17:32karolherbst: should work with simpledrmfb afaik
17:33KungFuJesus: cool, well forcing on DRI 3 in the xorg options seemed to stop the flicker. Still a weird stutter going on, though
17:33KungFuJesus: wonder if that's a potential bug
17:34karolherbst: or just the GPU overloaded or something :/
17:34karolherbst: or it's indeed a bug
17:35KungFuJesus: also get a blank screen in legacy doom when trilinear filtering is enabled
17:35KungFuJesus: I've seen some weird behavior with the way SDL and SDL2 play with glx's fb setting functions
17:39KungFuJesus: stutter looks to happen with double rate deinterlacing - I suspect you're correct in that the GPU can't keep up
17:43KungFuJesus: 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:54KungFuJesus: 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:16KungFuJesus: I do wonder how much of that was cpu bound bottlenecks in the proprietary nvidia drivers
19:06KungFuJesus: 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:08KungFuJesus: interesting, an assertion failure
19:47KungFuJesus: anholt: eh, why'd marge fail on that?
19:48anholt: mali lab fail
19:52KungFuJesus: 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:53KungFuJesus: seems to be looking for space remaining in a buffer given the pointer subtraction that occurs
19:57KungFuJesus: 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:16KungFuJesus: both of those pointers are null
20:21KungFuJesus: ahh, push_datah _maybe_ doesn't look so endian safe?
20:40KungFuJesus: 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:26KungFuJesus: anholt: https://www.youtube.com/watch?v=ae8t-QKPVY4
23:09KungFuJesus: 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:09KungFuJesus: or I dunno, an ARC GPU is being used on a big endian platform, I guess