Open jeffbolznv opened 12 hours ago
spencer-lunarg
commented
11 hours ago related to https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/8063
basically I am happy to look into this if someone can write me a positive test for VK_EXT_opacity_micromap as I am not aware how to use it and we need a regression test
I could use the sample, but there was zero VVL coverage ever added for this extension and things will only keep regressing without proper tests added
spencer-lunarg
commented
4 hours ago Was able to reproduce, there is so much un-fun code around VkAccelerationStructureGeometryKHR (both in the VUL Safe Struct code and the dispatching code in VVL)
This will take a lot more time (mainly due to lack of knowledge around this API) to try and pick apart
for the short term, I found that going set VK_LAYER_DISABLES=VK_VALIDATION_FEATURE_DISABLE_UNIQUE_HANDLES_EXT does bypass the crash and works as expected (there is zero coverage for this extension so nothing else should blow up using this extension)
spencer-lunarg
commented
4 hours ago ok, poking more, we really don't handle all of RTX handle wrapping at all, things like vkCmdBuildAccelerationStructuresKHR are completely missing wrapping based on the geometryType
Environment:
Describe the Issue
I got an internal report that there's a device_lost when validation handle wrapping is enabled and running the mm_opacity sample from https://github.com/nvpro-samples/vk_mini_samples/. I was able to reproduce this locally with TOT VVL. I suspect what's happening is there can be a VkAccelerationStructureTrianglesOpacityMicromapEXT containing a VkMicromapEXT handle pointed to by VkAccelerationStructureGeometryDataKHR::triangles and this doesn't get unwrapped. VkAccelerationStructureGeometryDataKHR has this weird "selection" behavior in the XML and I think the python scripts aren't handling this corner case.
Expected behavior
mm_opacity shouldn't crash with VVL enabled.
Valid Usage ID N/A