Improving SBT API

[Jaisiero]

Hi guys.

I want you to check out these changes.

SBT now is more complex but allows you to relate better betwen shader stages and shader groups and ask for any SBT configuration.

I added more features (which I've been working on for a few weeks) to the MPM sample.

Let me know if some changes are needed.

[GabeRundlett]

Hi @Jaisiero I would like to understand why the create default sbt function now constructs multiple buffers, one for each "region". I would like to know why this is, and if it makes sense, why the create default sbt also returns a buffer

[Jaisiero]

Hi Gabe!

The thing is that the ray tracing pipeline handlers need to be copied to a host buffer and passed as arguments to the vkCmdTraceRays call to link them to the pipeline itself. This is better explained in the following link:

SBT handles

This functionality is quite complex and this is the best way I could think of for the user to have all the group handlers at their disposal since they are ordered according to the following requirements:

I'm sure you can expose all this logic to the user, but you have to take into account all these details, such as aligning the handlers to memory. If you can think of a better way to deal with this problem I'm open to improvements of course.

[GabeRundlett]

This does not explain why there are multiple buffers. Also, the buffer that contains the shader handles absolutely should not be a host buffer as it currently is. Either way, though, there should only be a SINGLE buffer created, with the function just returning the single buffer and the strided device address regions.

Note: the API has this, where there is both a buffer output in the function signature, but also a buffer output within the entries struct which is also a result of the same function.

typedef struct
{
    daxa_BufferId buffer;
    daxa_SpanToConst(daxa_GroupRegionInfo) group_regions;
} daxa_RayTracingShaderBindingTableEntries;

DAXA_EXPORT daxa_Result
daxa_ray_tracing_pipeline_create_sbt(
    daxa_RayTracingPipeline pipeline,
    daxa_RayTracingShaderBindingTableEntries * out_sbts, daxa_BufferId * out_buffer,
    daxa_BuildShaderBindingTableInfo const * info);

[GabeRundlett]

this appears to be a copy+paste error and I would like you to completely review the changes you've made because it does not seem complete or tested.

It appears that the buffer is created twice with the same size (but computed completely differently)

    // Allocate a buffer for storing the SBT.
    auto sbt_info = daxa_BufferInfo{
        .size = current_offset,
        .allocate_info = DAXA_MEMORY_FLAG_HOST_ACCESS_SEQUENTIAL_WRITE,
        .name = std::bit_cast<daxa_SmallString>(name_cstr),
    };
    // NOTE: it is responsibility of the user to destroy the buffer
    auto & sbt_buffer_id = *out_buffer;
    auto const create_buffer_result = daxa_dvc_create_buffer(device, &sbt_info, r_cast<daxa_BufferId *>(&sbt_buffer_id));

    /// LATER, in the same function...

    // Allocate a buffer for storing the SBT.
    auto sbt_handler_info = daxa_BufferInfo{
        .size = sbt_handle_size,
        .allocate_info = DAXA_MEMORY_FLAG_HOST_ACCESS_RANDOM,
        .name = std::bit_cast<daxa_SmallString>(name_handle_cstr),
    };
    
     auto handle_result = daxa_dvc_create_buffer(device, &sbt_handler_info, r_cast<daxa_BufferId *>(&out_entries->buffer));

[Jaisiero]

Yes that's where the actual SBT lives composited by handler GROUPS. Then based on your handlers (one for every stage), you made your SBT based on shader groups. Each color is a group. Each cell is a handler:

To sum up. For setting up your RT pipeline and for tracing rays you need at least two buffers during RT pipeline's lifetime: one for the actual handlers and one made up of shader groups.

I hope that makes sense.