Confused on Steam Play and Proton? Be sure to check out our guide.

DXVK Native is the fork of the original translation layer DXVK, the part of Proton that translates Direct 3D 9 / 10 / 11 to Vulkan but this is meant for Linux native builds and a new release is out now. 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 previous interview!

The point of the project is for game and application ports to hopefully be quicker, as the developer won't need to write an entirely new rendering backend so it can help port development. Perhaps with the likes of the Steam Deck coming which uses SteamOS Linux, we might see more developers take a look at it.

With this being the second official release of DXVK Native, there's no special release notes but it does bump up all the support from the most recent version of the main DXVK project, including DLSS support. The project readme was also cleared up on a number of points.

Games known to use DXVK Native include:

Article taken from GamingOnLinux.com.
22 Likes
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more here.
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
7 comments

superboybot 22 Oct
I support native Linux games, and I think tools like this are fantastic for simplifying the porting process. Unlike relying on Proton, getting a native build of a title means Linux is officially supported, which is excellent.

That said, are there technical benefits to porting a game with DXVK Native versus using Proton? From my understanding, there's still overhead from using a translation layer.
MayeulC 22 Oct
Quoting: superboybotUnlike relying on Proton, getting a native build of a title means Linux is officially supported, which is excellent.
I can picture developers officially supporting Proton.

Quoting: superboybotThat said, are there technical benefits to porting a game with DXVK Native versus using Proton? From my understanding, there's still overhead from using a translation layer.

Of course. Graphics APIs are one of the most complicated part to port, so DXVK Native takes care of that. The rest of the game then interacts with native APIs, without the "translation layer overhead" for files I/O, user input, math, locking and threading, etc.

It can also lead to compatibility issues between Windows and Linux versions, as stuff like floating point math might not be handled the same. Wine provides libraries (winelib) for that too.

It becomes sort of like mingw32/64: compile a program against windows APIs, get a Linux executable using Linux APIs.
superboybot 22 Oct
Quoting: MayeulCOf course. Graphics APIs are one of the most complicated part to port, so DXVK Native takes care of that. The rest of the game then interacts with native APIs, without the "translation layer overhead" for files I/O, user input, math, locking and threading, etc.

It can also lead to compatibility issues between Windows and Linux versions, as stuff like floating point math might not be handled the same. Wine provides libraries (winelib) for that too.

It becomes sort of like mingw32/64: compile a program against windows APIs, get a Linux executable using Linux APIs.

My question was poorly worded. A frequent point I've seen brought up as to why devs would port their games to Linux over using Proton is to squeeze out extra performance (eliminating the overhead of compatibility layers). While there would be some benefits in these cases to using things like DXVKN, as you pointed out, I don't know how impactful they will be.
mirv 22 Oct
View PC info
  • Supporter Plus
Quoting: superboybot
Quoting: MayeulCOf course. Graphics APIs are one of the most complicated part to port, so DXVK Native takes care of that. The rest of the game then interacts with native APIs, without the "translation layer overhead" for files I/O, user input, math, locking and threading, etc.

It can also lead to compatibility issues between Windows and Linux versions, as stuff like floating point math might not be handled the same. Wine provides libraries (winelib) for that too.

It becomes sort of like mingw32/64: compile a program against windows APIs, get a Linux executable using Linux APIs.

My question was poorly worded. A frequent point I've seen brought up as to why devs would port their games to Linux over using Proton is to squeeze out extra performance (eliminating the overhead of compatibility layers). While there would be some benefits in these cases to using things like DXVKN, as you pointed out, I don't know how impactful they will be.

Performance impact might not be so large, except for a few areas like shader caching. Using dxvk-native probably suffers the same, and it's going to depend on the game as well, but equally I'm sure there are ways to pre-cache anything needed on startup to ensure stuttering isn't a problem later. That's _much_ easier to do native than going through wine. If it's even an issue.
Other performance related areas stem from what you can do with the API (e.g poking memory directly instead of going through buffer copies). You _can_ get more performance doing things that way (independent of which platform), but the usual tradeoff applies: it's going to need a little more effort too.

Going native (heh) also has other benefits, especially if the game is going to target multiple platforms anyway, from stabibility related areas to possible additional features or support you can take advantage of (think text-to-speech, file system support, even debugging features).

There's also a case to be made for using Vulkan directly over DXVK because the latter is essentially an implementation of DX11/10/9 and those APIs are not future-proof. Great for porting older code that uses them and when you don't want to rewrite a render backend, but not something new games will want to be running in a few years.

Pros & cons.
ijuujhuh 22 Oct
I don't understand what this is for. Why would a native Linux game use Direct 3D 9 / 10 / 11 ?
BielFPs 22 Oct
Quoting: superboybotThat said, are there technical benefits to porting a game with DXVK Native versus using Proton? From my understanding, there's still overhead from using a translation layer.
Let's try to make an analogy on this case:

Imagine you need to watch a video without subtitles (windows game) where people on it only speaks my native language (windows api calls).

You (linux system) probably won't understand anything (since linux doesn't work with windows calls), but if I (dxvk) watch the video together with you, I can explain what they're saying at the same time (dxvk translating windows calls to linux calls)

Of course you'll understand better if there's a english version of the video (native linux game) or if you know how to speak my language (linux working natively with windows calls).

But since that's is not the case, you can still understand the video content (windows game working on linux) because I'm translating it to you (using proton). Sure I can make some mistakes (bugs) or we can have a little delay because I need to listen to what they're saying, before translate it to you (game stuttering) but it's still better than you not understanding anything at all (not being able to play).

So answering your question: The advantage is that you don't need to have 2 different versions of the same game (windows and linux builds) and dxvk native makes sure will be always be the same translator being used.
const 22 Oct
Any form of port, be it with or without translation layers, can run worse, nearly the same or better then on Windows. It depends on the codebase, the effort and the knowledge that went into it. Chances are, someone like Icculus or Ethan Lee with tons of experience or a dedicated developer with unlimited time could make a better port without translation layers but that's not guaranteed. While they can't solve every problem with perfect performance, a lot of knowledge and experience are already embedded in those translation layers and that can way even stronger. Also, ports based on those layers have a better chance to exist in the same codebase and buildsystems, which absolutely helps us in regards of continuous support.
When it comes to dxvk and winelib, there is also a lot of potential to document possible performance killers and make developers aware of those. Maybe with inline annotations and alternative, more explicit calls in the API or even something like a ruleset for automated code analysis. I could imagine that to be a very effective way to help ports getting even better.
We are at a point where it's quite hard to calculate if a specific port strategy will have enough impact to add value compared to just running the game through proton.
We can only hope that SteamDeck will make our platform interesting enough for studios to target linux from the beginning or by chance select engines and tools that have very good support. :)


Last edited by const on 22 October 2021 at 10:57 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Patreon, Liberapay or PayPal Donation.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just 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!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.