Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

For 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 become SDL_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:

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.
29 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
4 comments

Eike Aug 11, 2021
View PC info
  • Supporter Plus
Of course and undeniably, he did because we asked him.

Seriouly, though:
Thanks Joshua!

*edit* This could be good for native ports versions. Yes, I still hope for native.


Last edited by Eike on 11 August 2021 at 11:44 am UTC
superboybot Aug 11, 2021
Slightly 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


Last edited by superboybot on 11 August 2021 at 11:59 am UTC
BielFPs Aug 11, 2021
Is there something they could do to improve the performance? (software side)
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
mcoffin Aug 11, 2021
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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.