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

[CochainComplex]

I have heard that mapping DX12 to Vulkan should be easier as DX12< mapping to Vulkan because of its similar nature of beeing a low level api

[geearf]

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.

Is not wanting to work on a codebase such a bad thing? I mean how many years forward do you think the Wine guys will be supporting D3D->Vulkan wrappers? I'd bet a lot more than what it took to build DXVK to current.

[stevecrox]

Is not wanting to work on a codebase such a bad thing? I mean how many years forward do you think the Wine guys will be supporting D3D->Vulkan wrappers? I'd bet a lot more than what it took to build DXVK to current.

Is not wanting to work on a codebase such a bad thing? I mean how many years forward do you think the Wine guys will be supporting D3D->Vulkan wrappers? I'd bet a lot more than what it took to build DXVK to current.

Software engineering is a job, this means inheriting messy codebases and fixing them. You don't get to do new development all the time. Someone has to maintain it.

They are a company looking to sell a product. This means idiological purity has to be second to business pragmatism.

Look at Ubuntu who massively suffer from NiH, rather than extend Gnome 3 or KDE they spent years building
their own desktop at a loss to the business. They switched to gnome 3, added a few plugins and have a similar desktop. That switch is massively accelerating Gnome performance.

[dragon321]

But why? Because DXVK is not invented by them?

Well, DXVK has some problems with 32 bit games and even DXVK wiki recommends using wined3d for 32 bit games.

Maybe not in DX11, but DX9 support is pretty mature in wined3d and Vulkan backend can make it work better.

[shmerl]

Instead of wasting time on re-inventing the wheel, let Wine developers add Wayland support. Seriously. dxvk does the job perfectly already for Vulkan backend.

[oiaohm]

Instead of wasting time on re-inventing the wheel, let Wine developers add Wayland support. Seriously. dxvk does the job perfectly already for Vulkan backend.

Doing a direct Wayland backend for wine would also be a lot of reinventing wheel as well.

shmerl we have the upcoming headache of how to cross from 32 bit to 64 bit with distributions starting not to ship 32 bit parts. dxvk has not done any work on that yet some of the reason why wine developers wanted dxvk developer to come across.

dxvk does not deal with dx1-7 yet either. Life is basically not easy.

[betam4x]

Instead of wasting time on re-inventing the wheel, let Wine developers add Wayland support. Seriously. dxvk does the job perfectly already for Vulkan backend.

We will likely never see Wine support Wayland unless one of the following happens:

1. The Wayland team works with the Wine team on implementing features needed to support Wine
2. Wine builds out a Wayland virtual desktop and confines the application to the virtual desktop.
3. Someone figures out a creative way to implement certain Windows API calls within the restrictions that the Wayland team has provided (which is unlikely).

The issues is that quite a few Windows API calls do things that Wayland doesn't support. This isn't the fault of the Windows API (though some may try to blame it on Windows), but rather, the way Wayland is implemented.

Wayland makes several (sometimes incorrect) assumptions about how applications SHOULD behave and what they should be allowed to do.

[betam4x]

Doing a direct Wayland backend for wine would also be a lot of reinventing wheel as well.

shmerl we have the upcoming headache of how to cross from 32 bit to 64 bit with distributions starting not to ship 32 bit parts. dxvk has not done any work on that yet some of the reason why wine developers wanted dxvk developer to come across.

dxvk does not deal with dx1-7 yet either. Life is basically not easy.

If the author got bored, earlier DirectX versions would be trivial to implement. DirectX 7 is actually MUCH easier to implement than DirectX 9 or 11.

[betam4x]

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.



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.



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.



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.

That is a packaging issue more than anything. The real issue for Wine developers is that the DirectX API itself is designed for use with C++, since it uses COM. You CAN use it in C (with the use of macros), but I'd be surprised if anyone does. That is likely the reason the author of DXVK chose to build it in C++.

Regarding WineGecko, I wish more Wine components would take this approach. I would honestly like to see the Wine team split up the project into multiple git repositories and package each component independently. That way Windows components with COM interfaces can be written in C++ if needed. Furthermore, these components can be built/tested easier, and it will help the Wine team identify dependency issues, which in turn, will improve compatibility. This is just wishful thinking however.

Note that by doing this, they could potentially build out automated application testing (think: swap out a system dll and start say...photoshop for example, perform a series of actions and expect specific results, fail if the result is incorrect). Technically they can do this with Wine now (to an extent), but it is much more difficult.

[oiaohm]

The Wayland team works with the Wine team on implementing features needed to support Wine

That wrong. All the features need to implement wine on Wayland is there and has to be there for Xwayland. Just it a hell lot of work to make work.

Wayland makes several (sometimes incorrect) assumptions about how applications SHOULD behave and what they should be allowed to do.

Funny enough is list them. Then carefully go and look at how Windows protects User Account Control dialogs and you will find you have just listed how they are protected.

Then you should wake up Wayland protocol limitations are exactly the same as the Windows compositor limitations that the windows win32 in fact sits on top of,

Basically you are completely wrong here. But just like when Microsoft made Windows Vista and inserted the compositor there is a hell load of work.

If the author got bored, earlier DirectX versions would be trivial to implement. DirectX 7 is actually MUCH easier to implement than DirectX 9 or 11.

Dx7 is not simpler neither is Dx9. What makes both of those messy is the fact Nvidia decided to get creative with opengl and decide to allow DX buffers and Opengl buffers to interact. D9vk in dxvk does not support that interaction yet.

The real issue for Wine developers is that the DirectX API itself is designed for use with C++, since it uses COM. You CAN use it in C (with the use of macros), but I'd be surprised if anyone does. That is likely the reason the author of DXVK chose to build it in C++.

Direct X API is horrible implemented across multi different msvc C++ versions internally some of the error with DXVK that going to get online player banned is using C++ single version. Because you cannot copy the memory behaviour of different versions of C++ from one version of C++. The catch here is you can from C copy the memory behaviour of different versions of msvc C++.

Fun right DX 11 is designed to be used form C++ but then to implement it behaviour correct you have to use C or 4 versions of MSVC C++.

Real issue is implementing DX has multi levels of evil and is very simple to over look one and end up getting people banned for so called cheating when they are not.

What the 4 C++ are.

1) Parts provided by Microsoft build for user space is built using there chosen version from SDK.
2) Parts provided by Microsoft built for kernel space using their chosen verison of NDK that times may be run in userspace.
3) Parts provided by driver vendor for userspace. Some version of MSVC
4) Parts provided by driver vendor for kernel space. MS NDK some version compiler

Basically when it comes to compiler versions driver vendors and Microsoft are not on the same page. At times the driver vendor or microsoft might provide user space libraries where some are build different versions of the compilers to the rest.

So only have 4 different C++ compilers in the mix is being optimistic. These different C++ versions can mean needing different in memory alignments of stuff. This multi C++ nightmare apply to implementing the complete windows libraries.

This is also not allowing that wine and dxvk is in fact building with gcc who C++ implementation is different to Microsoft one.

So yes dxvk has been able to implement more faster than wine developer can by going C++ but its going to hit a compatibility wall all from the choice of language and the resulting choice of compiler. The fastest path to solution is not always the best.

Why does it make sense to port wined3d to vulkan for DX11/DX10/DX9 when we have DXVK is this complete compiler trap. Its not like those implementing wined3d C code cannot use dxvk as reference.

Lot of people who push C++ complete ignore the differences between compiler versions on memory alignments and other things that the C++ standard does not define. The unfortunate part here is some of the anti cheat will check for stuff at particular memory alignments and throw error/ban if alignment is off and this is not the ones that checksum everything.