Currently, we cannot compare raytracing perf between Windows (Gits Playback on DirectX) and Linux (Gits Playback on DirectX on Proton on Mesa Vulkan) because the BVH scratch sizes requested by DirectX are smaller than those required by Vulkan. As such, when a DirectX recording is replayed on Linux, it does not allocate enough space for the BVH, causing errors.
We tried solving this with by setting accelerationStructureScratchPadding to a large value, effectively multiplying the scratch space Gits tells DirectX each acceleration structure needs, by a constant factor. This way, we can, in theory, port the recordings over to Vulkan on Linux without risking them running out of scratch space.
This was fine for large BVHes, where the scratch memory requirements were dominated by factors that scaled with the number of leaves in the BVH. However, the scratch memory requirements of small BVHes are dominated by fixed costs that do not scale with the number of leaves. And since these fixed costs are much higher (>10x) for Mesa than they are for the Windows driver, it's not feasible to rely on accelerationStructureScratchPadding -- we would need to multiply the scratch sizes by over 10x, limiting which applications we can test.
To fix this we recommend that Gits add a new option for adding fixed increases to the calculation for acceleration structure sizes (which I'll call accelerationStructureScratchFixed here), so that the scratch size Gits tells the application ends up being calculated like this:
newScratchSize = oldScratchSizeFromDriver * accelerationStructureScratchPadding + accelerationStructureScratchFixed;
This will allow us to add padding to acceleration structures that more closely models what Vulkan needs in comparison to DirectX..
Currently, we cannot compare raytracing perf between Windows (Gits Playback on DirectX) and Linux (Gits Playback on DirectX on Proton on Mesa Vulkan) because the BVH scratch sizes requested by DirectX are smaller than those required by Vulkan. As such, when a DirectX recording is replayed on Linux, it does not allocate enough space for the BVH, causing errors.
We tried solving this with by setting
accelerationStructureScratchPaddingto a large value, effectively multiplying the scratch space Gits tells DirectX each acceleration structure needs, by a constant factor. This way, we can, in theory, port the recordings over to Vulkan on Linux without risking them running out of scratch space.This was fine for large BVHes, where the scratch memory requirements were dominated by factors that scaled with the number of leaves in the BVH. However, the scratch memory requirements of small BVHes are dominated by fixed costs that do not scale with the number of leaves. And since these fixed costs are much higher (>10x) for Mesa than they are for the Windows driver, it's not feasible to rely on
accelerationStructureScratchPadding-- we would need to multiply the scratch sizes by over 10x, limiting which applications we can test.To fix this we recommend that Gits add a new option for adding fixed increases to the calculation for acceleration structure sizes (which I'll call
accelerationStructureScratchFixedhere), so that the scratch size Gits tells the application ends up being calculated like this:This will allow us to add padding to acceleration structures that more closely models what Vulkan needs in comparison to DirectX..