17:32karolherbst: are there any known problems with SCOPE_DEVICE barriers + atomics with aco or llvm? Would be nice if somebody knows something, because debugging those things are never trivial
18:25Venemo: karolherbst: what are you expectations for SCOPE_DEVICE barriers?
18:26karolherbst: that they make write visible for the entire device
18:29karolherbst: anyway, I'm seeing consistency failures in compute shaders running multiple work groups
18:30Venemo: I think you just found a bug, then
18:30karolherbst: though I'm not sure whose bug it is
18:31Venemo: the code handling the cache flags has been refactored since the last time I took the time to understand it, so I'm not sure how it works now, but I think it isn't just based on the nir scope
18:32karolherbst: what is interesting is, that the same test works fine on zink + radv
18:32karolherbst: but doesn't with radeonsi + aco
18:33karolherbst: both using 1024 threads and 16 threads per block
18:33karolherbst: maybe some difference in lowering or something weird...
18:33Venemo: there are ac_cache_flags and there is also a gfx12_scope, and I can't find what handles them :(
18:34Venemo: I guess ac_get_hw_cache_flags
18:35Venemo: this seems to be mostly based on gl_access_qualifier, not on the scope
18:35karolherbst: yeah.. but that won't really explain why things work with radv, would it?
18:36karolherbst: maybe I should dig a bit deeper, haven't checked if it works with zink+radv before...
18:36Venemo: well, a good way to answer that would be to have a simple repro case and look at the shader disasm for both, and see what happens
18:36karolherbst: I'm sure it's some difference in lowering or something
18:36Venemo: my best guess is a missing cache flag for one reason or another
18:36karolherbst: well the test triggering it is anything but simple
18:36karolherbst: but that's kinda true for most atomic consistency testing
18:37Venemo: does the disasm look significantly different?
18:37karolherbst: haven't checked yet
18:37karolherbst: will do so later, just wanted to ask before I waste hours debugging it if somebody is aware of something
18:37Venemo: honestly, I'm not sure, maybe someone else on the channel will know more, but my guess is that we never had a real test case for these things
18:38karolherbst: I guess the vulkan testing there isn't great?
18:38Venemo: your guess is as good as mine
18:38karolherbst: well opengl..
18:38karolherbst: it works with vulkan...
18:38karolherbst: or maybe zink does something sneaky...
18:38Venemo: well the GL CTS is not famous for its awesome coverage
18:39karolherbst: I don't think this even exist in GL
18:39bnieuwenhuizen: well, with the memory model lots of tests have been added to Vulkan CTS for atomics & barriers, so I'm betting the Vulkan side is decent
18:40karolherbst: though I have no idea who atomic operations with explicit scope and memory order is even done in glsl for vulkan
18:40karolherbst: *how
18:42bnieuwenhuizen: IIRC https://github.com/KhronosGroup/GLSL/blob/main/extensions/khr/GL_KHR_memory_scope_semantics.txt is the glsl ext for the vulkan memory model
18:42karolherbst: ahh yeah
18:43karolherbst: gl definitely desn't have that
18:44karolherbst: or well..
18:44karolherbst: we don't
18:44karolherbst: and according to gpuinfo nobody else does
18:44bnieuwenhuizen: yeah it is not a proper GL extension thing
18:44karolherbst: I see
18:45bnieuwenhuizen: the mesa spir-v frontend has some code IIRC to convert legacy stuff to the vulkan memory model, but no idea what happens GL side
18:45karolherbst: so yeah.. I still bet on something lowering related
18:45karolherbst: yeah.. doesn't really matter, because from the CL side it's just OpAtomicLoad and spirv_to_nir splits it up
18:46karolherbst: (or whatever atomic operation)
18:48karolherbst: normally the good thing in mesa is that drivers share the same compiler with vulkan, so I can just rely on those things working, sometimes something doesn't work properly...
18:49Venemo: karolherbst: are you familiar with how to run piglit? I'm having a difficult time figuring out how to run a test locally
18:49karolherbst: depends on the testing. If you want to run a specific shader_test thing, you just use bin/shader_runner
18:50karolherbst: or the binary
18:50Venemo: I want to run spec@glsl-1.50@gs-max-output and this works: "./piglit run gpu -t spec@glsl-1.50@gs-max-output results" and crashes, however gdb cannot recognize ./piglit so I can't debug the crash
18:51karolherbst: bin/glsl-1.50-gs-max-output
18:51Venemo: if I run "./bin/glsl-1.50-gs-max-output" this just opens an empty black window and doesn't do anything
18:51karolherbst: ohh wait
18:51karolherbst: -fbo -auto or something as flags?
18:52Venemo: MESA_LOADER_DRIVER_OVERRIDE=zink ./bin/glsl-1.50-gs-max-output -fbo -auto => pass
18:52karolherbst: the piglit html report usually tells what command it executed
18:52karolherbst: and the flags
18:52karolherbst: so might want to take a look at those
18:52Venemo: where is that html report?
18:53karolherbst: CI artifacts I think
18:53Venemo: can't I ask it to generate that locally?
18:53karolherbst: it's also where the logs and stuff is
18:53karolherbst: if you have a piglit run, yes
18:53karolherbst: piglit-summary-html.py
18:54karolherbst: _but_
18:54karolherbst: piglit shouldn't crash....
18:55karolherbst: so I expect it's somewhere in piglit directly
18:55Venemo: what kind of args does ./piglit-summary-html.py expect? I tried giving it the results directory, and the result json
18:55karolherbst: output result_json
18:56Venemo: well, it doesn't say much, only that gs-max-output crashed
18:56karolherbst: but it should say what command it executed
18:57Remco: This is older, and skipped, but it does have the command that would be used: https://people.freedesktop.org/~airlied/piglit/zinknvk/gl/spec@glsl-1.50@gs-max-output.html
18:57Venemo: karolherbst: got it, thank you! yes, it does say that if I click on the crash
18:57karolherbst: I hope that also leads to a crash
18:57karolherbst: there is a bit more info, might be relevant
18:57Venemo: yes, it does now
18:58karolherbst: nice
18:58Venemo: I wish piglit was as simple to use as the VK CTS
18:59Venemo: okay, looks like the crash is already there on main so it isn't a regression at least
19:00Venemo: I almost forgot how much I love bisecting things
19:00Venemo: especially recompiling the whole mesa while at it
19:01karolherbst: you can use `git bisect run` tho
19:02karolherbst: https://gist.github.com/karolherbst/54185a5362a4498f44c705b6db79b32a
19:04Venemo: nice, I was unaware of that
19:06karolherbst: yeah.. the "exit 125" is in that script to tell it there was a compilation error (so it skips), the other part is to deal with random error codes git bisect run won't handle well... anyway yeah, it helps a lot with git bisects