01:56orbea: es2gears (and various opengl programs like mpv) is segfaulting with the current mesa git on my musl-1.2.4 system, any ideas? https://termbin.com/91rj
01:56orbea: this only happens when mesa is compiled with -O1 or higher
02:39bbhtt: karolherbst: #llvm says it's a bug in mesa because llvm doesn't expose the necessary functions. The problem is the multi arch libdir `/usr/lib/$arch_triplet`
02:39bbhtt: bbhtt: Here's the conversation https://0x0.st/XsNj.png
02:39bbhtt: oops
02:39bbhtt: karolherbst: passing the clang binary path as clang_path makes it output the correct clang_res_path
02:40bbhtt: I expect debian and others to get bit by this too in a few years when they upgrade mesa
02:41bbhtt: they also have a multi arch libdir like freedesktop-sdk
03:52bbhtt: probably worse than copying the headers, I patched it like this https://dpaste.com/HQTCMWB5V.txt
08:56pq: mattst88, cool, thanks!
09:19aralmeida: i think i understand what scala does, i do not think that anyone can understand the code, but i delt with such numbers for years in a row, so set is increasing order at least fictively cause it can be delta encoded , so say 20 30 40, so 20*64+30*128+40*192=12800 , now 12800/64 minus x times 64 in a loop is 8, now 12800/128 minus 64 is 36 64-36 is 28, so trailing zeros down from 28 is first element is
09:19aralmeida: 20 aka 28-8 is 20, so 12800/192 is 66 minus 64 is 2 2=28 leading zeros together with 28 aka 28+2 is 30, so provided that you can divide with 64 to pack that tree, or have remainder tree from constant divison that's larger, it as expected is something to approve, but another way i described is also good and even preferred (no loops needed at runtime) but this can be constructed in this lang too. Extremely good even , scala is as smart
09:19aralmeida: as I am :).
09:22aralmeida: but i have similar concept for vintage hw, lacking bitwise and loops and opencl, but their method is good for anything considered a computer of modern kind.
10:12DavidHeidelberg: Who likes EGL? Who likes reviewing EGL MRs? Who likes reviewing X11 MRs? Who likes reviewing MRs which allows user-space to ditch GLX at some point? Who likes MRs which slightly violate the specifications? You can get everything! https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9989
10:13DavidHeidelberg: Sorry for the roller-coaster of emotions :D
10:16emersion: WSI \o/
10:17karolherbst: bbhtt: but it works everywhere else
10:17karolherbst: bbhtt: and using the `clang` path definetly doesn't work
10:19karolherbst: bbhtt: we've been there, like all those suggestions there don't work
10:20karolherbst: I'm sure it kinda depends on how things are built, but...
10:21karolherbst: bbhtt: but yeah.. I _think_ the relative prefix might be what we have to deal with here
10:21karolherbst: but I don't know what exactly
10:21karolherbst: mind figuring out what that's set to when building llvm/clang?
10:22karolherbst: bbhtt: also.. the clang binary path works, because it's doing relative magic, you could also pass in /usr/whatever_dir/whatever_file and it would work
10:23karolherbst: so that the clang binary path works is merely coincidental
10:23karolherbst: I've fixed this part at least 5 times now :D
10:23karolherbst: and the current version is what works best so far
11:31bbhtt: karolherbst: Do you mean prefix or the CLANG_RESOURCE_DIR when building llvm?
11:32karolherbst: the install prefix
11:34bbhtt: prefix is `/usr`, libdir is `lib/$arch-triplet`
11:34karolherbst: bbhtt: anyway.. reading the source of GetResourcesPath it suggests that you have to pass in the so file, not the executable :)
11:34karolherbst: mhhhh
11:35karolherbst: and still.. `CLANG_RESOURCE_DIR` is clearly wrong
11:35karolherbst: I should check how CLANG_RESOURCE_DIR is actually computed
11:36karolherbst: bbhtt: is the packaging setting `CLANG_RESOURCE_DIR`?
11:37bbhtt: karolherbst: Nope, but I/we tried setting it twice to check
11:37karolherbst: let's see...
11:37bbhtt: the full path doesn't work, relative like Fedora doesn't work
11:37bbhtt: and no one else seems to set it
11:37karolherbst: fedora does
11:37karolherbst: `-DCLANG_RESOURCE_DIR=../lib/clang/%{maj_ver} \`
11:38karolherbst: uhh... it's all such a pain honestly
11:40bbhtt: yea we tried something like that already https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/18009
11:42karolherbst: I _think_ the question is just what is the _intended_ base for CLANG_RESOURCE_DIR
11:43karolherbst: but the base is either the clang binary or the so file
11:43karolherbst: and it probably also depends on if you have the binary or the library used?
11:43karolherbst: I honestly don't know :)
11:44karolherbst: and afaik the config or build system of clang doesn't really tell us what's up
11:45karolherbst: bbhtt: like the other alternate is to run `clang -print-resource-dir` but that's uhm.. pain
11:45karolherbst: especially in a devel environment
11:53karolherbst: bbhtt: but yeah... in the end I really just want an API for this, but the upstream issue I've filed went nowhere
11:53karolherbst: https://github.com/llvm/llvm-project/issues/60849
11:54bbhtt: karolherbst: Yea that's what I also got, thanks
11:54karolherbst: and the solution can't be to call clang
12:10DemiMarie: karolherbst: I think you may need to make the PR yourself, sadly.
12:15karolherbst: but I could complain for 5 years instead before finally doing it
12:15dwfreed: :D
13:29jenatali: karolherbst: just embed the headers and be done with it IMO
13:33orbea: any ideas why es2gears is segfaulting on my musl-1.2.4 system when when mesa is compiled with -O1 or greater optimizations? https://termbin.com/91rj
13:37karolherbst: jenatali: yeah... probably...
13:37karolherbst: I just don't want to know what potential other issues this leads us to when clang diverges from the included header and distros not rebuilding mesa on every clang rebuild :D
14:08psykose: orbea: if that's master it almost looks like a stack overflow
14:09psykose: try -Wl,-z,stack-size=0x200000
14:09psykose: (2MiB)
14:10orbea: will try...
14:16orbea: psykose: no luck
14:17psykose: er
14:17psykose: mesa is a library so the linker flag does nothing
14:17orbea: i'll try building mesa-progs with it
14:17psykose: try https://github.com/chimera-linux/cports/blob/master/main/mesa/patches/musl-stacksize.patch instead
14:18orbea: trying
14:18psykose: misremembered it
14:18karolherbst: psykose: ngl, beatiful hack
14:19psykose: not really a hack
14:19karolherbst: ehh wait... the stack only grows for the main thread.. right
14:20psykose: the glibc default thread stack size is based on.. rlimit_stack which is 2-10mb or so?
14:20psykose: on musl it's 128k
14:20psykose: this just sets it to 8mib instead
14:20karolherbst: mhhh
14:20karolherbst: guess mesa should set it then indeed
14:20psykose: it would probably be fine to set something smaller than that huge 8mib, since even on glibc it usually is, i guess
14:20psykose: 2mib is a nice starting value
14:21psykose: i don't remember if someone ever reported this
14:21karolherbst: why aren't stacks growing in threads though?
14:21psykose: they never auto grow for thread, there's jus tinitial
14:21orbea: psykose: that worked :)
14:21karolherbst: yeah.. I wonder why
14:21psykose: guessed right :D
14:22orbea: psykose: do you also happen to have a fix for vulkan with musl? :P
14:22psykose: it's always worked for me
14:22psykose: what doesn't work
14:22psykose: i've used radv for years :D
14:22orbea: mpv + vulkan or n64 emus like RMG or simple64
14:22psykose: and anv
14:22psykose: hmm
14:22psykose: mpv vulkan is what i always use
14:22orbea: i reported the n64 issue, let me find the link
14:22karolherbst: mhh guess the reason is that the buffer is preallocated...
14:23karolherbst: I wonder when CPU applications will start managing their own VM :D
14:23karolherbst: that would be cursed
14:23psykose: too cursed
14:23orbea: psykose: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10488
14:23karolherbst: but that would give you growable stacks in threads
14:23orbea: a friend also reproduced that using their alpine
14:24karolherbst: and makes realloc also way easier to use
14:24karolherbst: *implement
14:24psykose: hmm, never saw that crash before
14:24psykose: but i never tested aco specifically
14:24psykose: i can try that rn
14:25orbea: :)
14:25psykose: is there a way to force aco-only or do i have to build an llvm-free radeonsi first
14:25orbea: i thought it was default
14:25psykose: well if it's default then it works for me
14:26psykose: i'll try build this mupen thing real quick
14:27psykose: does this even have a build system
14:27psykose: sigh
14:27orbea: thanks
14:28orbea: its uses cmake
14:28gfxstrand: Ugh... Sometimes I hate GL. "Why do we need DualSlotInputs?!? Why does anyone care about this information?!? Oh, right... It's because OpenGL decided that a dvec4 should take a single location when used for VS inputs for $reasons"...
14:28karolherbst: people should have written the compiler implementation for this before accepting this into the spec tbh
14:29psykose: orbea: where specifically? -core has like nothing in it
14:29orbea: psykose: if it helps I have build systems for both, RMG is easier to build https://0xacab.org/orbea/9stoats/-/tree/master/games-emulation?ref_type=heads
14:29orbea: *ebuilds rather
14:29psykose: sure
14:30psykose: that looks better
14:31orbea: i asked the simple64 dev if he'd be willing to make his build system support distros more and got a strong "no"..., rmg was much more willing to help out :Shrug:
14:31gfxstrand: karolherbst: Yeah, they should have. We learned better with Vulkan but GL is stuck the way it is.
14:31gfxstrand: And people were arguing for the GL behavior for Vulkan for "consistency"
14:31gfxstrand: Glad we dodged that bullet
14:32karolherbst: oh wow...
14:33gfxstrand: I do wonder if it's possible to hoiste this stuff even further into ST so the compiler can most stop caring. I suspect no, though. Or at least I suspect it'd be tricky
14:33karolherbst: yeah.. I think long term to make it the st's responsibility to lower this nonsense
14:33karolherbst: is the right approach
14:33gfxstrand: Well, ST already is.
14:34gfxstrand: But as of mareko's latest patches, NIR is now preserving all that info. I can't see any reason for doing so besides letting us run even more NIR optimizations before input locations are assigned so that ST can still parse everything out.
14:35karolherbst: yeah.. that's what I meant, I see no reason why drivers should be bothered with any of this
14:35gfxstrand: Drivers aren't
14:35gfxstrand: But core NIR is
14:35karolherbst: ohh.. I see
14:35gfxstrand: Well, drivers are still a little bit, maybe. I think drivers have to do location + high_dvec2 but that's it
14:36karolherbst: yeah... I've done cursed stuff in this regards for codegen, but that's maybe also due to legacy reasons
14:36gfxstrand: Probably?
14:36gfxstrand: I mean anything with GL is "legacy" reasons, no?
14:36gfxstrand: :P
14:39jenatali: Sigh Anybody know why this job is getting a 404? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/56749837#L1198
14:40gfxstrand: jenatali: Ask on #freedesktop?
14:41jenatali: Yeah, wasn't sure if this is an infrastructure problem or a job configuration problem though
14:41gfxstrand: IDK either
14:41gfxstrand: It could be that our Android build prep isn't uploading its artifacts properly.
14:42gfxstrand: I'm a bit surprised an s3 link would 404 otherwise
14:42jenatali: > ERROR: No files to upload
14:42jenatali: Oh that's the container, not the build
14:42jenatali: Wait no, that is the build job
14:46psykose: orbea: how do i enable the -parallel bulkan thing
14:46psykose: in rmg
14:46psykose: ah found it
14:46psykose: segfaulted
14:46orbea: yea, its in plugins
14:47psykose: sik https://img.ayaya.dev/9bKb6M9JjWqA
14:51psykose: it works after raising the stack size
14:51psykose: https://img.ayaya.dev/ajRc7iCRaxMR
14:51psykose: for the rmg build
14:52psykose: i think that patch for mesa threads is not reused for these vk threads, and those are either elsewhere or application stuff
14:52psykose: idk graphics apis
14:52jenatali: I think my question is, why did this job seemingly not do anything: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/56748426
14:52psykose: and mpv just doesn't crash at all for me (no overrides or anything)
14:53psykose: orbea: ^
14:53orbea: psykose: thanks for trying, I don't know graphics APIs either
14:53psykose: works with/without RADV_DEBUG=llvm so same issue in both i think
14:53psykose: and crashed with either before raising it
14:55psykose: looking at the backtrace
14:55psykose: this isn't a mesa-spawned thread
14:55psykose: but just QThreadPrivate::start of Thread::EmulationThread::run()
14:55psykose: and vulkan seems to do stuff in that same thread, not spawn its own
14:55psykose: so i think this is application responsibility
14:55psykose: have to raise this per app or whatever
14:56jenatali: DavidHeidelberg: I think you might be the right person to help? Not sure. Looks like my MR might've silently broken the Android build: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/56748426
14:56psykose: orbea: do you have a mpv crash on musl? think it's a separate issue entirely, i've never had one
14:56psykose: + bt etc
14:57orbea: psykose: yes, but I think I only made the mpv issue https://github.com/mpv-player/mpv/issues/12468
14:57orbea: i meant to make the mesa issue, but never got around to it...
14:57psykose: hm does that still happen on master
14:58orbea: yep
14:58orbea: as of yesterday at least
14:58orbea: and indeed fixing the stacksize fixes RMG (and probably simple64 too)
14:59psykose: i looked at uhh
14:59psykose: the mpv bug
14:59psykose: the line seems to be 411 here https://gitlab.freedesktop.org/mesa/mesa/-/blob/b5d6b7c402a06204ba54df9cb357c89fec9db01a/src/compiler/nir/nir_lower_io_to_vector.c
14:59psykose: (roughly correlating by date of when you posted that)
14:59psykose: given that it's nonsense it's probably the mesa stack size
15:00psykose: i.e. fixed with the other patch
15:00psykose: check again
15:00orbea: i already checked after making seeing opengl work :)
15:00psykose: hm ok
15:01psykose: now for an extra meme of yet the same thing: what about raising the mpv stack size :DD
15:01orbea: yep, going to try doing it for mpv itself
15:03orbea: yea, that works
15:03psykose: nice
15:03orbea: so opengl needs to be in mesa and vulkan needs to be per app?
15:03psykose: seems so
15:03psykose: the weird thing is why i don't get it for mpv
15:04psykose: but that might be luck
15:04orbea: probably why it was working for me for a long time
15:04psykose: maybe if i updated to mesa git it would happen
15:04psykose: or had a different gpu
15:04orbea: and then broke after an update
15:04psykose: i have a rx6600 so a bit newer, maybe ends up doing different code stuff
15:17orbea: psykose: updated the three existing issues, thanks
15:17psykose: :)
16:23gfxstrand: I'm a bit surprised an s3 link would 404 otherwise
16:25DemiMarie: karolherbst: just make the PR
16:25karolherbst: you see.. that requires working on the LLVM codebase
16:26DemiMarie: Which is probably the only solution here, unless you decide to just stop using LLVM
16:27DemiMarie: Is there a reason (beyond the preprocessor) that OpenCL is harder than GLSL?
16:29gfxstrand: It's full C syntax
16:29gfxstrand: Oh, and there's OpenCL C++, too.
16:31karolherbst: well.. OpenCL C++ in _theory_ is spir-v only at runtime, but there are extensions which allow C++ at runtime
16:31karolherbst: and apparently on android it's a common thing
16:31gfxstrand: Yup because most vendors refuse to accept SPIR-V.
16:31gfxstrand: And given the bullshit we've seen out of SPIRV-LLVM-Translator, I kinda don't blame them. :'(
16:32karolherbst: because compiling C++ at runtime is such a good idea
16:32karolherbst: mhhh
16:32karolherbst: right...
16:32karolherbst: hopefully the spirv target will be better
16:39karolherbst: speaking of translator bullshit, I still have this MR I need to cleanup or something: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27640
16:39karolherbst: gfxstrand: in case you have any better ideas ^^
16:40jenatali: gfxstrand: Yeah in #freedesktop it looks like Eric found the problem
16:40gfxstrand: \o/
16:40gfxstrand: karolherbst: Ugh...
16:40karolherbst: same
16:43karolherbst: it's kinda annoying that opt_deref (or whatever translates copies to copy_deref) and opt_memcpy fight each other here and you can end up with a bad path giving you scratch mem even though you don't need it...
17:31mareko: gfxstrand: I'm pretty sure you don't have to handle high_dvec2 in any gallium drivers, it's just for a few passes to be able to compute VS input locations correctly, and for st/mesa to lower it
17:31mareko: high_dvec2 only exists for the GLSL linker and st/mesa
17:36gfxstrand: mareko: So is the location correct and high_dvec2 is just info?
17:36gfxstrand: Or is the actual locaiton slot + high_dvec2?
17:36gfxstrand: Not that any of this matters for Vulkan
17:39mareko: gfxstrand: the actual location is location + high_dvec2, but gallium drivers can ignore it because st/mesa set the result nir_intrinsic_base
17:40mareko: I don't actually really know, I would have to remind myself at how st/mesa works
17:42mareko: gfxstrand: one sure reason for high_dvec2 to exist is to be able to DCE "low_dvec2" without breaking everything, previously we couldn't do that
17:43gfxstrand: mareko: Yeah, I get why it's there. I'm annoyed by GL but that's nothing new. 😅
17:47mareko: nir_opt_varyings started eliminating unused "low_dvec2", but that broke VS inputs because high_dvec2 was only ambiguously expresed in nir_intrinsic_base, and it only worked because dual slot VS inputs were never DCE'd partially, well they are now
17:48gfxstrand: yeah
18:05DemiMarie: gfxstrand: Full C syntax is not that hard, look at the Tiny C compiler. If you need to support OpenCL C++ then I agree.
18:10DemiMarie: gfxstrand: My peeve with Android is that nobody uses upstream drivers.
18:10gfxstrand: Well, yes
18:10gfxstrand: We're all peeved about that
18:12DemiMarie: Apparently it is because there is no market pressure to upstream drivers and reverse engineering takes too long.
18:12DemiMarie: Of course Intel and AMD manage to have launch-day upstream support.
18:13DemiMarie: Is this Google’s fault.
18:13gfxstrand: Maybe? Kinda?
18:13gfxstrand: It's more because the driver stack is dictated by the OEM and they always take the HW vendor's driver.
18:13gfxstrand: Google could break that chain by using Mesa in a phone since they are the OEM for the pixel devices.
18:14DemiMarie: That would cause delays, though, because that stack must be reverse engineered.
18:14DemiMarie: What I would do if I were Google is turn on module signature checking and say all modules must be signed by Google.
18:15DemiMarie: Or just make Mesa a hard compatibility requirement.
18:16DemiMarie: Maybe Google doesn’t have enough clout in the Arm space? Not sure.
18:32mattst88: heh, I have some memory of a story about an android game that was actually shipping freedreno in their apk
18:32mattst88: so that their game would use it instead of the system-provided proprietary driver
18:36gfxstrand: Yeah, there's a couple of those
18:36gfxstrand: DemiMarie: Google has been in an interesting dance with the Arm ecosystem (and Qualcomm in particular) for the history of Android
18:37gfxstrand: Let's just say that clawing back control is slow-going.
18:40DemiMarie: gfxstrand: who is winning?
18:49jenatali: gfxstrand: Ping on !22298, I'd like to land that if you're not too strongly opposed
19:32JohnnyonFlame: having an odd issue with rdna2/linux 6.2, every now and then my entire video output freezes and I can't even drop to tty, sound/network are still clearly working since I can hear video playback going
19:34JohnnyonFlame: multimon setup, 75hz vertical display + 144hz vrr displayport display
19:42mattst88: fab: please fix your connection
21:33gaudeamus: i just wanted to test your big words about mental illness, scalas actual problem in bitsetlike file is the function in keyiterator, where the divide and conquer loop alike thing happens, if the word is changed to more than 64 it can be gotten rid of, however then you would have to get rid of the super bitcount intrinsics too, not sure why they endorse such hw code cause single instruction is likely very fast but the dc loop could be
21:33gaudeamus: expensive, however modern computers do it fast in fact, overall i do not like this loop where !contains is in the file, but this can be easily redesigned. But for a 15year old solution, it was a good start for both performance and space efficiency. For the context that loop should be the thing that adds the 64's one by one with a step of 1digit back, so that loop and inner test of bool returning element inclusion in the set could be
21:33gaudeamus: just removed, as it limits the performance. otherwise the lang is good looking. I assume that limiter and bitcount over complication is intentional performance hinderer.
21:33dwfreed: ugh
21:37dwfreed: if you see me speak immediately after our friend there, *don't* do anything
21:38dwfreed: Kayden: emersion: ^^^
21:38Kayden: dwfreed: ah, thanks, did not realize you were here handling it :)
21:39dwfreed: Please feel free to ping me (preferably by PM) if I seem to have missed it
21:59Ermine: Not every client shows joins/parts/modesets/kicks
22:20karolherbst: smart clients show them only for relevant people
22:31dwfreed: Ermine: the actions I take have no outwardly visible effects
22:32dwfreed: They are, however, quite effective
22:38Ermine: dwfreed: secret network stuff ninjutsu!