Wine "PBA" Shows Potential For Improving Direct3D-Over-OpenGL Performance

[oiaohm]

Anyway, codeweavers main benefits is their contribution to wined3d. As we can see its worked so well that the community had to step in to make Gallium Nine, and they shit all over it. Now the community stepped in again with VK9 and soon a DX11 to Vulkan. Don't forget this very performance tweak.

This is your problem codeweavers main benefits is not their work on wined3d.

https://source.winehq.org/git/wine.git/commit/164517fe575564daa44f74cc3bc4a6bbdd7d3f3d

You need to take a close look at the commit log.

If codeweavers were to disappear, the community would fork it and continue it. Like Wine-Staging where three gentlemen took over. Go check out the thread on how many people were upset that Wine-Staging devs left it. Codeweavers wouldn't be missed.

Really codeweavers is 60+ developers. 8+ from codeweavers while staging was being used to test CSMT were assisting them.

Staging developers left after the codeweaver developers pulled back support and they found out they were not enough man power. The codeweavers developers had been telling for 12 months the need to be mainlining more stuff because things would go wrong when code-weavers pulled back their resources.

Its going to be interesting to see if the 3 who are attempt to take over staging are able to. Or if they will burn out first. Yes they will need to drop the patch count of staging by a huge number. By over half. 3 people don't stand a chance of maintain 1100+ patches for a 2 week release cycle. It works out if working 12 hours days with no days off 1100 patches means 9 min per patch review time per release if only one person out of the 3 can work for release cycle. 3 people could give you half and hour a patch but running in the tests is going to consume up most of that.

The reality is staging only lasted as long as it did due to support from codeweavers. 12 months before staging maintainers quit codeweavers had step in and given support on condition that more stuff mainlines.

Nobody is saying to abandon OpenGL, but Gallium Nine has proven it works well. Vulkan has also proven to benefit emulators. It took four years for Wine to enable CSMT by default. There's a reason why Wine-Staging became so popular. Not that other people didn't fork it to implement CSMT.

Why did codeweavers support staging. Because the testing required clean tests without and without CSMT to locate if the issue in a game was coming from the new CSMT work or was coming form some other internal change.

Play On Linux does a far better job at this than plain Wine, and it's not like the devs are fans of that project.

I am really not a fan of Play On Linux because I do support and I have people saying hey this don't work and it turns out I have reports in the appdb that with plain wine it works and it turns out to trace to Play On Linux install scripts doing alterations that no longer work.

Doom 2016 needs Vulkan which I hear they're going to do something about it, but I need Wine-Staging for it. Same goes for Origin and Uplay games I have. Whatever it is that's needed, the Wine-Staging guys knew about it since they patched it. I think one of the things the new Wine-Staging guys are trying to do is see if the Wine devs can main the patches to reduce the huge list of patches they do.

Don't try to push staging. The reason why wine-vulkan https://github.com/roderickc/wine-vulkan was started as working space for the vulkan to be merged mainline instead of staging was because Doom 2016 breaks with the extra patches in Staging.

Origin and Uplay games have test results showing that minimal patches to make them work to mainline is the most effective yet no one has submitted those patches for mainline.

Reality is staging has issues. These come from.
1) Under resourced.
2) being too accepting of patches.

The too expecting of patches means poor quality patches are in staging and over time these start causing other programs to malfunction and ruining test results.

Staging has been a grab bag of patches of do you feel lucky punk.

[artivision]

This is your problem codeweavers main benefits is not their work on wined3d.

https://source.winehq.org/git/wine.git/commit/164517fe575564daa44f74cc3bc4a6bbdd7d3f3d

You need to take a close look at the commit log.



Really codeweavers is 60+ developers. 8+ from codeweavers while staging was being used to test CSMT were assisting them.

Staging developers left after the codeweaver developers pulled back support and they found out they were not enough man power. The codeweavers developers had been telling for 12 months the need to be mainlining more stuff because things would go wrong when code-weavers pulled back their resources.

Its going to be interesting to see if the 3 who are attempt to take over staging are able to. Or if they will burn out first. Yes they will need to drop the patch count of staging by a huge number. By over half. 3 people don't stand a chance of maintain 1100+ patches for a 2 week release cycle. It works out if working 12 hours days with no days off 1100 patches means 9 min per patch review time per release if only one person out of the 3 can work for release cycle. 3 people could give you half and hour a patch but running in the tests is going to consume up most of that.

