Vulkan validation layer errors and provisional caps shenanigans
seanbaxter opened this issue · 6 comments
In 8_ray_tracing/shaders I'm getting this:
$ spirv-val raytrace.comp.glsl.spv
error: line 67: Opcode TypeRayQueryKHR requires one of these capabilities: RayQueryKHR
%76 = OpTypeRayQueryKHR
I'm struggling with these caps myself. glslc is emitting OpCapability::RayQueryProvisionalKHR, even though OpCapability::RayQueryKHR is in the SPIR-V headers, under a different opcode. However that latter capability isn't even in the SPIR-V specification yet.
I just rebuilt SPIRV-Headers and SPIRV-Tools today. When I compile with Debug symbols, the Validation layers give this error:
INFO: Loader Message
--> Inserted device layer VK_LAYER_KHRONOS_validation (libVkLayer_khronos_validation.so)
ERROR: UNASSIGNED-CoreValidation-Shader-InconsistentSpirv
--> Validation Error: [ UNASSIGNED-CoreValidation-Shader-InconsistentSpirv ] Object 0: handle = 0xc06b18, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x6bbb14 | SPIR-V module not valid: Opcode TypeRayQueryKHR requires one of these capabilities: RayQueryKHR
%76 = OpTypeRayQueryKHR
But there seems to be no pleasing the validation layers. I've been changing my own shader compiler backend for different combinations of caps and extensions. If I emit RayQueryKHR instead of RayQueryProvisionalKHR, the validation layer spews out this:
ERROR: UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled
--> Validation Error: [ UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled ] Object 0: handle = 0xfcab38, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x8c548bfd | Shader requires VkPhysicalDeviceRayTracingPipelineFeaturesKHR::rayTracingPipeline but is not enabled on the device
ERROR: UNASSIGNED-CoreValidation-Shader-FeatureNotEnabled
For the record I'm on 455.46.04 on a RTX 2060.
I tried rebuilding shaderc from source, even pulling the SPIRV-Tools and SPIRV-Headers submodules from master rather than whatever stale commit they were pinned at, and get the same issues.
The RFC for SPV_EXT_ray_query says that the Provisional and regular RayQuery caps are the same, but both spirv-val and the Vulkan validation layers don't agree.
I should add that the shader (at least using RayQueryProvisionalKHR) works in release builds. It's the validation layer in debug build that breaks it.
Hi Sean!
There are a couple of things this could be - usually, when someone testing the tutorial internally ran into a problem like this, it was due to one of the following 3 things:
- Vulkan SDK version other than the public 1.2.162.0 version (the requirement for >= 1.2.162.0 in Chapter 1 is pretty strict at the moment since the non-provisional extension is new - an alpha or private Khronos version of 1.2.162 or 1.2.148 might be able to run the chapter checkpoints, but the included tools and validation layer might not be up to date!)
- A bug in glslangValidator (packaged with the Vulkan SDK)
- A bug in the Vulkan Validation Layers (packaged with the Vulkan SDK)
I checked the project again today using the latest Vulkan SDK on Windows and wasn't able to reproduce the issue, but there are some things that can be done.
The first thing to check is to make sure that if you have 1.2.162.0, that it's not the alpha (pre-release) version; I don't really have a good way of checking this at the moment other than reinstalling the Vulkan SDK. Then, I'd make sure glslangValidator is being found in the right place using where glslangValidator (on Windows) and by looking at the compiler's output log, in case maybe 1.2.162.0 is installed, but the build system is finding the wrong glslangValidator. If that prints out a path to a 1.2.162.0 version of the Vulkan SDK (such as C:\VulkanSDK\1.2.162.0), then the next step is probably to build glslangValidator and the Vulkan Validation Layers.
On Windows with Visual Studio 2019, this only requires building the Vulkan Validation Layers, since those include and build glslang as a submodule. Here's a batch script to do that using the 1.2.162.0 branch (remove the -b v1.2.162 to get the latest public version)
rem Build the Vulkan Validation Layers (downloads Vulkan-Headers, glslang, and SPIRV-Headers)
rem See https://github.com/KhronosGroup/Vulkan-ValidationLayers/blob/master/BUILD.md for more info.
git clone -b v1.2.162 --depth 1 https://github.com/KhronosGroup/Vulkan-ValidationLayers.git
cd Vulkan-ValidationLayers
mkdir build
cd build
..\scripts\update_deps.py --arch x64 --config release
cmake -A x64 -C helper.cmake ..
cmake --build . --target install --config Release
This will create files in build\glslang\build\install and build\install that then must be copied into the Vulkan SDK directory, overwriting the files there (or one can set VK_LAYER_PATH to say "Vulkan, find the Validation Layers in a different place").
If this doesn't solve the problem, then it's possible to build a debug version of the Vulkan Validation Layers to see where it's emitting the error from (by omitting --config release and --config Release in the script above, if I remember correctly)! If your IDE can find the symbol files, then you can put a breakpoint on where the nvpro-samples framework prints out "ERROR: " and then go up the stack to enter the Validation Layers.
As you've noticed as well, in this case one can ignore the validation layer errors (or even disable the validation layer)! This tutorial tries not to do that because it'll hopefully catch typos from readers following the code, but if time is of the essence then it can make sense.
Hope this helps - and thanks for putting together the Circle C++ port of the code!
Very odd. You're right about the Vulkan toolkit. When I sudo apt install vulkan-sdk I get this:
vulkan-sdk is already the newest version (1.2.162.0-1lunarg20.04-2).
Yet when I run your tutorial programs through the validation layers I get this:
Vulkan Version:
- available: 1.2.154
- requesting: 1.2.0
Something is not in sync. Good diagnosis.
Hi Sean - just checking in on this, are you still running into this issue by any chance?
Also, I remembered that some people were running into an issue where Vulkan was loading an old version of the validation layers by mistake on Windows due to old registry keys the Vulkan SDK uninstaller didn't remove (and sometimes this shows up as an out-of-date Vulkan version available) - is it possible something like this might be happening on Linux with VK_LAYER_PATH?
Thanks!
You can close this one.. Truth is I turned off validation a while back because there's a bug where it hangs on loading modules that bring in physical storage buffer pointers from UBOs. No idea if this ray tracing thing has been resolved. I'll re-open if the other thing gets fixed but this still flakes out.
Sounds good, thanks!