The Vulkan 1.3 requirement isn't going anywhere, we have no intention to support hardware which no longer gets active driver support. AMD's Windows driver for Vega/Polaris is already on the chopping block because those never received maintenance5 support before being dropped (they do work fine on Linux).
As for static linking, if you really want to go that route than that's something you can trivially do in a local fork, I don't really see a good reason to have this upstream though. Our build system mostly caters to steam runtime needs (and we're already not doing enough to keep that functional, looking at recent PRs), I don't think adding another path that basically won't receive any testing whatsoever is a good idea.
I made few more tests and got "static" libdxvk_d3d9.a, but it still uses libSDL2-2.0.so.0. So I run my test with DXVK_WSI_DRIVER=SDL2 and got same error as in the https://github.com/doitsujin/dxvk/issues/4842
Video subsystem has not been initialized
So, I checked WSI code and found that libSDL2-2.0.so.0 and 2 other was hard coded in:
https://github.com/doitsujin/dxvk/blob/54d37d964e076e7dfae5fddd94640785a69e3122/src/wsi/sdl2/wsi_platform_sdl2.cpp#L13
https://github.com/doitsujin/dxvk/blob/54d37d964e076e7dfae5fddd94640785a69e3122/src/wsi/sdl3/wsi_platform_sdl3.cpp#L13
https://github.com/doitsujin/dxvk/blob/54d37d964e076e7dfae5fddd94640785a69e3122/src/wsi/glfw/wsi_platform_glfw.cpp#L11
@doitsujin May be you know better way to define that dynamic libs?
You'll just have to change the code.
Please don't do this if you plan to distribute an app to other users. You're just going to make it impossible for them to upgrade to a newer DXVK.
Please don't do this if you plan to distribute an app to other users. You're just going to make it impossible for them to upgrade to a newer DXVK.
More and more publishers are releasing source code for games from the 2000s (few exaples: Electronic Arts, K-D LAB, Nival). These are undemanding but interesting games. And some of this games I would like to run on ARM SBCs without Wine.
There are already several dozen such games and it will be difficult to write a renderer for each game, so it is easier to modify DXVK and use it as render wrapper + SDL2/SDL3 for Window, Input and other stuff.
My 1st attempt was 2 years ago and it was quite successful: I added basic Linux support to Storm engine - I got almost working game (without in-game cutscene) that uses DXVK or Gallium Nine. Vulkan on Mali GPU was in very bad condition, but with Gallium Nine I got 25-45 FPS without any optimization.
Mali GPU just got Vulkan 1.2, but still missing fillModeNonSolid, shaderClipDistance and multiViewport features because lack on Mali's hw.
There are many options for solving problems, but they all have their downsides:
So option when it's not possible upgrade to a newer DXVK - is a bearable solution if I will use custom DXVK.
So option when it's not possible upgrade to a newer DXVK - is a bearable solution if I will use custom DXVK.
Not sure if it helps in any way for your particular use case, but it's probably a good idea to take any < Vulkan 1.3 requirements over to: https://github.com/pythonlover02/DXVK-Sarek. It's a fork of the dxvk 1.10.x branch which aims to continue support for older Vulkan-capable hardware and backport things from mainline dxvk when possible. Just note that performance is not expected to be great on such hardware.
MESA_VK_VERSION_OVERRIDEx1 2025-05DXVK_WSI_DRIVER=SDL2`x1 2025-05
As far as I can see - DXVK always build shared library :
https://github.com/doitsujin/dxvk/blob/v2.6.1/src/d3d9/meson.build#L60
https://github.com/doitsujin/dxvk/blob/master/src/d3d11/meson.build#L80
I would like to have option to build static version of DXVK Native.
The Meson documentation says:
It is generally preferred to use the library command instead of shared_library and static_library and then configure which libraries (static or shared or both of them) will be built at the build configuration time using the default_library built-in option.https://mesonbuild.com/Build-targets.html
There are already examples of complex projects that are compiled statically and distributed by 1 executable file. The first thing that comes to mind is Godot.
That's why building a static application with DXVK Native doesn't seem impossible to me.
In addition to the ease of distribution, I am concerned about the requirement for Vulkan 1.3, since there is still a list of GPUs that support Vulkan 1.1+, but not 1.3:
https://www.reddit.com/r/linux_gaming/comments/1exfnp7/list_of_gpus_that_can_only_use_the_old_dxvk/
(not sure about AMD GPU in though).
So I could build 2 versions of the executable and test them separately.
I understand that this is not the main scenario for using DXVK, but I still want to hear the opinion of smart people: will it be possible to add a static build of DXVK Native with simple changes or are there other options to reduce the dependence on system libraries and distribute games as my_app +libdxvk_d3d9.so without dependence on libSDL*.so