CI windows vulkan update

[yaz0r]

This reworks the way vulkan sdk is pulled, to hopefully simplify the burden of updating vulkan sdk
Also provide help for #8778

The general idea is to grab the minimal bits we need from the khronos repo with a specific tag. We only pull 2 things:

• vulkan-header (just what we need to build all the code)
• vulkan-loader (so we can link the loader in).

This treats the vulkan-header as the "vulkan sdk" folder, as it allow us to not have to copy out all the headers after unzip.
The loader require a minimal build to generate the .lib/dll required. This is done by just invoking cmake in the vulkan-load folder, and copying those out to the "vulkan sdk" folder.

For convenience, a $vulkanVersion is provided to target whatever release of the sdk we want to build against, and simplify the burden of updating.

Note: an initial attempt was done by pulling the sdk zip from lunarg, but that turned into a much longer download process, and there was issue unzipping the archive. This is way faster to just download the header/loader and use that for builds.

[ocornut]

Thank you Vincent! I merged this as f77f68a (with changelog and minor shallow tweaks of comments)

Tho I have to admit I am not 100% satisfied by this, since the process of downloading a ZIP file seems generally simpler, even though the new SDK are about ~14 MB (due to pdb). For the records can you clarify "there was issue unzipping the archive" ?

Let's run with your changes for now! But in case it ends up more brittle due to past/future Vulkan SDK changes I may backtrack to use a ZIP. In theory I would find it valuable to ensure that we can change the tag to any version number, but do we know if the same build process/paths works with old VulkanSDK etc? In practice it may not matter so much.. let's see how it goes.

[yaz0r]

@ocornut yeah it's not the bestest, but I tried to strike the balance between cleanness ease to update the sdk version. So I tried to avoid to have to upload a custom zip somewhere at all cost, as it's just too much friciton.

I originally tried to pull down the sdk straight from https://vulkan.lunarg.com/sdk/home and 2 issues came up quickly. The headers are only in the sdk installer, and while 7zip can pull out the files from it without actually installing, I couldn't force powershell to uncompress it in place. The only zip you can get (the 14mb) only has the loader and not the headers.
The other issue is that it's just too big and added many minutes to the CI and as such wasn't practical.

Arguably you could get away with just the headers, and dynamically load the loader dll, so you don't even need to get the loader and build it.

Afaik the build process and tag scheme has been fairly stable for a while, but we are never guaranteed for it to not change. Although in that case, it wouldn't break CI, but just need to massage things a bit to upgrade to whatever version.

[ocornut]

This is failing:
https://github.com/ocornut/imgui/actions/runs/17669956838/job/50219315250

[ocornut]

This is failing:
https://github.com/ocornut/imgui/actions/runs/17669956838/job/50219315250

FYI i am also watching a CI run the new steps are fairly long.
Pretty uploading custom zip is better tbh. I don't mind doing so as soon as we had a documented trace of how to create a new one.

[yaz0r]

Oh this is a 32bit build. Those weren't running the other day when I made the PR.
I can get a zip ready a bit later today and document the process.

[ocornut]

Oh this is a 32bit build. Those weren't running the other day when I made the PR.

Ah yeah.
We have on-commit builds which runs a shorter/limited selection of builds to save on time etc., and scheduled everyday build which runs all of it.

[yaz0r]

Looking at this now. Official SDK don't even have a 32bit loader pre-built anymore, so going to have to build my own

[yaz0r]

I'm still iterating on this, but here is a proposal:
https://github.com/yaz0r/imgui/blob/master/.github/workflows/build_windows_vulkan.yml
is a manual workflow that generate the vulkan zip equivalent to what you were using before, with both win32/64 lib and the headers.
From there you can either:

• Build that on say weekly basis with a retention set to a bit more than that (max is 90 days I think), and just reference that artifact from you normal build.
• Only run it manually to create the artifact you want, and just upload it as the one you use currently in the build.

[yaz0r]

See https://github.com/yaz0r/imgui/actions/runs/17718430439 for the result of the workflow and generated .zip

[ocornut]

Thanks for the update!

• In official windows SDK the directory casing is Include/ not include/ might as well use that.
• The workflow file/name could be called e.g. build_windows_vulkan_libs to avoid ambiguity, and output e.g. vulkan_windows_libs_$($env:VULKAN_TAG).

I would prefer to run this manually and occasionally anyhow. To be honest we may even be better off with a simple powershell batch file copying the same commands? There isn't a strong need to be updating often, mostly if a SDK specific problem occurs.

Once we have those zip we can consider tweaking CI to build twice, one with oldest supported SDK, one with a recent one.

The previously updated zip was ~434 KB (https://github.com/ocornut/imgui/files/3789205/vulkan-sdk-1.1.121.2.zip) because it only carried headers + lib, not actual dll (as we don't run on the CI server) let alone pdb. Nowadays if I strip those files it goes down to ~1.5 MB. I'd probably strip them from the copying script/batch file.

[yaz0r]

@ocornut yaz0r@546a55e
Run off that branch: https://github.com/yaz0r/imgui/actions/runs/17883210381

It moves the bulk of the logic to a standalone ps1 script. I left it as a workflow that can be triggered manually and generate a file of the format vulkan_windows_libs_$($env:VULKAN_TAG)
Also renamed the include to Include

[yaz0r]

Also, trimmed to minimal .lib files.
There some new headers that you might not care about, but the size impact is minimal.

I reverted the build step to your old zip, as I'm not sure how you uploaded it in the first place.

[yaz0r]

@ocornut updated the PR with the changes

[ocornut]

Attachment:
vulkan_windows_libs_1.4.326.zip

[ocornut]

Thank you!
I have merged this as ef6fe2e, then applied amends dc0198a.
As a sort of noise-minimizer control freak, I thought the .yml wasn't necessary as it would appear forever in GitHub CI ui, so I removed it in second commit but added references in comments; both to the possibility of restoring it + steps to recreate this.

GitHub upload urls changed so new urls look less adequate for what we are doing here, but I reckon we are not going to look at this very often, so I believe our problem is nicely solved now. Thank you very much!