02:24karolherbst: KungFuJesus: happens
15:54KungFuJesus: hah, starting to look like it _can_ affect x86 as well under the right conditions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498
15:54karolherbst: fun issue
15:54karolherbst: but yeah...
15:54karolherbst: compiler bugs are never off the table
15:55KungFuJesus: it sounds like they're going to true to backport the fix, I'm not sure what that means with my MR
15:55KungFuJesus: wait and let it die? Put it in there for a version check? Add a compile time check for the bug?
15:55karolherbst: we don't want to carry workarounds for broken compilers is my take
15:55karolherbst: once it released we can simply refuse to compiler on broken compilers
15:56KungFuJesus: I'm more than happy to let it die on the table and add GCC's own test for the bug if someone can show me how to actually integrate that into meson
15:56karolherbst: it's hard to tell if the compiler is broken tho
15:56KungFuJesus: sure, but that test case makes _this_ one reveal it's ugly head pretty readily
15:57KungFuJesus: (Jakub's, not mine)
15:57KungFuJesus: particularly: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108498#c19
15:57karolherbst: yeah... so meson allows you to run processes and stuff
15:57karolherbst: maybe ask dcbaker on a take on this for meson?
15:58karolherbst: let me leave a comment
15:58KungFuJesus: it will of course, be a nuisance to everybody trying to compile with this compiler, whether they are affected or not. But it does maybe twist the right maintainer arms to make sure they get the patch?
15:59karolherbst: could make it nouveau only
15:59karolherbst: maybe other drivers are affected in weird ways
15:59karolherbst: broken compilers are just pure evil
16:02KungFuJesus: yeah I kind of wonder how many bugs are out there because of this
16:03karolherbst: I once spot a race condition in nouveau.. apparently fixing it fixed a bunch of random bugs we were never able to figure out
16:06KungFuJesus: good for the goose is good for the gander?
16:17KungFuJesus: I was still kind of hoping I'd get an answer for why the emitted code is so ridiculously suboptimal on PPC. But I take it the TGSI stuff is only parsed once before being translated into fragment and vertex shaders specific to Rankine?
16:28KungFuJesus: it's shocking how much better the code out of clang is, and for PPC that seems to be a common trend. It apparently has been translating to bad autovectorized code as well. A more recent example: https://github.com/openzfs/zfs/pull/14234#issuecomment-1330689697
16:28KungFuJesus: lots of stack vommiting there
18:41KungFuJesus: whenever this goes in, things will at least function better on big endian: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19051
18:41KungFuJesus: I've still found a handful of bugs that I plan to chase down, but everything mostly renders correctly with that in place
18:42KungFuJesus: no more byteswapped pink doom or having to patch GL applications to say that uncompressed RGBA textures are byte swapped when they're not
19:42karolherbst: though I'd kind of prefer less checks against the endian
19:42karolherbst: anyway, you might want to run the CTS with your changes on llvmpipe and see if you hit any regressions
20:13KungFuJesus: which changes, specifically?
20:14KungFuJesus: that MR isn't mine, but, I've tried llvmpipe with the same applications that are adversely affected with big endian and they still appear correct
21:13KungFuJesus: hmmm, sort of wondering if _this_ MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20812 might fix the flicker when using mythtv's glsl based deinterlacer
21:17KungFuJesus: then again I think that flicker issue predated the migration to NIR in the middle
21:17KungFuJesus: still worth trying, I guess
21:20KungFuJesus: the flickering seems to occur on the alpha channel because it will often show the UI behind it
21:21KungFuJesus: probably something dumb like poor byte swapping on the alpha channel - the stuff we've come to expect from the big endian hacks :-/