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
Announcement
Collapse
No announcement yet.
WineD3D Vulkan Back-End Is Back In The Works Following Wine 5.0
Collapse
X
-
Originally posted by R41N3R View PostBut 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.
Comment
-
Originally posted by geearf View Post
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.Originally posted by geearf View Post
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.
​
​​​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.
- Likes 4
Comment
-
Originally posted by R41N3R View PostBut why? Because DXVK is not invented by them?
Maybe not in DX11, but DX9 support is pretty mature in wined3d and Vulkan backend can make it work better.
Comment
-
Originally posted by shmerl View PostInstead of wasting time on re-inventing the wheel, let Wine developers add Wayland support. Seriously. dxvk does the job perfectly already for Vulkan backend.
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.
- Likes 2
Comment
-
Originally posted by shmerl View PostInstead of wasting time on re-inventing the wheel, let Wine developers add Wayland support. Seriously. dxvk does the job perfectly already for Vulkan backend.- The Wayland team works with the Wine team on implementing features needed to support Wine
- Wine builds out a Wayland virtual desktop and confines the application to the virtual desktop.
- Someone figures out a creative way to implement certain Windows API calls within the restrictions that the Wayland team has provided (which is unlikely).
Wayland makes several (sometimes incorrect) assumptions about how applications SHOULD behave and what they should be allowed to do.
- Likes 2
Comment
-
Originally posted by oiaohm View Post
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.
Comment
-
Originally posted by oiaohm View PostThere 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.
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.
Comment
-
Originally posted by betam4x View PostThe Wayland team works with the Wine team on implementing features needed to support Wine
Originally posted by betam4x View PostWayland makes several (sometimes incorrect) assumptions about how applications SHOULD behave and what they should be allowed to do.
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.
Originally posted by betam4x View PostIf 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.
Originally posted by betam4x View PostThe 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++.
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.Last edited by oiaohm; 26 January 2020, 10:26 PM. Reason: added what the 4 C++ are and a few extra notes on the topic.
- Likes 3
Comment
Comment