Source: dxvk
Severity: wishlist
Recent versions of DXVK have support for being compiled as native Linux
libraries, so that native Linux games (particularly those that were ported
from Windows) can use the Direct3D APIs on both platforms. Windows-specific
parts of the APIs are implemented via either SDL2 or GLFW, with SDL3 as a
potential future enhancement (for example a HWND gets mapped to a tagged
union involving a SDL_Window). When compiled in this mode it is known as
DXVK Native.
Several of Valve's native Linux games use a bundled copy of DXVK as their
graphics layer on Linux, for example Portal 2, and so does the FNA game
library. Interest has been expressed in having DXVK Native available
in the Debian-based Steam Runtime so that these games and libraries can
all share a copy, instead of each having to bundle their own.
At the moment DXVK Native's ABI is not stable and the libraries don't
have a proper SONAME, but the next release after 2.3.1 (2.3.2? 2.4.0?)
is meant to have proper SONAMEs like libdxvk_d3d9.so.0, and install
development files and pkg-config metadata in the conventional way.
I was asked for .deb packages of DXVK as part of my work with the Steam
Runtime, and based them on the dxvk packaging in Debian. For the moment
this has to be based on a git snapshot, but I'll try to upgrade it to
a real release when available. Commits can be fetched from here:
https://salsa.debian.org/smcv-guest/dxvk wip/dxvk-native
I'm unsure whether this would be better as additional .deb packages from
src:dxvk, or as a separate source package src:dxvk-native that happens
to have the same upstream source code. I've prototyped it as an extension
of the existing src:dxvk, with:
* Package: libdxvk-dxgi0
* Package: libdxvk-d3d9-0
* Package: libdxvk-d3d10core0
* Package: libdxvk-d3d11-0
* Package: libdxvk-native-dev (-dev files for all of the above)
I hope those binary packages seem reasonable to the dxvk maintainers?
If possible I'd like to keep Debian and the Steam Runtime compatible
with each other.
All of those binary packages are Architecture: any, and in principle
they should be portable to any architecture. I adjusted the packaging
to restrict the build of the Wine-based/DLL packages to architectures
where Wine is available, with a <nowindows> build-profile as described
in https://wiki.debian.org/BuildProfileSpec which can be used to turn
them off, leaving only DXVK Native.
If DXVK Native is merged into src:dxvk, then the parts that need
wine{32,64}-development should maybe be restricted to only be built
in experimental or something (there is code for this in src:openjk),
to let DXVK Native migrate to testing without being blocked by those.
Or it could be a separate source package to allow for separate migration.
The prototype linked above uses a `meson dist` tarball which incorporates
the vendored libdisplay-info and the vendored MinGW, SPIRV and Vulkan
headers. For packaging in unstable you would presumably want to de-vendor
at least the SPIRV and Vulkan headers, and maybe the others too, which
would require partially or fully reverting my commit "Use upstream
vendored subprojects in a `meson dist` tarball".
After a suitable DXVK becomes available, please consider applying whatever
parts of my wip/dxvk-native branch seem useful to you.
Thanks,
smcv
