Moving glslang dependencies build out of the VulkanSceneGraph as back to optional external dependency

[robertosfield]

In the early days of development the VulkanSceneGraph linked to glslang as an external dependency but this was fraught with issues of different 3rd party repositories presenting different versions of glslang and packaging them in inconsistent ways, and the versioning of glslang at times as well - it was nightmare trying to keep the VSG building cleanly with all these combinations of how glslang presented itself.

The solution I ended up with was to build the glslang source code as part of the VulkanSceneGraph itself. To achieve this I had to branch glslang and fixes a large number of warnings - VulkanSceneGraph uses stricter warning levels than glslang, but it's worked reasonably well - it's pretty unobtrusive for most users. However, it's not idea, it's a workaroud to what was a tangled mess of inconsistencies.

Fast forward to do today and glslang-14.x is finally becoming more consistent distributed - LunarG's VulkanSDK 1.3.283.0 now includes a modern enough glslang, it's header and crucially the cmake config files on all platform build combinations. vcpkg inlcudes glslang and a modern enough version of gslang is included in K/Ubuntu 24.04 LTS, and the glslang repo itself is good enough place to rely upon.

This improvement in the availability of glslang-14.x in usable forms means we can revisit how we include glslang and try out linking to as an optional dependency, so as a trial I have created an external_glslang branch that gets rid of the internal gslang build and just links to the external glslang:

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

I have tested under Kubuntu 20.04, 22.04 and 24.04, and will be continuing testing of Windows 11 today. Under Kubuntu 20.04 and 22.04 the version of glslang they provide is not modern enough so if you want to use runtime shader compilation then you need to build glslang from source or use VulkanSDK-1.3.283.0 or later. Under Windows's using VulkanSDK-1.3.283.0 or later should be sufficient, as well as pulling in glslang fom vcpkg - but that's something I'll confirming today.

I would appreciate members of the community testing out the external_glslang branch on their systems. CMake configure step will say if it's found an appropriate version of glslang or not. If it doesn't find a suitable version then the VSG build will work fine but won't be able to build in support for compiling GLSL shaders to SPIRV at runtime.

The current vsgshadow example default code path utilizes shadow compilation so just running it will let you know if everything is built with glslang successfully, checked the include/vsg/Version.h for the include/vsg/core/Version.h will also show support or not, the is what mine looks like right now with support:

/// vsg::ShaderCompiler support enabled when 1, disabled when 0
#define VSG_SUPPORTS_ShaderCompiler 1

While I have access to various versions of Kubuntu and Windows 11 here I don't have prior versions of Windows, Android, macOS or other Linux distros so I am reliant on members of the community with these systems to test things out.

I have updated the build instructions a little already to reflect these changes but I'll need to refine them further before the VulkanSceneGraph-1.2 stable release, so please have a read through those as well and make suggestion/amendments to make them more helpful and up to date.

Thanks.
Robert.

[AnyOldName3]

In my testing the 1.3.283 Vulkan SDK for Windows was still missing SPIRV-ToolsConfig.cmake, and without it, find_package(glslang CONFIG) would fail. However, the branch works fine for me with self-built glslang. https://vulkan.lunarg.com/issue/home?limit=10;q=;mine=false;org=false;khronos=false;lunarg=false;indie=false;status=new,open seems to be the current tracker entry for missing bits of CMake config in the Vulkan SDK, so hopefully it'll get fixed.

[robertosfield]

To make it possible to check the VSG version to deter,mine when glslang is an external dependency I have just bumped the VSG version to 1.1.5 in the external_glslang branch 16b8369

---

When testing external_glslang branch on Windows I found out, as Chris mentions above, that VulkanSDK-1.3.283's inclusion of gslang is a bit broken, so had to fallback to using the glslang in vcpkg. I had to update my vcpkg to get the latest version of their glslang which is now 14.2. With the vcpkg installed everything worked great, including fixes a crash that was happening due to the glslang fork that the VSG was compiling in prior to the external_glslang branch,

[rainergericke]

I made tests on macOS today. The VulkanSDK-1.3.283's inclusion of gslang is a bit broken indeed. Using a glslang installation provided by homebrew (a package manager for Mac) worked out of the box.

[robertosfield]

Thanks for the testing @rainergericke. Which version of glslang comes with homebrew?

[rainergericke]

glslang --version:

