VKD3D 1.5 Lands In Wine For Updated Direct3D 12 Over Vulkan

[arQon]

Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.

Or, you could not voice an insulting opinion about people you know absolutely nothing about; and accept the reality that Wayland is a non-functional unstable dumpster fire, which is not exactly a desirable thing to introduce to a project that already has one of those to deal with.
But, you do you.

[mulenmar]

some changes to Wine that seem "obvious" in the surface cause other problems moving Wine forward.

This is a giant red flag that a software project was not designed and maintained properly -- modularity is vital for large projects, specifically so that new technologies can be adapted to with minimal fuss.

If Wine can't adapt because it would break things, they need to step back and do some rework.

But yeah Wayland needs to fix its own shit already too, so Wine has a proper target to work with in the first place.

[JPFSanders]

Your claim makes no sense because the question wasn't about Win32 support in Proton but the Proton fork of vkd3d, so a technology aimed at games.

Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.

I strongly disagree, In my personal experience the Wine developers have always been helpful, what is not understood by many is that some changes to Wine that seem "obvious" in the surface cause other problems moving Wine forward.

[Quackdoc]

Your claim makes no sense because the question wasn't about Win32 support in Proton but the Proton fork of vkd3d, so a technology aimed at games.

Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.

well considering that we have yet to have a somewhat decent cross platform dock or even a good virtual keyboard that works across compositors, I would have to agree with them, everything uses some kind of compositor specific crap, wlr-layers, or whatever KDE or gnome have. Wayland is a fucking mess lol, I would agree with their stance on this one

[Awesomeness]

They serve different use cases, proton doesn't care about obscure Windows applications that require exotic functionality/integration with other Win APIs and that can get in the way of gaming performance.

Your claim makes no sense because the question wasn't about Win32 support in Proton but the Proton fork of vkd3d, so a technology aimed at games.

Given the backwards facing rhetoric of upstream Wine developers – somewhat recent (2020?) statements such as saying there is no need to support Wayland because X11 is better anyway for supporting systray – I have the strong suspicion that working with Wine developers are just a chore to work with.

[Linuxxx]

It still doesn't make much sense. If we assume that CodeWeavers mostly cares about macOS support, a direct Metal to D3D12 wrapper would be easier to develop and deploy and it would have lower overhead as well.

Looks like the few remaining Linux customers still justify the effort of only writing a D3D12-to-Vulkan wrapper and then using MoltenVK to translate Vulkan-to-Metal on macOS.

Plus it's Apple users we are talking about here:
They are simply used to miserable gaming performance!

[brent]

Because it's developed for CodeWeaver's CrossOver product, which is mainly bought by macOS users.

And since VKD3D-Proton rightfully doesn't care about Apple's own Metal API, CodeWeavers is forced to develop their own solution, a.k.a. plain VKD3D.

It still doesn't make much sense. If we assume that CodeWeavers mostly cares about macOS support, a direct Metal to D3D12 wrapper would be easier to develop and deploy and it would have lower overhead as well.

[Linuxxx]

Why does this even exist? vkd3d-proton is so far ahead it's not even funny.

Because it's developed for CodeWeaver's CrossOver product, which is mainly bought by macOS users.

And since VKD3D-Proton rightfully doesn't care about Apple's own Metal API, CodeWeavers is forced to develop their own solution, a.k.a. plain VKD3D.

[JPFSanders]

Why does this even exist? vkd3d-proton is so far ahead it's not even funny.

They serve different use cases, proton doesn't care about obscure Windows applications that require exotic functionality/integration with other Win APIs and that can get in the way of gaming performance.

Wine cares about those applications.

Both are open source and code is moved back and forth between them every now and then. They don't exist on separate vacuums.

[Quackdoc]

Is vkd3d-proton a hard fork of vkd3d, or do they still take some stuff from upstream?

as far as I can tell, vkd3d will occasionally pick things up from proton, and Hans has a few commits in vkd3d, but they are mostly entirely seperate outside of a few crossovers.