Integrating glslang directly into VulkanSceneGraph build

[robertosfield]

Since the inception of the VulkanSceneGraph project the ability to compile GLSL shaders into SPIR-V that Vulkan drivers consume has been a necessity,

Initially I uses glslangValidator to do this work off line, then later I linked the glslang library with the VulkanSceneGraph in order to compile shaders into SPIR-V at runtime to enable easier development and advanced features like shader composition. Relying upon glslang has turned out to be far more painful that it should be, with the API evolving over the years, different packaging of glslang being done in various ways on various platforms has meant that it's been a wake a mole task trying to keep the VSG working on all the various build and runtime combinations involving glslang and SPIRV-Tools.

It's been a real pain point for the development of the VulkanSceneGraph past 4 years and it's not got any easier and more and more permutations of glslang and SPIRV-Tools have popped on different build combinations. It's not just painful for me as project lead it's also resulting int he VSG crashing for some folks on some platform combinations. I just want an easy life and for VSG users to have an easy life without these issues, but I also want to power that is runtime shader composition.

Over the years I've tried a few different combinations of ways to solve it, which works for a while till another build/runtime combination pops up. Last week I hit upon an issue on a clients system that very much looked like a runtime compatibility issue with glslang/SPIRV libs it's tricky to fix with end users having to nurse their dev systems into configurations that are reliable.

So again I've been on the hunt for a new approach to providing shader compilation, and I tried several different approach over the past week, and finally have an approach that might work - but it's a bit hacky and not a conventional approach, but it does at least bring control back in our hands.

The approach I'm not trying out is to optionally pull in glslang repo as a submodule and then building the glslang sources files directly as part of the VSG library itself. No glslang symbols or headers are exported as public components of the VSG, it's all entirely encapsulated with the VSG library. The work is checked into the glslang branch of the VSG:

https://github.com/vsg-dev/VulkanSceneGraph/tree/glslang

The automated builds are now working on Linux, Windows and macOS so fingers crossed it'll work for all users.

In order to get this to work I have had to clone the official glslang repo and added a build_vars.cmake file that sets up SOURCE and EXTERA_DEFINES vars that the VSG build users. I could have put this file into VSG itself but I think it would be more robust if changes into glslang can be locally reflected in updating the build_vars.

I don't know whether the glslang devs will want such an addition in the main repo so I've created a local clone of the official repo and added the build_vars.cmake there:

https://github.com/vsg-dev/glslang

I still don't know whether this approach is going to work reliably on all systems and build combinations, I'm hoping by compiling the required functionality into VSG with a software dev of glslang that we can control we'll finally be able to provide a unified and simple solution for everyone. My hope is all the hassles that we've had will be resolved and we can all focus on making great applications rather than chasing ever changing 3rd party dependency combinations.

At this point though, it's still experimental, it's a solution that doesn't follow normal conventions, so I wouldn't be surprised if I get a few "WTF are you doing that for you nutter" :-) I have done what I can to smooth the way but now I need members of the community to just check out the glslang branch of the VulkanSceneGraph and just build and install as you would normally and let me know how you get on.

There are a few changes you'll see - the first cmake configuration will initialize glslang as a submodule, this can be quite slow as glslang repo is relatively large compared to the VSG, the source code isn't big though, so compiling the VSG isn't much slower.

Another difference you'll see, especially under Linux, is lots of warning emitted when compiling the glslang source files. This is due to the VSG compiling with much more verbose warnings levels that glslang is normally compiled with. What I'll do is create a branch of vsg-dev/glslang and fix the warnings then create a pull request so hopefully the main glslang repo can benefit from us tightening things up.

I haven't yet tested vsgFramework but that will need updating to remove the glslang and SPIRV-Tools entries. I'm crossing my fingers and toes that it'll work and be simpler for end users.

If this all looks like it's workable approach I'll go for making a VulkanSceneGraph-1.0.3 release at next weekend (25/26th of February.)

What I'd really appreciate right now is folks checking out the glslang branch of the VSG and then building and install the VSG and associated projects that you use, and testing of vsgExamples and your own applications.

A good example that relies upon vsg::ShaderCompiler to be fully functionally is vsgclip so a test like:

vsgclip models/lz.vsgt

Is a good test. If you want to try building the VSG without glslang you can change the cmake variable VSG_SUPPORTS_ShaderCompiler from 1 to 0. When built without shader compilation that vsgclip example will fail with an exception reporting that it can't compile the required shaders.

Thanks in advance for you help in testing.

[robertosfield]

I have just updated vsgFramework to use the glslang branch of the VSG, this means I can get rid of the glslang and SPIRV-Tools sections!

https://github.com/vsg-dev/vsgFramework/tree/glslang

[rolandhill]

Hi Robert,

I've pulled and built the glslang branch on Kubuntu and everything looks to be working fine, however, I notice that CMAKE has picked up the glslang executable from the VulkanSDK. So, I'm not quite sure if I'm using the VulkanSDK version or the one built into VSG. VSG_SUPPORTS_ShaderCompiler is set to 1 and there were lots of warnings as you predicted.

One of my shaders is a custom ShaderSet and the rest are generated as code by a ShaderFactory before being compiled on the fly. If I am using the VSG version of glslang then it's working well.

Is there a permanent way to direct VSG to use the built in versions? I don't want to be setting the glslang executable paths every time I use CMAKE.

Regards,
Roland

[robertosfield]

