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.

If you make use of the Wine compatibility layer on Fedora, it seems the upcoming Fedora 33 release may end up defaulting to DXVK for better performance.

Currently in Fedora, like most distributions, Wine is mostly left alone. Once installed, it's up to users to tinker with it and configure it (I much prefer using Lutris personally). That may change though if this latest proposal is accepted for Fedora 33 which releases in October 2020. There is currently a dedicated wine-dxvk package you can install to get it but this change would set DXVK as the default graphics backend for Wine to translate Direct3D 9/10/11 to Vulkan.

The benefits are obvious, like giving users of Wine a much better gaming experience for Windows-only titles. DXVK is used in Proton for Steam Play, it's developed at a quick pace for game compatibility and the performance is often far better than Wine's own wined3d which translates Direct3D to OpenGL.

See the proposal here if interested.

Article taken from GamingOnLinux.com.
Tags: Distro News, Fedora, Wine | Apps: Wine
20 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 checked 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.
32 comments
Page: 1/2»
  Go to:

silmeth Jul 22, 2020
It took just about 4 years from first public Vulkan API spec release to distros switching to Vulkan-based solution for D3D translation on Wine by default. I’d say that’s a pretty good time frame for adoption of brand new graphics API.
Alm888 Jul 22, 2020
I absolutely hope it gets rejected.

The last thing I want in the distro I use is some 3rd-party fork instead of upstream version. Otherwise WINE won't have any patches from Fedora anymore, as (rumor has it) DXVK does not play nice with WINE, outright conflicting with its libraries.

