A crash occurs when testing vsgPoints Demo.

[XMatrixXiang]

vsgPoints Tag 0.6; VulkanSceneGraph Tag: 1.1.7 glslang: 14.3.0 using the input parameter "--flat --mesh D:\workspace\dev\vsgExamples-dev\data\models\lz.vsgt", a crash occurs.

The final crash stack is shown in the figure below.

[robertosfield]

Just tried VSG master and vsgPoints master on Kubuntu 24.04:

vsgpoints_example --mesh --flat models/lz.vsgt

Everything works correctly, this is what you should see:

Have you built the VulkanSceneGraph against glslang? Check the include/vsg/core/Version.h to see if CMake has found glslang and built the VSG against it, the VSG_SUPPORTS_ShaderCompiler macro will be set to 1 if everything is set up correctly.

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

[XMatrixXiang]

Just tried VSG master and vsgPoints master on Kubuntu 24.04:

vsgpoints_example --mesh --flat models/lz.vsgt

Everything works correctly, this is what you should see:

Have you built the VulkanSceneGraph against glslang? Check the include/vsg/core/Version.h to see if CMake has found glslang and built the VSG against it, the VSG_SUPPORTS_ShaderCompiler macro will be set to 1 if everything is set up correctly.

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

I checked the CMake configuration. There is no problem with the configuration of glslang. I tried to use the master branch and switched glslang to 14.2.0. The vsgPoints demo still cannot run normally.

[XMatrixXiang]

I provide Vulkan by installing VulkanSDK - 1.3.296.0 - Installer.exe. Does this version also need to be specified?

[robertosfield]

Could you step through the code with a debugger to see what is going wrong in the call that crashes?

[XMatrixXiang]

Could you step through the code with a debugger to see what is going wrong in the call that crashes?

Just now, I debugged the vsgpoints_example program through Vs. The crash stack when using the parameters --flat --mesh lz.vsgt is shown in the following figure:

[robertosfield]

OK, this telling us you using a VSG version that isn't built against gslang, so shader compiler support is not available.

You'll need to make sure vsgPoints is linking to a version of the VSG has been built against glslang, perhaps you have two VSG's installed and vsgPoints is linking to the one without glslang/Compile Compilation support.

[robertosfield]

I disabled use of glslang in my VSG via cmake and rebuilt the VSG, vsgXchange and vsgPoints and when I run vsgpoints_example this is what I see:

$ vsgpoints_example --mesh --flat models/lz.vsgt
Time to read points = 0.0100021 seconds
Converted mesh to 8,964 points.
Could not create window.

When I re-enable glslang/ShaderComposition I see the scene correctly rendered:

$ vsgpoints_example --mesh --flat models/lz.vsgt
Time to read points = 0.0100096 seconds
Converted mesh to 8,964 points.
Average frame rate = 58.1603 fps

This building against VSG, vsgXchange and vsgPoints master.

[XMatrixXiang]

VSG The vsg was recompiled with glslang enabled. Now, in Release mode, it can run normally.

However, in Debug mode, an exception will occur. The exception information is shown in the following figure.

I took a rough look at the code. At first, I thought it was caused by this statement. if (options == nullptr) options = &defaultOptions; Because "options" will point to the address of a local variable inside a function. After the function is executed, the life cycle of the temporary variable ends. However, through debugging, it is found that when "GlslangToSpv" is called, "options" is not a nullptr. So now I am a bit unclear about how this is generated exactly. Ignoring this exception, the program can still continue to run.

[robertosfield]

That looks like a glslang bug. Check the glslang version you are building against the the glslang project itself to see if that issue has been reported fixed.

However, I'm still mystified why the options would be null as the VSG code creates a glslang::SpvOptions and then passes a pointer to it when calling glslang::GlslangToSpv:

            glslang::SpvOptions spvOptions;
            if (settings)
            {
                spvOptions.generateDebugInfo = settings->generateDebugInfo;
                if (spvOptions.generateDebugInfo)
                {
                    spvOptions.emitNonSemanticShaderDebugInfo = true;
                    spvOptions.emitNonSemanticShaderDebugSource = true;
                }
            }

                (*(program->getIntermediate((EShLanguage)eshl_stage)), vsg_shader->module->code, &logger, &spvOptions);

Could there be a glslang requirement that the SpvOptions object lives pass the end of the getIntermediate(..) call?