add SPIR-V types as builtins #35240

Migrated from https://github.com/ziglang/zig/issues/20550 for further discussion.

Feel free to discuss:

• Arguments for reviving assembly-backed types proposal. However I think you will have a hard time convincing me that it should require inline assembly to create types, when builtins are available instead.
• Exactly what set of new builtins should be introduced (1 with an enum? 1 builtin per type?)
• How this relates to #32032 and https://github.com/ziglang/zig/issues/4960

ATM all SPIR-V types can be created without writing a single assembly line except for OpTypeMatrix, opaque types and the niche vendor-specific types (which as i understand, can't be used without some assembly anyway).

We can perhaps introduce the @Opaque builtin to leave space for other targets that might benefit it.

constImage=@Opaque(.{.spirv_image=.{.usage=.{.sampled=u32},.format=.unknown,.dim=.@"2d",.depth=.unknown,.arrayed=false,.multisampled=false,.access=.unknown,}});

list of types to support (can be expanded later)

Other ways to express these types as @andrewrk mentioned, are:

• A general builtin for creating @SpirvTypes which would semantically be equal to @Opaque
• Individual builtins for each type: @Sampler, @Image, etc

Quick question on scope: does runtime array (OpTypeRuntimeArray) fit under 35240, or is it a separate proposal?

On master I can't find a way to declare a storage buffer whose length is set by the host at dispatch time without either baking N into the .spv (extern struct { data: [N]u32 }) or hand-writing inline asm. GLSL/HLSL both express this as a tail array in an SSBO, so users coming from those languages will reach for it.

I tried lowering it in the backend without a language change (side-table tracking "id has SPIR-V type *RuntimeArray<T> even though Zig sees *[*]T"), works for direct buf.*.data[i], but membership doesn't propagate through: function calls, locals, etc. Draft at #35179 if it's useful as a data point.

Ali's @Opaque example is shaped around handle-ish types (Image, Sampler), and I'm not sure a runtime array reads as opaque since you index into it. Just didn't want to assume it was covered.

Thanks for reminding out OpTypeRuntimeArray @quint.
It for sure does fit under this proposal. I'd suggest to close #35179 to continue further discussion here.

OpTypeRuntimeArray is clearly not an opaque but more like C's flexible arrays, which we have no way to explicitly distinguish with normal arrays and pointers. Therefor I see two ways to address it:

• Go with one of @Opaque+@RuntimeArray (perhaps it's useful for CBE as well?), Individual builtins or @SpirvType eww
• Implicitly emit it when the only legal usage is permitted. i.e. when we have a []T addrspace(.storage_buffer) last field inside a .uniform or .storage_buffer struct. Which I'm not really a fan of because first of all, slices/arrays != flexible-arrays as they clash in concept and ultimately blocks the user from having what they see and what they want.

@RuntimeArray or whatever it's called should have the ability to be indexed via the arr[x] syntax. elements can also be referenced &arr[x] and the .len field is also available.

Agreed on (1). My attempt at the implicit lowering broke in the cases you'd expect (function calls, locals, address of) because the backend was trying to reconstruct intent the language had already discarded. I'd expect an explicit builtin avoids that.

One note while we're here: runtime array, matrix, and the cooperative matrix, vector, and tensor families all share a shape. They are parameterized by element type plus indexable structure, not opaque. Might be worth treating @RuntimeArray as the first of that small set rather than a one off.

@RuntimeArray may confuse people who are not familiar with raw SPIR-V, perhaps something like @DynamicArray or @ExternalArray would be better fitting

Exactly what set of new builtins should be introduced (1 with an enum? 1 builtin per type?)

Strongly in favor of one builtin with an enum (@SpirvType) as it will neatly section off the SPIR-V extensions to the language, similar to the @CType proposal that @mlugg and I have been cooking up. Just as we've been thinking for std.c, std.gpu can contain helper functions that wrap @SpirvType to make constructing types less verbose.

(Side note: We should probably consider renaming std.gpu to std.spirv.)

Sorry for being super nit-picky but isn't "Type" in "@SpirvType" a little redundant, since based on zigs naming conventions functions that start with capital letters return types anyway?