You can down-vote me to hell (well, except you can't ;) ), but I am firmly on WINE's side in their conflict.

DXVK guy is nobody and nothing without WINE (he can go sell his library to Windows users for all I care; I've heard it works on Windows™), he is in no position to bring incompatibility in a piece of software that: a) existed long before he even started his project; and b) enabled a lot of critical Windows™ applications to work in Linux (Winamp with its plug-ins, many of which have no Linux alternative, custom-built game resources extractors, banking software).

Prioritizing some custom upsetream-incompatible library over vanilla version is like a tail wagging a dog!

Everyone who absolutely WANTS DXVK-version can go to… Steam and install Proton™!!!


Last edited by Alm888 on 22 July 2020 at 11:40 am UTC
Mar2ck Jul 22, 2020
Quoting: Alm888The last thing I want in the distro I use is some 3rd-party fork instead of upstream version. Otherwise WINE won't have any patches from Fedora anymore, as (rumor has it) DXVK does not play nice with WINE, outright conflicting with its libraries.
DXVK is just dll files. Theres no patch or fork required
Nanobang Jul 22, 2020
View PC info
  • Supporter
Quoting: Alm888I absolutely hope it gets rejected.

The last thing I want in the distro I use is some 3rd-party fork instead of upstream version. Otherwise WINE won't have any patches from Fedora anymore, as (rumor has it) DXVK does not play nice with WINE, outright conflicting with its libraries.

You can down-vote me to hell (well, except you can't ;) ), but I am firmly on WINE's side in their conflict.

DXVK guy is nobody and nothing without WINE (he can go sell his library to Windows users for all I care; I've heard it works on Windows™), he is in no position to bring incompatibility in a piece of software that: a) existed long before he even started his project; and b) enabled a lot of critical Windows™ applications to work in Linux (Winamp with its plug-ins, many of which have no Linux alternative, custom-built game resources extractors, banking software).

Prioritizing some custom upsetream-incompatible library over vanilla version is like a tail wagging a dog!

Everyone who absolutely WANTS DXVK-version can go to… Steam and install Proton™!!!

I'm not familiar with Fedora, so I don't know how they do things, but --- if this were to happen --- couldn't you get Wine directly from WineHQ and use that? I'm on Ubuntu and I've always done that because the version in the Ubuntu repos has historically been pretty out-of-date. Not arguing, just wondering.
a0kami Jul 22, 2020
What about vkd3d, it might be confusing for users who wants out of the box dx12 app support as well.

Also Winamp, that's a name I haven't heard in decades
bubexel Jul 22, 2020
Quoting: Alm888I absolutely hope it gets rejected.

DXVK guy is nobody and nothing without WINE

Is it personal for you or what? what you have against him? take it easy...


Last edited by bubexel on 22 July 2020 at 12:53 pm UTC
Ehvis Jul 22, 2020
View PC info
  • Supporter Plus
Sounds like a terrible idea. DXVK is for games and does not work for most non-game software. The default should not be limited like that.
x_wing Jul 22, 2020
Quoting: Alm888I absolutely hope it gets rejected.

The last thing I want in the distro I use is some 3rd-party fork instead of upstream version. Otherwise WINE won't have any patches from Fedora anymore, as (rumor has it) DXVK does not play nice with WINE, outright conflicting with its libraries.

You can down-vote me to hell (well, except you can't ;) ), but I am firmly on WINE's side in their conflict.

DXVK guy is nobody and nothing without WINE (he can go sell his library to Windows users for all I care; I've heard it works on Windows™), he is in no position to bring incompatibility in a piece of software that: a) existed long before he even started his project; and b) enabled a lot of critical Windows™ applications to work in Linux (Winamp with its plug-ins, many of which have no Linux alternative, custom-built game resources extractors, banking software).

Prioritizing some custom upsetream-incompatible library over vanilla version is like a tail wagging a dog!

Everyone who absolutely WANTS DXVK-version can go to… Steam and install Proton™!!!

Wow wow wow!, you went from 0 to a 100 km/h in less than .1 seconds :p

I suggest you to read the Fedora proposal:

Quoting: Fedora ProposalDXVK is available as a wine-dxvk package since Fedora 31. wine-dxvk package uses alternatives system for following wine dll files: d3d9, d3d10.dll and d3d11.dll .

Should this proposal be accepted, a Pull Request will be merged into the wine-dxvk package which ensures it gets set as default backend only on systems with Vulkan support. wine-dxvk will then get added as "Recommends: wine-dxvk" into the wine package itself.

Users can run 'dnf reinstall wine-dxvk' after changing hardware configuration to get alternatives to use DXVK or wined3d updated.

So, it's not that wine+dxvk (which seems to be an already available option) will completely replace wine but that it will be the default option from now on for system that have a GPU that supports Vulkan API.

BTW, I think that this are the guys to blame for this blasphemy: Frantisek Zatloukal & Michael Cronenworth
silmeth Jul 22, 2020
Quoting: EhvisSounds like a terrible idea. DXVK is for games and does not work for most non-game software. The default should not be limited like that.

What do you mean by ‘does not work’ here, that it somehow breaks that software? If so, do you have any source on that? What software gets broken by DXVK? Sure, the emphasis of the project is on gettings games to work, but since it should mostly be a correct D3D implementation on top of Vulkan, I don’t see a reason why it would break non-game software (but I might be wrong, never tested DXVK with ‘regular’ programs myself). I cannot imagine Fedora installing it by default if it broke ‘most non-game software’.

If you mean just that most non-gaming software does not need most of D3D implemented (so it is not used) – the same can be said about many other libs installed with default Wine… If you don’t use it, you just don’t use it. And the proposal acknowledges the possibility to opt-out of DXVK installation.
Ehvis Jul 22, 2020
View PC info
  • Supporter Plus
Quoting: silmeth
Quoting: EhvisSounds like a terrible idea. DXVK is for games and does not work for most non-game software. The default should not be limited like that.

What do you mean by ‘does not work’ here,

Don't know the exact limitations since I'm not an expert on the matter, but as I understand it, dxvk won't interoperate with the rest of win32. Something that games don't do anyway, but most desktop 3d software does.
arkhenius Jul 22, 2020
What desktop applications break with DXVK? Most desktop applications I know do not even use DirectX 9/10/11, so DXVK or WineD3D being the default for conversion (to Vulkan or OpenGL, respectively) should not have an impact on that.
Alm888 Jul 22, 2020
Quoting: Mar2ckDXVK is just dll files. Theres no patch or fork required
These "just dll files" are conflicting with core WINE files so those core files should also be replaced in order to facilitate DXVK. WINE developers proposed cooperation in order to synchronize DLL dependencies, but the DXVK guy just ignored them. Twice. Apparently, it is HIS project and HE and only HE is in command. This developer does not know what a teamwork is.

This is why in parallel to wine package there is concurrent and mutually exclusive "wine-dxvk" one. It is "either/or" situation.
And as I am thankful to WINE team for all their continuous work (and do not need DXVK, ever as I do not own a single DX11/DX10 game), it is vanilla WINE for me.

Quoting: Nanobang…couldn't you get Wine directly from WineHQ and use that?
Sure thing! I can, and did this in the past. But one needs to compile the lib her-/himself and uninstall pre-installed system WINE package. And some "devel" packages to enable a lot of WINE features (like, sound support) are not installed by default. That's a lot of extra work, especially since those libs' in-Fedora namings are not what WINE's configuration script tells you (a lot of guesswork involved).

Quoting: bubexelIs it personal for you or what? what you have against him? take it easy...
I just get agitated when some random guy (even if he is talented and capable) just comes on a warm place, uses years-of-work from others, but refuses to cooperate and acts like he is now the boss and all those old-timers are not worthy of consideration. Now we even have some "protondb" despite "winedb" existed years prior. So, no, I didn't meet with the guy face-to-face, just can't stay this disrespectful uncooperative behavior from someone whose work basically relies upon the work of the people he is so disrespectful to.

Quoting: aokamiAlso Winamp, that's a name I haven't heard in decades
Winamp itself maybe dead, but its wide plug-in collection is indispencible. There is simply no alternative for, let's say, playing VGM music for PC (with YM3812 chip instructions), or "Farbrausch v2" ("*.v2m") -- Audacious plug-ins are not capable.

Quoting: x_wingSo, it's not that wine+dxvk (which seems to be an already available option) will completely replace wine but that it will be the default option from now on for system that have a GPU that supports Vulkan API.

BTW, I think that this are the guys to blame for this blasphemy: Frantisek Zatloukal & Michael Cronenworth
The thing is, my PC is capable of Vulkan API, but I do not need DXVK in any way or form. Yet, I am (or will be) forcefully fed it from F33 onward. This is called "deprecation". Be it my will, I would also opted out from "wine-staging" (that is already masquerading as pure wine in Fedora) and go full vanilla.

Quoting: arkheniusWhat desktop applications break with DXVK? Most desktop applications I know do not even use DirectX 9/10/11, so DXVK or WineD3D being the default for conversion (to Vulkan or OpenGL, respectively) should not have an impact on that.
DXVK actively messes with WINE core libraries, replacing them with its own game-oriented ones. An OK solution for gaming-oriented custom build like Proton™, but a big "NO!" for general usage. But that is what is proposed right now.
jens Jul 22, 2020
  • Supporter
@Alm888, are you sure that you are using Fedora? You should at least know then that Fedora already ships wine-staging instead of vanilla wine. Do you know the difference between these? Fedora is already quite gaming focused, so this is just a consequent move.

Regarding your facts about DXVK messing with wine core libs, please refrain from commenting if you lack the knowledge. It seems that you have never setup anything with DXVK and you just base your facts on stuff you have read somewhere on the internet.

Edit: the fact that Fedora already ships wine staging should may be added to the article because it places the Fedora proposal in a different light imho.


Last edited by jens on 22 July 2020 at 6:10 pm UTC
Alm888 Jul 22, 2020
Quoting: jens@Alm888, are you sure that you are using Fedora?
Did you read this?
QuoteBe it my will, I would also opted out from "wine-staging" (that is already masquerading as pure wine in Fedora) and go full vanilla.
In short, yes, I am.
Quoting: jensRegarding your facts about DXVK messing with wine core libs, please refrain from commenting if you lack the knowledge. It seems that you have never setup anything with DXVK and you just base your facts on stuff you have read somewhere on the internet.
That's some empty words and accusations. You did not provide any evidence it is not as I said. And I know enough about how this all feud between WINE team and DXVK author started.
bubexel Jul 22, 2020
Quoting: Alm888Quoting: jens
@Alm888, are you sure that you are using Fedora?

Did you read this?

It's on your profile. It's visible for everybody.
jens Jul 22, 2020
  • Supporter
Quoting: Alm888
Quoting: jens@Alm888, are you sure that you are using Fedora?
Did you read this?
QuoteBe it my will, I would also opted out from "wine-staging" (that is already masquerading as pure wine in Fedora) and go full vanilla.
In short, yes, I am.
Quoting: jensRegarding your facts about DXVK messing with wine core libs, please refrain from commenting if you lack the knowledge. It seems that you have never setup anything with DXVK and you just base your facts on stuff you have read somewhere on the internet.
That's some empty words and accusations. You did not provide any evidence it is not as I said. And I know enough about how this all feud between WINE team and DXVK author started.

Sorry, missed your quote about wine-staging indeed, my fault, I apologize.
That said, considering that your happy with the delta between wine staging and vanilla wine, but making such a fuss about DXVK, I guess your are just on a personal crusade against DXVK. I guess you just refuse that project not due to technical reasons, but just emotionally because they did things differently than you would have liked it. Please take a step backwards and think about who the drama queen in this play actually is. I give you a hint, it is not one of the developers...


Last edited by jens on 22 July 2020 at 7:31 pm UTC
Mar2ck Jul 22, 2020
Quoting: Alm888I do not need DXVK in any way or form. Yet, I am (or will be) forcefully fed it from F33 onward
All they're doing is making wine-dxvk a recommended package for wine. Literally just blacklist the package no one is forcing you to use anything. This is a change to give the average user who may not even know about dxvk better compatibility/performance out of the box, if you don't want it you can just not use it.
Alm888 Jul 22, 2020
Quoting: jensThat said, considering that your happy with the delta between wine staging and vanilla wine, but making such a fuss about DXVK, I guess your are just on a personal crusade against DXVK.
I never said I was "happy" about wine-staging masquerading as vanilla in Fedora (you can not even see it in "winecfg.exe"! The only indication is the first two strings in console output when launching an app).
Quoting: jensI guess you just refuse that project not due to technical reasons, but just emotionally because they did things differently than you would have liked it. Please take a step backwards and think about who the drama queen in this play actually is. I give you a hint, it is not one of the developers...
Not "emotionally". Ideologically, yes. I am against the NIH syndrome and forks due to overblown ego. Philip could merge things upstream, but decided against it because DXVK is his project and he is the boss and answers to no-one besides himself (and GabeN, considering Philip is basically his wageslave :) ).
It is nice that after a year he decided to lend a hand to WINE team (especially considering the team have tragically lost its key graphics developer), but DXVK is still his pet-project and wine-dxvk is a fork. And I am against forks.
Quoting: Mar2ckAll they're doing is making wine-dxvk a recommended package for wine.
Read "pre-installed" (you did know Fedora Workstation comes with WINE pre-installed, right?). Sure, I can "blacklist", uninstall and purge everything, but if Fedora goes down the "fork-path" it will hinder upstream improvements even more so (than wine-staging).
jens Jul 22, 2020
  • Supporter
Where do you got the impression that DXVK is a fork? It is not.
Do you know that CodeWeavers is also working together with Valve? https://www.codeweavers.com/about/blogs/aeikum/2019/8/20/a-year-since-protons-launch
It is really not that black and white (or good and evil) as you are presenting it, there is much more collaboration than it seems.


Last edited by jens on 22 July 2020 at 8:51 pm UTC
Mar2ck Jul 22, 2020
Quoting: Alm888Sure, I can "blacklist", uninstall and purge everything, but if Fedora goes down the "fork-path" it will hinder upstream improvements even more so (than wine-staging).
DXVK is definitely not a fork in any way, maybe you're getting mixed up with proton? The proposal page even outlines how you would blacklist the package in case you didn't already know:
QuoteUsers would be able to opt-out from using DXVK by adding 'exclude=wine-dxvk*' into /etc/dnf/dnf.conf and removing wine-dxvk package.


Last edited by Mar2ck on 22 July 2020 at 8:20 pm UTC
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.