vkCreateRayTracingPipelinesKHR 37x slower with validation despite check_shaders=false

[mklefrancois]

Environment:

• OS: Windows 11
• GPU and driver version: NVIDIA RTX 3500 Ada Generation Laptop GPU, (580.368)
• SDK: 1.4.328
• Options enabled: Standard

The Issue

Calling vkCreateRayTracingPipelinesKHR with validation on is very slow compared to having it off.

• VVL on : 5543.015 ms
• VVL off: 148.288 ms

This is happening even with the following options

    validation.check_shaders         = VK_FALSE;
    validation.check_shaders_caching = VK_FALSE;

Expected behavior

If the above options aren't preventing validation of the pipeline creation, a new option should be added to skip shader validation during pipeline creation. Alternatively, there might be a performance issue in this part of the validation layer, as the overhead appears to scale exponentially with shader complexity.

Notes

The application uses pipeline caches, but whether we use them or not has very little effect when validation is on. The VVL's overhead takes over the driver compilation.

Please note that the shader sent to pipeline creation is an über-shader that handles the glTF PBR shading model and all its extensions. Small shaders seem fine, but as this shader grows larger, validation becomes problematic.

This can be tested using the following link: https://github.com/nvpro-samples/vk_gltf_renderer.
vk_gltf_renderer --vvl [0|1] can be used to activate or disable the Vulkan validation layers. In debug mode, VVL is on by default and off in release mode.

This is the SPIRV file
gltf_pathtrace.slang.zip

[spencer-lunarg]

So I did recently attempt to solve this (when check_shaders=false) in #10570 ... there is a chance I just missed some RTX path

We do also print a warning if the app turns on Sync Validation, we have to parse the SPIR-V because it is needed in order to detect hazards

@arno-lunarg can you grab this and try to spot where the slowness is occurring, if it is in spirv-val (where it has been in the past) then figure out why the check_shaders options didn't skip it

[arno-lunarg]

Hey, on my AMD 780m, I get:

PS C:\Users\Arno\lunarg\vk_gltf_renderer> .\_bin\Release\vk_gltf_renderer.exe
Creating Vulkan Context
| nvvk::Context::createInstance -> 194.738 ms
Extension not available: VK_NV_ray_tracing_invocation_reorder
Extension not available: VK_NV_device_diagnostic_checkpoints
Extension not available: VK_NV_device_diagnostics_config
Extension not available: VK_NV_device_diagnostics_config
Extension not available: VK_NVX_binary_import  (v.0 >= 1)
Extension not available: VK_NVX_image_view_handle  (v.0 >= 2)
Vulkan error: VK_ERROR_INITIALIZATION_FAILED from createDevice(), C:\Users\Arno\lunarg\nvpro_core2\nvvk\context.cpp:76
|-> 198.751 ms
Failed to initialize Vulkan context!

Do you please know if I can get around that @mklefrancois ?

Also, as Spencer mentioned, were you running with sync validation?

[mklefrancois]

Thanks for testing and sorry for the issues. Those extensions were added because USE_DLSS and USE_NSIGHT_AFTERMATH were defined.

I will make an update with proper fallback, but meanwhile,

in main.cpp, comment USE_NSIGHT_AFTERMATH

// #define USE_NSIGHT_AFTERMATH

In CMake, make sure USE_DLSS isn't active.

[arno-lunarg]

Thanks, it allowed me to go a bit further, but now I get a validation error during shader compilation then a fatal error:

Created new pipeline cache
| PathTracer::compileShader
| | Create Shader ModuleValidation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08740 ] | MessageID = 0x6e224e9
vkCreateShaderModule(): SPIR-V Capability ShaderInvocationReorderNV was declared, but one of the following requirements is required (VK_NV_ray_tracing_invocation_reorder).
The Vulkan spec states: If pCode is a pointer to SPIR-V code, and pCode declares any of the capabilities listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.4.328.1/windows/antora/spec/latest/chapters/shaders.html#VUID-VkShaderModuleCreateInfo-pCode-08740)

Validation Error: [ VUID-VkShaderModuleCreateInfo-pCode-08742 ] | MessageID = 0xfc68be96
vkCreateShaderModule(): SPIR-V Extension SPV_NV_shader_invocation_reorder was declared, but one of the following requirements is required (VK_NV_ray_tracing_invocation_reorder).
The Vulkan spec states: If pCode is a pointer to SPIR-V code, and pCode declares any of the SPIR-V extensions listed in the SPIR-V Environment appendix, one of the corresponding requirements must be satisfied (https://vulkan.lunarg.com/doc/view/1.4.328.1/windows/antora/spec/latest/chapters/shaders.html#VUID-VkShaderModuleCreateInfo-pCode-08742)

Vulkan error: VK_ERROR_INITIALIZATION_FAILED from C:\Users\Arno\lunarg\vk_gltf_renderer\src\renderer_pathtracer.cpp:723

I will have access to a 3070 TI next week though, so really don't dwell on that if you don't have time : )

[mklefrancois]

Thanks @arno-lunarg for trying again. I made an update, so the local changes shouldn't be needed anymore.

Soon the extension of shader invocation reorder will become multi-vendor (EXT) and no longer vendor specific, but meanwhile could you try changing the default value in shaders/gltf_pathtrace.slang to 0.

[[vk::constant_id(0)]]  int USE_SER = 0;

The compiled shader is embedded in the application by default, therefore recompiling the application should compile the shader and embedding it. The SER value can be changed in runtime, which trigger a runtime compilation, but assumes SER is available by default at startup.

Note: I'm suspecting validation errors to still be present, but the code shouldn't be executed.

Those extensions are still present in the SpirV, even if USE_SER==0

               OpExtension "SPV_KHR_non_semantic_info"
               OpExtension "SPV_KHR_physical_storage_buffer"
               OpExtension "SPV_KHR_ray_query"
               OpExtension "SPV_KHR_storage_buffer_storage_class"
               OpExtension "SPV_NV_shader_invocation_reorder"
               OpExtension "SPV_KHR_ray_tracing"

Please let me know if this helps.

[mklefrancois]

To avoid validation errors, it is also possible to comment the specialization constant and declare a preprocessor macro at the top of shaders/gltf_pathtrace.slang.

#ifndef USE_SER
#define USE_SER 0
#endif

This will remove "SPV_NV_shader_invocation_reorder" from the SpirV output.

[arno-lunarg]

Hello, so I found the issue: the app is using both old and new ways to setup VVL settings, and old ones take precedence. This is totally not an obvious think, so we will add the appropriate warnings to help users understand they should not do that.

In the meantime, here is a patch for validation_settings.hpp in nvpro_core2 to remove usage of old settings, since you use the new ones:
vvl_settings.patch

With this, settings like check_shaders work as expected!

[mklefrancois]

Thank you so much for the patch, and it is indeed working as expected, but unfortunately other aspect of the validation layer isn't working anymore, for example, debug printf.

When looking at the documentation, it is enabling the layer name, and removing it disable the feature.
https://docs.vulkan.org/samples/latest/samples/extensions/shader_debugprintf/README.html

Do you have a solution for this?

[arno-lunarg]

I think you just have to add a new VkBool32 printf_enable to validation_settings.hpp, and set it like the other settings:

{m_layer_name, "printf_enable", VK_LAYER_SETTING_TYPE_BOOL32_EXT, 1, &printf_enable},

And that tutorial also needs to be updated... Thank you for pointing it out!