What is your development cycle/pipeline garding new releases of VSG and VulkanSDK?

[vaillancourt]

Hello!

We're considering switching from OSG to VSG soon, and I've started to look at how to set things up to work with VSG and the VulkanSDK.

I'm seeing that:

• VulkanSDK gets new versions quite regularly
• VulkanSDK versions get "stale" two years after they are released: they are removed from the download list on the LunarG site after two years
• VSG gets new releases quite regularly too
• VSG needs Vulkan 1.1
• Using CMake to build a Visual Studio (2022) solution of VSG, the version of VulkanSDK gets "hard coded" in the solution files, thus we can't just change the VulkanSDK path/version in the VULKAN_SDK environment variable to have VSG using the newer version, we need to re-generate a new solution with the new version.

So, given that our development cycle is about two years per project, I'm seeing a couple of options:

• Keep up with updating the SDK and VSG until we're getting close to release, generating a new solution for VSG whenever a new SDK or VSG version is released
• Pick only one of the frameworks (either the SDK or VSG) and generate a new solution whenever a new version of it comes up, but not bother with the other one (unless there is a bug that gets fixed)
• Update both VSG and VulkanSDK whenever we start working on a new project and don't bother until the next project (unless there is a bug that gets fixed in a follow up release).

Are there other options? What are the usual ways to work with the SDK and VSG?

Thanks!
--Alexandre

[robertosfield]

The VulkanSceneGraph has fallbcks that define & extension function entry points when you compile against older Vulkan headers, with checks for version and extension entry points at runtime. This means you can compile against older or newer Vulkan versions, and link at runtime to older or new Vulkan versions, which decoples you form having to compile against any specific Vulkan/VulkanSDK version.

This should allow you to choose what versions of Vulkan or VulkanSDK to compile against. Typically it'd be whatever is the most convinient on your system, and may even be different versions on different OSs.

[vaillancourt]

Hmm, well as far as I can see in %VULKAN_SDK%\Lib, the SDK provides most of its .lib as static libraries, at least on Windows (glslang related). Only Vulkan-1.lib seems to be using a dll.

Also, the Visual Studio solution that is generated for VulkanSceneGraph/vsgXchange/vsgImGui/vsgExamples has hardcoded paths to the SDK; I wonder if there would be a way to replace the strings there with the environment variable.

[vaillancourt]

I just realized that we compile Glslang ourselves due to the issue with the CMake files related to the distribution of the project (the VulkanSDK); we use the "static" project, where we could probably use the "shared" one instead.

Then I'd need to figure of a way to tell VSG's solution to use the environment variable instead of a hardcoded path. Not sure if it would work.

[AnyOldName3]

If you search the generated CMakeCache.txt file for anything mentioning the Vulkan SDK directory and delete those lines, the next time you build the VSG, Visual Studio will automatically re-run CMake and it'll switch to whichever Vulkan SDK version is specified by the environment variable. You can even directly replace the version numbers. I have a snippet in my PowerShell history for that, so I'll share it here:

Get-ChildItem -Recurse -File CMakeCache.txt | ForEach-Object { Invoke-Expression "`${$_} = `${$_}.Replace('1.4.304.1', '1.4.321.1')" }

That'll search the current directory and all child directories for files called CMakeCache.txt and replace the version string 1.4.304.1 with 1.4.321.1, which was the last Vulkan SDK update I did.

It's intentional that the environment variable isn't checked each time you rebuild the project as it makes it easier to have multiple installations side by side and avoid having to do a clean rebuild each time you update something. It would be bad CMake practice to try and meddle with expected norms like this.

[vaillancourt]

Thanks for the tip!

We currently have a script that will download stuff from github and generate a new VS solution for it, and build it; this sounds quite equivalent to what you suggest.