Glslang Version: 11:14.2.0
ESSL Version: OpenGL ES GLSL 3.20 glslang Khronos. 14.2.0
GLSL Version: 4.60 glslang Khronos. 14.2.0
SPIR-V Version 0x00010600, Revision 1
GLSL.std.450 Version 100, Revision 1
Khronos Tool ID 8
SPIR-V Generator Version 11
GL_KHR_vulkan_glsl version 100
ARB_GL_gl_spirv version 100

[robertosfield]

Thanks. 14.2 is the version I saw with vcpkg on Windows as well.

[robertosfield]

We'll need to update the platform specific dependency and install notes to mention how to install glslang.

@rainergericke could you provide a bit of text & command line (if it's command line) on installing glsalng from homebrew so it can be included in the INSTALL.md notes? A PR would be fine too.

[rainergericke]

Installation of vsg with external glslang is straight forward on the Mac:

1. get a glslang distribution with homebrew:
   brew install glslang

2. configure vsg with cmake, it finds glslang automatically (commandline or cmake-gui)
   cmake -S /sourceDirPath/VulkanSceneGraph -B vsgBuild -G Ninja
   cmake --build vsgBuild
   cmake --install vsgBuild --prefix /PrefixDirPath

/sourceDirPath and /PrefixDirPath must be set to the user needs.

[robertosfield]

Thanks for the testing. Could you provide some instructions for the "## Quick build instructions for macOS using Xcode 9" section of VulkanSceneGraph/INSTALL.md? We have some instructions in place already but I think they'll be out of date now.

[theodoregoetz]

Tested on the external_glslang branch:

• Working: Fedora 40 (glslang 14.2)
• Working: Fedora 39 (glslang 14.0)

To install glslang-devel for the header files and unversioned libs, run dnf install glslang-devel.
Complete dependency install command from the base Fedora container:

dnf install git cmake ninja-build gcc-c++ libxcb-devel vulkan-loader-devel glslc glslang-devel

Build commands used:

git clone --branch external_glslang https://github.com/vsg-dev/VulkanSceneGraph.git
cd VulkanSceneGraph
cmake -B build -S . -GNinja
cmake --build build

[robertosfield]

Thanks for the testing and suggestions. I'm currently updating the INSTALL.md to include the above dnf entry. I'd like to standardize the cmake instructions as much as possible across platform combinations. Is the -GNinja required? What is the reason to prefer Ninja over standard Makefiles?

[AnyOldName3]

Ninja can be significantly faster on machines with lots of cores.

[rainergericke]

Cmake has also the generator option "Ninja Multi-Config". If used it is possible to build vsg in Release and in Debug mode without reconfiguration. Could be interesting for people who want to build both versions of vsg.

[theodoregoetz]

Ninja is not required but I've ceased to use Makefiles since about 2008 and I don't want to go back. Usually I have the CMAKE_GENERATOR environment variable set to "Ninja" in my ~/.zshrc file, but I made it explicit in the commands above to show my work.

[theodoregoetz]

Rockylinux 8 still ships with glslang 12.2
and Rockylinux 9 ships with glslang 13.1
both of which fail the find_package() version check.

[AnyOldName3]

You can still build a newer glslang version manually, though, right? You're already building the VSG, so it's hardly the end of the world if you also need to build one of its dependencies. You might need a newer version of CMake than you OS package repo provides by default, but usually there's a supported way to get a newer one.

[theodoregoetz]

yes, of course, and we do. On Rockylinux, we use devtoolset which bring most of the tools close enough to the latest versions that we don't usually have any problem.

[robertosfield]

As testing looked to have gone relatively smoothly I have gone ahead and merged the external_glslang branch with VSG master:

#1216

The VSG version has been bumped to 1.1.5 in prep for me tagging another developer release tomorrow. Could folks test VSG master and let me know if there are issues, or if there a refinements to the INSTALL.md docs to help guide developers on different platform combinations please post them here or generate a PR for them.

Thanks.

[rainergericke]

My tests of VSG version 1.1.5 were successful on macOS 14.5.

[frozenaccident]

Windows 10:
Used pre-built GLSLANG 14.2 - failed to configure the cmake project, cmakelists says glslang not found
Built GLSLANG 14.2 and installed it myself - failed to configure the cmake project, cmakelists says glslang not found
in both cases i also tried various environment variables, like glslang_DIR, paths to the bin folder, and what not... still can't find glslang
it finds glslangValidator successfully though:

[cmake] glslang not found. ShaderCompile support disabled.
[cmake] -- The following OPTIONAL packages have not been found:
[cmake] * glslang (required version >= 14)

EDIT: I also noticed that there's no glslangConfig.cmake in the lib\cmake folder

[AnyOldName3]

If you built and installed glslang, either you specified a CMake install prefix, or you let it default to C:\Program Files\glslang. Whichever path you used needs to be included in CMAKE_PREFIX_PATH either as an environment variable or CMake variable (depending on what's most convenient for your workflow). There'll definitely be a lib\cmake\glslang\glslang-config.cmake relative to that path.

[frozenaccident]

Unfortunately, it didn't help.
I tried 'set (CMAKE_PREFIX_PATH="C:/glslang")', tried various paths within this folder just to be sure, nothing helps.
There's no 'glslang' folder in the lib\cmake directory that usually contains glslang-config.cmake and glslang-targets.cmake files like the ones found in VulkanSDK directory.

Meanwhile, there's glslang that's delivered with VulkanSDK and checking with the command 'glslang --version' shows:
Glslang Version: 11:14.2.0

So I then tried adding this:
set(VULKAN_SDK_PATH "C:/VulkanSDK/1.3.283.0")
find_package(glslang REQUIRED HINTS "${VULKAN_SDK_PATH}/Lib/cmake")

which resulted in:

            Could not find a package configuration file provided by "SPIRV-Tools-opt"
            with any of the following names:

            SPIRV-Tools-optConfig.cmake
            spirv-tools-opt-config.cmake

            Add the installation prefix of "SPIRV-Tools-opt" to CMAKE_PREFIX_PATH or
            set "SPIRV-Tools-opt_DIR" to a directory containing one of the above files.
            If "SPIRV-Tools-opt" provides a separate development package or SDK, be
            sure it has been installed.

Thanks for the reply!

[AnyOldName3]

The glslang bundled with the Vulkan SDK is missing some important parts of its CMake config because LunarG just seem to copy a random subset of the files with each release. It's on their issue tracker, but they're not prioritising it for whatever reason.

[robertosfield]

Anton could you try the glslang in vcpkg rather than the one currently provided by the VulkanSDK, this one does at least have the correct CMake config support.

As Chris mentions LunarG haven't correctly handled the cmake config files for glslang in the Windows VulkanSDK so for now under Windows we'll need to fallback to using vcpkg or building and install glslang from source. Hopefully LunarG will sort it out for the next release of VulkanSDK.

[frozenaccident]

Thanks Robert, I couldn't get it to work via VCPKG, because I presumably lack some MSVS dependencies, but I had a success with MSYS2.
By the way, VCPKG offers version 1.3.280.0, while MSYS2 downloaded the latest Vulkan.
My steps after I had installed basic stuff like compilers and Vulkan through MSYS2 were:

• pacman -S mingw-w64-x86_64-glslang
• opened PowerShell and pasted: $Env:glslang_DIR = "path_to:\msys64\mingw64\lib\cmake\glslang".
  (This command sets the environment variable for the current session only).

EDIT: although i was able to configure the CMake project I can't compile it because of errors of this kind:
cstdlib:141:11: error: 'at_quick_exit' has not been declared in '::' 141 | using ::at_quick_exit

[robertosfield]

You shouldn't need the latest Vulkan in order to use glslang with vcpkg. When I tested under Windows 11 I was able to pull in glslang 14.2 from vcppkg, but first I had to pull the latest vcpkg as my checkout from earliery this year pulled in gslang-13.x which isnn't modern enough to build with the VSG.

I haven't tried mys2 so can't comment on specifics. In general if you are installing dependencies that have cmake config support you should be able to just point CMAKE at the path where all those libs are installed rather needn't to specifically set glslang_DIR etc.

[frozenaccident]

MSYS2 is giving me cancer rn lol, I guess there's an issue with my overall setup. Thank you once again!

EDIT: It turned out i didn't have cmake installed in my MSYS2 environment, so pacman -S mingw-w64-x86_64-cmake resolved the issue. Now, everything works as expected, have successfully compiled vsg.
I had to delete the previous cmake-tools-kits.json file in User/App/Local/CMakeTools and create settings.json in the vsg folder with this setup:

{
"C_Cpp.default.compilerPath": "C:\msys64\mingw64\bin\gcc.exe",
"C_Cpp.default.cppCompilerPath": "C:\msys64\mingw64\bin\g++.exe",
"cmake.cmakePath": "C:\msys64\mingw64\bin\cmake.exe",
"cmake.generator": "MinGW Makefiles",
"cmake.configureSettings": {
"CMAKE_MAKE_PROGRAM": "C:\msys64\mingw64\bin\mingw32-make.exe"
}
}

Then I chose the necessary kit in VS Code.
Thus glslang was found and CMake was able to find the compiler.

[AnyOldName3]

glslang has a C++ API, not a C API, so you need to build it with MinGW with an MSYS2 environment matching the one you're building VulkanSceneGraph with if you're building VulkanSceneGraph with MinGW for MSYS2, and you need to build glslang with MSVC if you're building VulkanSceneGraph with MSVC. You can't mix and match MSVC and MinGW here or mix MSYS2 environments.

[robertosfield]

I haven't worked on vsgFramework recently but it could be useful for folks that are finding it awkward to build dependencies alongside the VulkanSceneGraph. Tomorrow I'll update it to include building glslang before the VSG in prep for the VSG-1.0.5 release that I'll make this coming week.

[Mikalai]

@robertosfield Probably there is an issue on Windows with latest master and maybe this is related to glslang changes. I was using instance positions and after upgrade it started to crash. I've reproduced this on a modified example. In vsgbuilder example 'box if' changed to this:

if (box)
{
    geomInfo.position += geomInfo.dx * 1.5f;
    auto positions = vsg::vec3Array::create(5);
    geomInfo.positions = positions;
    for (int i = 0; i < 5; ++i)
    {
        (*positions)[i].set(geomInfo.position.x, geomInfo.position.y, geomInfo.position.z + i * 4);
    }
    stateInfo.instance_positions_vec3 = true;

    auto node = builder->createBox(geomInfo, stateInfo);
    bound.add(geomInfo.position);            

    if (auto sg = node.cast<vsg::StateGroup>(); sg && inherit)
    {
        options->inheritedState = sg->stateCommands;
        scene = sg;
    }
    else
    {
        scene->addChild(node);
    }
    stateInfo.instance_positions_vec3 = false;
}

And on Visual Studio 2022 on windows 11 it crashes. The callstack:

>	vsgbuilder.exe!std::vector<spv::Block *,std::allocator<spv::Block *>>::back() Line 1954	C++
 	vsgbuilder.exe!spv::Function::getLastBlock() Line 389	C++
 	vsgbuilder.exe!`anonymous namespace'::TGlslangToSpvTraverser::visitAggregate(glslang::TVisit visit, glslang::TIntermAggregate * node) Line 2967	C++
 	vsgbuilder.exe!glslang::TIntermAggregate::traverse(glslang::TIntermTraverser * it) Line 159	C++
 	vsgbuilder.exe!`anonymous namespace'::TGlslangToSpvTraverser::visitFunctions(const glslang::TVector<TIntermNode *> & glslFunctions) Line 5660	C++
 	vsgbuilder.exe!`anonymous namespace'::TGlslangToSpvTraverser::visitAggregate(glslang::TVisit visit, glslang::TIntermAggregate * node) Line 2926	C++
 	vsgbuilder.exe!glslang::TIntermAggregate::traverse(glslang::TIntermTraverser * it) Line 159	C++
 	vsgbuilder.exe!glslang::GlslangToSpv(const glslang::TIntermediate & intermediate, std::vector<unsigned int,std::allocator<unsigned int>> & spirv, spv::SpvBuildLogger * logger, glslang::SpvOptions * options) Line 10383	C++
 	vsgbuilder.exe!vsg::ShaderCompiler::compile(std::vector<vsg::ref_ptr<vsg::ShaderStage>,std::allocator<vsg::ref_ptr<vsg::ShaderStage>>> & shaders, const std::vector<std::string,std::allocator<std::string>> & defines, vsg::ref_ptr<vsg::Options const> options) Line 287	C++
 	vsgbuilder.exe!vsg::GraphicsPipeline::compile(vsg::Context & context) Line 161	C++
 	vsgbuilder.exe!vsg::BindGraphicsPipeline::compile(vsg::Context & context) Line 284	C++
 	vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::Compilable & node) Line 241	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::Command & value) Line 709	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::StateCommand & value) Line 713	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::BindGraphicsPipeline & value) Line 769	C++
 	vsgbuilder.exe!vsg::Inherit<vsg::StateCommand,vsg::BindGraphicsPipeline>::accept(vsg::Visitor & visitor) Line 70	C++
 	vsgbuilder.exe!vsg::StateGroup::t_traverse<vsg::StateGroup,vsg::Visitor>(vsg::StateGroup & node, vsg::Visitor & visitor) Line 69	C++
 	vsgbuilder.exe!vsg::StateGroup::traverse(vsg::Visitor & visitor) Line 73	C++
 	vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::Object & object) Line 232	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::Node & value) Line 530	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::Group & value) Line 542	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::StateGroup & value) Line 558	C++
 	vsgbuilder.exe!vsg::Inherit<vsg::Group,vsg::StateGroup>::accept(vsg::Visitor & visitor) Line 70	C++
 	vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51	C++
 	vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54	C++
 	vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::Object & object) Line 232	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::Node & value) Line 530	C++
 	vsgbuilder.exe!vsg::Visitor::apply(vsg::Group & value) Line 542	C++
 	vsgbuilder.exe!vsg::Inherit<vsg::Node,vsg::Group>::accept(vsg::Visitor & visitor) Line 70	C++
 	vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51	C++
 	vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54	C++
 	vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::View & view) Line 391	C++
 	vsgbuilder.exe!vsg::View::t_accept<vsg::View,vsg::Visitor>(vsg::View & node, vsg::Visitor & visitor) Line 56	C++
 	vsgbuilder.exe!vsg::View::accept(vsg::Visitor & visitor) Line 59	C++
 	vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51	C++
 	vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54	C++
 	vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::RenderGraph & renderGraph) Line 353	C++
 	vsgbuilder.exe!vsg::Inherit<vsg::Group,vsg::RenderGraph>::accept(vsg::Visitor & visitor) Line 70	C++
 	vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51	C++
 	vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54	C++
 	vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::CommandGraph & commandGraph) Line 278	C++
 	vsgbuilder.exe!vsg::Inherit<vsg::Group,vsg::CommandGraph>::accept(vsg::Visitor & visitor) Line 70	C++
 	vsgbuilder.exe!vsg::Viewer::compile(vsg::ref_ptr<vsg::ResourceHints> hints) Line 378	C++
 	vsgbuilder.exe!main(int argc, char * * argv) Line 327	C++
 	vsgbuilder.exe!invoke_main() Line 79	C++
 	vsgbuilder.exe!__scrt_common_main_seh() Line 288	C++
 	vsgbuilder.exe!__scrt_common_main() Line 331	C++
 	vsgbuilder.exe!mainCRTStartup(void * __formal) Line 17	C++
 	kernel32.dll!00007ffede03257d()	Unknown
 	ntdll.dll!00007ffedef6af28()	Unknown

I take glslang from vcpkg. Current glslang version there is 14.2.0.

Failing point in glslang is builder.setBuildPoint(shaderEntry->getLastBlock());

case glslang::EOpFunction:
    if (visit == glslang::EvPreVisit) {
        if (options.generateDebugInfo) {
            builder.setDebugSourceLocation(node->getLoc().line, node->getLoc().getFilename());
        }
        if (isShaderEntryPoint(node)) {
            inEntryPoint = true;
            builder.setBuildPoint(shaderEntry->getLastBlock());
            builder.enterFunction(shaderEntry);
            currentFunction = shaderEntry;
        } else {
            handleFunctionEntry(node);
        }

shaderEntry is null and this causes access violation. Maybe this is a miss configuration on my side, but I don't know what can be done else.

[robertosfield]

Check if your VSG picked up on glslang. If it isn't the VSG will still build but without shader compile support and won't be able to handle all SHaderSet combinations

…

On Sun, 23 Jun 2024, 00:27 Mikałaj, ***@***.***> wrote: @robertosfield <https://github.com/robertosfield> Probably there is an issue on Windows with latest master and maybe this is related to glslang changes. I was using instance positions and after upgrade it started to crash. I've reproduced this on a modified example. In vsgbuilder example 'box if' changed to this: if (box) { geomInfo.position += geomInfo.dx * 1.5f; auto positions = vsg::vec3Array::create(5); geomInfo.positions = positions; for (int i = 0; i < 5; ++i) { (*positions)[i].set(geomInfo.position.x, geomInfo.position.y, geomInfo.position.z + i * 4); } stateInfo.instance_positions_vec3 = true; auto node = builder->createBox(geomInfo, stateInfo); bound.add(geomInfo.position); if (auto sg = node.cast<vsg::StateGroup>(); sg && inherit) { options->inheritedState = sg->stateCommands; scene = sg; } else { scene->addChild(node); } stateInfo.instance_positions_vec3 = false; } And on Visual Studio 2022 on windows 11 it crashes. The callstack: > vsgbuilder.exe!std::vector<spv::Block *,std::allocator<spv::Block *>>::back() Line 1954 C++ vsgbuilder.exe!spv::Function::getLastBlock() Line 389 C++ vsgbuilder.exe!`anonymous namespace'::TGlslangToSpvTraverser::visitAggregate(glslang::TVisit visit, glslang::TIntermAggregate * node) Line 2967 C++ vsgbuilder.exe!glslang::TIntermAggregate::traverse(glslang::TIntermTraverser * it) Line 159 C++ vsgbuilder.exe!`anonymous namespace'::TGlslangToSpvTraverser::visitFunctions(const glslang::TVector<TIntermNode *> & glslFunctions) Line 5660 C++ vsgbuilder.exe!`anonymous namespace'::TGlslangToSpvTraverser::visitAggregate(glslang::TVisit visit, glslang::TIntermAggregate * node) Line 2926 C++ vsgbuilder.exe!glslang::TIntermAggregate::traverse(glslang::TIntermTraverser * it) Line 159 C++ vsgbuilder.exe!glslang::GlslangToSpv(const glslang::TIntermediate & intermediate, std::vector<unsigned int,std::allocator<unsigned int>> & spirv, spv::SpvBuildLogger * logger, glslang::SpvOptions * options) Line 10383 C++ vsgbuilder.exe!vsg::ShaderCompiler::compile(std::vector<vsg::ref_ptr<vsg::ShaderStage>,std::allocator<vsg::ref_ptr<vsg::ShaderStage>>> & shaders, const std::vector<std::string,std::allocator<std::string>> & defines, vsg::ref_ptr<vsg::Options const> options) Line 287 C++ vsgbuilder.exe!vsg::GraphicsPipeline::compile(vsg::Context & context) Line 161 C++ vsgbuilder.exe!vsg::BindGraphicsPipeline::compile(vsg::Context & context) Line 284 C++ vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::Compilable & node) Line 241 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::Command & value) Line 709 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::StateCommand & value) Line 713 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::BindGraphicsPipeline & value) Line 769 C++ vsgbuilder.exe!vsg::Inherit<vsg::StateCommand,vsg::BindGraphicsPipeline>::accept(vsg::Visitor & visitor) Line 70 C++ vsgbuilder.exe!vsg::StateGroup::t_traverse<vsg::StateGroup,vsg::Visitor>(vsg::StateGroup & node, vsg::Visitor & visitor) Line 69 C++ vsgbuilder.exe!vsg::StateGroup::traverse(vsg::Visitor & visitor) Line 73 C++ vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::Object & object) Line 232 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::Node & value) Line 530 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::Group & value) Line 542 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::StateGroup & value) Line 558 C++ vsgbuilder.exe!vsg::Inherit<vsg::Group,vsg::StateGroup>::accept(vsg::Visitor & visitor) Line 70 C++ vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51 C++ vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54 C++ vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::Object & object) Line 232 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::Node & value) Line 530 C++ vsgbuilder.exe!vsg::Visitor::apply(vsg::Group & value) Line 542 C++ vsgbuilder.exe!vsg::Inherit<vsg::Node,vsg::Group>::accept(vsg::Visitor & visitor) Line 70 C++ vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51 C++ vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54 C++ vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::View & view) Line 391 C++ vsgbuilder.exe!vsg::View::t_accept<vsg::View,vsg::Visitor>(vsg::View & node, vsg::Visitor & visitor) Line 56 C++ vsgbuilder.exe!vsg::View::accept(vsg::Visitor & visitor) Line 59 C++ vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51 C++ vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54 C++ vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::RenderGraph & renderGraph) Line 353 C++ vsgbuilder.exe!vsg::Inherit<vsg::Group,vsg::RenderGraph>::accept(vsg::Visitor & visitor) Line 70 C++ vsgbuilder.exe!vsg::Group::t_traverse<vsg::Group,vsg::Visitor>(vsg::Group & node, vsg::Visitor & visitor) Line 51 C++ vsgbuilder.exe!vsg::Group::traverse(vsg::Visitor & visitor) Line 54 C++ vsgbuilder.exe!vsg::CompileTraversal::apply(vsg::CommandGraph & commandGraph) Line 278 C++ vsgbuilder.exe!vsg::Inherit<vsg::Group,vsg::CommandGraph>::accept(vsg::Visitor & visitor) Line 70 C++ vsgbuilder.exe!vsg::Viewer::compile(vsg::ref_ptr<vsg::ResourceHints> hints) Line 378 C++ vsgbuilder.exe!main(int argc, char * * argv) Line 327 C++ vsgbuilder.exe!invoke_main() Line 79 C++ vsgbuilder.exe!__scrt_common_main_seh() Line 288 C++ vsgbuilder.exe!__scrt_common_main() Line 331 C++ vsgbuilder.exe!mainCRTStartup(void * __formal) Line 17 C++ kernel32.dll!00007ffede03257d() Unknown ntdll.dll!00007ffedef6af28() Unknown I take glslang from vcpkg. Current glslang version there is 14.2.0. Failing point in glslang is builder.setBuildPoint(shaderEntry->getLastBlock()); case glslang::EOpFunction: if (visit == glslang::EvPreVisit) { if (options.generateDebugInfo) { builder.setDebugSourceLocation(node->getLoc().line, node->getLoc().getFilename()); } if (isShaderEntryPoint(node)) { inEntryPoint = true; builder.setBuildPoint(shaderEntry->getLastBlock()); builder.enterFunction(shaderEntry); currentFunction = shaderEntry; } else { handleFunctionEntry(node); } shaderEntry is null and this causes access violation. Maybe this is a miss configuration on my side, but I don't know what can be done else. — Reply to this email directly, view it on GitHub <#1199 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKEGUGNEPCYEOE73RLC4B3ZIYB4ZAVCNFSM6AAAAABIDHBF7SVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TQNBZGI4TI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

[Mikalai]

I guess vsg picked up glslang. In CMakeCache:
//The directory containing a CMake configuration file for glslang.
glslang_DIR:PATH=D:/Code/3rd/vcpkg/installed/x64-windows/share/glslang

Also, before when indeed there was no glslang I saw a fatal in console like:
VulkanSceneGraph not compiled with GLSLang, unable to compile shaders.

After that I realized that there were changes regarding glslang. I've upgraded vcpkg, installed glslang from there, rebuild VSG. During cmake config it reported that it found optional glslang. But unfortunately the crash above happens after these changes.

[Mikalai]

I figured out the problem. Despite glslang was found in vcpkg when vsg is build header file was taken from VULKAN_SDK installation path. And I had 1.3.250.1 where glslang::SpvOptions had not compileOnly attribute but, what is weird, looks like when VSG is build it takes header from VULKAN_SDK but lib files from vcpkg. As lib in vcpkg expects newer SpvOptions which is bigger with additional compileOnly attribute, it receives some garbage which is interpreted as true, and according to source code when compileOnly is true shaderEntry is not created which leads to the crash I've observed. When I updated SDK to 1.3.283.0 where compileOnly exists sample started to work. So this is environmental, but actually currently I don't know how to properly configure VSG build thus there is no interference between vcpkg glslang and the one in vulkan sdk. Probably I should remove glslang from vcpkg and feed VSG the one from VULKAN_SDK.

[Mikalai]

Failed to configure vsg build with glslang from vulkan sdk, probably due to issues in sdk itself mentioned above. Switched back to vcpkg. Adjusted paths to be sure that glslang include files are taken from vcpkg. Now all works fine. But this issue with path ordering is a bit tricky.

[robertosfield]

Good to hear you've resolved things.

Writing this all up as you've done helps give us and others in the community clues as it what cases things can fail and what to do with.

I'm hoping these teething problems will resolve themselves as VulkanSDK addresses it's flawed glslang support and vcpkg Vulkan matures. Until then we'll have to try to come up with clearer instructions for users to avoid the potential pitfalls.

[smacl6301]

Long time Windows C++ hack here but not a regular user of cmake or vcpkg. Using VisualStudio 2022, I need glslang to use vsgPoints and had quite a time getting this all to work. It turns out vcpkg in Visual Studio 2022 also has issues, see https://superuser.com/questions/1829880/vcpkg-could-not-locate-a-manifest-vcpkg-json which I got around by using vcpkg from Visual Studio 2017. Unfortunately, the vsg cmake does not like the results so I ended up cloning and building glslang and SPIRV from github, links below;

GLSLang, https://github.com/KhronosGroup/glslang
SPIRV https://github.com/KhronosGroup/SPIRV-Tools

Rebuilding vsg then led to a bunch of import errors;

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::glslang"
configuration "Debug".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target
"glslang::glslang-default-resource-limits" configuration "Debug".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::SPIRV"
configuration "Debug".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::glslang"
configuration "Release".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target
"glslang::glslang-default-resource-limits" configuration "Release".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::SPIRV"
configuration "Release".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::glslang"
configuration "MinSizeRel".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target
"glslang::glslang-default-resource-limits" configuration "MinSizeRel".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::SPIRV"
configuration "MinSizeRel".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::glslang"
configuration "RelWithDebInfo".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target
"glslang::glslang-default-resource-limits" configuration "RelWithDebInfo".

CMake Error in CMakeLists.txt:
IMPORTED_LOCATION not set for imported target "glslang::SPIRV"
configuration "RelWithDebInfo".

Generating done (0.1s)

My workaround here was to manually add the glslang and SPIRV directories and libraries to all the vsg visual studio solutions, removing the otherwise linked Vulkan SDK ones. My thinking that having an installer with pre-built solutions and libraries would be a significant boon for potential new Windows vsg users coming from a different tool-chain as getting a vsg development environment up and running under Windows is a long and frustrating exercise for those of us not overly familiar with cmake.

[vsg-dev]

I checked out vcpkg from github myself, I didn't realized that VS would have inbuilt as well. I got a Windows 11 machine back in January and installed VisualStudio 2022 and have been working part time under Windows since then, still consider myself a Windows newbie though.

Rather than making our platform binaries I think it would be best to support 3rd party packaging schemes like vcpkg and have them provide the VSG and other associated projects. This way we can work better with native packaging schemes that users will be familiar with rather than duplicate and maintain our own packaging of binaries and headers.

Currently we are on a 1.1.x developers series track, once we get closer to the next stable release - which will be 1.2.0 I'll call for help form the community to get the VSG and sibling projects in a place that they can be easily integrated with 3rd party packaging schemes. I need help with it, there are too many different packaging schemes on different platforms to attempt to take this work on as well as maintain/developer the VSG itself.

[smacl6301]

I guess there is a trade-off here between ease of use versus the advantage of using 3rd party packaging. As someone who builds and uses a reasonable number of open source packages (e.g. OpenCV, PROJ, GDAL, Xerces, LibTiff, Zlib etc...) the combination of vsg, vsgXchange and vsgPoints has been by far the most challenging to work with. As a Windows developer using an SDK such as vsg, first and foremost I need a set of libs and header files I can use with my program. Second is to be able rebuild these from source using Visual Studio solution and project files. If these can be generated from Cmake, so much the better. If however running cmake generates a bunch of errors relating to 3rd party dependencies, which I need to dig out and build based on their dependencies things get really messy really quickly. Having a prebuilt snapshot of solution files and libraries for a recent stable release would remove a lot of headaches, even if the version in play might be missing the latest and greatest functional enhancements and fixes. Just my 2c.

[vsg-dev]

The VSG it newer and has newer dependencies than the likes of OpenCV and PROJ and GDAL etc. so we're earlier in the cycle of resolving all the possible gotcha on different platform combinations. The change to moving glslang back out of the core VSG build is recent change for us, longer term it should help, but under Windows it looks be a bit fragile on the glslang front so will take a bit more time for us to navigate the gotchas and for likes of LunarG to resolve the problems they have with VulkanSDK etc.

Pre-built binaries is a fine idea but for what platform combination? The VSG user base covers a diverse range of platforms this isn't a straight-forward task. We don't have magic time and money faries that can do all the required work for us so it's a case of trying to come up with the solutions that cover the widest bases whilst minimizing the overheads in time and money.

[frozenaccident]

it's fine, i'm so grateful for this instrument no matter what, can't wait for 1.2

[AnyOldName3]

As I've said in a few places now, if you're not already familiar with vcpkg, it's probably easiest for Windows users to just build glslang according to the instructions in its readme, which basically amount to

cd <parent of where you want glslang to be>
git clone https://github.com/KhronosGroup/glslang.git
cd glslang
.\update_glslang_sources.py
mkdir build
cd build
# this will probably default to the latest Visual Studio generator you've got installed and require no extra arguments
cmake .. 
# feel free to specify RelWithDebInfo or Debug or to do this for more than one config
cmake --build . --config Release
cmake --install . --config Release --prefix ..\install

and then simply specify -DCMAKE_PREFIX_PATH=<parent of where you want glslang to be>\glslang\install when configuring VSG, which presumably you already know how to do if you built vsgXchange.