Graphics Reference
In-Depth Information
to be used at the same time. Figure 2.18 shows graphically how a buffer can be referenced
simultaneously by more than one resource view.
HLSL append/consume buffer resource objects. Once the buffers have been created
with the appropriate resource views, they can be bound to the pipeline and used from
within a shader program. The syntax for declaring append and consume buffers is provided
in Listing 2.15.
struct Particle
{
f!oat3 position;
float3 velocity;
float time;
};
AppendStructuredBuffer<Particle> NewSimulationState : register( u0 );
ConsumeStructuredBuffer<Particle> CurrentSimulationState : register( ul );
Listing 2.15. The declaration of append and consume buffers in HLSL.
Probably the next most frequently used methods for append and consume buffers
are the actual append() and consume() resource object methods. These operate as would
be expected, with the desired value being returned in the case of consume(), and being
pushed into the buffer in the case of append(). We can also see in the listing that the
GetDimensions() method is also available on the append and consume buffers. This can
be used from within HLSL to read the number of elements that are available in the buffer,
and to subsequently ensure that data is not appended to the buffer too many times, which
would result in loss of the additional data.
Byte Address Buffers
Still another variation of the buffer resource type is available. The byte address buffer
provides a much more raw memory block for the HLSL program to manipulate. Instead of
using a fixed structure size to determine where to index within the resource, a byte address
buffer simply takes a byte offset from the beginning of the resource and returns the four
bytes that begin at that offset as a 32-bit unsigned integer. Since the returned data is always
retrieved in four-byte increments, the requested offset addresses must also be a multiple of
four. However, other than this minimum size requirement, the HLSL program is allowed
to manipulate the resource memory as it sees fit. The returned unsigned integer values can
also be reinterpreted as other data types by some of the type-converting intrinsic functions.
It may not be immediately obvious what the utility of such a buffer would be. Since
the HLSL program can interpret and manipulate memory contents as it sees fit, there is
no requirement for each data record to be the same length, as we have seen in the various
Search WWH ::




Custom Search