On Tue, 07 Jan 2025 at 21:35:53 +0900, Marc Dequènes (duck) wrote:
> If it works fine with a unique source package then it would be easier.
Do you mean you prefer the way I packaged it, with a single source package
that builds both DXVK Native (on all architectures) and DXVK-for-Wine
(on Windows architectures)?
Or do you mean you'd prefer two separate source packages?
> I do not want to vendor anything that's not necessary, so I was wondering
> about the mingw-directx-headers. Then I saw the directx-headers-dev package
> but unfortunately that's not what we need. Would the archall package
> mingw-w64-common work?
Perhaps? The risk is that Debian's version of mingw-w64 could be either
too new or too old, breaking assumptions made by DXVK or by DXVK-based
games.
The upstream build system installs the headers (they become part of
DXVK's API), but it would probably be possible to replace them with a
directory containing symlinks to the same curated subset of Debian's
version of mingw-w64-common, or something like that.
In Steam Runtime 3 I'm vendoring these headers and others anyway,
and likely to continue to do so, because I need to backport it to
approximately Debian 11 by vendoring Vulkan and SPIRV headers - but I
can do that downstream without your help.
> I have many games I can use to test the resulting package
> and even spot nasty upstream regressions but nothing using the native build
> (I'm not a Steam user so even if you published the Steam runtime sources
> that would not help).
We do publish the source code for all packages in the Steam Runtime as
.dsc to make sure we meet our (L)GPL obligations, but we don't generally
publish the git repositories for arbitrary packages (it's just a lot of
code, most of which we patch trivially or not at all, so the cost/benefit
ratio doesn't look great). I could probably mirror our src:dxvk onto Salsa
for reference if you're interested?
It is technically possible to use the Steam Runtime as a separate thing
without going via Steam, but I'm not aware of any non-Steam games that
use DXVK Native in practice, and as a semi-self-contained binary
distribution it doesn't really help you to test a pure Debian setup.
The examples I borrowed from @misyltoad for the autopkgtest are really
just a smoke-test, but they're the best I currently have for DirectX
branches other than 9. I've heard that native Linux games based on FNA are
likely to require DXVK Native in future (not sure which DirectX branch),
but I don't have any concrete examples right now: the FNA maintainer is
waiting for us to integrate SDL 3 into the Steam Runtime, which in turn
is waiting for SDL upstream to declare it to be stable.
For `libdxvk_d3d9.so.*`, my test targets for the Steam Runtime are
currently all Valve games that require Steam: Team Fortress 2, Portal 1,
Portal 2, Left 4 Dead 2. TF2 is free-as-in-free-beer if that's any help?
Some unsupported tinkering is currently required to make those games
use a DXVK version other than the one that they bundle, although they'll
most likely switch to relying on the Steam Runtime's copy of DXVK next
time their Linux ports get a significant update.
smcv
