07:30 mlankhorst: What's the difference between drm accel and normal drm drivers?
08:21 airlied: mlankhorst: accel drivers don't expose kms and are for non gpu devices
08:21 airlied: otherwise not much, technical solution to a social problem :-P
08:21 airlied: but also userspace GPU probing won't hit them
08:24 airlied: https://docs.kernel.org/accel/introduction.html
11:33 alyssa: 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:33 alyssa: 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:34 alyssa: (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:21 mlankhorst: Yeah curious what a non-accelerating non-modeset device would look like
12:22 daniels: mlankhorst: vgem
12:30 dolphin: 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:30 Leftmost: 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:46 jenatali: alyssa: ack, I don't see a good way around that one either
12:47 alyssa: jenatali: k, will do that when i'm in the office
12:47 alyssa: thanks
12:48 alyssa: 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:49 alyssa: [Folding stuff like `iand(a, ior(b, c))` into `lut3(a, b, c, 0xsomething)`
13:02 Company: 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:40 lucaceresoli: Hello, I am a drm-misc committer, but only even committed to drm-misc-next. Can I commit to drm-misc-fixes too?
13:40 mlankhorst: Sure
13:40 lucaceresoli: mlankhorst: ah, thanks! -- Just wanted to make extra sure I'm not committing where not supposed to :)
14:17 karolherbst: Do we have a nir pass that can properly optimize barriers like this? https://gist.githubusercontent.com/karolherbst/6b7317eab671b2240a9cd0c1104e9098/raw/ef4f6131a589a4dd279246124a7e9daced96a886/gistfile1.txt
14:17 karolherbst: most of those barriers seems uneccesary
14:19 dj-death: karolherbst: maybe nir_opt_acquire_release_barriers ?
14:19 pendingchaos: karolherbst: there's https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36602/diffs?commit_id=2a666a8908ba238bfbf4b8b46c29f55bca974f57 for shared access
14:20 karolherbst: yeah let me try that commit
14:21 karolherbst: dj-death: hacking on nir_opt_acquire_release_barriers was kinda what I'd try to do when there is nothing else
14:22 pendingchaos: could maybe use ACCESS_COHERENT for ssbo/image instead of make-available if you're okay losing the memory scope
14:22 pendingchaos: I'm not 100% sure, but make-visible might be slightly different from ACCESS_COHERENT
14:22 pendingchaos: (make-visible might make future accesses to the same location visible, not just ACCESS_COHERENT's behaviour of only affecting the first access)
14:22 karolherbst: ohh it also does non atomics mhhh
14:22 karolherbst: yeah.. only really caring about shared memory atm
14:24 karolherbst: pendingchaos: yeah, your commit works perfectly
14:24 karolherbst: I have shaders I want to beat nvidia at, and this problem solved reduces the gap by 12 pp :D
14:25 karolherbst: but let me see if nir_opt_acquire_release_barriers also helps
14:28 karolherbst: yeah so nir_opt_acquire_release_barriers doesn't seem to do anything
14:31 karolherbst: well needs an atomic present to operate mhh
15:07 alyssa: Company: Uh yeah no we're not dealing with that heh
15:09 Company: 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:10 alyssa: 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:12 Company: I'd only do that with #ifdef MSVC, but yeah
15:24 jenatali: 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:24 jenatali: Lemme godbolt that and see if it works...
15:35 dj-death: jenatali: wondering if you have an idea about this error : https://gitlab.freedesktop.org/mesa/mesa/-/jobs/84571667#L1851
15:35 dj-death: jenatali: not supported by MSVC ? : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36647/diffs?commit_id=5395059a3ae406541ed19dafa862e9815be2f8ac#716e94477865f663d8648ee93e49310dd6802ab7_3868_4160
15:35 jenatali: Looking
15:36 jenatali: Yeah, statement expressions aren't supported, that's a GCC extension
15:37 jenatali: Why is that a macro and not an inline function?
15:38 dj-death: because of the vk_outarray...
15:38 dj-death: but I guess I can rework that stuff
15:39 jenatali: Seems you can just leak some implementation details of the VK_OUTARRAY macros into an inline function and it's not so bad
15:39 jenatali: Better than doing all of that in macros IMO
15:39 dj-death: the problem is that the structure defined in macros locally
15:40 dj-death: but okay
15:40 dj-death: will deal with it :)
15:40 jenatali: Oof
15:40 jenatali: Anonymous structs are fun...
15:40 jenatali: If this was C++ you could just make it a template and pass the anonymous struct type...
15:41 gfxstrand: 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:43 zmike: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36634
15:47 alyssa: gfxstrand: Yes but if you define it any different from NIR, you don't match the constant folding which seems.. really suss.
15:47 alyssa: In general I think we've nak'd NIR ALU opcodes that change definition based on the backend
15:47 alyssa: I don't see why this is different
15:50 alyssa: and also b2b32/b2b1 get emitted for non-shared mem stuff too
15:51 alyssa: (seemingly including UBOs)
15:51 alyssa: (and SSBOs)
16:12 gfxstrand: alyssa: Uh... It shouldn't be for UBOs/SSBOs. That should be i2b/b2i
16:13 gfxstrand: We do use b2b for shader/function_temp, though. But again, doesn't escape the GPU.
16:19 alyssa: gfxstrand: Uhhhh
16:20 alyssa: then lower_explicit_io seems to do the right thing but lower_io doesn't
16:21 gfxstrand: Because `lower_io` shouldn't be used for these things?
16:21 gfxstrand: and/or should be fixed
16:22 alyssa: Hm. I definitely saw this in shaderdb yesterday, I'll try to figure out the root cause
16:22 alyssa: 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:23 alyssa: 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:23 alyssa: (could be wrapped up in helpers to centralize that logic)
16:24 alyssa: but so far I haven't seen a good reason not to just do 0/~0 everywhere
17:57 ahadi: 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:57 ahadi: 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 ?
20:00 zzyiwei: Hi, does anyone know when is the next planned feature release? There's no 25.3 on https://docs.mesa3d.org/release-calendar.html yet.
20:05 dcbaker: eric_engestrom: ^
21:07 pzanoni: how often does the mesa gitlab CI update vk-gl-cts?
21:31 zmike: on releases
21:31 zmike: just mark the fails and go for it