On Mon, 24 Mar 2025 at 04:14:12 +0900, Marc Dequènes (duck) wrote: > On 2025-01-07 23:11, Simon McVittie wrote: > > 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. > > I discovered Lutris is using umu which is based on the Steam Runtime, which > can be handy for games that do not work with Wine+DXVK+VKD3D (the original > VKD3D I mean). I have no idea if that's using DXVK Native inside but it's > apparently vendoring everything so I won't be able to use the new libraries > in the dxvk package.
I think anything that involves Wine is going to be using DXVK DLLs (like what you already packaged) and not DXVK Native (what I'm aiming to add here). DXVK Native is for the benefit of native Linux games like Portal 2, rather than for the benefit of Wine running Windows games. > > 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. > > Alright, so I guess I could simply release new versions and upload as long > as the basic tests work, and we'll add more later if we can, then may I > leave it to you to do more testing on your end and report problems you > encounter? I think that's all we can really do at the moment. Given the trixie release timeline, having DXVK Native in experimental for now would seem reasonable, and perhaps it can go to testing/unstable in the forky cycle? When dealing with the Steam Runtime, I'm branching from your packaging *anyway* in order to do a backport to a Debian 11 derivative, so it's equally straightforward for me to base the Steam Runtime's dxvk on either testing, unstable or experimental. I asked a FNA maintainer on <https://github.com/ValveSoftware/steam-runtime/issues/687> and he's made a SDL3 beta branch available for <https://store.steampowered.com/app/1800730/I_MAED_A_GAM3_W1TH_Z0MB1ES_1N_IT1/> (which is a Steam game, but free-as-in-free-beer, and probably doesn't have any particular DRM beyond being most conveniently installed via Steam, because there isn't much point in putting intrusive DRM in a free game). Trying that out is on my to-do list: when I update to 2.6 I'll probably use that as one of my smoke-tests. The most likely games to use DXVK Native in the near future are FNA games like that one, and the Valve games I mentioned previously. > I looked at your changes and I have a few questions: > - why are the dh_auto_* steps in execute_after_* instead of override_*? > IIUC they will be run twice. Yes, but that's intentional. On the architectures that you were already supporting, we need two separate `meson setup`/`meson compile` pipelines: once for DXVK Native (added by my MR, usually a native build, mostly with debhelper defaults, outputting Linux ELF shared libraries, building in obj-${DEB_HOST_GNU_TYPE}) and once for use with Wine (pre-existing code written by you, cross-compiling with the mingw64 toolchain and outputting Windows PE DLLs, building in ${WINE_BUILD_DIR}, cannot always use debhelper defaults). On architectures where Wine isn't supported (for example riscv64) we only run the first build pass (the new one added by by changes), so we only build DXVK Native (Linux ELF libraries), and skip the Windows PE DLLs. If someone builds riscv64 binaries for a FNA game, it could use the resulting DXVK Native binaries as a dependency. At the dh_auto_configure stage, I used override_ because we need hooks both before and after dh_auto_configure. At the dh_auto_clean, dh_auto_build and dh_auto_install stages, I used execute_after_ because the debhelper defaults are fine for DXVK Native, and your Wine-specific second build pass can be done semi-independently. > - would you mind having the headers bundled into subprojects / vendor.xz? > honestly I would prefer if the debian/ diff would only show useful packaging > bits. You mean debian/vendor.xz? Sure, I can try to set that up while rebasing on 2.6. While being able to integrate this in Debian directly looked relatively far-off, I was using the workflow for debian/vendor/mingw-directx-headers that was easiest for me to maintain as a fork, but now that you've showed interest in merging my changes, I'll pivot to trying to follow your preference. I personally prefer having the vendored stuff in git directly so I can review what changed in it without needing to use diffoscope (for larger vendored modules by using multiple orig.tar like I do in src:yquake2, or for smaller vendored modules by having it unpacked in debian/ like I did with debian/vendor/mingw-directx-headers here) but I realise opinions can differ on this topic. smcv
