Wine 3.3 Brings First Vulkan Bits, D3D CSMT By Default

[oiaohm]

Vulkan can be used as an intermediate system exactly like Gallium, so i speak about native state trackers here and not compatibility layers and not 1:1 job. Meaning that the development time to make a native implementation will be equal to the development time needed to raise just 1% the speed of emulation at the same compatibility level. Wile you use simple words for the current WineD3D like "implementation" you actually doing a lot more complex job to figure out how you can dot each thing to the new api. The time you spending is not upon "implementing" but to figure out how to, after that you re-correct everything many times. I don't blame you that you don't have the sense of the difference in development times but your management is faulty. The first priority for a company is to cut the development times.

Lets keep on forgetting the basic problem. Under windows you have one part shared between all the graphic systems. Vulkan provides ways to export Vulkan buffers to opengl. Problem under windows you have opengl buffers to direct x and the reverse notice problem Vulkan only provides 1 direction when you need both directions. Gallium nine never has address the sharing problems. Nothing you said about Vulkan also deals with the sharing problem. Vulkan does not at this stage provide the sharing you require to support all applications.

So to implement wined3d with same functionally as current on Vulkan would also require doing opengl on Vulkan and adding in the windows extensions. Projects doing opengl on Vulkan have not got too far. Lets talk about increasing the current work load by many times. So working on fixing up the performance of direct x on opengl is a lot less costly than attempting to current wined3d functionality on Vulkan.

Like it or not at this stage to support some applications the opengl version has to remain maybe in future an extension to Vulkan will appear allowing opengl buffers to be used from Vulkan.

Now this is not that wined3d long term plan will be pure opengl. Like when opengl 4.6 hits using the same shader complier for DX10, 11 and 12. Yes 12 be Vulkan and 10 and 11 be opengl at first. Remember the opengl sharing only works up to DX11. So the lines in sand with wined3d stopping at 11 then doing 12 in Vulkan makes sense for the functionality requirements. The line in sand could move if feature appears.

[artivision]

Lets keep on forgetting the basic problem. Under windows you have one part shared between all the graphic systems. Vulkan provides ways to export Vulkan buffers to opengl. Problem under windows you have opengl buffers to direct x and the reverse notice problem Vulkan only provides 1 direction when you need both directions. Gallium nine never has address the sharing problems. Nothing you said about Vulkan also deals with the sharing problem. Vulkan does not at this stage provide the sharing you require to support all applications.

So to implement wined3d with same functionally as current on Vulkan would also require doing opengl on Vulkan and adding in the windows extensions. Projects doing opengl on Vulkan have not got too far. Lets talk about increasing the current work load by many times. So working on fixing up the performance of direct x on opengl is a lot less costly than attempting to current wined3d functionality on Vulkan.

Like it or not at this stage to support some applications the opengl version has to remain maybe in future an extension to Vulkan will appear allowing opengl buffers to be used from Vulkan.

Now this is not that wined3d long term plan will be pure opengl. Like when opengl 4.6 hits using the same shader complier for DX10, 11 and 12. Yes 12 be Vulkan and 10 and 11 be opengl at first. Remember the opengl sharing only works up to DX11. So the lines in sand with wined3d stopping at 11 then doing 12 in Vulkan makes sense for the functionality requirements. The line in sand could move if feature appears.

Except that Mac doesn't support OpenGL4.3+, so there will be no "chance in the future", it's already a loss.

[oiaohm]

Except that Mac doesn't support OpenGL4.3+, so there will be no "chance in the future", it's already a loss.

Funny third party moltengl does support opengl 4.3+ on metal. They currently support up to opengl 4.5 on Mac. So nothing like not being up on current facts.

The other issue is with the recent changes on opengl 3.3 wine is doing roughly 50% of native. For gamers not a good value. For those wanting old business programs to work fast enough. Remember the majority of those paying codeweavers are interested in business applications not games. Business applications can use horrible multi versions DX in 1 application and also thrown opengl for good measure.

Really it simple to say change wined3d to vulkan or other options totally forgetting number of application that breaks. The fact Mac is not doing new versions of opengl and there are opengl programs for windows needing 4.5 opengl or better is in fact a problem in it own right.

Remember wine is still supporting applications from windows 3.11 for businesses. So you are talking many decades before wine can drop its opengl requirement to provide to applications.

So migrate wined3d to vulkan would also require doing opengl on vulkan to keep current application compatibility with out vulkan getting a new version with a new feature providing what wine needs . So you are talking a nightmare huge project.

https://github.com/g-truc/glo << This here that could have helped to dig wine out of current hole is stalled.

This is what I mean lockstep. To break the lock to allow wined3d to move to vulkan requires opengl on vulkan yet those working to make games faster are not working on that.

[artivision]

Funny third party moltengl does support opengl 4.3+ on metal. They currently support up to opengl 4.5 on Mac. So nothing like not being up on current facts.

The other issue is with the recent changes on opengl 3.3 wine is doing roughly 50% of native. For gamers not a good value. For those wanting old business programs to work fast enough. Remember the majority of those paying codeweavers are interested in business applications not games. Business applications can use horrible multi versions DX in 1 application and also thrown opengl for good measure.

Really it simple to say change wined3d to vulkan or other options totally forgetting number of application that breaks. The fact Mac is not doing new versions of opengl and there are opengl programs for windows needing 4.5 opengl or better is in fact a problem in it own right.

