08:45 phasta: Could someone review this pls? https://lore.kernel.org/dri-devel/20260625104903.1713213-2-phasta@kernel.org/
12:54 mlankhorst: Do updates to MAINTAINERS go to -fixes or -next?
12:57 glehmann: has anyone every looked into implementing VK_EXT_shader_long_vector?
12:58 glehmann: tbh it sounds ridiculous to me, and NIR is in no shape to support vec1024
12:58 glehmann: but apparently DX12 SM6.9 requires it
13:01 glehmann: maybe it's time to remove alu source swizzles from NIR
13:01 glehmann: but even then there are so many fixed size arrays to worry about
13:03 jenatali: I don't realistically expect long vectors to actually do anything interesting except for coopvec cases
13:03 karolherbst: glehmann: maybe should just scalarize it inside vtn? Though nvidia has boolean coop matrix operations where you can operate on a 16x8x256 matrix :') Not sure what other purposes there are for VK_EXT_shader_long_vector?
13:03 jenatali: Could be possible to just "scalarize" down to smaller vectors except for coopvec ops, with dedicated "assemble" intriniscs to merge them together?
13:04 glehmann: ye lowering them in vtn is probably the only realistic option we have rn
13:05 glehmann: I don't really understand coopvec either
13:05 jenatali: Took me forever to wrap my head around it
13:05 glehmann: or well, I don't understand what exactly is expected on the compiler side
13:05 glehmann: there seems to be a ton of hand waving involved
13:06 glehmann: like when you are actually hitting fast paths
13:06 jenatali: My understanding is it's SIMT programming model of cooperative matrix, i.e. using the matrix hardware with an implicit (vec x thread) that turns it into a matrix shape
13:07 jenatali: With the actual matrix then being a 3D matrix that's fed into the op in a 2D slice at a time. Or something like that
13:10 glehmann: I don't really see the benefits compared to coop matrix
13:10 phasta: mlankhorst: I always push them into -next. Can't think of a reason where -fixes would be appropriate
13:20 alyssa: glehmann: oh is that public now?
13:20 alyssa: I've been scared of it for ages
13:21 alyssa: I think konstantin and cmarcelo had plans maybe
13:22 mareko: it looks like coopvec needs specialized HW to be efficient, it seems to be just per-invocation vector_reg1 = matrix_from_memory * vector_reg0
13:23 mareko: + vector_reg2, or something like that
13:24 mareko: the benefit seems to be that no registers are needed to hold the matrix, instead the MMA op does the matrix load
13:25 karolherbst: alyssa: same tbh 🙃
13:26 karolherbst: I'm fine with having long vectors as glsl_types, but not sure it makes any sense to have them as actual nir defs, dunno
13:40 alyssa: glehmann: it's never been clear what we could replace swizzles /with/ that would actually be.. better
13:42 glehmann: a dedicated swizzle instruction would already be better
13:43 glehmann: because then alu sources are explicitly sized, and don't depend on the opcode
13:44 glehmann: so we wouldn't need one nir_op_fdot per size
13:44 alyssa: yes.. unclear what perf impacts that would have
13:44 glehmann: we would save a bit of memory for fully scalar alu code
13:45 alyssa: Yeah. But cost a bunch more memory for any load/texture/etc and it is very much not clear what's a win
13:45 alyssa: It's probably still the right direction to go, though
13:50 glehmann: nir_op_vec* should probably also be its own instruction type
13:50 alyssa: Yeah
13:51 alyssa: So then the next question is, should we try to unify nir_op_vec* and swizzles into a common new instr type?
13:51 alyssa: And if so - do we also try to unify packs and unpacks into that type?
13:52 alyssa: The logical extreme is a nir instr type that takes N sources and a selector for each byte of the destination from a byte of a source, which would subsume swizzle + vec + pack + unpack in full generality (equivalent to nvidia's permute instruction).
13:53 alyssa: But I.. don't think we actually want that in NIR for a bunch of reasons.
13:55 glehmann: imo we should have 1. swizzle instr type with one source and a variable lenghth uint16_t swizzle, 2. create vec instr type with a variable length array of 1 component sources, 3. bitcast instr type (or intrinsic) with one source and src_components * src_bit_size == dest_components * dest_bit_size
13:57 alyssa: That's probably reasonable
13:58 alyssa: I'm just very aware that sizeof(nir_instr) == 32
14:02 alyssa: and.. maybe it's ok? idk
14:03 glehmann: we also have an swizzle overhead of 32 byte for a binary alu instr at the moment
14:03 alyssa: Yep
14:04 alyssa: Don't get me wrong- I'm not opposed, I'd love to see it happen
14:04 alyssa: There's just enough open questions that I never started typing
14:05 glehmann: not sure where you would even start, the frontends or the backends
14:06 alyssa: personally I've always started with backends
14:06 alyssa: mostly because there's a lot more of them
14:06 alyssa: and the average quality is a lot lower
14:11 alyssa: and I'd volunteer to help but I am still recovering from nir_register burnout
14:12 alyssa: I guess I can commit to doing review + whatever changes are needed to backends I maintain
14:12 karolherbst: how do we deal with a algebraic opts that depend on vec and pack instructions?
14:12 alyssa: cry
14:12 glehmann: we can change nir_search to support those instruction types
14:13 karolherbst: I wonder...
14:13 karolherbst: maybe we want to do this first
14:14 karolherbst: but not sure..
14:14 glehmann: We also don't have to do everything at once
14:14 karolherbst: yeah I'm trying to come up with good algebraic transformation that would depend on non alu ones
14:14 karolherbst: f2f16(tex) would be a classic, but that's also going to be pain to support, so probs not
14:15 glehmann: we already have a pass for that...
14:15 karolherbst: oh, we do?
14:15 karolherbst: backend or common?
14:16 glehmann: nir_opt_16bit_tex_image
14:16 glehmann: first NIR pass I ever worked on
14:16 karolherbst: ahh.. it's in mediump, no wonder I never saw it
14:17 karolherbst: we support two rounding modes even
14:18 glehmann: AMD supports none :D
14:18 karolherbst: "fun"
14:18 karolherbst: well rounding is explicit, so it's either zero or nearest.. probably easy to support, but we can't represent it atm...
14:18 karolherbst: but anyway...
14:19 glehmann: (or more exactly, fp32 textures use rtz, but fixed point textures go straight to fp16 with rtne)
14:19 karolherbst: I'd love to see more flexibility in nir_opt_algebraic, but not sure I'd ever had the need to operate on non alu
14:20 glehmann: I don't think we want the complexity. Some intrinsics might be useful, but for sure not all of them
14:54 alyssa: glehmann: anyways you now see why nobody's done this yet ;)
14:55 glehmann: well I already knew that it would be a ton of work
14:56 alyssa: =D