Shader module "mandatory SPIR-V input" and NV_GLSL_SHADER potential bug ?

Vulkan
1

Hello,

I present myself as an experienced OpenGL developper but a complete newbie with Vulkan. I am not a native english speaker, sorry for any language mistakes.

I have been following this tutorial: https://vulkan-tutorial.com/Drawing_a_triangle/Graphics_pipeline_basics/Shader_modules#page_Compiling_the_shaders
Code available here: https://github.com/Overv/VulkanTutorial/blob/master/code/15_hello_triangle.cpp

As stated by the Vulkan FAQ (https://www.lunarg.com/vulkan-sdk/faq/)
“The Vulkan shader language is SPIR-V, which is a low-level binary intermediate representation (IR). The Vulkan API requires the SPIR*-V format for all shaders.”

and by the Shader Module Specifications (https://vulkan.lunarg.com/doc/view/1.0.26.0/linux/vkspec.chunked/ch08s01.html)
“The shader code defining a shader module must be in the SPIR-V format”

However I can confirm the source code of the tutorial is also working with raw GLSL shader files (even though the validation layer warns that the shader module is invalid because it cannot find the Magic Number)

As I understand, the “NV_GLSL_SHADER” extension allow such a behaviour (I am using a GTX 1050) but I verified it wasn’t enabled in this example through “createInfo.ppEnabledExtensionNames[i]”.
Source:
https://developer.nvidia.com/engaging-voyage-vulkan (Very bottom paragraph)
https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/pull/1452/commits/ce33c489d0192995a3ef63dfd64df19365f71674

Am I missing something here ? is it because of something in the code I have missed ? or is it just NVIDIA going funky with the standard ? Is it worth opening a Github issue ?

2

Remember: violating most rules of Vulkan means you get undefined behavior. Passing a shader that is not valid SPIR-V is undefined behavior. If an implementation wants to accept “not valid SPIR-V” that happens to be valid GLSL, that would qualify as “undefined behavior”. So if NVIDIA wants to behave that way regardless of whether the extension is enabled, that’s fine.

This is why validation layers exist: so that you can know when you’re doing something that you’re not allowed to.

3

I see, It is funny though that the extension only exist for availability checking purposes.

4

No, it exists to guarantee things. If NVIDIA wanted, they could not let non-SPIR-V code work unless you switched the extension on. That something undefined happens to do what you want doesn’t change the fact that you’re relying on undefined behavior.

5

or is it just NVIDIA going funky with the standard ?

It’s exactly that, a vendor specific “thing”. There is no requirement that the extension has to be enabled to work and as it’s a nvidia specific extension they’re free to implement it the way the want to.

And that’s exactly what the spec of that extension says:

This extension allows GLSL shaders written to the GL_KHR_vulkan_glsl extension specification to be used instead of SPIR-V. The implementation will automatically detect whether the shader is SPIR-V or GLSL, and compile it appropriately.

No mention that the extension has to actually be enabled.

6

[QUOTE=Sascha Willems;43155]
No mention that the extension has to actually be enabled.[/QUOTE]

In fact, there is (VkShaderModuleCreateInfo VU – spec compiled without extensions):

pCode must point to valid SPIR-V code, formatted and packed as described by the Khronos SPIR-V Specification

It only suffers from Issue 533. As Alfonse said, it is “undefined behavior” to provide GLSL and not enable VK_NV_glsl_shader. Meaning it may work as the user intended, or it may accidentally destroy one spacial dimension and turn us all into pancakes.