Expand description
Generating accesses to ByteAddressBuffer contents.
Naga IR globals in the Storage address space are rendered as
ByteAddressBuffers or RWByteAddressBuffers in HLSL. These
buffers don’t have HLSL types (structs, arrays, etc.); instead, they
are just raw blocks of bytes, with methods to load and store values of
specific types at particular byte offsets. This means that Naga must
translate chains of Access and AccessIndex expressions into
HLSL expressions that compute byte offsets into the buffer.
To generate code for a Storage access:
-
Call
Writer::fill_access_chainon the expression referring to the value. This populatesWriter::temp_access_chainwith the appropriate byte offset calculations, as a vector ofSubAccessvalues. -
Call
Writer::write_storage_addressto emit an HLSL expression for a given slice ofSubAccessvalues.
Naga IR expressions can operate on composite values of any type, but
ByteAddressBuffer and RWByteAddressBuffer have only a fixed
set of Load and Store methods, to access one through four
consecutive 32-bit values. To synthesize a Naga access, you can
initialize temp_access_chain to refer to the composite, and then
temporarily push and pop additional steps on
Writer::temp_access_chain to generate accesses to the individual
elements/members.
The temp_access_chain field is a member of Writer solely to
allow re-use of the Vec’s dynamic allocation. Its value is no longer
needed once HLSL for the access has been generated.
Note about DXC and Load/Store functions:
DXC’s HLSL has a generic Load and Store function for ByteAddressBuffer and
RWByteAddressBuffer. This is not available in FXC’s HLSL, so we use
it only for types that are only available in DXC. Notably 64 and 16 bit types.
FXC’s HLSL has functions Load, Load2, Load3, and Load4 and Store, Store2, Store3, Store4. This loads/stores a vector of length 1, 2, 3, or 4. We use that for 32bit types, bitcasting to the correct type if necessary.
Enums§
- One step in accessing a
Storageglobal’s component or element.