Hi Roland, Thanks for testing, it sounds like things are working as intended. If you are using the glslang branch of the VSG then you'll be using the compiled in glslang support. There isn't any linking of any external libraries for shader compilation now, it's either compiled in or not available. The version compiled in with be the one I cloned and tweaked on vsg-dev/glslang, the version of glslang that comes with VulkanSDK, installed from Ubunutu repo or just built independently by yourself won't affect the version that the VSG. One problem that may occur with the VSG compiling in glslang is if you also link to glslang in your application as the various glslang symbols will be multiply defined. If this happens simply remove the extra link to glslang as it isn't required for the VSG now. I've modified the VSG's cmake config support to not contain any glslang references now so this eventually will only happen if you've explicitly linked to glslang. Cheers, Robert.

[robertosfield]

Now that we are compiling in a specific modern version of glslang we know out of the box what features it has so I've been able to removed the conditional blocks and associated defines, this simplifies the CMake and ShaderCompiler.cpp code substantially - in fact github is reported 67 additions and 563 deletions. so nearly 500 lines less VSG code/scripts, The changes in glslang branch vs master are:

https://github.com/vsg-dev/VulkanSceneGraph/compare/glslang

On the VSG side I think I'm most there now, so will turn my attention to the compile errors in glslang that are being picked up because the VSG builds with more sensitive warnings enabled.

I've tested under Kubuntu but the code needs testing across Windows, macOS, iOS Android to make sure I haven't missed anything, I'd appreciate more community testing on these platforms. Please report successes or failures as this help us know how well things are converging.

[Mikalai]

Hello Robert,
I've built glslang branch on windows using VC++ compiler. vsg and examples build succeeded and "vsgclip models/lz.vsgt" works as expected. There were 3 warnings like

C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\src\glslang\SPIRV\SpvBuilder.cpp(1114,54): warning C4267: 'argument': conversio
n from 'size_t' to 'unsigned int', possible loss of data [C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\build\src\vsg\vsg.vcx
proj]
C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\src\glslang\SPIRV\SpvBuilder.cpp(2079,37): warning C4267: 'argument': conversio
n from 'size_t' to 'unsigned int', possible loss of data [C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\build\src\vsg\vsg.vcx
proj]
C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\src\glslang\SPIRV\SpvBuilder.cpp(2081,68): warning C4267: 'argument': conversio
n from 'size_t' to 'const spv::Id', possible loss of data [C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\build\src\vsg\vsg.vc
xproj]

[robertosfield]

@Mikalai I have made a fix for the first of the above 3 warnings, but I haven't figured out exactly what the fix should be for the second two. The glslang code is a bit inconsistent w.r.t type naming. I don't have Windows here to test against could you have a bash at fixing the above warnings? Even a hint as to what the compiling might have an issue should be enough for me to figure out what will be required.

[Mikalai]

As I understood the root cause is that parameter p has type size_t which is 8 bytes on 64 bit environment, while spv::Id is unsigned which is 4 bytes. Thus firstParamId + p has type size_t and it has to be narrowed to spv::Id when std::map<spv::Id, spv::Id>::operator [] and makeDebugDeclare are called. To fix this I've changed line 2067 in SpvBuilder.cpp like this

for(unsigned p = 0; p < static_cast<unsigned>(paramTypes.size()); ++p)

and this fixed warnings on lines 2079 and 2081.

I guess this is not applicable here, but just for information, to avoid such cast warnings gsl library can be used https://github.com/microsoft/GSL. It has gsl::narrow function that performs some checks and if narrowing truncated value, it throws exceptions at runtime, but when gsl::narrow is used it suppresses cast warnings.

[robertosfield]

Thanks I've merge this fix with my fork of glslang. Fingers crossed this means we'll now be warning free across platforms.

[robertosfield]

On Mon, 20 Feb 2023 at 20:36, Mikałaj ***@***.***> wrote: Hello Robert, I've built glslang branch on windows using VC++ compiler. vsg and examples build succeeded and "vsgclip models/lz.vsgt" works as expected. There were 3 warnings like C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\src\glslang\SPIRV\SpvBuilder.cpp(1114,54): warning C4267: 'argument': conversio n from 'size_t' to 'unsigned int', possible loss of data [C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\build\src\vsg\vsg.vcx proj] C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\src\glslang\SPIRV\SpvBuilder.cpp(2079,37): warning C4267: 'argument': conversio n from 'size_t' to 'unsigned int', possible loss of data [C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\build\src\vsg\vsg.vcx proj] C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\src\glslang\SPIRV\SpvBuilder.cpp(2081,68): warning C4267: 'argument': conversio n from 'size_t' to 'const spv::Id', possible loss of data [C:\Code\3rd\vulkan\VSG\VulkanSceneGraph\build\src\vsg\vsg.vc xproj]

Thanks for the testing, good to hear it's working. I spent most of today working through the glslang warnings that appear under Linux when using the warning options that the VSG users - there are hundreds of warnings so having just 3 under Windows would be a delight by comparison. It may be that the warnings that I fix for Linux will fix the above.

…

Message ID: ***@***.*** com>

[robertosfield]

I been doing tests of the VSG built with the glslang branch vs the VSG built against the glslang in VulkanSDK 1.3.239.0 and both create identical .spv when I run:

vsgconv vsgExamples/data/shaders/standard_pbr.frag standard_pbr.spv

I've been using vsgclip as a quick test as it's custom use of shaders requires runtime shader compilation and it works with VSG master and VSG glslang, and the later version is 1.1% smaller once the executable is stripped.

I'm pretty happy with the glslang branch, it might be a bit of goofy approach to solving the issues with integrating glslang but it seems to be working as well as I could have possibly hoped for.

Unless there is any issues raised I'll merge with VSG master today.