Open aqnuep opened 2 months ago
There are no VVL tests for the following types of shader module usages:
For 1 there for sure is because I added them recently in https://github.com/KhronosGroup/Vulkan-ValidationLayers/pull/8162
this whole thing has become a big mess
background - for Pipelines, because of details of GPL, we decided to create the vvl::Pipeline
state object first. We also needed to reduce our memory footprint in pipelines/shader object so we made StatelessSpirv
checks so we didn't have to hold the memory.... then I tried to add support for inlining in VK_KHR_maintenance5
we need new VVL tests to cover this case.
So I added new tests and confirmed the VK_KHR_maintenance5
worked, will try testing it with combination of VK_EXT_shader_module_identifier
Thanks, @spencer-lunarg, greatly appreciated!
Environment:
Describe the Issue
There are no VVL tests for the following types of shader module usages:
VK_KHR_maintenance5
feature allowing the application to not useVkShaderModule
objects, but instead specify shader module information inline, by includingVkShaderModuleCreateInfo
in thepNext
chain ofVkPipelineShaderStageCreateInfo
VK_EXT_shader_module_identifier
extension is usedExpected behavior
Validation for these features should work as expected and should continue to work as expected, which requires appropriate VVL test coverage.
Valid Usage ID
All shader module related VUIDs.
Additional context
About 5 months ago there was a refactoring of SPIR-V validation separating "stateless" (i.e. only device state dependent) validation from pipeline state dependent validation, and these checks were moved from being detected during
vkCreate*Pipelines
tovkCreateShaderModule
,vkCreateShadersEXT
, etc.Until recently, this was broken (there was no SPIR-V validation at all) when including
VkShaderModuleCreateInfo
in thepNext
chain ofVkPipelineShaderStageCreateInfo
due to the lack of test coverage. In order to make sure this won't break again, we need new VVL tests to cover this case.Similarly, before that another refactoring round broke
VK_EXT_shader_module_identifier
validation, where a shader module and SPIR-V module data itself is optional as a whole, causing crashes in the validation layer because of the invalid expectation of SPIR-V module data to be always available. In order to make sure this won't break again, we need new VVL tests to cover this case.