The reality is staging only lasted as long as it did due to support from codeweavers. 12 months before staging maintainers quit codeweavers had step in and given support on condition that more stuff mainlines.




Why did codeweavers support staging. Because the testing required clean tests without and without CSMT to locate if the issue in a game was coming from the new CSMT work or was coming form some other internal change.



I am really not a fan of Play On Linux because I do support and I have people saying hey this don't work and it turns out I have reports in the appdb that with plain wine it works and it turns out to trace to Play On Linux install scripts doing alterations that no longer work.



Don't try to push staging. The reason why wine-vulkan https://github.com/roderickc/wine-vulkan was started as working space for the vulkan to be merged mainline instead of staging was because Doom 2016 breaks with the extra patches in Staging.

Origin and Uplay games have test results showing that minimal patches to make them work to mainline is the most effective yet no one has submitted those patches for mainline.

Reality is staging has issues. These come from.
1) Under resourced.
2) being too accepting of patches.

The too expecting of patches means poor quality patches are in staging and over time these start causing other programs to malfunction and ruining test results.

Staging has been a grab bag of patches of do you feel lucky punk.

Listen friend Oiaohm, your not telling the 100% truth here. First you say that development needs money and that comes from OSX, then you say that Wine has only Codeweavers and then that the commits say that Wine is not mainly about D3D. That you forgot to say is how many man hours D3D costs regardless of commits and how many all the rest. I mean that if we have a complete D3D9-11 state tracker for Gallium or Vulkan then what we actually need Codeweavers for? I think after that we can continue our own.

[oiaohm]

Listen friend Oiaohm, your not telling the 100% truth here. First you say that development needs money and that comes from OSX, then you say that Wine has only Codeweavers and then that the commits say that Wine is not mainly about D3D. That you forgot to say is how many man hours D3D costs regardless of commits and how many all the rest. I mean that if we have a complete D3D9-11 state tracker for Gallium or Vulkan then what we actually need Codeweavers for? I think after that we can continue our own.

Really you need to ask yourself why don't we have a complete d3d9 to-11 state tracker. The answer is money.

You need money to buy the resource required.

To have developers work full-time on something someone has to pay them.
To have Quality control infrastructure someone has to pay to buy and maintain that hardware.

Even if you replace wine direct x parts you still need the core support for windows applications this is something codeweavers currently does as well.

Remember items like the Linux over 90 percent of the coders a full time employed to-do it.

Codeweavers has not really found ideal ways of raising money. Targeting OS X and Android is just because they know money there to be got.

The reality is 90% of an high quality open source project are not built by people doing it for a hobby but for people employed to work on it.

[artivision]

Really you need to ask yourself why don't we have a complete d3d9 to-11 state tracker. The answer is money.

You need money to buy the resource required.

To have developers work full-time on something someone has to pay them.
To have Quality control infrastructure someone has to pay to buy and maintain that hardware.

Even if you replace wine direct x parts you still need the core support for windows applications this is something codeweavers currently does as well.

Remember items like the Linux over 90 percent of the coders a full time employed to-do it.

Codeweavers has not really found ideal ways of raising money. Targeting OS X and Android is just because they know money there to be got.

The reality is 90% of an high quality open source project are not built by people doing it for a hobby but for people employed to work on it.

And yet Gallium Nine and DXVK are one man's job for a few months. So why there is so much difference?

[oiaohm]

And yet Gallium Nine and DXVK are one man's job for a few months. So why there is so much difference?

Really it super simple. Those one man teams are getting to cheat by having a way smaller supported list of applications. This is also why these one man teams what switch to change between what codeweavers has done and their less than half done work.

Codeweavers developers have 15000+ applications they have to care about. They cannot do alterations like not supporting dx7, dx8, dx 9 hybrid applications because those are in that 15000+ list. They cannot do dx9 breaking dx10/11/12 applications because that is also in the 15000+ list. So doing something galluim nine is totally forbin as it breaks way too many applications. Same with doing something like DXVK.

Reality here like it or not Gallium Nine and DXVK combind does not even support 10% of what codeweavers developers have to care about;.

[artivision]

Really it super simple. Those one man teams are getting to cheat by having a way smaller supported list of applications. This is also why these one man teams what switch to change between what codeweavers has done and their less than half done work.

