search

KhronosGroup / VK-GL-CTS

Khronos Vulkan, OpenGL, and OpenGL ES Conformance Tests
https://www.khronos.org/
Apache License 2.0
526 stars 294 forks source link

`dEQP-VK.api.version_check.entry_points` wrongly assumes `vkCmdPushDescriptorSetWithTemplateKHR()` presence #423

Closed CreativeCylon closed 1 year ago

CreativeCylon commented 1 year ago

I believe I have found a CTS bug.

On a Vulkan 1.0 driver with VK_KHR_descriptor_update_template but no VK_KHR_push_descriptor support, dEQP-VK.api.version_check.entry_points still fails with:

 <Text>Enabled extensions check - tries to get functions of supported extensions from proper vkGet*ProcAddr.</Text>
 <Text>[0] vkGetDeviceProcAddr(device, &quot;vkCmdPushDescriptorSetWithTemplateKHR&quot;) returned nullptr. Should return valid function address.</Text>
 <Text>Failed</Text>

https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkCmdPushDescriptorSetWithTemplateKHR.html mentions that the function is provided by VK_KHR_descriptor_update_template with VK_KHR_push_descriptor so both extensions should be checked before attempting to get the function.

I believe the current logic ends up adding the function check based on just VK_KHR_descriptor_update_template rather than checking VK_KHR_push_descriptor as well. https://github.com/KhronosGroup/VK-GL-CTS/blob/4340e6e70bc62746e7cd03e8d03541e446f4f17f/external/vulkancts/modules/vulkan/api/vktApiVersionCheck.cpp#L244-L254

I found this while running CTS 1.3.4.1 after implementing VK_KHR_descriptor_update_template on the powervr Mesa driver.