Closed Faymoon closed 5 years ago
I use Vulkan with glslangValidator to compile GLSL to spir-v. And i found that : https://github.com/KhronosGroup/GLSL/blob/master/extensions/khr/GL_KHR_vulkan_glsl.txt#L549. It could be a good idea to support both syntax.
What do you think about it ?
As a first step I included the new keywords this extension introduces in my parser. If I understand this extension correctly for full support, I would have to run an instance of a spir-v creation tool, like glslangValidator to give me error feedback. This will take some time...
thanks
I know this is an old issue, but it's still open, so I hope you'll forgive me for barging in. :)
I've been working on a project for a while now that was previously OpenGL-only, and have found your extension wonderfully useful, so first off thank you! Unfortunately, now that I'm expanding into supporting other backends, I'm running into a problem with Vulkan-flavored GLSL, despite the addition of external compilers as an option.
Using glslangValidator as my external compiler, I see some disheartening squiggles when I attempt to use descriptor sets with a 'set' of more than 0, e.g.
layout (set = 1, binding = 0) uniform ViewMatrix
{
...
I also get an error with gl_VertexIndex. I wasn't using it in my own shaders, but testing now I see it reports undeclared identifier
. Luckily, the error reported by Vulkan for my descriptor sets is a bit more useful, only allowed when using GLSL for Vulkan
, which led me to discover the reason behind it, and the reason @Faymoon's issue is still around: glslangValidator needs the -V
switch to indicate that it's being fed GLSL with Vulkan semantics, instead of ordinary GLSL. Compiling my shaders from the command line without -V shows the same errors described here, while adding -V lets everything build properly.
Is there any chance of adding an option to pass custom arguments to the external compiler we choose? There are quite a few parameters supported by glslangValidator, and I can't honestly predict if any of them would cause your extension issues, but passing -V is, as far as I know, the only way to compile Vulkan's particular dialect of GLSL.
I did try a few workarounds, namely with CMD scripts and Windows shortcuts, but since the external compiler is started with UseShellExecute=false, they don't seem to want to run; setting the working directory to the appropriate temporary path would also be troublesome. I could write a custom executable to pass along the temporary shader files while adding the necessary command line arguments, I imagine, but I thought it was worth asking here in case you're amenable to the idea of allowing custom arguments.
Hi! Thanks for investigating the issue. I added an option setting for external compiler arguments and did a quick check with the layout binding you used in your comment above. I found that glslangValidator.exe
produces a different error format for Vulkan: When using -V
the file numer is replaced by the actual file path, which was too much for my simple error parsing. So for now I replace all occurrences of the file in the error messages by the file numer 0
. Very hacky, but this now seems to work without wrong squiggles. Hopefully this resolves the whole issue.
Wow, thanks for the quick response! I've updated to the latest build and can confirm the new option works. My descriptor sets don't produce errors any longer, but when intentionally introducing invalid code I do see squiggles in the appropriate places and with the appropriate error messages, so it seems like -V
does indeed do the trick.
I didn't realize the validator produces different output for different GLSL versions, and I'm sorry you had to hack around that, but it looks like an effective solution so far. Thank you for your time, I appreciate the fix!
Excellent! Thanks for your testing effort!
Installed product versions
Description
This extensions says me there is an error when i write
gl_VertexIndex
but when i compile the shader there is no error.Steps to recreate
gl_VertexIndex
Current behavior
It says me an error so i can't code properly.
Expected behavior
It should say me nothing..