DXVK 0.54 Brings Better AMD Performance, Improved GPU Utilization

[AsuMagic]

Not to mention, Wine still depends on C89 maximum, right? That's even less of a solid and reasonable technical choice as much more sane C standards exist and are basically supported on every platform Wine would ever wish to be usable on.

[AsuMagic]

He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.

DXVK has null interest for Windows gamers because D3D11 native drivers will outperform DXVK in the forseeable future.
Of course, you could gain fractions of FPS by making DXVK a native Wine library but you will instantly make it harder to compare results against Windows Vulkan drivers and to test games that cannot run under Wine, mostly because of DRM issues. Solving problems in games that are not playable under Wine yet still allows to improve the shape of DXVK for Wine gaming because games may share issues that are more easily debuggable in a game or another.
Plus with a DLL you will not need separate builds for separate platforms e.g. macOS which could potentially benefit from DXVK soon as moltenVK seems to get the job done.
People have been compiling DXVK as a native Wine library just fine but there were major issues and the measured performance gain was near null IIRC. Making a native library is not going to automagically solve all performance problems, and it's clearly not worth the debugging & maintenance time.

Just because Wine and DXVK do not rely on the same internal technology doesn't mean they're incompatible and useless to each other. That's nonsense. Meson (and ninja) was picked because it's the less painful and efficient solution. Please get me any result where autotools gets faster and easier to use than Meson. It is only convenient to put releases on GitHub because it's easy to find and use. What's the trouble? Should it be hosted the exact same way as Wine does just in order to look like it's done the same way as Wine? What is the trouble of using proper modern C++ to implement a C++ API? The sole arguments you can find in defense of using exclusively ANSI C is Wine is compatibility as per their wiki, which is mostly a legacy reason that isn't even remotely affected by DXVK.

Obviously, Wine's work is great, and while wined3d has to adapt to an API that maps less well DXVK has destroyed the entire field in terms of development time. I would personally not doubt the developer's choices in that regard.

Again, saying that DXVK doesn't contribute to Wine gaming just because they are independent projects that are implemented differently is nonsense, because DXVK is virtually useless for Windows gaming... And it's very obviously targetted at Wine gaming.

[sdack]

Nonsense. Wine is also free to start accepting C++ libraries.

DXVK is free to accept Rust and Fortran code, or to use C for that matter. Only such ignorance doesn't get you very far. You will have to make your own project when you cannot get yourself to conform to the standards of others. There you'll learn that there are others like you who have the same problem but with your project, and it will be you who doesn't accept their contribution. It's a story as old as the bible, mate.

GitHub is then full of solo artists, who want to redefine everything like the barista who puts another spin on a cup of coffee. And I'm sure Microsoft has thought about it when they bought GitHub. They want this.

We can argue whether DXVK would have iterated as fast and been as successful, as it has been... If say DXVK had to be subject to Wine's code restrictions (old C standard, etc.) and slow-review process.

That's true. But if you've been following the development then you also know that wine-vulkan couldn't move on, because Vulkan had changed it's license with 1.1. It's lucky that the lawyers removed the problem as quickly as they did, because if not then wine-vulkan and DXVK would have remained at Vulkan 1.0 forever. If DXVK hadn't been built on top of wine-vulkan, then it could already have used features of Vulkan 1.1. So it's not simply an advantage, but an additional layer can be a blessing as well as an impossible hurdle.

I don't believe it needs much of a discussion, because it should be common knowledge that the closer one can build to the bare metal, the better the results will be. It's the story of Linux after all and also the reason for Vulkan's performance. DXVK is really just a cheap glue, but an effective one and it would have been better if it had been built right into WINE from the start.

The moment WINE has caught up with its efforts will DXVK disappear. And there is no guarantee for any of the DXVK code to finds its way into WINE. Probably none of it will.

[shmerl]

He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.

Nonsense. Wine is also free to start accepting C++ libraries.

[bobwya]

He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.

