Description
When creating a buffer with ACCELERATION_STRUCTURE_SCRATCH, its memory location is not always aligned correctly. On vulkan this will cause validation errors with
[2025-12-17T01:04:22Z ERROR wgpu_hal::vulkan::instance] VALIDATION [VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710 (0x63ff8904)]
vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (18446664917465611072) must be a multiple of minAccelerationStructureScratchOffsetAlignment (128).
The Vulkan spec states: For each element of pInfos, its scratchData.deviceAddress member must be a multiple of VkPhysicalDeviceAccelerationStructurePropertiesKHR::minAccelerationStructureScratchOffsetAlignment (https://vulkan.lunarg.com/doc/view/1.4.328.1/windows/antora/spec/latest/chapters/accelstructures.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710)
This is because the alignment when allocating the memory for the buffer to go on is 64, not 128. This is because buffer usage ACCELERATION_STRUCTURE_SCRATCH maps to vk::BufferUsageFlags::STORAGE_BUFFER | vk::BufferUsageFlags::SHADER_DEVICE_ADDRESS, neither of which have as high an alignment requirement (on intel its 64) compared with using the buffer as an acceleration structure scratch buffer.
Repro steps
Happened for me randomly while running the ray cube compute example.
Expected vs observed behavior
wgpu should not cause vulkan validation errors to be emitted
Extra materials
Platform
trunk. Unsure if this is a regression due to changing allocaters.
Description
When creating a buffer with ACCELERATION_STRUCTURE_SCRATCH, its memory location is not always aligned correctly. On vulkan this will cause validation errors with
[2025-12-17T01:04:22Z ERROR wgpu_hal::vulkan::instance] VALIDATION [VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710 (0x63ff8904)] vkCmdBuildAccelerationStructuresKHR(): pInfos[0].scratchData.deviceAddress (18446664917465611072) must be a multiple of minAccelerationStructureScratchOffsetAlignment (128). The Vulkan spec states: For each element of pInfos, its scratchData.deviceAddress member must be a multiple of VkPhysicalDeviceAccelerationStructurePropertiesKHR::minAccelerationStructureScratchOffsetAlignment (https://vulkan.lunarg.com/doc/view/1.4.328.1/windows/antora/spec/latest/chapters/accelstructures.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03710)This is because the alignment when allocating the memory for the buffer to go on is 64, not 128. This is because buffer usage
ACCELERATION_STRUCTURE_SCRATCHmaps tovk::BufferUsageFlags::STORAGE_BUFFER | vk::BufferUsageFlags::SHADER_DEVICE_ADDRESS, neither of which have as high an alignment requirement (on intel its 64) compared with using the buffer as an acceleration structure scratch buffer.Repro steps
Happened for me randomly while running the ray cube compute example.
Expected vs observed behavior
wgpushould not cause vulkan validation errors to be emittedExtra materials
Platform
trunk. Unsure if this is a regression due to changing allocaters.