Wine 4.6 Released With Initial Bits Towards Vulkan WineD3D Backend

[oiaohm]

Calling a project DX[version]VK is also bad for the reason that the best naming convention is mother>daughter. Direct X being implemented on top of Vulkan the best names are VKD3D[version].

Vkd3d was taken by wine project for Dx 12 and newer. Kind of makes sense from the wine point of view Dx12 by it design cannot be implemented on top of opengl at all. wined3d covers all the Dx versions than can be implemented on opengl and vulkan. So to the wine project developers this makes sense.

dxvk currently covers dx10/11 in near future it could cover dx9 of course it could expand from dx9 to dx8 as well. Any long term dx on top of vulkan that is going to last is going to expand in support dx values if implementation only support 1 dx version they have made a mistake.

[rmfx]

Calling a project DX[version]VK is also bad for the reason that the best naming convention is mother>daughter. Direct X being implemented on top of Vulkan the best names are VKD3D[version].

[cybertraveler]

...

Interesting info. Thanks.

[RussianNeuroMancer]

Is microstutter really an issue with shader compile? I thought shader compilation caused more issues with hitching and multiple frame drops at level/scene load time.

Unfortunately some engines load shader ingame, when it used for a first time. To get idea google info about running Overwatch in WINE.

[dreamer_]

Regarding mictostuttering - I don't get why Valve still not using their shader cache distribution infrastructure (…) 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.

No, they couldn't - re-distributing cache from users is a security issue and wouldn't work well anyway, because cache needs to be recreated for every vendor and driver version separately.

To fix this, Valve is working on Fossilize - serialization library for Vulkan objects. Once it'll work, cache will be stored in verified, serialized form on Valve servers and then distributed to all users and de-serialized on their computers.

So they are working on it, just instead of quick-and-dirty hack they decided to work on proper solution. Viva la Valve!

[oiaohm]

Does anyone else find it hard to mentally keep track of which Vulkan to DirectX translation project supports which DirectX version? The names are not intuitive at all.

I'd be able to remember the projects properly if they named them something like:

DX9VK-<original-author/origin>
DX11VK-<original-author/origin>
DX12VK-<original-author/origin>

If one project supported multiple DirectX versions, those simple names above would still work. You could read the name as referencing a primary DirectX target version and the project description could state the details of all the major & minor DirectX versions it supports.

At least they are doing better than Microsoft with product naming:

Number 1 you have to watch out for trademark violation. DX9, DX10, DX11, DX12 are all trademarked by Microsoft.

wined3d will grow a Vulkan part. This will be to cover from Dx1 to Dx11.

Dx10-11 by Microsoft these days are referenced as 1 spec. DX8-9 are also under the hood one spec yet we see VK9 and galluim9 not doing the Dx8. Dx1-7 is also 1 spec.

So there are 4 specifications of Direct x.
Dx1-7
Dx8-9
Dx10-11
Dx12

This gets more complex when you look at specification to specification interconnection.

Items allocated in Dx1-7 should be render by dx8-9 calls and reverse at times.
Items allocated in dx9 should be renderable by Dx10-11 and reverse at times.

There is only 1 vulkan dx12 implementation that is the vkd3d out of the wine project. Dx12 is one and only time in direct x history you have a specification that does not mandate interaction with the other specifications.

DX9VK, Dx11VK really cannot live in isolation to each other implementing in isolation is a mistake. dxvk has dx10/11 and needs to grow dx9 support this will support vista and never applications.

There were a lot of attempt to implement dx on opengl as well. Do note that wined3d is the last standing of those. This is because wined3d targeted all versions.

[cybertraveler]

Does anyone else find it hard to mentally keep track of which Vulkan to DirectX translation project supports which DirectX version? The names are not intuitive at all.

I'd be able to remember the projects properly if they named them something like:

DX9VK-<original-author/origin>
DX11VK-<original-author/origin>
DX12VK-<original-author/origin>

If one project supported multiple DirectX versions, those simple names above would still work. You could read the name as referencing a primary DirectX target version and the project description could state the details of all the major & minor DirectX versions it supports.

At least they are doing better than Microsoft with product naming:

XBox
XBox 360
XBox One

[nranger]

It's such a waste that every Proton user get microstuttering while shaders is compiled in background, instead of downloading pre-compiled shader cache.

Is microstutter really an issue with shader compile? I thought shader compilation caused more issues with hitching and multiple frame drops at level/scene load time. Whereas microstutter was more a driver/display stack issue where frame present, buffer swaps, scanout/vsync, and animation time in the game engine start overshooting and/or undershooting. I'm seriously asking, I'd like to know more. My understanding of the display stack issues is based on things like Keith Packard's recent presentations on fixing up X and DRM drivers for VR.

[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.

[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.