Vulkan Scene Graph’s Fork of glslang Repo and Future Development Plans

[turp2twin]

I’m reaching out to gather some insights into your fork of the Khronos Group’s glslang repository. Could you share the initial purpose behind this fork? Additionally, I’m interested in knowing what future plans you might have for this particular fork. Are there any specific development directions or enhancements you are targeting in the upcoming period? This information would be valuable to me and my continued development using vsg. Great work to the team!

Thank you for your time and assistance.

[robertosfield]

Hi Nik,

Thanks for reaching out.

The VulkanSceneGraph uses glslang to compile GLSL shaders at runtime to facilitate runtime shader composition. The VSG like the OpenSceneGraph(OSG) before adds to GLSL use #pragma to let the scene graph backends know what code shader paths are available for control - so features can be toggled on/off by passing in #defines, I coined the phrase "#pragma(tic) shader composition" when I came up with a long way back - over a decade ago. The VSG also can pre-compile to SPIR-V a set of different combinations of defines to avoid the need to compile at runtime, but there are always shader compile paths that may be required for applications so having the option to compile GLSL to SPIR-V is really helpful. An simple example of the type of shader we compile is that standard.vert - note the #pragma import_defines(..) and the way the defines are used in the shader - it's used a bit like OpenGL's modes can be used in the old fixed function world.

The VulkanSceneGraph (VSG) builds glslang from source as part of the VSG build so I forked glslang to make it possible to do it a bit more cleanly than was possible with main glslang repo. Most of the changes are warning fixes as the VSG builds with much tighter warning settings than glslang.

This building of glslang rather than linking to the glslang libraries is far from ideal, it really just a short term workaround for glslang developer libraries being distributed is such disparate forms, trying to keep the VSG compiling against all the possible forms of glslang that different repositories provided turned out to be a real nightmare. It was really hard to keep things compiling as 3rd party repos changed what they provided, these changes would break the VSG build and I ended up with lots of hacky CMake and C++ code to try and keep things mostly working across all platforms.

The "build our own folk of glslang" solution ended up the least awful solution, though I still consider it's still pretty awful though. I never meant the VSG to depend upon anything other than Vulkan, C++17 & CMake, so having glslang integrated in the way it as is an imperfect and undesirable holding place for when glslang becomes more reliably distributed by the various repos.

My ideal would be for use to drop the internally built glslang and our branch completely and just be able to rely upon 3rd party CMake find scripts. @AnyOldName3 has done a bit of work in this direction and has pushed some changes to the glslang project to help with this, I will have to defer to Chris to detail the work he's done in this direction.

Another possible route would be for us to ditch linking to glslang at compiling time and just load glslang at runtime and important the C symbols and work that way.

Another way would be for Khronos to directly support applications that need to compile GLSL etc. to SPIR-V at runtime with a utility library. Not all Vulkan based applications would need this but flexible middle-ware like the VSG need it, it's one of the few things I miss from OpenGL is not having this capability just there alongside the graphics library.

I hope this helps give a bit of insight to how we ended up with the kludge we have. We'd be happy to work with the glslang team to find a better way.

Cheers,
Robert Osfield
VulkanSceneGraph Project Lead.

[robertosfield]

@turp2twin I have now created a external_glslang branch of the VulkanSceneGraph that pulls in glslang-14.0 or later as an external dependency. If testing across all the plaforms that our users work on goes well I will merge this branch of VSG and it'll be included in master and then in turn as part of our up coming VulkanSceneGraph-1.2 stable release. I have written up these changes in the VSG Discussions thread #1199.

My hope is that testing will go smoothly and the VSG community will seamlessly shift across to using glslang provided by VulkanSDK, packaging systems or compiled from source. Once we;re at that point it would be great to see glslang evolve and maintain it's inclusion in VulkanSDK, packaging systems etc. as library we can rely upon in the years ahead. This should also make it easier for VulkanSceneGraph users to test and make improvements to glslang more directly as my fork of glslang solved a short term problem but precluded any easy contributions back to gslang.