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

[phoronix]

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

While most Linux gamers are making use of DXVK these days for efficiently mapping Direct3D 9/10/11 over Vulkan when running Wine/Proton for enjoying Windows games on Linux, Wine developers still maintain WineD3D for going from Direct3D to OpenGL for cross-platform compatibility. Out today is a new patch series improving the WineD3D performance...

https://www.phoronix.com/scan.php?page=news_item&px=WineD3D-D3D11-CS-Fence

[rmfx]

Why don’t they do a future proof dx9/10/11/12/OpenGl to Vulkan series of wrapper instead of this ?

That should be their main focus, they claim that dxvk is not up to their standards, then go for a real alternative then. And make it future proof by setting Vulkan as the reference API for everything.

[Aryma]

as someone who still uses WineD3D thank you

I hope to see more love for WineD3D in the future

[aufkrawall]

Is it worth giving the Vulkan backend of WineD3D a try? GL backend performance is still terrible even with ancient stuff like Gothic 2 (DirectDraw). Even AMD Windows driver is faster.
Probably not by much though.

[shmerl]

Why don’t they do a future proof dx9/10/11/12/OpenGl to Vulkan series of wrapper instead of this ?

That should be their main focus, they claim that dxvk is not up to their standards, then go for a real alternative then. And make it future proof by setting Vulkan as the reference API for everything.

I never really got their resistance to accept dxvk as part of Wine. Sounded more political than technical to me.

May be someone can explain this with details?

[birdie]

I never really got their resistance to accept dxvk as part of Wine. Sounded more political than technical to me.

May be someone can explain this with details?

Maybe NIH, maybe pride, maybe the fact that DXVK has a very different workflow which doesn't quite fit Wine's style. Alexander wants not just new code and bug fixes but also tests which DXVK AFAIK doesn't have. Lastly, DXVK has its own release cadence.

I'm fine with DXVK being an external project but I don't understand why Codeweavers continue to develop their half-assed D3D implementation. Better help DXVK instead.

[jntesteves]

WineD3D has been developed, tested and tuned for games for almost 2 decades. DXVK is great for newer games, but for most games from the 2000s and even some from the 2010s it won't launch, or be unusable buggy. DXVK's focus is obviously on new games, no one will do the work of testing and fixing it on every game ever released. WineD3D is necessary, it's not going anywhere, even though we might need Zink to use it in the future.

[birdie]

WineD3D has been developed, tested and tuned for games for almost 2 decades. DXVK is great for newer games, but for most games from the 2000s and even some from the 2010s it won't launch, or be unusable buggy. DXVK's focus is obviously on new games, no one will do the work of testing and fixing it on every game ever released. WineD3D is necessary, it's not going anywhere, even though we might need Zink to use it in the future.

I'm not so sure about this statement. Have you got any data to prove it?

[shmerl]

WineD3D has been developed, tested and tuned for games for almost 2 decades. DXVK is great for newer games, but for most games from the 2000s and even some from the 2010s it won't launch, or be unusable buggy. DXVK's focus is obviously on new games, no one will do the work of testing and fixing it on every game ever released. WineD3D is necessary, it's not going anywhere, even though we might need Zink to use it in the future.

Still doesn't mean it can't be accepted in Wine together with wined3d or the need to reinvent the wheel with Vulkan backend.

[zexelon]

I love the work that Wine is doing these days for gaming. It would be nice though if they went back a bit to focus on the application side... and if by some miracle could get Office 365 working on Linux!