Support us on Patreon
PayPalDXVK 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:
- Portal 2 (Valve - Windows & Linux)
- Left 4 Dead 2 (Valve - Windows & Linux)
- Ys VIII, Ys IX (PH3 Games - Stadia)
- Perimeter (Linux)
- Momentum Mod (Linux)
- Portal 2: Community Edition (Linux)
- Half-Life: 2 and the episodes (Valve - Windows & Linux) - currently in Beta
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
6 comments
superboybot Oct 22, 2021
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.
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.
1 Likes, Who?
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.
3 Likes, Who?
superboybot Oct 22, 2021
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.
0 Likes
I don't understand what this is for. Why would a native Linux game use Direct 3D 9 / 10 / 11 ?
0 Likes
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.
1 Likes, Who?
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
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
0 Likes
See more from me