Ray Tracing: unexpected VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03711

[rg3igalia]

Environment:

• OS: Fedora Linux 43
• GPU and driver version: RADV from Mesa main
• SDK or header version if building from repo: 430c8b9
• Options enabled (synchronization, best practices, etc.): defaults + synchronization

Describe the Issue

A few ray tracing CTS tests, like dEQP-VK.ray_tracing_pipeline.acceleration_structures.format.traditional_structures.gpu_built.a2b10g10r10_unorm_pack32.nopadding.index_none, produce VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03711 unexpectedly. The error message looks like this:

vkCmdBuildAccelerationStructuresKHR(): pInfos[0].pGeometries[0].geometry.triangles.vertexData.deviceAddress is 0xffff800100200000 and is not aligned to the minimum component byte size (0) of its corresponding vertex format (VK_FORMAT_A2B10G10R10_UNORM_PACK32).\nThe Vulkan spec states: For each element of pInfos[i].pGeometries or pInfos[i].ppGeometries with a geometryType of VK_GEOMETRY_TYPE_TRIANGLES_KHR, geometry.triangles.vertexData.deviceAddress must be aligned to the size in bytes of the smallest component of the format in vertexFormat (https://docs.vulkan.org/spec/latest/chapters/accelstructures.html#VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03711)

The issue appears to happen because the layers calculate a minimum component byte size for a format based on the number of bits in each component, divided by 8. For VK_FORMAT_A2B10G10R10_UNORM_PACK32, the A2 part makes it end up with a minimum alignment of 0. The routine that checks pointer alignments always returns not-aligned when the divisor is zero.

Expected behavior

No validation issues, but the VUID could be a bit more precise. I think when using packed formats for geometry data, the alignment probably needs to match the pack size.

Valid Usage ID

VUID-vkCmdBuildAccelerationStructuresKHR-pInfos-03711

Additional context

N/A

[spencer-lunarg]

@rg3igalia I'm a bit confused, for VK_FORMAT_A2B10G10R10_UNORM_PACK32, the spec says

deviceAddress must be aligned to the size in bytes of the smallest component of the format in vertexFormat

so is this just 1 here then?

I guess not sure if this something we in VVL need to round up to 1 byte?

[rg3igalia]

As I said, I think the key here may be "_pack32" in the format name, and the VUID may need adjusting. In this case I believe the alignment requirement of each vertex should be 4 bytes. For example, when drawing normally with vkCmdDraw and reading vertices from a vertex buffer, you have:

VUID-vkCmdDraw-format-10389

For each vertex attribute accessed by this command, if its VkVertexInputAttributeDescription::format or VkVertexInputAttributeDescription2EXT::format is a packed format, and the legacyVertexAttributes feature is not enabled, the value of attribAddress, calculated as described in Vertex Input Calculation, must be a multiple of the size of the format

VUID-vkCmdDraw-format-10390

For each vertex attribute accessed by this command, if its VkVertexInputAttributeDescription::format or VkVertexInputAttributeDescription2EXT::format is not a packed format, and either the legacyVertexAttributes feature is not enabled or format has 64-bit components, the value of attribAddress, calculated as described in Vertex Input Calculation, must be a multiple of the component size of the format

And the description of packed formats in section 54.1.4 says:

For the purposes of address alignment when accessing buffer memory containing vertex attribute or texel data, the following formats are considered packed - components of the texels or attributes are stored in bitfields packed into one or more 8-, 16-, or 32-bit fundamental data type.

[spencer-lunarg]

update - VUID will be fixed in https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/8004

Will get a fix for that