Hmmm... I would disagree that Phillip is not contributing to Wine. He has stated that he doesn't run Windows and clearly DXVK is targeted at Linux+Wine (primarily due to the tier 1 Vulkan support on Linux at the moment). The benefits to Windows users are significantly lower than to Linux users. The former able to chose from 1-2 alternative graphics stacks and the latter currently having no really performant DX11 translation stack (although Wine Staging+Wine-PBA is a start).

We can argue whether DXVK would have iterated as fast and been as successful, as it has been... If say DXVK had to be subject to Wine's code restrictions (old C standard, etc.) and slow-review process. There are probably some benefits from using a more modern language like C++ and a modern toolchain. Especially so if a developer is more comfortable using a more modern language.

Because DXVK is cross-platform, bugs can be cross-referenced between say the Linux graphics driver stack and the Windows driver stack. There is a good reason for Nvidia and Mesa developers to be lurking on the DXVK Issue tracker!

We should not forget that simply DXVK shims above the Wine-Vulkan layer when running on WIne. The developer of the Wine-Vulkan patchset has been actively supporting DXVK.

What matters to me, as a Wine user, is that DXVK can integrate very easily with existing Wineprefix('s). There will even be a winetricks verb for this (soon I hope!) Despite it being a third party project.

[sdack]

Not sure why people are so upset with meson & ninja, they function fine under Linux and there must be reasons for using it (perform better?, is easier?, also supported on other platforms?)

I don't know who is upset about these tools, but there is certainly a lot of hype and false information floating around, which one can blame. For instance did the GNOME project switch from autoconf & make to meson & ninja, because someone was getting major performance gains with it. The claims were real, but the arguments were one-sided. Nobody looked at why they failed as badly as they did with autoconf & make. One can create a mess with any tool if it's only complex enough, and end up regretting it. Whatever the problems were did it not end up as feedback and improvements to autoconf & make or only in a better use of the tools, but instead did they switch to a new build system, which hasn't even matured yet.

However, this is what any project wants, to get feedback, but young developers always quickly run off at the slightest sign of adversity to do their own thing. They are simply not used to working in diverse teams (they are more used to cherry-picking their friends via Facebook i.e.) and so this sort of thing always creates drama understandably. It's the "Starbucks wrote my name on my cup"-generation or Facebook-generation if you will, but they are the next generation of developers no less. So they do a lot of old stuff in different ways, they isolate themselves from established projects, only to make it their own. (It reminds a bit of the story of the Lost Son.)

[Maslou]

Tremendous results, I'm cheating on the progress in the development of this library. I'm waiting for the Portwine-linux project to include DXVK. This will allow even novice lynx to play games Steam \ BattleNet (windows).
P.S. Sorry for my English!

[theriddick]

I do hope there is more progress being done on the DX12 to Vulkan project.
Seems we have some sneaky exclusives on that walled garden(dx12) which would be nice get around sometime in future.

Hopefully sometime in distant future DXVK will no longer be needed for new games, great for legacy support only sort of thing.

Not sure why people are so upset with meson & ninja, they function fine under Linux and there must be reasons for using it (perform better?, is easier?, also supported on other platforms?)

PS. It is open-source so somebody should try to port over the code to the wine compat compilers if its so important.

[sdack]

I believe that Philip's contribution to WINE will be a critical path to bringing more gaming to Linux.

He isn't contributing to WINE. He is contributing to Windows gamers. The toolchain of DXVK however appears to only oppose the WINE project, which uses autoconf & make, C and winegcc, whereas DXVK uses meson & ninja, C++ and mingw. DXVK is a Windows DLL and it is distributed as a binary on GitHub aside its source code. Frankly, solo artists like him who avoid and oppose the established projects such as WINE is what Microsoft is now trying to get their hands on.

[oooverclocker]

Thanks to everyone working on DXVK! This is the most wonderful and important project in the last weeks. I can't await to run my Windows only games on Linux on this.

Valve to auto package the games with a wine runtime with flatpak

Let's not make too much premature noise about it and better encourage the right people.