Support us on Patreon
PayPalIf 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.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: jensWhere do got the impression that DXVK is a fork? It is not.
I think they might be confusing general situation around the D3D translation tools, especially DXVK (D3D9–11, originally started by doitsujin as C++-based D3D11 implementation on top of Vulkan) with Vkd3d (D3D12 implementation, started by Wine team, esp. by Józef Kucia, after whose death it was indeed forked and the fork is used in Proton) – and hating on all of them just in case.
Anyway, you’re fighting a troll.
Last edited by silmeth on 22 July 2020 at 8:35 pm UTC
1 Likes, Who?
Man when Linux users get set against a project, it's an all out war.
Personally, I love that Fedora packages wine-staging instead of old crusty stable. I'm wine-dxvk is being considered. The way they package many of these makes is so much easier to use for me. I don't get the hate because it's fairly easy to install alternative versions and use whatever works for you. For me, this is just another reason Fedora is easy for me to game on.
Personally, I love that Fedora packages wine-staging instead of old crusty stable. I'm wine-dxvk is being considered. The way they package many of these makes is so much easier to use for me. I don't get the hate because it's fairly easy to install alternative versions and use whatever works for you. For me, this is just another reason Fedora is easy for me to game on.
0 Likes
Quoting: Alm888Not "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.
Sorry, but with this type of answers is difficult to believe that you don't have an emotional/personal problem with Philip. DXVK has zlib License, if Wine devs decides to merge things upstream there is nothing that Philip can do. So, if DXVK is not part of Wine is more a Wine devs decision at this point. The same we can be said for all the patches present in Wine-Staging vs Vanilla Wine.
1 Likes, Who?
Quoting: x_wingSorry, but with this type of answers is difficult to believe that you don't have an emotional/personal problem with Philip.Understandable. Maybe I overreacted a little bit. But while I do not hate him or anything, I do not have any positive feelings either. For me DXVK is a useless junk addition that I do not use (nor plan to). And when I leave test results on "appdb.winehq.org" I am forced to use self-compiled vanilla WINE (because Fedora does not provide me that option). So, addition of DXVK as a base Fedora package only complicates things more for me.
Quoting: x_wingDXVK has zlib License, if Wine devs decides to merge things upstream there is nothing that Philip can do.Is that so?
There are a lot of WINE-related packages in Fedora. I doubt something like "wine-courier-fonts" or "wine-wingdings-fonts" has the same license as core part. DXVK could be made into additionally installed package, if it was compatible. But it conflicts with core WINE libraries, namely "dxgi.dll" and "d3d11.dll". Thus, the need of a separate bundle.
Quoting: x_wingSo, if DXVK is not part of Wine is more a Wine devs decision at this point. The same we can be said for all the patches present in Wine-Staging vs Vanilla Wine.Is it so x2? WINE project was the first to implement those libs. But then came Mr. Rebohle and reinvented them (thus, NIH syndrome) instead of adapting/improving the existing ones. And the conflict begun.
"Fun" fact: the core of the conflict? Mr. Rebohle is using C++ instead of C and did not want to mess with C-wrtitten WINE libraries. So, it is a programming language holy war at its core!
Saying it was "a Wine devs decision" is like saying the tail wags the dog.
Last edited by Alm888 on 23 July 2020 at 5:34 am UTC
0 Likes
Quoting: Alm888I am forced to use self-compiled vanilla WINE (because Fedora does not provide me that option). So, addition of DXVK as a base Fedora package only complicates things more for me.In case you're interested, WineHQ provides an official repository for Fedora builds.
5 Likes, Who?
Quoting: Alm888Is it so x2? WINE project was the first to implement those libs. But then came Mr. Rebohle and reinvented them (thus, NIH syndrome) instead of adapting/improving the existing ones. And the conflict begun.
"Fun" fact: the core of the conflict? Mr. Rebohle is using C++ instead of C and did not want to mess with C-wrtitten WINE libraries. So, it is a programming language holy war at its core!
Saying it was "a Wine devs decision" is like saying the tail wags the dog.
Please don’t create drama when there is no drama. Both D3D implementations do live happily next to each other, both have a different focus, both have a different approach and a different project style. There was never any big drama or war regarding programming languages. What you are referring too was all just make up internet drama by outsiders that wanted to see a lot of drama.
Look at the wine commits, you’ll sometimes find the names of the DXVK authors there. Look at the DXVK commits, also there you’ll find names of CodeWeavers people.
6 Likes, Who?
Quoting: tuubiIn case you're interested, WineHQ provides an official repository for Fedora builds.Thank you! I will keep that in mind when I switch to a fresher version of Fedora. Right now I am restricted to F30 due to certain scientific software.
1 Likes, Who?
Quoting: tuubiQuoting: Alm888I am forced to use self-compiled vanilla WINE (because Fedora does not provide me that option). So, addition of DXVK as a base Fedora package only complicates things more for me.In case you're interested, WineHQ provides an official repository for Fedora builds.
Say I use their Debian Repo as even on Sid the Debian version has a bad habit of ending up out of step with upstream and I like to run the newest version of Wine at basically all times. Only time I consider switching back to an older version is when there has been a major regression and even then if none of my stuff is hit I just use latest.
Last edited by Gamewitch on 23 July 2020 at 8:21 am UTC
0 Likes
Quoting: Alm888Quoting: tuubiIn case you're interested, WineHQ provides an official repository for Fedora builds.Thank you! I will keep that in mind when I switch to a fresher version of Fedora. Right now I am restricted to F30 due to certain scientific software.
Reading this, may be another distribution than Fedora would fit your use cases somewhat better ... Fedora moves fast and F30 is already EOL.
2 Likes, Who?
Quoting: Alm888It 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.
Wine devs normally are very closed circle, is difficult allow entry to new developers (specially when can affect in many ways some parts case wined3d with dxvk)
But actually them dont accept dxvk (wine programming standar issue, dxvk use C++ and wine dont accept that)
However package is optional, but as gamer wined3d is a dead horse and d9vk/dxvk is possible use many games with very good performance and features case vsync (this give troubles in wined3d)
Another thing is d9vk/dxvk use cpu in better way (better multithreading) than wined3d
Without forget time to resolve bugs in wined3d compared dxvk, dxvk is more proactive in this matter, personally i dont want give support to wined3d for wait years to solve bugs or in other cases stay as non resolved or abandonen
Actually them stay working on own vulkan solution but when appear will be late because dxvk stay some time ago without forget performance (possible worst in wine vulkan implementation)
Last edited by mrdeathjr on 23 July 2020 at 11:52 am UTC
1 Likes, Who?
See more from me