00:38 airlied: woot tensor layout tests finally pass
10:26 eric_engestrom: zzyiwei: yeah, I have some medical stuff planned and I haven't figured out when I'll be able to make releases, that's why it's not in the calendar yet
10:30 eric_engestrom: I'll be out starting on oct 22 (maybe 21), and I'm not sure how long until I'm able to do things; medical leave is 6 weeks, but given that release work is not a full day of work and I do it from home (and if it's too painful to sit I can just stop and resume another day), I think I'll try to do it after 2 weeks and see how it goes
10:32 eric_engestrom: the branchpoint would normally be on the week before that, but I think there's no point branching and then just leaving it sitting for weeks, diverging for no reason, so I think I'll put the branchpoint 2 weeks after my surgery, ie. on Nov 5
10:32 eric_engestrom: thanks for prompting me to actually think it through 😊
10:32 eric_engestrom: I'll update the calendera with that
11:12 eric_engestrom: (changed my mind, I'll try to do it after one week, meaning 25.3 is pushed back by only 2 weeks)
11:12 eric_engestrom: release calendar update here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37435
11:12 eric_engestrom: distro packagers, let me know (on the MR) if pushing back 25.3 causes issues for you :)
11:12 K900: This will be cutting it very close for NixOS 25.11 end of November
11:12 K900: But I think we can make it work
11:15 eric_engestrom: K900: thanks for letting me know :)
11:15 eric_engestrom:should write down the schedules of all the distros
11:31 karolherbst: end of October? Nice, guess I need to focus on landing more stuff until then :D
14:27 dcbaker: eric_engestrom: Would you like help with the next release?
14:45 eric_engestrom: talked in private, dcbaker will take the 25.3 release cycle, and it will happen at the normal schedule (branchpoint on oct 15) :)
15:53 zzyiwei: eric_engestrom: Oh my...no worries about the next release. At least there's no urgency from our end. Please take good care of yourself and I hope you have a good recovery from your surgery!
15:55 eric_engestrom: zzyiwei: thank you ❤️ fyi the 25.3 release cycle will be managed by dcbaker so it will not be delayed and not require anything from me :)
18:12 simon-perretta-img: Aside from the opcode count increasing and the fact that most drivers don't seem to need/use vec widths other than 2..5/8/16 in NIR, are there any other obvious reasons I might be overlooking for not having more?
18:18 dj-death: simon-perretta-img: I think ALU instruction side
18:18 dj-death: simon-perretta-img: I tried to propose vec32 at some point
18:18 dj-death: alyssa: you might remember why
18:20 simon-perretta-img: Ah... yeah that makes sense for upping the limit
18:22 alyssa: swizzle[]
18:22 alyssa: swizzle[] is on every nir_alu_src and sized to maximum vec length
18:22 alyssa: if you double the vec length every ALU instruction bloats accordingly
18:23 alyssa: going 16->32 makes every ffma grow by 48 bytes
18:23 alyssa: if someone could make swizzle[] not worst-case allocated I wouldn't care
18:23 alyssa: but so far no takers on that
18:24 alyssa: (Part of me would like to just remove swizzles from NIR but unfortunately that's a nonstarter.)
18:24 simon-perretta-img: Fair
18:25 simon-perretta-img: Although in which case, I guess defining some of the ops between 5,8,16 without upping the limit probably wouldn't be too controversial?
18:25 alyssa: That'd probably be fine yeah
18:25 simon-perretta-img: There are some pco-specific reasons for wanting to, but also I imagine nir_opt_load_store_vectorize would benefit from it
18:25 alyssa: If you need vec7 or something, go for it
18:26 alyssa: but no vec32 unless it comes with a patch to shrink nir_alu_src
18:26 simon-perretta-img: Haha noted
18:27 simon-perretta-img:sweeps Rogue DMA ops that can output vec1024 under the rug
18:27 alyssa: Yeah no
18:28 alyssa: Find another solution, vec1024 is not your solution.
18:29 simon-perretta-img: Dw I wasn't being serious lol, the most that would ever realistically be needed is a vec18 or something
18:30 alyssa: dj-death: If we still need vec32, lmk. now that I'm team bleu I might be more motivated to try to wrestle swizzle[]
18:30 alyssa: ("Team Bleu? Is that French?" "Non it's just a cheesy joke")
18:31 HdkR: Variable length NIR instructions weeee
18:31 alyssa: HdkR: It's already var length
18:31 HdkR: Dang
18:31 alyssa: it's just an array-of-struct-of-arrays where the outer array is var and hence the inner cannot be
18:32 HdkR: ah
18:32 jenatali: Make swizzle into a pointer which can point after the sources to a second variable-length chunk of memory? Then null can be "no swizzle"
18:33 jenatali: Though that makes it hard to convert from no swizzle to have a swizzle
18:33 jenatali: Eh, can just reallocate the instruction with swizzles, not that bad probably
18:33 alyssa: That's going to slow down the common cases with e.g. simple non-identity swizzles
18:34 alyssa: lots of pointer chasing
18:34 alyssa: so would need minimally like a tagged pointer thing
18:34 jenatali: If it's to the same block of memory though it should be cache-friendly
18:34 alyssa: "inline small swizzle or pointer to large swizzle"
18:34 jenatali: Oh, for vec sizes < 8 yeah it could just be inline
18:35 dj-death: alyssa: it would help for load uniform blocks
18:35 dj-death: alyssa: right now we're limited at 16 * 4 = 64B
18:35 alyssa: dj-death: Is that enough of a reason to burn a month on this? :(
18:35 dj-death: alyssa: but we could load 128 with 32 items
18:35 dj-death: alyssa: really a month? :)
18:35 dj-death: alyssa: I thought that would be an afternoon for you
18:35 alyssa: Probably.
18:35 alyssa: No
18:36 alyssa: would need replumbing swizzles in 20 backends
18:36 dj-death: arg
18:36 jenatali: Does it really need to return an immediately ALU-able vec32 or could it return something else opaque that has smaller vectors extracted from it?
18:37 dj-death: well just do ours, throw it at perf CI and if the number look good...
18:37 dj-death: jenatali: could be opaque
18:37 alyssa: I like opaque tbh
18:37 dj-death: but then we don't get the vectorizer
18:37 jenatali: Hm, true
18:37 alyssa: We could standardize Big Vectors in nir, though
18:38 alyssa: common intrinsics to swizzle/extract/build? them
18:38 jenatali: Seems reasonable to me
18:38 alyssa: makes vectorizer messier but then simplifies everything else
18:39 alyssa: and then ideally we would make spirv-to-nir handle vec16 as big vec
18:39 jenatali: At that point I wonder if you could drop ALU vec size back down? Probably not though
18:39 alyssa: so we can shrink swizzle[] back down to 8
18:39 alyssa: jenatali: Should be able to. No Mesa driver does vec16 ALU in hardware, it's just there because of OpenCL
18:40 jenatali: Oh cool, I'd assumed someone could do some 8x16 or something
18:40 alyssa: Midgard is capable of doing vec16 alu but it's not wired up and I'm nak'ing anyone who tries.
18:40 simon-perretta-img: I imagine that opaque approach could also be nice for being able to do things like indexable regs without having to use scratch mem
18:40 jenatali: :P
18:40 alyssa: as the original author of an unmainted compiler, I retain NAK rights
18:40 alyssa: :p
18:40 alyssa: simon-perretta-img: we already have that lol
18:40 alyssa: load_reg/store_reg
18:41 anholt: plug: for anyone looking at indexable regs, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37245 may help you make better choices about what to leave as regs.
18:42 simon-perretta-img: Huh, TIL
18:43 alyssa: anholt: nir patch is a-b me, not sure you're going to get a good review on that
18:43 jenatali: alyssa: One random thought - DXIL is actually adding arbitrary length vectors, so if there were intrinsics to operate on NIR "big vec" to do basic things like add/sub/mul without swizzles, I could translate those and get more compact shaders
18:43 alyssa: but feel free to merge
18:43 alyssa: jenatali: Yeah there's really two ways we could do this
18:44 anholt: alyssa: I've been thinking about taking a stab at tuning someone else's driver about vars-to-scratch to increase interest. but, also, I need to sort out this copy prop vars masking because that's so much bigger of a deal and affects the same area.
18:44 alyssa: jenatali: One is "big vec" is an opaque handle in NIR (like how nir reg works) and you need to do an extract/swizzle intrinsic to pass it to ALU
18:45 alyssa: The other is having actual vec128 (or whatever) in NIR, and you can pass it into nir_alu_src[], but it's automatically an identity swizzle (and you need a special intrinsic to swizzle non-identity)
18:45 alyssa: Both of these are ugly but could be made to work
18:45 jenatali: Yeah I like that latter one, that seems useful
18:47 alyssa: Both seem like a /lot/ of work to fix up all the producers. Idk
18:48 alyssa: The latter has the benefit that it can at least be done incrementally with a nir_validate check
18:48 alyssa: (and gives a path to shrinking all the way down to vec4 swizzles if that ends up faster.)
18:49 alyssa: anholt: Yeah that's fair
18:50 simon-perretta-img: Is the reasoning behind swizzle being integrated into nir_alu_src rather than e.g. a separate swizzle op, to save a level of indirection?
18:50 alyssa: historical reasons basically
18:50 simon-perretta-img: Mm, fair
18:51 alyssa: but see also "we have 20 backends which means any nontrivial change to core NIR data structures costs 10s of 1000s of dollars of engineering time"
18:53 alyssa: what I like about the latter approach is that only NIR producers really get changed
18:54 alyssa: and only producers that mess with swizzle[] manually, pure nir_builder stuff doesn't change
19:19 ukleinek: is it better to report nouveau bugs on the ML or in the bug tracker?
19:38 ukleinek: Context is https://lore.kernel.org/dri-devel/E79B534D-6630-4AF3-950D-2391CDABCE16.1@smtp-inbound1.duck.com/
19:45 gfxstrand: How big is an image descriptor on AMD?
19:46 pendingchaos: images are 32 bytes, samplers and buffers are 16 bytes
19:46 pendingchaos: msaa images with fmask are two image descriptors
19:47 gfxstrand: Okay, that explains the sampled image descriptor size
20:37 Kayden: what happened here?
20:37 Kayden: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37440
20:38 Kayden: windows-msvc: fatal error C1083: Cannot open include file: 'util/format/u_format_gen.h': No such file or directory
20:38 gfxstrand: Weird
20:38 Kayden: no changes related to that...
20:38 zmike: I've seen that before
20:38 gfxstrand: Maybe a meson dep is missing and someone lost the race?
20:38 zmike: it's a build system race condition
20:38 zmike: there's a lot of them
20:38 Kayden: ah
20:39 Kayden: I'll try it again
20:42 anholt: Kayden: landed a fix (I hope) https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37316
20:43 Kayden: anholt: thank you!
20:44 anholt: tbh I wish we could convince meson to put deps on mesutil finishing before moving on to anything else. u_format generation dep correctness is just sisyphean.
20:45 gfxstrand: Yeah, generated headers are just cursed from a build system POV.
20:45 gfxstrand: We have some generated headers for Vulkan as well and eesh.
22:19 anholt: ooh, https://reviews.llvm.org/D83032 looks like it could automated detect missing C/C++ header deps for the builds we do in CI.
22:19 anholt: someone should do something about that.
22:20 anholt: (gives me a distressing number of plausible-looking failures on my build)
22:27 mattst88: I haven't tested it myself, but another gentoo dev has a script that finds missing deps in build.ninja files
22:27 mattst88: https://codeberg.org/eli-schwartz/eschwartz-dev-scripts/src/branch/master/install-qa-check.d/50ninja-missingdeps
22:27 mattst88: it's written as a QA-check for portage, but should be trivially modifiable to standalone
22:28 mattst88: he said he's wanted to add it or something like it to Mesa's CI, but hasn't had a chance yet
22:39 elibrokeit: eric_engestrom previously suggested I add that script to the mesa CI, yeah. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29115#note_2472998
22:39 elibrokeit: I just never found the time to do it yet. :/