`LiteFX::Rendering::DescriptorSet`¶

Defines a set of descriptors.

Synopsis¶

Declared in <litefx/rendering.hpp>

template<
    typename TBuffer,
    typename TImage,
    typename TSampler,
    typename TAccelerationStructure>
requires std::derived_from<TBuffer, IBuffer> &&
        std::derived_from<TSampler, ISampler> &&
        std::derived_from<TImage, IImage> &&
        std::derived_from<TAccelerationStructure, IAccelerationStructure>
class DescriptorSet
    : public IDescriptorSet

Description¶

Descriptors can be grouped into multiple descriptor sets. It is generally a good practice to group descriptors based on the frequency of the updates they receive. For example, it typically makes sense to store the camera buffer in a descriptor set, since it only needs to be updated once per frame for each camera, whilst the object or material data should be stored in separate descriptor sets, that are possibly updated before each draw call. However, other scenarios employing multiple descriptor sets are also possible.

From a shader perspective, a descriptor set is identified by a set (GLSL) or space (HLSL), whilst a descriptor is addressed by a binding (GLSL) or register (HLSL). Descriptor sets are read from GPU-visible memory, depending on how they are bound during the current draw call.

From a CPU perspective, think of a descriptor set as an array of pointers to different buffers (i.e. descriptors) for the shader. A descriptor can be bound to a set by calling DescriptorSet::update. Note that this does not automatically ensure, that the buffer memory is visible for the GPU. Instead, a buffer may also require a transfer into GPU visible memory, depending on the ResourceHeap. However, as long as a descriptor within a set is mapped to a buffer, modifying this buffer also reflects the change to the shader, without requiring to update the descriptor, similarly to how modifying the object behind a pointer does not require the pointer to change.

Note, that there might be multiple descriptor set instances of the same DescriptorSetLayout, pointing to different IBuffer instances, depending on the number of frames in flight. Since multiple frames can be computed concurrently, it is important to properly synchronize descriptor set updates. Generally, there are three strategies to choose from, that you can implement or mix in custom flavors, depending on your use case:

Naive:: The naive approach most closely matches earlier graphics API concepts. Create one buffer per descriptor and synchronize frames. This basically means that each back buffer swap is synchronized to wait for the graphics pipeline. This way, writing to a buffer ensures, that it is only read within the frame of reference and modifying it does not interfere with other frames. This strategy is memory efficient, but may cause the GPU to stall. It may, however be a valid strategy, for data that is only written once or very infrequently.
Array of Buffers:: The helper methods for creating and updating constant buffers are able to create buffer arrays. Those arrays can be used to create a buffer for each frame in flight. When binding a buffer to a descriptor, it is possible to bind only one element of the array. This way, each frame has its own buffer and does not interfere with other buffer writes.
Ring-Buffer:: The most efficient (yet not always applicable) approach involves creating one large buffer array, that is bound to multiple descriptor sets. This ensures that the buffer memory stays contiguous and does not get fragmented. However, this requires to know upfront, how many buffers are required for each descriptor, which might not always be possible. Thus another flavor of using this technique involves a creating a large enough descriptor array and updating the descriptor set with an increasing array element for each object as a ring-buffer. As long as there are enough elements in the buffer, so that no second update interferes with a buffer write in an earlier frame, this method provides the most efficient approach. However, it may be hard or impossible to determine the ideal size of the ring-buffer upfront.

Note that samplers, textures and input attachments currently do not support array binding, since they are typically only updated once or require pipeline synchronization anyway.

Base Classes¶

Name	Description
`IDescriptorSet`	The interface for a descriptor set.

Type Aliases¶

Name
`acceleration_structure_type`
`buffer_type`
`image_type`
`sampler_type`

Member Functions¶

Name	Description
`~DescriptorSet` [destructor] [virtual]	Destructor
`bindToHeap`	`bindToHeap` overloads
`globalHeapAllocation` [virtual]	Returns the allocation information for the descriptor set in the global descriptor heap indicated by `heapType.`
`update`	`update` overloads

Using Declarations¶

Name
`bindToHeap`
`update`

Protected Member Functions¶

Name	Description
`DescriptorSet` [constructor]	Constructors
`operator=`	Assignment operators

Template Parameters¶

Name	Description
TBuffer	The type of the buffer interface. Must inherit from `IBuffer`.
TImage	The type of the image interface. Must inherit from `IImage`.
TSampler	The type of the sampler interface. Must inherit from `ISampler`.
TAccelerationStructure	The type of the acceleration structure interface. Must inherit from `IAccelerationStructure`.

Derived Classes¶

Name	Description
`DirectX12DescriptorSet`	Implements a DirectX 12 `DescriptorSet`.
`VulkanDescriptorSet`	Implements a Vulkan `DescriptorSet`.

LiteFX::Rendering::DescriptorSet¶