Minimal support for VK_KHR_acceleration_structure

[krys-g]

Description

In feature request #2317, you explained that implementing support for VK_KHR_ray_query would be a major undertaking, and I fully understand.

However, how about supporting just VK_KHR_acceleration_structure? Although I'm not familiar with Renderdoc's internals, I hope a bare minimum implementation should not have too much to do: accept the extension, capture the content as a regular buffer, and perhaps track the object in the resource lists, but otherwise don't interact with it.

There is a use case for VK_KHR_acceleration_structure without support for VK_KHR_ray_query and VK_KHR_ray_tracing: it is possible to implement ray queries in SW as a Vulkan layer (focusing on functionality, not raw performance), translating RQ calls into regular compute shaders. Being able to debug applications using such SW layer, plus AS builds, in Renderdoc would be tremendously useful.

Not all entrypoints need be supported. The minimum set could be:

• vkCmdBuildAccelerationStructuresKHR
• vkCreateAccelerationStructureKHR
• vkDestroyAccelerationStructureKHR
• vkGetAccelerationStructureBuildSizesKHR
• vkGetAccelerationStructureDeviceAddressKHR

Environment

• RenderDoc version: 1.19
• Operating System: Linux Debian
• Graphics API: Vulkan

[baldurk]

No this is not something I would implement or accept a PR for. You or someone could explore implementing it on a fork if you need it yourself, but bear in mind that it would not be upstreamable without further work. The utility of supporting only this one extension is very small (possibly zero, given reasoning below) and would produce confusion that only part of the ray tracing extensions are supported.

Supporting this part of the extension properly is not a small amount of work as you describe, and it is definitely not acceptable to only implement part of an extension as then anyone using the remaining functionality would encounter crashes or incorrect behaviour. An extension needs to be fully supported, except where the API provides functionality for querying optional support.

I'm also not sure I understand how this would work in a software emulation layer. For one thing layer ordering I believe is not strictly defined, and if RenderDoc is above the emulation layer it would prevent the use of VK_KHR_ray_query and VK_KHR_ray_tracing and defeat the point. If it's below the emulation layer, there is no legal way that I can see to interact with acceleration structure contents using just this extension.

Unless I'm missing something the ASs are opaque data structures that must only be accessed via VK_KHR_ray_query and VK_KHR_ray_tracing, so any emulation layer that implements ray queries or ray tracing as a software compute step would also need to implement acceleration structures as a compute/plain buffer to be able to introspect them - it's still all-or-nothing. If you use the driver's acceleration structure implementation then you must use its ray tracing implementation too as the AS is opaque. You could implement compute emulation in the driver where the AS format is known, but then that is the same as the case above where RenderDoc is above the emulation.