Codeweavers developers have 15000+ applications they have to care about. They cannot do alterations like not supporting dx7, dx8, dx 9 hybrid applications because those are in that 15000+ list. They cannot do dx9 breaking dx10/11/12 applications because that is also in the 15000+ list. So doing something galluim nine is totally forbin as it breaks way too many applications. Same with doing something like DXVK.

Reality here like it or not Gallium Nine and DXVK combind does not even support 10% of what codeweavers developers have to care about;.

Understandable but Gallium Nine plays all my D3D9 games on my laptop at 40fps medium settings wile WineD3D9 at 15fps. Do you admeasure 15fps to those 15000+ working applications?

[oiaohm]

Understandable but Gallium Nine plays all my D3D9 games on my laptop at 40fps medium settings wile WineD3D9 at 15fps. Do you admeasure 15fps to those 15000+ working applications?

What version wine. I guess not 3.2. 3.2 in most benches is doing at least 50% of native. Ok not ideal but a hell of improve over 10 percent. There are more performance fixes in the upcoming 3.3.

Reality here is the CSMT stuff had to land before a stack of other performance fixes could be done.

The reality is doing CSMT right was not easy particularly when it had to be done for all DX versions at the same time. One of the worst items for multi DX is MS Office with company made addon dlls. Items like that are not as heavy as games so even with wine old single thread dx were doing over 60fps. So there are applications that are perfect acceptable even with non CSMT DX9.

Reason why to wine developers wine 3.0 was see as big was CSMT this means a lot of developers time has been freed up to work on performance fixes and the require frame for performance fixes is now in place. Basically CSMT was a key stone part.

Do remember Gallium Nine is no use to where codeweavers sells product. Users buying cross-over from code-weavers are happy even with this lower performance as long as their business programs work. They will not be happy if those applications break.

The 15000+ pool of applications is a very hard restriction. Those are the ones people truly pay so they work at acceptable performance levels. As I say this does come down to money.

[Bestia]

Saying that CodeWeavers wouldn't be missed is so dumb. You don't realise that they are the biggest contributor to Wine.

It all starts with Alexandre Julliard who is best known as the project leader for Wine and also CodeWeavers employee.

https://en.wikipedia.org/wiki/Alexandre_Julliard

The CSMT was developed by Stefan Dösinger of CodeWeavers.

They develop the whole of Wine not just the D3D part of it. Look at this article on Phoronix it shows that CodeWeavers are the biggest contributor.

Commits from CodeWeavers

Michael in that article didn't show that commits authored with e-mail address @winehq.org are mostly from Alexandre Julliard or sometimes from Michael Stefaniuc which apparently is a Red Hat employee. I don't know if this are paid or made in their spare time.

[oiaohm]

Saying that CodeWeavers wouldn't be missed is so dumb. You don't realise that they are the biggest contributor to Wine.

It all starts with Alexandre Julliard who is best known as the project leader for Wine and also CodeWeavers employee.

https://en.wikipedia.org/wiki/Alexandre_Julliard

The CSMT was developed by Stefan Dösinger of CodeWeavers.

They develop the whole of Wine not just the D3D part of it. Look at this article on Phoronix it shows that CodeWeavers are the biggest contributor.

Commits from CodeWeavers

Michael in that article didn't show that commits authored with e-mail address @winehq.org are mostly from Alexandre Julliard or sometimes from Michael Stefaniuc which apparently is a Red Hat employee. I don't know if this are paid or made in their spare time.

It also miss the ones who are contracted by codeweavers to-do something as sub contracted personal don't get a codeweavers address. Direct full time employees have codeweavers addresses. So just looking at those with codeweavers addresses is tip of iceberg of how much work on wine traces back to the money codeweavers earns then reinvests in wine.

[oiaohm]

Saying that CodeWeavers wouldn't be missed is so dumb. You don't realise that they are the biggest contributor to Wine.
Commits from CodeWeavers

That search is also just the tip of iceberg. Programmers contracted by Codeweavers don't get a codeweavers address. So it codeweavers direct staff with those addresses. Thing is Codeweavers does subcontract particular developers its not like all developers who are skilled who codeweavers want can they have leave where they are working so then it comes the next best thing. So that search is just a tip of iceberg for how much work is coming from codeweavers reinvestment of the money they have earned from their products using wine.