WineD3D Vulkan Back-End Is Back In The Works Following Wine 5.0

[phoronix]

Phoronix: WineD3D Vulkan Back-End Is Back In The Works Following Wine 5.0

One of the features that didn't materialize in time for Wine 5.0 as the annual stable Wine release was the work-in-progress Vulkan back-end to WineD3D. Rather than going from Direct3D to OpenGL as WineD3D currently does, there has been efforts to introduce a Vulkan back-end similar to the likes of DXVK...

http://www.phoronix.com/scan.php?page=news_item&px=WineD3D-Vulkan-Post-5.0

[R41N3R]

But why? Because DXVK is not invented by them? Because they cannot contribute to some other free and open source software? They don't like some programming langue? This sounds just hilarious... They will waste a huge amount of development time for something that we can expect to be fully functional when? 2030 with Wine 15? And stating by WineD3D's history, I fear it will not even provide any performance benefit. I'm not convinced.

[mphuZ]

Well.. If one person managed to achieve normal work in a year and a half, then the Wine team should get it much faster!

[loganj]

mphuZ and yet, seems that VKD3D was started (Nov 2016) before dxvk (Oct 11, 2017 initial commit) and it took a longer time to actually work.

[Xaero_Vincent]

Well WineD3D is way behind DXVK. It's not just that DXVK offers much faster performance but it's a more complete implementation than WineD3D is and many games don't even render properly or at all with D3D and require DXVK.

So I guess it's good that Wine is working on an official Vulkan implementation because the OpenGL one is nearly useless on Linux and soon macOS will remove their deprecated OpenGL support entirely; Wine will require MoltenVK for any games to work in macOS unless Codeweavers wants to write and maintain a completely separate Metal renderer.

This video is an example (skip to the 2:35 minute mark to see the WineD3D):

[randomsalad]

But why? Because DXVK is not invented by them? Because they cannot contribute to some other free and open source software? They don't like some programming langue? This sounds just hilarious... They will waste a huge amount of development time for something that we can expect to be fully functional when? 2030 with Wine 15? And stating by WineD3D's history, I fear it will not even provide any performance benefit. I'm not convinced.

Coding standards. The Wine project is adamant about their pure C implementation, while DXVK is a project written in C++. I don't know if there are any advantages to either implementation, but the objective truth is that DXVK is a complete implementation, while d3dvk is a work in progress, despite the time discrepancy. The nice thing about DXVK is that it's not exclusively built for wine; You can use it anywhere you have a vulkan backend and software written in d3d11/10, which will become important when dx11 is eventually deprecated.

[Sethox]

But why? Because DXVK is not invented by them? Because they cannot contribute to some other free and open source software? They don't like some programming langue? This sounds just hilarious... They will waste a huge amount of development time for something that we can expect to be fully functional when? 2030 with Wine 15? And stating by WineD3D's history, I fear it will not even provide any performance benefit. I'm not convinced.

I doubt there are arrogance involved, it's more to old standards vs. new methodology. Imagine if DXVK project was just a "solution" to a situation, but the solution cannot fit in every situation/use cases to the mainstream Wine project. Pieces has to be adapted and replaced to fit entirely (reason why it takes time) while a solution only need to be developed and connect how the project-developers see it fit. That's the complicated yet easy to answer the time difference.

Coding standards. The Wine project is adamant about their pure C implementation, while DXVK is a project written in C++. I don't know if there are any advantages to either implementation, but the objective truth is that DXVK is a complete implementation, while d3dvk is a work in progress, despite the time discrepancy. The nice thing about DXVK is that it's not exclusively built for wine; You can use it anywhere you have a vulkan backend and software written in d3d11/10, which will become important when dx11 is eventually deprecated.

randomsalad's answer brings out an interesting point too I did not think of. DXVK is just not for Wine, but now when DXVK is so developed and tested (well known too) I doubt anyone wants to rewrite it to C (con and pros). Nothing stops anyone else to try, the code is there.. if you don't like to wait that is (why wait when you can literally make it yourself).
The argument of time is a pointless one if you yourself are not willing to put the effort in my opinion, especially when it's open source (a bit of a tangent). To be clear, I am well aware not everyone has the time thus end-users wait, and that not all end-users have the knowledge how to develop and really explains why they bring up the developing time.

