Wine 4.6 Released With Initial Bits Towards Vulkan WineD3D Backend

[phoronix]

Phoronix: Wine 4.6 Released With Initial Bits Towards Vulkan WineD3D Backend

Wine 4.6 is now available as the latest bi-weekly development release and is actually quite exciting on the feature front with the developers -- especially those at CodeWeavers -- being quite active this spring...

http://www.phoronix.com/scan.php?page=news_item&px=Wine-4.6-Released

[pinguinpc]

This wine version add new build dependency mingw cross compiler, have more work in mfplat - quartz and others

Resident Evil 6 + Mods

Last test with Pentium G3258 @ 4.1ghz + Artic Cooling Alpine 11 Plus

With Core i3 8350K Tri-Core @ 5.0ghz + Zalman CNPS 10x Performa+

[MastaG]

So are they still going to work on using dxvk (or at least parts of it) for their WineD3D to Vulkan layer?
Or are they going to write it from scratch without even looking at dxvk?

[simburde]

What a waste of human resources! Sometimes people just can't avoid political and ideological reasons and get pragmatic.

[sdack]

What a waste of human resources! Sometimes people just can't avoid political and ideological reasons and get pragmatic.

It's the same with the US and Canada. Why the need for two governments?! What a waste of human resources!

[chris200x9]

It's the same with the US and Canada. Why the need for two governments?! What a waste of human resources!

Exactly! Why do we need a whole different government for our 51st state? That's just wasteful.

[R41N3R]

Yeah, why would Wine consider to use a fast and stable project like DXVK and soon D9VK, when they can start something from scratch again ;-)

[sdack]

Yeah, why would Wine consider to use a fast and stable project like DXVK and soon D9VK, when they can start something from scratch again ;-)

Only in your dreams. DXVK dropped their latest release, because it crashes too many drivers. That's no stable at all. It's then never been stable, but only reasonably stable for some titles. Everyone who had a difference experience continues to hold their breath and utters only praise in hope it doesn't upset the author and so that their favorite game still finds support soon.

And while it's faster than OpenGL - only thanks to Vulkan of course - is it also no where near the speed of Windows itself. It remains a slow solution and the choice of using OpenGL or Vulkan remains about as pathetic as two homeless guys who are fighting over a banana. Even when you there get a title to run solid at 60 fps+vsync with DXVK does it still produce microstutter and just doesn't feel as smooth as Windows.

My only hope is that competition will change things up. I'm definitely happy to see others implementing DX11 on Vulkan support into WINE. It means it will become an integral part of it and receive fixes and support for many years to come. I sure don't see that happening with DXVK. The author wasn't interested in contributing to the WINE code base in the first place, nor is he interested in a cooperation now, so why will he care in the future about his own project? Only in your dreams.

[oiaohm]

So are they still going to work on using dxvk (or at least parts of it) for their WineD3D to Vulkan layer?
Or are they going to write it from scratch without even looking at dxvk?

Yeah, why would Wine consider to use a fast and stable project like DXVK and soon D9VK, when they can start something from scratch again ;-)

Both of you the story is more complex.

https://mesamatrix.net/

spirv is the shader language of Vulkan. Do notice GL_ARB_gl_spirv in Opengl 4.6 here. So sections of Vulkan support have to be implemented in the Opengl Wined3d anyhow to take full advantage of Opengl 4.6.

Dxvk is design purely for a Vulkan back end. There can be differences between opengl spirv and vulkan spirv as well so there need to be a Wined3d form that will be slightly different to Dxvk in places.

Yes this is kind of the question why maintain independent Opengl and Vulkan direct x implementations particularly when the opengl one has to contain Vulkan parts anyhow for the most recent version of opengl.

It was predictable that at some point wined3d would grow Vulkan support as the requirements of Opengl was going to push Wined3d that way.

Extending wined3d is not starting from scratch either. The developer adding Vulkan support to Wined3d was tied up working vkd3d the DX12 implementation. Only reason Vulkan support in Wined3d did not start sooner is lack of wine project resources.

Think about it we want systems that are stuck with opengl for some reason to perform the best possible as well. DXVK/D9VK is not the end of the story they have been good prototypes to show the Vulkan form can perform well and be good for vulkan wined3d to run against.

[RussianNeuroMancer]

Regarding mictostuttering - I don't get why Valve still not using their shader cache distribution infrastructure. I get that it's preparation for something bigger than us (probably something like second wave of SteamOS-based console, this time with Proton) but they could at least let people upload shader caches for stable Mesa releases, upload and re-distribute shaders among Proton users automatically or something like that. It's such a waste that every Proton user get microstuttering while shaders is compiled in background, instead of downloading pre-compiled shader cache.