Open ArielG-NV opened 3 months ago
How does HLSL/dxc handle texture buffer types that exceeds 4 floats?
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.
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)...
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.
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 fromtexture_buffer
location 0.