[oiaohm]

Well WineD3D is way behind DXVK. It's not just that DXVK offers much faster performance but it's a more complete implementation than WineD3D is and many games don't even render properly or at all with D3D and require DXVK.

There are different applications that render correct with WineD3D and still don't render with DXVK so claiming more complete implementation is not exactly right.

So I guess it's good that Wine is working on an official Vulkan implementation because the OpenGL one is nearly useless on Linux and soon macOS will remove their deprecated OpenGL support entirely;

Unfortunately this is going to lead to absolute ugly because the opengl backend is not in fact 100 percent useless. Are you forgetting when you come to some of your legacy games they are opengl engines only. Also you get like old applications that have sections rendered in opengl and dx 9 in the same window.

Wine will require MoltenVK for any games to work in macOS unless Codeweavers wants to write and maintain a completely separate Metal renderer.

Not exactly true. The android support in wine has been working on supporting running opengl applications on opengl es. So some of your old games will work on macOS MoltenGL. Some of your old enterprise applications will be still requiring the opengl backend due to the way they abuse opengl.

What macos is doing could lead to.
Metal->MoltenVK->Zink(some opengl to vulkan wrapper)->wined3d and wine opengl could be a possible required path to run some applications. Welcome true total ugly.

Xaero the reason for need the opengl backend from wined3d is some of your horrible old applications. Reason for wine need opengl is again for horrible old opengl only applications/games and horrible old opengl/dx program hybrids.

DX to Vulkan is possible for pure DX applications. Also this means users have to have moved from using opengl only cards. Yes people are still out there using opengl only cards.

DXVK has in some ways been able to move faster because they have not been considering how to solve the hybrid nightmares. When I say hybrid nightmares I mean the programs that in a single window are mixing sections rendered in opengl with sections rendered in dx and needing those synced.

Xaero you are looking at benchmarks of games. Codeweavers customers happen to include enterprise customers with some of the most horrible built production applications you have ever seen for abuse of dx and opengl in a single window. Yes those cases don't need more than 10 fps. These horrible cases why wine need for dx to opengl is not going away any time soon.

This also leads to a horrible different if wine is wanting to keep lines of code as low as possible to maintain and cannot drop the opengl layer support(really you cannot) you need the vulkan part to share code with the opengl part where it makes sense wined3d part.

Yes making a joint vulkan/opengl code base is way harder than just making a vulkan or opengl code base.

Coding standards. The Wine project is adamant about their pure C implementation,

That is not 100 percent true. winegecko that is a sub part of wine is C++. Sections of wine are pure C but sub part technically can be C++.

Core parts of wine are normally locked to C to remove the annoying variation between C++ versions that you can get. C++ based parts like winegecko normally shipped to end users as prebuilt binary MSI packages. So compiler issue is mitigated. Wine coding standard would not forbid dxvk coming in as like a winegecko project.

[loganj]

is wine for android working? i wonder if they'll add vulkan support for android version too

[oiaohm]

is wine for android working? i wonder if they'll add vulkan support for android version too

Define working. It works enough that notepad in wine and basic programs work. Wine project does have builds for android. You standard android keyboards don't in fact work. You have to use
https://f-droid.org/en/packages/org....on.pckeyboard/

More fun is currently due to hangover not being complete if you are on a arm64 android(that is like 99.9 percent of them) you need windows arm64 bit applications that are kind of rare.

All android devices that don't ship with Android 10 installed are not required to support vulkan even if they are latter vendor upgraded to Android 10. So you have opengl ES 3.1 on a large number of Android devices. Note 3.2 has been released for ages.

Also devices that ship with Android 10 and claim to be "low memory" devices as in your Android go devices also are not required to support Vulkan. And again may only support Opengl ES 3.1

Basically supporting Android is a level 1000 migraine for wine project.

Please note Opengl ES 3.1 is not the same as your desktop Opengl is a version of opengl with massive amounts of feature removed and some unique features.

OpenGL backend on wine some of it is required so at some point wine can run on a reasonable number of Android devices due to how horrible Android min specifications are.