Remember wine is still supporting applications from windows 3.11 for businesses. So you are talking many decades before wine can drop its opengl requirement to provide to applications.

So migrate wined3d to vulkan would also require doing opengl on vulkan to keep current application compatibility with out vulkan getting a new version with a new feature providing what wine needs . So you are talking a nightmare huge project.

https://github.com/g-truc/glo << This here that could have helped to dig wine out of current hole is stalled.

This is what I mean lockstep. To break the lock to allow wined3d to move to vulkan requires opengl on vulkan yet those working to make games faster are not working on that.

Sorry friend but i cannot understand why OpenGL should also move upon Vulkan... I also don't understand why OpenGL should exist at all, but that is another matter.

[boltronics]

The best thing about Wine 3.3 is that wine-staging also tagged a 3.3 release to patch cleanly against it. It's quite wonderful to see that wine-staging has returned (thanks to new maintainers).

Having said that, in its absence I've figured out the patches I've been missing from staging to make a bunch of things work. For example, I now know that if I need to get Uplay functional, I can do that with vanilla wine if I apply the secur32-Zero_Buffer_Length and crypt32-Certificate_Check patches. If I want to get rid of the annoying warnings about servers being unavailable, I'll also be needing to apply the bcrypt-Improvements and crypt32-ECDSA_Cert_Chains patches. Honestly, I'd never have taken the time to figure this stuff out if wine-staging had always been there. The upside going forward is that now I don't need to rely on it as much, which is great when it comes to updating bug reports.

One thing I found strange with wine-staging 3.3 is that there is still the CSMT checkbox under the staging tab. One other thing was the release announcement summary mentioning 3.3 having CSMT on by default, but this was already listed in Henri Verbeet's changlog for 3.2. I'm guessing they forgot and then later realised it was actually too significant to leave out "announced" it for 3.3.

[oiaohm]

Sorry friend but i cannot understand why OpenGL should also move upon Vulkan... I also don't understand why OpenGL should exist at all, but that is another matter.

1) wine mainline developers cannot take the point view of not having opengl. Since Windows applications exist that use opengl wine has to have opengl.

2) since applications exist that have a hybrid of dx and opengl sharing buffers from opengl to dx7-11 and reverse Wine mainline has to support this.

Current Vulkan Opengl link is Vulkan buffers to Opengl not taking a Opengl FBO and exposing it in Vulkan. Yes there are ways of exposing Opengl FBO in direct x.

Issue here is Microsoft made opengl32.dll in that they include a lot of WGL extensions so Opengl to support Windows applications is also linked to Direct X.

Windows graphic stack in one mother of a interconnected web.

[oiaohm]

One thing I found strange with wine-staging 3.3 is that there is still the CSMT checkbox under the staging tab. One other thing was the release announcement summary mentioning 3.3 having CSMT on by default, but this was already listed in Henri Verbeet's changlog for 3.2. I'm guessing they forgot and then later realised it was actually too significant to leave out "announced" it for 3.3.

Kind of on purpose forgot. What happen with CSMT is that the announcement of it being default was dropped from 3.2 announcement because patch was missing that should have been merged before CSMT was turned on by default.
wined3d: Introduce separate read and write resource map flags. With out this you have incorrect locking between CSMT threads so you are not running as multi-thread as you should be. When a feature is turned on in wine yet its announcement is delay a version this is normally sign of goof that a patch got missed out the merge that should have been included but this missing patch did not break the automated testing system and no one had noticed until after release had been finalised. Yes once the version number is set on git and cvs prior of the release with wine there is no going back with wine project rules. There have been about 3 release of wine that were a day after the prior one and that was also missed patches but those broke automated testing and was in the early days of automated testing being automated..

[Danny3]

Did you file a bug report and bisect the regression? In my experience with Wine, the developers are responsive to users that take the time to identify the bad commits. Their bug tracker is just overloaded with low quality reports and too few volunteers to triage.

If you care about GTA V take the time to make good bug reports, and your work will likely be rewarded. Open source software only works when users do their part.

Sorry if I was'nt explicit enough.
I was just looking a the test results done by others, I haven't tested it myself since I have Linux at the moment installed only on my laptop which is not powerful enough to run such a game even in native form on Windows.
I tried WINE years ago, but I couldn't run any game, I didn't know how to configure it and I gave up, probably I didn't have too much time too.
So I'm just waiting looking at the reports right now.

[Danny3]

use playonlinux and choose the better option for you

Thanks for the recommendation!

[boltronics]

Kind of on purpose forgot. What happen with CSMT is that the announcement of it being default was dropped from 3.2 announcement because patch was missing that should have been merged before CSMT was turned on by default.
wined3d: Introduce separate read and write resource map flags. With out this you have incorrect locking between CSMT threads so you are not running as multi-thread as you should be. When a feature is turned on in wine yet its announcement is delay a version this is normally sign of goof that a patch got missed out the merge that should have been included but this missing patch did not break the automated testing system and no one had noticed until after release had been finalised. Yes once the version number is set on git and cvs prior of the release with wine there is no going back with wine project rules. There have been about 3 release of wine that were a day after the prior one and that was also missed patches but those broke automated testing and was in the early days of automated testing being automated..

That makes sense. Thanks for the explanation.