New Patches Help WineD3D Performance - Doubled FPS In Some Micro-Benchmarks

[shmerl]

Reality you could call this a kind of race its still hard to pick a winner.

Solution is kind of simple. Ship both wined3d and dxvk / vkd3d-proton and allow selecting what you need with winecfg. I see no reason not to do that.

[oiaohm]

Solution is kind of simple. Ship both wined3d and dxvk / vkd3d-proton and allow selecting what you need with winecfg. I see no reason not to do that.

This runs into wine project goal problem.

https://wiki.winehq.org/AppDB_Rating_Definitions

Platinum
Works as well as (or better than) on Windows out of the box.

Adding setting to winecfg to allow application to run goes against Platinum/wine end goal requirement. Yes out of the box requirement that users should not need to play with settings so programs run.

You could call this a wine culture problem. This is why dxvk failing test suites is a problem. Ideal world here is changing between wind3d and dxvk should have the same test successes and failures so not causing users to have a different outcome based on how the setting is set.

vkd3d is mostly dx12. wind3d is dx11-1.

Yes the wine project goals created the appdb ratings that way. Yes the project goals give dxvk a huge requirement to jump over.

[shmerl]

This runs into wine project goal problem.

https://wiki.winehq.org/AppDB_Rating_Definitions

Not a technical blocker, more a bureaucratic problem or like you said a culture problem. If something doesn't fit, Wine can adapt instead of being stuck behind.

[oiaohm]

Not a technical blocker, more a bureaucratic problem or like you said a culture problem. If something doesn't fit, Wine can adapt instead of being stuck behind.

Its more than bureaucratic. Start thinking wine project is running the appdb now you have two users with the same version of wine on the same OS same basic hardware with one claiming X program works and other claiming it does not.

out of the box.<< Where user delete the wineprefix and installs game and you are done is a wine project goal. This goal makes the appdb lot simpler technically manage.

The protondb has had a stack of issues with disputing users where one user claims something works and another says it totally broken because of the switch between wined3d and dxvk. So having switch to enable/disable dxvk this is now creating a technical problem that can be seen in the real world.

Remember wined3d is not behind dxvk in every metric. Performance dxvk wins. Amount of implement dx 1-11 API wined3d is way ahead and wins that.

This is another part of the problem the status between dxvk and wined3d is not black and white but shades of grey the winner changes based on what metric you are using.

Yes and the difference is changing. Wined3d is gaining in performance and dxvk is gaining in implemented API.

This is not a simple we have the answer problem. In many ways this need to play out for a few more years to see how much wined3d with its vulkan backend gains in performance and how much dxvk is able to gain in API/ABI implementation.

Yes it really simple to try to call the winner now and its like betting on the leading horse half way though the race at the moment (being dxvk) it might win but it also could trip and fall before the finish line.

[Monsterovich]

Even now, gallium-nine gives much better performance for d3d9 only software [even compared to Windows], it's quite amazing how much will just work at 4K with my modest hardware: RX470 + FX9370

I was never able to get gallium-nine to work, even on a supported GPU. I always thought that it was abandoned. Anyway, without supporting it on NVIDIA, everything is pointless because NVIDIA is a main-stream gaming GPU vendor. I guess that's why it was forgotten.

[oiaohm]

I was never able to get gallium-nine to work, even on a supported GPU. I always thought that it was abandoned. Anyway, without supporting it on NVIDIA, everything is pointless because NVIDIA is a main-stream gaming GPU vendor. I guess that's why it was forgotten.

https://www.phoronix.com/scan.php?page=news_item&px=Zink-Gallium-Nine-Vulkan

That is something that is changing. The work from zink means gallium-nine in future will also be able to work over vulkan. So able to work on Nvidia cards with functional vulkan support.

So yes things are getting interesting.

[s_j_newbury]

I was never able to get gallium-nine to work, even on a supported GPU. I always thought that it was abandoned. Anyway, without supporting it on NVIDIA, everything is pointless because NVIDIA is a main-stream gaming GPU vendor. I guess that's why it was forgotten.

gallium-nine works great. I maintain my own Proton fork which uses gallium-nine by default for d3d9 games.

[s_j_newbury]

Anyway, without supporting it on NVIDIA, everything is pointless because NVIDIA is a main-stream gaming GPU vendor. I guess that's why it was forgotten.

No, it's irrelevant. The Linux graphics stack can not be held hostage by a single vendor which doesn't even contribute. The NVIDIA hardware is supported through Nouveau, it works with gallium-nine, it's NVIDIA which sabotages it on any non-ancient devices through refusal to release signed firmware, or reclocking information.

If there had been buy-in to Gallium state trackers for D3D including dx10 and dx11, which was under development for a while, the whole D3D->Vulkan translation debacle would have been avoided and there would have been flawless support now even on non-Vulkan capable hardware. It might have even been ported to to Windows where it could have been used with virtio-gpu, or even as native hw drivers as alternative to the proprietary drivers there which would have made a lot of users of AMD Terrascale GPUs very happy. Gallium3D was always intended to be platform/window system agnostic.

Alternative history.

[bemerk]

With open-source people can always work on their own state trackers and if i remember correctly these are also available for higher dx versions.
So if the owners have a paragon moment and decide to upstream their efforts like it was done for ntfs , it can still happen despite dxvk and vkd3d.
Maybe MS wants to complete their mesa work

[oiaohm]

With open-source people can always work on their own state trackers and if i remember correctly these are also available for higher dx versions.
So if the owners have a paragon moment and decide to upstream their efforts like it was done for ntfs , it can still happen despite dxvk and vkd3d.
Maybe MS wants to complete their mesa work

https://www.phoronix.com/scan.php?page=news_item&px=MTMyNDU

Sorry to say the Dx11 and Dx10 state trackers in mesa were nuked out of existence in 2013 due to lack of developers.