Switch to using Ubuntu 25.10 vulkan/mesa

[ericcurtin]

Because "Ubuntu packages to be discontinued in Vulkan SDK"

[ericcurtin]

@yeahdongcn PTAL, what are the differences between LunarG vulkan and 25.10 mesa/vulkan?

[0cc4m]

@ericcurtin The LunarG Ubuntu packages are deprecated, yes, but the code you're replacing does not use them, it uses the .tar.xz. I assume this is more about the ARM64 issue you reported a while ago?

[ericcurtin]

@0cc4m you are right! To be honest one of the reasons I opened this is I am curious of the functionality difference between the plain old 25.10 package which is low maintenance (and probably has more users, maintainers, consolidated engineering efforts?) vs the Vulkan SDK from LunarG

[0cc4m]

@ericcurtin Sorry about the delay, let's figure this out. The Vulkan SDK and the packages on Ubuntu contain the same programs, the SDK is just more up to date. But I see how especially the missing ARM Linux support is a problem. Can you check which versions of libvulkan-dev (the Vulkan headers), libvulkan1 (the library), mesa-vulkan-drivers and glslc (the shader compiler) it installs for an Ubuntu 25.10 container?

[TinyServal]

Thanks for bringing this up, switching to the distro packages would make it possible to build this for arm64, since LunarG does not and will not ever support arm64 platforms running linux. Personally I don't understand this decision but that's how they run their business.

This has been a common issue in a few projects I've came across so far, most people assume the SDK package from LunarG is mandatory, which completely blocks any arm64 builds. The packages for questing are reasonably fresh, here are the actual versions for your reference. @0cc4m

Package	Version	Upstream
libvulkan-dev	1.4.321.0	1.4.328.1
libvulkan1	1.4.321.0	1.4.328.1
mesa-vulkan-drivers	25.2.3	25.2.6
glslc	2025.2	2025.4

[0cc4m]

Thank you. That is reasonably recent. I think supporting ARM is more relevant than being a few minor versions more up to date.

@ngxson @jeffbolznv Any concerns?

[jeffbolznv]

I think shaderc 2025.2 has the extensions we currently use, so that's probably fine. I kind of wish we built shaderc from source as a dependency, to avoid having to deal with old glslang/spirv-tools versions, but that would be a big change.

[ngxson]

Sorry I don't have enough experience working with Vulkan, so I cannot review this PR

[TinyServal]

I kind of wish we built shaderc from source as a dependency, to avoid having to deal with old glslang/spirv-tools versions, but that would be a big change.

The shaderc project doesn't look too complicated to build, if you really want that I can probably look into it after this is merged.

[yeahdongcn]

I kind of wish we built shaderc from source as a dependency, to avoid having to deal with old glslang/spirv-tools versions, but that would be a big change.

The shaderc project doesn't look too complicated to build, if you really want that I can probably look into it after this is merged.

@TinyServal This is a working Dockerfile I previously used to build Vulkan, GLSLang, Shaderc, and GLSLc on arm64. It might serve as a reference: https://gist.github.com/yeahdongcn/f57a37bfadcb0a607a6b0e5e710cbef2

[jeffbolznv]

Shaderc uses a pretty straightforward cmake build system. It's more a question of whether the licenses are compatible and whether we want to increase the build time.

[TinyServal]

Thanks for the Dockerfile example, and for license shaderc is Apache 2.0 which should be compatible with MIT.

[ericcurtin]

I would suggest working with Debian/Ubuntu package maintainers to update packages if they are deemed too old or missing some build flag, etc.

[TinyServal]

I agree, it's probably not worth the extra build time unless the packages are extremely stale, and the package maintainers refuse to update it. Can we get another reviewer to approve this PR?