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

[s_j_newbury]

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

There was indeed a state tracker for dx10 and 11 as I mentioned, but it got removed from Mesa as nobody was maintaining it. There are expertise prerequisites for working on something like that, knowledge of the APIs certainly helps, I for one am completely clueless when it comes to DirectX.

It's a bit late now probably, even gallium-nine struggles against DXVK for mindshare, despite significant advantages in performance and hardware coverage, almost any card from the last 20 years! There's probably not so much to be gained by dx10/11. It pretty much means all r600 and Intel Gen4+ get performant d3d10, and a few get d3d11. Mind you, fewer support Vulkan, it's obviously not been sufficient to motivate anybody capable.

[s_j_newbury]

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.

It's still in the git history. They could be resurrected if somebody wanted to work on them, all it takes is a revert. I suppose, since Crocus, it might be a worthwhile project for somebody, it would probably be possible to borrow a lot of the gallium-nine wine driver code, or perhaps even extend it to support it, although as I recall the gallium-nine project wanted to keep their scope limited for maintainability.

[s_j_newbury]

It's still in the git history. They could be resurrected if somebody wanted to work on them, all it takes is a revert. I suppose, since Crocus, it might be a worthwhile project for somebody, it would probably be possible to borrow a lot of the gallium-nine wine driver code, or perhaps even extend it to support it, although as I recall the gallium-nine project wanted to keep their scope limited for maintainability.

This is interesting (I completely missed it):
https://cgit.freedesktop.org/mesa/me...e7fb7f7ef10cd7

and

https://github.com/iXit/wine-nine-standalone/issues/112

Maybe there is hope? Certainly something to build upon.

[s_j_newbury]

This is interesting (I completely missed it):
https://cgit.freedesktop.org/mesa/me...e7fb7f7ef10cd7

and

https://github.com/iXit/wine-nine-standalone/issues/112

Maybe there is hope? Certainly something to build upon.

It would be very interesting to see Linux working with DX10/11 GPUs and providing better support than Windows at running Windows games, there's probably a lot of old laptops in that category, which probably don't even work with Windows 10.

[Quackdoc]

This is interesting (I completely missed it):
https://cgit.freedesktop.org/mesa/me...e7fb7f7ef10cd7

and

https://github.com/iXit/wine-nine-standalone/issues/112

Maybe there is hope? Certainly something to build upon.

d3d10umd has very little incentive to be built upon for wine. that being said it wouldn't necessarily be too hard. but I doubt there would be much incentive to do it.

wined3d is actually not trash as most people are saying. while wined3d VK backend doesn't outpreform DXVK, if wine wanted to use DXVK instead of wine, they would HAVE to fork it, and implement all the missing features. which would not only be way more work then getting WineD3D up to the quality standards (again DXVK is laser focused on gaming preformance NOT API accuracy) but the potential it could also actively reduce preformance of DXVK anyways is very real.

as for wine itself, implementing a native gallium implementation doesn't make too much sense either. if the goal is to be as compatible as possible implementing a Gallium backend means that the device will need to support either gallium or vulkan. while this is great for many linux distros, wine devs to my knowledge have always been forward thinking. there are plenty of devices/OS's that don't support gallium drivers like that. WineD3D is still useful for people who like to play retro games. it is the most compatible dxwrapper in my experience.

and it can even be used in conjunction with qemu-3dfx to get decent 3d acceleration in windows XP and win9x guests

while it's definitely not a bad idea to implement usermode drivers, the incentive is just not there yet in my opinion.

[s_j_newbury]

d3d10umd has very little incentive to be built upon for wine. that being said it wouldn't necessarily be too hard. but I doubt there would be much incentive to do it.

Yet gallium-nine is still actively maintained.

wined3d is actually not trash as most people are saying. while wined3d VK backend doesn't outpreform DXVK, if wine wanted to use DXVK instead of wine, they would HAVE to fork it, and implement all the missing features. which would not only be way more work then getting WineD3D up to the quality standards (again DXVK is laser focused on gaming preformance NOT API accuracy) but the potential it could also actively reduce preformance of DXVK anyways is very real.

