05:54 mareko: alyssa: it would make backends more complex
07:19 mareko: anholt: reviewed
07:20 mareko: alyssa: I think the main reason we have vec8 and vec16 is because some hw (e.g. AMD) has bit_size=32 vec8 and vec16 loads in the ISA
07:26 glehmann: I think vec8/16 was originally added for CL
07:27 glehmann: but yes they are nice for amd,
08:12 tzimmermann: jfalempe, thanks for reviewing the client-free series. could you please also take a look at patch 4?
08:13 jfalempe: tzimmermann: Sure, I'll take a look.
08:14 tzimmermann: thanks
11:04 mlankhorst: airlied: did you create a new version of the memcg accounting series yet?
14:04 alyssa: Kayden: right..
14:04 alyssa: mareko: I mean, maybe a little bit
14:05 alyssa: Intel has vec32 loads but I'd really like a solution that doesn't bloat nir_alu_src::swizzle[] even worse
14:05 alyssa: (IIRC)
14:09 alyssa: (deleting swizzle[] will never not be tempting, but, um.)
14:17 mareko: what do folks think about adding a resource type to image_load etc. to select between image binding, image bindless, image deref, and newly also texture binding, texture bindless, and texture deref for image opcodes
14:19 glehmann: alyssa: isn't 64bit vec16 enough for intel?
14:58 alyssa: glehmann: hmm, maybe yeah
16:22 tomeu: dcbaker: hi! what do you think of merging https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36699 in time for 25.3?
16:23 tomeu: tomeu: the kernel part is also ready, IMO
16:27 dcbaker: tomeu: I'm not going to be able to branch for a few hours (probably around 1400 PDT)
16:28 gfxstrand: danylo: Care to give !37803 one more read? It's changed quite a bit since your RB.
16:28 gfxstrand: Ideally, I'd like to land it today.
16:28 dcbaker: tomeu: I don't have a problem with it going in first, or I can pull the commits into the -rc2 if we just miss it and you think it's ready in a couple of days
16:28 dcbaker: I'm not sure that I can give a meaningful review or ack though
16:29 danylo: gfxstrand ok
16:29 tomeu: dcbaker: I personally think it's ready for merging, it's just that I don't know when we will get more comments, if any...
16:30 tomeu: because there aren't not that many people yet contributing to the NPU drivers
16:31 dcbaker: AFAICT, you are the expert on NPU drivers :D
16:32 dcbaker: so from my point of view if you want it in and think it's ready send it to marge, it'll be 5 hours before I start the branching process at the earliest
16:56 alyssa: jenatali1: When do we get to drop support for MSVC older than 17.9?
16:57 alyssa: I want typeof in common code >:)
16:57 jenatali1: Fine by me
16:58 jenatali1: We track MSVC releases pretty rapidly
17:01 alyssa: Oh, cool
17:01 alyssa: because we added the workaround code not too long ago
17:01 alyssa: Oh it's autodesk that wants old MSVC..
17:01 jenatali1: Yeah I'm not holding you back there
17:01 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36682 great.
17:02 alyssa: meh, after the branch point seems like a good a time as any to bump the req then
17:05 alyssa: for context I want to make util_dynarray_append infer the type
17:05 alyssa: which should be pretty trivial with typeof
17:05 jenatali1: That sounds great
17:05 alyssa: and I can write the coccinelle obviously
17:06 alyssa: but, compiler support
17:06 jenatali1: Yeah. My only requirement is MSVC but it can be fully up-to-date, I don't need older compilers
17:16 alyssa: *nod*
18:52 zmike: eric_engestrom: how goes the branching
18:56 eric_engestrom: zmike: dcbaker is the manager for the 25.3 release cycle :)
19:08 zmike: aha
19:18 austriancoder: tomeu: no clang-format for ethos? :)
19:18 tomeu: there should be!
19:21 tomeu: austriancoder: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36699/diffs#diff-content-294d957bceeee33b81f256060d081adff04f09d8
19:24 austriancoder: tomeu: ahh.. it does not apply for mlw_codec/
19:25 tomeu: right, I would prefer to not touch that code and just bring updates from the downstream compiler periodically
19:26 austriancoder: sure
19:26 tomeu: being only the weight encoder, developed against a clear spec, I don't expect having to fix it often (and I haven't needed to make any change so far)
19:29 austriancoder: tomeu: lgtm - time to merge it :)
19:29 alyssa: tomeu: Uh... how on earth did an implicit sync uapi get merged in 2025
19:30 tomeu: because of the ML APIs being that simple that it's good enough
19:31 alyssa: wild
21:05 airlied: mlankhorst: I should now that rc1 is out, I should even start applying patches from it