07:30mlankhorst: What's the difference between drm accel and normal drm drivers?
08:21airlied: mlankhorst: accel drivers don't expose kms and are for non gpu devices
08:21airlied: otherwise not much, technical solution to a social problem :-P
08:21airlied: but also userspace GPU probing won't hit them
08:24airlied: https://docs.kernel.org/accel/introduction.html 11:33alyssa: jenatali: so msvc doesn't support gnu-extension-of-the-day, and I don't see a way to implement https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37200 without it
11:33alyssa: wondering if simply not building the util/lut test on msvc is unreasonable since I don't expect that code to be used on msvc ever
11:34alyssa: (and even in some bizarro future where agx or anv or something builds on Windows, it'd probably be on mingw/clang and not msvc.)
12:21mlankhorst: Yeah curious what a non-accelerating non-modeset device would look like
12:22daniels: mlankhorst: vgem
12:30dolphin: airlied, sima: backmerged drm-next to drm-intel-gt-next to bring in some changes that had been committed via other trees (without acks, too...)
12:30Leftmost: Is https://github.com/KhronosGroup/SPIRV-Guide the best place to get started with understanding SPIR-V (with an eye toward contributing to mesa)? Are there other resources that I should look at?
12:46jenatali: alyssa: ack, I don't see a good way around that one either
12:47alyssa: jenatali: k, will do that when i'm in the office
12:47alyssa: thanks
12:48alyssa: We'll probably eventually use that in NIR but in a dedicated opt pass that again can be msvc-gated since you dont need it
12:49alyssa: [Folding stuff like `iand(a, ior(b, c))` into `lut3(a, b, c, 0xsomething)`
13:02Company: alyssa: technically, you can add #define a ((uint8_t) 0xAA) in the header or do "static const uint8_t a = 0xAA;" to avoid the gnu extension, but I'm not sure you wanna deal with the side effects of the global symbols
13:40lucaceresoli: Hello, I am a drm-misc committer, but only even committed to drm-misc-next. Can I commit to drm-misc-fixes too?
13:40mlankhorst: Sure
13:40lucaceresoli: mlankhorst: ah, thanks! -- Just wanted to make extra sure I'm not committing where not supposed to :)
14:17karolherbst: Do we have a nir pass that can properly optimize barriers like this? https://gist.githubusercontent.com/karolherbst/6b7317eab671b2240a9cd0c1104e9098/raw/ef4f6131a589a4dd279246124a7e9daced96a886/gistfile1.txt 14:17karolherbst: most of those barriers seems uneccesary
14:19dj-death: karolherbst: maybe nir_opt_acquire_release_barriers ?
14:19pendingchaos: karolherbst: there's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36602/diffs?commit_id=2a666a8908ba238bfbf4b8b46c29f55bca974f57 for shared access
14:20karolherbst: yeah let me try that commit
14:21karolherbst: dj-death: hacking on nir_opt_acquire_release_barriers was kinda what I'd try to do when there is nothing else
14:22pendingchaos: could maybe use ACCESS_COHERENT for ssbo/image instead of make-available if you're okay losing the memory scope
14:22pendingchaos: I'm not 100% sure, but make-visible might be slightly different from ACCESS_COHERENT
14:22pendingchaos: (make-visible might make future accesses to the same location visible, not just ACCESS_COHERENT's behaviour of only affecting the first access)
14:22karolherbst: ohh it also does non atomics mhhh
14:22karolherbst: yeah.. only really caring about shared memory atm
14:24karolherbst: pendingchaos: yeah, your commit works perfectly
14:24karolherbst: I have shaders I want to beat nvidia at, and this problem solved reduces the gap by 12 pp :D
14:25karolherbst: but let me see if nir_opt_acquire_release_barriers also helps
14:28karolherbst: yeah so nir_opt_acquire_release_barriers doesn't seem to do anything
14:31karolherbst: well needs an atomic present to operate mhh
15:07alyssa: Company: Uh yeah no we're not dealing with that heh
15:09Company: the other option I thought about is turning it into a static inline constexpr lambda function somehow, but I have no idea if you can abuse MSVC's C++ skills for that
15:10alyssa: I thought about that but I don't really want to compile random C code as C++, that's bit me too many times
15:12Company: I'd only do that with #ifdef MSVC, but yeah
15:24jenatali: Yeah I was contemplating ways to do it with multiple macros, i.e. passing the expression into a second macro which has a, b, c parameters where you can pass constants, and then I think into a third to force expression evaluation?
15:24jenatali: Lemme godbolt that and see if it works...
15:35dj-death: jenatali: wondering if you have an idea about this error : https://gitlab.freedesktop.org/mesa/mesa/-/jobs/84571667#L1851 15:35dj-death: jenatali: not supported by MSVC ? : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36647/diffs?commit_id=5395059a3ae406541ed19dafa862e9815be2f8ac#716e94477865f663d8648ee93e49310dd6802ab7_3868_4160 15:35jenatali: Looking
15:36jenatali: Yeah, statement expressions aren't supported, that's a GCC extension
15:37jenatali: Why is that a macro and not an inline function?
15:38dj-death: because of the vk_outarray...
15:38dj-death: but I guess I can rework that stuff
15:39jenatali: Seems you can just leak some implementation details of the VK_OUTARRAY macros into an inline function and it's not so bad
15:39jenatali: Better than doing all of that in macros IMO
15:39dj-death: the problem is that the structure defined in macros locally
15:40dj-death: but okay
15:40dj-death: will deal with it :)
15:40jenatali: Oof
15:40jenatali: Anonymous structs are fun...
15:40jenatali: If this was C++ you could just make it a template and pass the anonymous struct type...
15:41gfxstrand: alyssa: b2b32 can be whatever representation you want. It exists for shared memory which never leaves the GPU so as long as b2b1 can consume b2b32, you're good.
15:43zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36634 15:47alyssa: gfxstrand: Yes but if you define it any different from NIR, you don't match the constant folding which seems.. really suss.
15:47alyssa: In general I think we've nak'd NIR ALU opcodes that change definition based on the backend
15:47alyssa: I don't see why this is different
15:50alyssa: and also b2b32/b2b1 get emitted for non-shared mem stuff too
15:51alyssa: (seemingly including UBOs)
15:51alyssa: (and SSBOs)
16:12gfxstrand: alyssa: Uh... It shouldn't be for UBOs/SSBOs. That should be i2b/b2i
16:13gfxstrand: We do use b2b for shader/function_temp, though. But again, doesn't escape the GPU.
16:19alyssa: gfxstrand: Uhhhh
16:20alyssa: then lower_explicit_io seems to do the right thing but lower_io doesn't
16:21gfxstrand: Because `lower_io` shouldn't be used for these things?
16:21gfxstrand: and/or should be fixed
16:22alyssa: Hm. I definitely saw this in shaderdb yesterday, I'll try to figure out the root cause
16:22alyssa: but also - I stand behind my earlier/actual objection of 'NIR ALU opcodes with impl-defined behaviour scare me and we shouldn't be doing them'
16:23alyssa: If we genuinely want to change the encoding per-GPU, i'd rather have a shader option that makes lower_explicit_io & friends change what actual opcodes they generate
16:23alyssa: (could be wrapped up in helpers to centralize that logic)
16:24alyssa: but so far I haven't seen a good reason not to just do 0/~0 everywhere
17:57ahadi: Hi, I'm trying to implement cswr(context save and restore) for amdgpu .. I can see in their amdkfd driver amd make use of sendmsg(MSG_RTN_SAVE_WAVE) which seems to return an address for each wave to write it's gprs and other regisetrs to ? .. but only amdkfd allocate a cswr buffer for this .. I also saw that it has smth to do with MQD(m... queue descriptor ?) .. my quesion is ..
17:57ahadi: is this mes specific functionality and amdgpu and mesa doesn't/can't make use of this or it's smth I can make use of if I use debugfs to set priv registers ?