BLAS Build and Update

2024-01-08T00:00:00+00:00

What’s the deal with BLASes?

A BLAS is the local accelleration structures required for raytracing stuff using modern graphic APIs.

Basically you will need BLASes that represent mesh instances in scene, and add them all to a TLAS.

It’s easy to build a BLAS right after mesh loading, but still there a few things to consider :

BLAS need to separate opaque vs. non-opaques batchs
Dynamic geometry needs to update BLAS when it changes

We end up having a different strategy for static and opaque geometries :

Static Geometry

These geometries do not change often. Ideally we would like to build them once, share them as much as possible and destroy them when they are no more needed (no more instance using it).

These geometries are build with the FAST_TRACE flag only because we will never update them.

When building BLAS right after loading a mesh, it would be convenient to know in advance which parts are using alphablend or alphatest, but it’s also convenient to be able to use the same mesh with different material instances.

In vgframework, the mesh models are cooked without knowledge of the materials used and it’s up to every MeshModelInstance to choose the materials to use.

A MeshModel holds a map of its different BLAses variants. A key is built from the materials used by the graphic instance so that the same configuration (e.g. Opaque/Opaque/Alphablend) return the same BLAS and increase its RefCount or create it when needed.

Examples

3 cubes using the same opaque material

The 3 cube are sharing the same BLAS.

3 cubes using different opaque materials

The 3 cube are still sharing the same BLAS, because new materials are still opaque.

3 cubes using different materials but one is alphablend

The 2 opaque cubes are sharing the same BLAS made of one opaque batch while the last one is using itw own BLAS made of 1 non-opaque batch.

Dynamic geometry

As opposed to static geometries, dynamic geometries change every frame (e.g. skinned meshes) so we build them with the FAST_BUILD and ALLOW_UPDATE flags to reduce the cost of this update.

Skinning

During views culling, the skins instances visible in any view (incl. shadow casting lights POV) are added to a lock-free list using atomics.

The skinning for all these instances is done once (per LOD) in a single vertex buffer. When updating BLAS their offset in this buffer is used as with a regular Vertex Buffer excepted here the buffer is the output of skinning compute shader.

Dynamic geometries BLASes are not shared with this design, but it could be useful in the future if animation instancing is needed (e.g. to render crowds).

Bindless Table

2024-01-08T00:00:00+00:00

I’ve been experimenting with Bindless rendering using DirectX12 & Vulkan APIs recently.

Here is the layout I currently use for bindless table :

Table Layout

Type	Range	Space	Binding
Texture1D (float4)	[0 ..16383]	10	0
Texture2D (float4)	[0 ..16383]	20	0
Texture2D (uint)	[0 ..16383]	21	0
Texture3D (float4)	[0 ..16383]	30	0
ByteAddressBuffer	[16384..32767]	-	1
RWTexture1D	[32768..40959]	210	2
RWTexture2D	[32768..40959]	220	2
RWTexture3D	[32768..40959]	230	2
RWByteAddressBuffer	[40960..49151]	200	3
RaytracingAccelerationStructure	[49152..49167]	-	4

Notes:

The DirectX12 version uses the Space value to alias the different types of resource view formats
The Vulkan version uses the Binding value to differenciate between the different types of resource views
Several TLAS can be used if multiple views are used. The current value implies a maximum of 16 views using RayTracing.

In case you want more details, check the file table.hlsi in the repo.

Reserved Slots

By default, a new resource requiring a view will be created allocating a new bindless handle in these ranges, but it’s convenient to have some hard-coded slots :

To avoid an extra indirection (e.g. passing buffer handle as root constant) :

PS_Output PS_Forward(VS_Output _input)
{
    PS_Output output = (PS_Output)0;
    
    ViewConstants viewConstants;
    viewConstants.Load(getBuffer(RESERVEDSLOT_BUFSRV_VIEWCONSTANTS));

    [...]

To fallback to missing texture :

m_defaultTexture = device->createTexture(texDesc, "DefaultTex2D", initData, ReservedSlot(BINDLESS_TEXTURE_INVALID));
VG_ASSERT(m_defaultTexture->getTextureHandle() == BINDLESS_TEXTURE_INVALID);
        
// copy descriptor to all 'texture' slots
for (uint i = BINDLESS_TEXTURE_START; i < BINDLESS_TEXTURE_COUNT; ++i)
    if (BINDLESS_TEXTURE_INVALID != i)
        copyTextureHandle(i, m_defaultTexture);

To initialize shader structs with proper default values (e.g. default albedo, default normal map etc…) :

struct GPUMaterialData
{
    #ifdef __cplusplus
    GPUMaterialData()
    {
        setAlbedoTextureHandle(RESERVEDSLOT_TEXSRV_DEFAULT_ALBEDO);
        setNormalTextureHandle(RESERVEDSLOT_TEXSRV_DEFAULT_NORMAL);
        setPBRTextureHandle(RESERVEDSLOT_TEXSRV_DEFAULT_PBR);
    }   
    #endif 

    // .x = albedo | normal 
    // .y = pbr | unused 
    uint4 textures; 

    [...]
};

These custom hardcoded slots are defined compile-time and “allocated” bottom-up before the last value of the range used as invalid value.

Type	Name	Value
Texture	PBR	16379
Texture	Normal	16380
Texture	Albedo	16381
Texture	ImGui	16382
Texture	Default	16383
Buffer	InstanceData	32763
Buffer	SkinningMatrices	32764
Buffer	LightsConstants	32765
Buffer	ViewConstants	32766
Buffer	Default	32767

Debugging

Using GPU debug tools like Renderdoc or PIX, it is possible to view the descriptor used and the resource contents.

vimontgames.github.io