Support us on Patreon
PayPalFor developers looking to bring their games to Linux officially, DXVK Native can be a good option to help reduce the time and complexity involved in doing so. Developed by Joshua Ashton who has been involved in DXVK, VKD3D-Proton, updating a few Valve games and more. Be sure to check out our interview!
Built against the Steam Runtime, the idea is that developers would use DXVK Native to get Vulkan support in their native Linux builds of games cutting out a chunk of the work needed on bringing up a whole new graphics API. It's the native version of DXVK, which does not need the Wine compatibility layer to work.
How does it work? From GitHub:
DXVK Native replaces certain Windows-isms with a platform and framework-agnostic replacement, for example,
HWNDs can becomeSDL_Window*s, etc. All it takes to do that is to add another WSI backend.DXVK Native comes with a slim set of Windows header definitions required for D3D9/11 and the MinGW headers for D3D9/11. In most cases, it will end up being plug and play with your renderer, but there may be certain teething issues such as:
__uuidof(type)is supported, but__uuidof(variable)is not supported. Use__uuidof_var(variable)instead.DXVK Native also has some performance tweaks for D3D9, disabling float emulation and some validation. This is configurable in
d3d9_config.h.
Multiple games already use it too including:
- Portal 2 (Valve - Windows & Linux)
- Left 4 Dead 2 (Valve - Windows & Linux)
- Ys VIII, Ys IX (PH3 Games - Stadia)
- Trails of Cold Steel 3 & 4 (PH3 Games - Stadia)
- Perimeter (Linux)
For the likes of Portal 2 and Left 4 Dead, both got official upgrades earlier this year to add it in. The originals used Valve's own Direct3D to OpenGL abstraction layer ToGL with both of the games now having an option to launch with Vulkan instead of OpenGL on Linux. Interestingly for Stadia, Google recently announced they're working on their own 'Porting Toolkit' that includes translation libraries for DirectX to Vulkan.
DXVK Native been around for a little while but only today saw a first proper tagged release, and an actual readme to give a little more information on what it's for.
Check out DXVK Native on GitHub under the zlib/libpng license.
Article taken from GamingOnLinux.com.
Seriouly, though:
Thanks Joshua!
*edit* This could be good for native
Last edited by Eike on 11 August 2021 at 11:44 am UTC
superboybot Aug 11, 2021
Very cool because it takes A LOT of the nightmare-hassle out of porting a game to Linux if it's not using OpenGL/Vulkan.
That said, to what extent is this preserving the overhead of non-native games?
I'm dum: DXVK is for DX9-11
Last edited by superboybot on 11 August 2021 at 11:59 am UTC
I've noticed some input lag with Portal 2 and a lot of stuttering when I tested l4d2 with -vulkan in a windows machine.
Although this might be a problem with the source engine too
Quoting: superboybotSlightly conflicted...
Very cool because it takes A LOT of the nightmare-hassle out of porting a game to Linux if it's not using OpenGL/Vulkan.
That said, to what extent is this preserving the overhead of non-native games?
Also, AFAIK DirectX 12 is easier to learn/use than Vulkan. Isn't this basically removing any incentive to use Vulkan?
I'm dum: DXVK is for DX9-11
Also, if you look at a driver like AMDVLK, the similarities between Vulkan and the "HAL" (hardware abstraction layer) in a driver, they are nigh one and the same. In the case of DX10-DX11, Vulkan actually works pretty well as a framework to build a driver, and any approach to writing a native driver from scratch would likely take a similar approach. For DX9, which is much more stateful, there's a lot of potential to introduce some non-optimized paths as you're adding more code, but it's still similar to the approach one would take writing a native driver.
The exception to this is DX12, which is quite similar to Vulkan in approach and features, so when something in DX12 doesn't have a direct 1:1 analogue in Vulkan, there is potential for overhead there.
TL;DR - Vulkan is pretty similar to the code contained in most old-school drivers in that it makes a pretty good framework for building OpenGL/DX9/DX10/DX11 drivers.
See more from me