shader-slang / slang

Making it easier to work with shaders
MIT License
2.05k stars 175 forks source link

SPIRV and Metal `TextureBufferType` support #4435

Open ArielG-NV opened 3 months ago

ArielG-NV commented 3 months ago

TextureBufferType currently has no way to emit with the SPIRV backend, the intrinsic is unimplemented.

Metal requires all texture_buffer objects to be primitive types only, <uint>, <float>, etc. Metal requires a legalization pass to solve this problem. This legalization pass should decode a struct and accesses into offsets from texture_buffer location 0.

csyonghe commented 3 months ago

How does HLSL/dxc handle texture buffer types that exceeds 4 floats?

csyonghe commented 3 months ago

Looking at the HLSL spec, it seems a tbuffer is treated as a u32 format texture, and loads from the buffer is lowered into texture fetches + bit casts. Seems like a lowering pass is in order to support this on spirv and metal. I doubt it offers any actual benefit over the use of a StructuredBuffer.

ArielG-NV commented 3 months ago

I doubt it offers any actual benefit over the use of a StructuredBuffer.

tbuffer predates StructuredBuffer, likely is only kept around for legacy reasons, although tbuffer does use cbuffer packing rules from what I gather, so that may make a difference (for the worse in some senarios)...

ArielG-NV commented 3 months ago

How does HLSL/dxc handle texture buffer types that exceeds 4 floats?

likely as you said here: "loads from the buffer is lowered into texture fetches + bit casts"

the logic should be reasonably simple regardless since Slang knows the offset of every field, therefore meaning all accesses are fairly obvious in byte offset.