wined3d is does a good job, but there is a reason gamers prefer DXVK. Performance level has to be sufficient. For retro games on modern hardware, I'm sure it's fine.

as for wine itself, implementing a native gallium implementation doesn't make too much sense either. if the goal is to be as compatible as possible implementing a Gallium backend means that the device will need to support either gallium or vulkan. while this is great for many linux distros, wine devs to my knowledge have always been forward thinking. there are plenty of devices/OS's that don't support gallium drivers like that. WineD3D is still useful for people who like to play retro games. it is the most compatible dxwrapper in my experience.

Native Gallium does make sense for any supported GPU on Linux, all maintained OpenGL drivers are now Gallium3D based. Also don't forget, not every OS supports OpenGL or Vulkan either, Mac OS for example. That's why gallium-nine exists even though Wine made clear it would never go upstream, and why it was made a standalone DLL. The performance is typically better than Windows with gallium-nine, that can't be said for WineD3D or DXVK, and it works for for any GPU with "Shader Model 3.0" feature level, so retro games can be played on retro hardware with a secure OS, or on more modern hardware at much higher resolutions- as I mentioned I can play d3d9 games at 4K maximum quality on an AMD FX9370 + RX470.

and it can even be used in conjunction with qemu-3dfx to get decent 3d acceleration in windows XP and win9x guests

That sounds pretty cool, I didn't know about that.

while it's definitely not a bad idea to implement usermode drivers, the incentive is just not there yet in my opinion.

More likely the skill-set isn't there for people with an incentive, but those who could do it have more valuable things to do with their time!

[Quackdoc]

Yet gallium-nine is still actively maintained.

d3d10umd and G9 are two very different things, for starters as it stands d3d10umd only currently works as a software rasterizer.

wined3d is does a good job, but there is a reason gamers prefer DXVK. Performance level has to be sufficient. For retro games on modern hardware, I'm sure it's fine.

the entire stink is people wanting wine to abandon wined3d in favor of dxvk, which wine will never do, because dxvk will never be able to fit all of the needs of wined3d

Native Gallium does make sense for any supported GPU on Linux, all maintained OpenGL drivers are now Gallium3D based. Also don't forget, not every OS supports OpenGL or Vulkan either, Mac OS for example. That's why gallium-nine exists even though Wine made clear it would never go upstream, and why it was made a standalone DLL. The performance is typically better than Windows with gallium-nine, that can't be said for WineD3D or DXVK, and it works for for any GPU with "Shader Model 3.0" feature level, so retro games can be played on retro hardware with a secure OS, or on more modern hardware at much higher resolutions- as I mentioned I can play d3d9 games at 4K maximum quality on an AMD FX9370 + RX470.

targeting OGL and VK is generally better idea, as OGL can be ported to most platforms, and any device that supports gallium pretty much supports OGL to an extent. a native driver makes sense for linux in specific I think it makes a lot of sense, but for wine specifically not so much, as wine has come to a more broad scope than just linux.

That sounds pretty cool, I didn't know about that.

yeah its pretty cool, the dev of the project also have patches that make virgl work with both mac and linux hosts, unfortunately it seems getting patches merged up stream won't happen as he did not follow proper protocol to get them merged... pain, just pain.

More likely the skill-set isn't there for people with an incentive, but those who could do it have more valuable things to do with their time!

can't really argue this one lol. all in all, I think seeing d3d10umd expanded to zink would be cool, and useful for other reasons, (windows vms), I just don't think wine has incentive to work on it.

[siyia]

This is huge! it ll probably bring wined3d close to dxvk levels

[pal666]

WineD3D is necessary, it's not going anywhere, even though we might need Zink to use it in the future.

if you can use zink then you can use wine-nine, which would be better

[pal666]

https://wiki.winehq.org/Developer_FA..._other_code.3F

somebody should tell wine devs that msvc has much better support for c++ than for c