Pointer corruption and crash, when handling VK_EXT_opacity_micromap

[AlexanderVeselov-arm]

Environment:

• SDK or header version if building from repo: VulkanSDK-1.3.280, also reproduced on 00c0bd4 (main)
• Options enabled (synchronization, best practices, etc.): CoreValidation

(Omitting rest of the stuff, as it is bug in C++ code and must be platform independent)

Describe the Issue

Hello!

Apparently validation layer has an unwrapping related bug in handling .pNext, that points to VkAccelerationStructureTrianglesOpacityMicromapEXT.

For example, when calling vkGetAccelerationStructureBuildSizesKHR with OMM, validation layer takes const-pointer to VkAccelerationStructureBuildGeometryInfoKHR , with information about micromap available via pointer chain:

// before api-call
(const VkAccelerationStructureTrianglesOpacityMicromapEXT*)build_geom_info.pGeometries->geometry.triangles.pNext->micromap	0x0000021663851c60 // points to internal VVL wrapper

vkGetAccelerationStructureBuildSizesKHR(...); 

// after api-call input data was changed
(const VkAccelerationStructureTrianglesOpacityMicromapEXT*)build_geom_info.pGeometries->geometry.triangles.pNext->micromap	0x000002164de03330 // points to 'real' OMM handle

The reason for is lack of deep-copy mechanism for VkAccelerationStructureGeometryDataKHR, followed by unwrapping of OMM handle.

[spencer-lunarg]

So we have zero tests for VK_EXT_opacity_micromap currently and unfortunately has fallen back on our priority list. I am happy to at least not have things crash, but also not familiar with this extension and the what we really need is a "positive" test that uses the API correctly to make sure we aren't crashing on basic usage

[AlexanderVeselov-arm]

Unfortunately on our side OMM is not a main focus today, just experimenting around with desktop gpu.

"positive" test that uses the API correctly to make sure we aren't crashing on basic usage

I'll put it in a backlog for now, to get back to it, once we have time.