search

dotnet / Silk.NET

The high-speed OpenGL, OpenCL, OpenAL, OpenXR, GLFW, SDL, Vulkan, Assimp, WebGPU, and DirectX bindings library your mother warned you about.
https://dotnet.github.io/Silk.NET
MIT License
3.89k stars 378 forks source link

Build Vulkan Loader native package for `win-arm64` #2090

Closed alexrp closed 2 months ago

alexrp commented 2 months ago

Depends on this upstream PR being merged and released: https://github.com/KhronosGroup/Vulkan-Loader/pull/1469

alexrp commented 2 months ago

Unfortunately, nothing is ever easy.

We 'need' to build Vulkan Loader with the ClangCL toolset because it's the only way to build the Arm64 assembly. Not doing so trips this warning:

https://github.com/KhronosGroup/Vulkan-Loader/blob/77d1f9803624eafdf4dd8e51b2417c737574bb66/loader/CMakeLists.txt#L125-L128

Is that warning a problem? Who knows. It's up to the phase of the moon and the mood of the C compiler.

The issue is that VS ships with ClangCL toolsets for each build machine architecture. So there's an x86, x64, and Arm64 toolset. But you can only run the x64 and x86 (under WoW64) toolsets on e.g. a GitHub Actions runner. And I don't see any obvious way to cross-compile. So unless we can get our hands on a Windows Arm64 runner, I think we're out of luck.

I can of course just make the Windows Arm64 build use MSVC instead and we just pray that the tail call elimination kicks in. @Perksey @Beyley any thoughts?

Perksey commented 2 months ago

zig cc

alexrp commented 2 months ago

Might be possible. :thinking: I'll check first if it can be done with a CMake toolchain file pointing to zig cc.

If that's too annoying to do, we might have to make a proper build.zig like was done for the other dependencies that are built with Zig. That's a slightly more involved project that I don't have time for currently, though, so I'll leave it up for grabs if it comes to that.

alexrp commented 2 months ago

Some early findings: zig cc with CMake should be possible, but it's a pain in the ass going Linux -> Windows Arm64 due to resource compiler nonsense. Will have to do it on Windows.

alexrp commented 2 months ago

Upstream PR has been merged. We need to actually update our Vulkan Loader submodule to a newer tag (once available) since we need multiple build system changes that were made since v1.3.280.

Perksey commented 2 months ago

I think we should just point at an untagged SHA, seeing as a new tag implies we need to update our bindings again and I don't think there's appetite for that.

alexrp commented 2 months ago

Unfortunately we're already a tag behind: https://github.com/KhronosGroup/Vulkan-Loader/releases/tag/v1.3.281

So it seems like we'll have to do that anyway?

Perksey commented 2 months ago

Ah okay, so our Vulkan Loader version is behind our Vulkan Headers version. So no update needed, phew!