Wine-Staging Has Been Revived, Working Towards New Release

[mannerov]

So would I. How does one get Gallium Nine to work without needing a patched Wine? That seems impossible.

We made the gallium nine d3d9.dll need no change to wine interfaces (there used to be a few needs to know what X11 window lies behind the app Windows window). Then you just need to have a tool to configure the dll override. It's ninewinecfg.

Then to install on top of any wine installation, one just need to copy at the right locations precompiled d3d9-nine.dll and ninewinecfg.
We have Fedora and OpenSuze packages: https://github.com/iXit/wine/wiki
If someone is willing to make packages for other distros, he is welcome.

[RussianNeuroMancer]

oiaohm
I wonder if currently developed Vulkan-based Direct3D implementations avoided Nine mistakes? For example as I see Direct3D 9 and Direct3D 11 implementations is developed by different people as different projects, but as I understand from your posts seems like everything from Direct3D 7 to Direct3D 11 should be developed under one umbrella to behave correctly with wide range of apps?

[iyxwsoekthsv]

So, my point is, that you should keep in mind that when you speak about DirectX9 you do not speak about "just one API", but API that covers more than half of the titles on the market, and it's used for decade+, so it makes sense to target such API = therefore gallium nine.

It is however just 1 API. An API that really is quickly being abandoned. Trust me on that, I've been a gamer for most of my life (literally), I think I do know what the industry is like.

I am not saying or suggesting that Gallium Nine should be abandoned or that DX9 support should be removed from Wine or anything.

Just saying that moving ahead, into the future, Gallium Nine will slowly end up simply losing its use. Particularly with DX12 and Vulkan on the field as we speak, there is really very little reason for any game developer to launch new titles with DX9 as a backend. Which is one of the many reasons that the newer titles usually perform relatively poorly in Wine. Since its DX12 support is not up-to-par with its DX9 support yet.

Anyhow, I tried everything now.

Enforcing DX9 by means of DLLOVERRIDING, force enabling and disabling Wine's CSMT, force enabling and disabling Gallium Nine's internal CSMT, 32-bit and 64-bit prefixes and I am still seeing not a single shred of difference between the two other than Gallium Nine + Oibaf being slightly less stable. And yes, I have actually confirmed that the titles I am trying this with do actually use Gallium Nine (launching from terminal, watching for the green "Using native Direct3D 9" (or w/e) message coming from Gallium Enabled Wine. The sole difference I can spot in that benchmark demo I run (fr025) is that in Wine Devel, there is a small hickup during a small scene, which is not there in Gallium enabled Wine.

I think the problem really is that you guys are all playing titles which are far more GPU bottlenecked. Which rely far more heavily on good GPU performance. Think I'm going to try Diablo 3 next. Always did perform pretty poorly on this APU.

[oiaohm]

oiaohm Yes, I've experienced some problems with checkbox at the current stage, that wasn't the case in the past, and it is mainly result of the different implementation for wine 3.x.

https://wiki.winehq.org/Wine-Staging_DllRedirects

The current implementation of DLL redirects does not store any information about loaded dlls which were redirected. This causes trouble if an application tries to manually load the target of a redirection while the same library is already loaded under a different name. Wine does not notice that the library was already loaded and tries to load it a second time. The behaviour of builtin/native DLLs is slightly different, but in both cases an application might be confused.

This was noted as of Staging 1.7.33 so the checkbox has never in fact 100 percent worked right. So that patch to remain need a full recoded with the complexities of the applications containing their own loaders. It was staging that introduced the real PE files first and this increase the failure rate as applications with loaders that would fail on the fake wine dlls would request to system and work in some cases. So its case that fixing applications that were complete crashing resulted in other applications going bad.

The past its always been broken its just been the level of broken that has changed a little. Just because you were using applications not running into the broken does not mean others were not.

But application per WINEPREFIX is far from elegant solution, I mean wine itself have tons of issues, furthermore it is very unlikely that there will be a lot of titles in DirectX9 in future, so what DX10/11 does is irrelevant to the gallium nine itself, because when dll override is working properly, checkbox would get the prefix in the state it was before it is checked, and performance benefit is big enough to bother with clicking one checkbox, and will likely stay that way in the future, simply because lot's of DX9 games are single threaded, and any added translation layer, no matter how good it is (and it is far away from good, at least on AMD hardware...) will have impact in the future as well, and, it is also unlikely that IPC would go much further in next decade, soe ven very strong CPU's wouldn't be able to deal with it in specific situations, even if wine developers manage to do all that stuff on separate threads, there is latency problem that will without any doubt impact performance.

Unfortunately you are clueless. There will not be many new pure dx 9 applications this is true. But unfortunately due to what Microsoft has done to the DX API/ABI you will have a DX 12 game calling to DX 9 for some features for DX10 for others and DX11 for others. Why Microsoft did not forwards port all the features from dx9 to dx 10 then did not forwards port all the features form dx10 to dx11 then again did not forwards port all the features for dx11 to dx 12 instead provide a interface dxgi to allow you to mix multi versions of dx with each other.

So there will be new titles using DX9 but they will not be DX9 pure they will be multi DX version applications that galluim nine does not handle. So really when you turn galluim nine on you should turn DX10+ off unless you want strange things to happen from time to time.

After all, if nine doesn't work, you can always roll back to wine d3d (again, assuming there's no bugs, and there wasn't before, so it is reasonable that once implementation for 3.x+ is done properly, that's it).

Yes as long as you are aware that you need to reinstall the applications when doing this because applications set settings based on what they detected in the past include internal caches.

But same question you posed about gallium nine can be posed about wine itself, so I don't see the point in it.

wined3d has a few things going for it. One it can in fact be used under windows by Virtual machine makers.

https://fdossena.com/?p=wined3d/index.frag

Some people do put wined3d on windows to run dx 1-7 games. Wine to support OS X and Android and other platforms would have to maintain the opengl back-end anyhow. Remember wine has limit resources. So wanting dx1 to dx11 support as one unified part helps with maintenance. The maintenance problem is another issue. Gallium nine method has not really be cross platform. This is why Gallium head to head with vulkan implementations is going to be interesting.

I don't know, but that is not the point, there is probably better way of dealing with windows libraries to what wine is doing now, and if developement continues, one day wine will get there, even if that means re-writing part by part in modular approach.

Please do not presume the reality with anti-cheat and other things appearing in games the ability to override libraries dependably is coming more and more restricted on methods you can use. How wine has to-do things is limited by how applications work.

The main point here is that if you do not use nvidia hardware, you are basically sc**wed with current wined3d implementations, why that is the case, I have no clue, but it simply is. It's getting better to be honest, especially since 2.x versions, but it's nowhere near how it is on nvidia cards with proprietary drivers. That's where all this confusion about iyxwsoekthsv post comes from, but as I said in the recent posts, it is possible that it works better for his use case, but that doesn't change the fact that it doesn't for majority of other users. That was the point, how things will go into future, I will leave for much smarter people than myself to solve (or not solve).

Lot of wine being better with Nvidia is not wine in fact being better with nvidia just wine using all exposed standard opengl functions and Nvidia having more. If you had been watching mesamatrix https://mesamatrix.net/ you would have notice the open source opengl drivers have improved in features and wined3d behaviour with non nvidia cards have improved in alignment. You can seen this when you make a old version of wine run on new mesa drivers compared to old version running on old mesa drivers its chalk and cheese.

Wine on current mesa is not as far behind as it use be.

[oiaohm]

oiaohm
I wonder if currently developed Vulkan-based Direct3D implementations avoided Nine mistakes? For example as I see Direct3D 9 and Direct3D 11 implementations is developed by different people as different projects, but as I understand from your posts seems like everything from Direct3D 7 to Direct3D 11 should be developed under one umbrella to behave correctly with wide range of apps?

There are different lines in sand you can choose.

Like if you were doing XP and before only you will need DX7 to DX9 and a block. If you were doing Windows 10 and newer you could get away with DX9+ only. If you are in the middle at Windows 8 you have from dX 7 to dX 11.

Please note applications were designed and tested expecting mixes like this. Picking a single version of DX ignores the existing of mulit DX version applications.

https://www.gamedev.net/forums/topic/309518-could-dx9-and-dx7-be-mixed-together/

This here is back from 2005 yes there are game developer who worked out how to exploit the dx 7 buffers to have them transfer into dx9. Some of the so called dx9 games that will not work with galluim nine turn out to be dx 7/9 hybrids This is some of the problem with people around galluim they look at the applications they have working they are not taking as good as look at the applications that are breaking. There is a horrible long term story from Dx7 forwards of hi-bred applications..

Dx1 to dx7 is pure forwards compatible API/ABI.

Yes the reason why wine developers were asking for more DX support is the wine developers are well and truly aware of the existing of DX multi version applications.

[mannerov]

It's not really a gallium nine mistake to not implement other dx versions. It is just a design choice: wined3d is here to stay and can be used in cases this is required of the game. A huge amount of dx9 games don't.

[leipero]

iyxwsoekthsv I see your point, but we can't ignore the fact that those DX9 games are not going anywhere, long term solution is for wine translation layer through wined3d, but we are talking for times decade or more from now, I understand that. But I'm not so sure that any API in the future would share DirectX 9 success, and that will probably lead towards fast paced introduction of new API's with exclusivity/exclusion of systems, for example DX9 could run on Win98, but since Vista (DX9 = no XP support), Win 7 (DX11 = no Vista support afaik), Win 10 (DX12, no Win 7 support afaik), I didn't mention Windows 8, since 10 is "improved" 8.

Good, I don't know, maybe for your use case it is better to use wine d3d, however I do not agree that we are running games that are GPU limited, in fact the oposite is true, the most difference I see in game that under Windows itself doesn't use more than 60% of GPU, nine should help in CPU limited scenarios, in GPU limited scenarios it should make no difference (apart from those small stutters you mentioned).

Just to add, 3DMark 03/06 both have similar scores when compared CSMT vs. nine, those are GPU limited benchmarks, literally none of the real games act like those benchmarks.

oiaohm Ok, it might have been broken, but I really never have experienced any problems whatsoever running multiple applications on single prefix with tons of redirects, so call me lucky i guess. I did experience problems with redirection recently since wine 3.x and implementation of nine by separate ninewinecfg.

Unfortunately you are clueless. There will not be many new pure dx 9 applications this is true. But unfortunately due to what Microsoft has done to the DX API/ABI you will have a DX 12 game calling to DX 9....

Ok, so DX9 is used as "shared library" by DX1x, it is still irrelevant if redirecting is working properly.

Yes as long as you are aware that you need to reinstall the applications when doing this because applications set settings based on what they detected in the past include internal caches.

To be honest, I yet have to see application that need that, never in my computer usage I saw such thing, most applications can be portable even without registry settings, some very few poorly written applications require registries to be exported/imported (mostly for DRM reasons), but I can't name one application that does that, not saying there isn't one tho.

I cannot speak about maintenance of wine codebase, I don't know that.

Please do not presume the reality with anti-cheat and other things appearing in games the ability to override libraries dependably is coming more and more restricted on methods you can use. How wine has to-do things is limited by how applications work.

Well, you will always have applications that will not even work, forget about anti-cheat, just take an example of starforce protection, and even some versions of securom, in fact, in some games starforce is somehow used as anti-cheat protection making those games incompatible with wine while they would function without problem otherwise.

Yes, with newer versions of Mesa (12, maybe 13) it got quite a bit better, now there are small increases, not as far behind as it was, but still...

[iyxwsoekthsv]

iyxwsoekthsv I see your point, but we can't ignore the fact that those DX9 games are not going anywhere, long term solution is for wine translation layer through wined3d, but we are talking for times decade or more from now, I understand that. But I'm not so sure that any API in the future would share DirectX 9 success, and that will probably lead towards fast paced introduction of new API's with exclusivity/exclusion of systems, for example DX9 could run on Win98, but since Vista (DX9 = no XP support), Win 7 (DX11 = no Vista support afaik), Win 10 (DX12, no Win 7 support afaik), I didn't mention Windows 8, since 10 is "improved" 8.

Good, I don't know, maybe for your use case it is better to use wine d3d, however I do not agree that we are running games that are GPU limited, in fact the oposite is true, the most difference I see in game that under Windows itself doesn't use more than 60% of GPU, nine should help in CPU limited scenarios, in GPU limited scenarios it should make no difference (apart from those small stutters you mentioned)

Long term solution is going to end up being WINDOWSBox (as opposed to DOSBox). Really, that is where we'll end up. Simply because in a matter of mere years, the hardware will be so powerful that we can easily get away with pure software emulation for older, deprecated DirectX versions. Making it relatively easy to implement.

Secondly, we'd all better pray that DX9 will not end up being the last major DX version with that level of succes. It would imply a very poor level of innovation, on part of the entire industry. Besides, DX12 as well as Vulkan are such a leap forward over DX9 that it is basically a given that they will surpass DX9 in its success. If not DX12, then DX13. The hardware is there, DX9 cannot make good use of that hardware, it was designed for a different era of hardware. DX12 is more contemporary. So is Vulkan. They will surpass DX9. They should. If they don't, I am going to cringe in terror at the entire gaming industry. Or heck, the entire IT industry. And, trust me, I've put up with a lot from it. Been a gamer for considerably more than 30 years, I've had to accept a lot of bull from the industry but I'll be damned if DX9 will end up being the shining beacon of hope. We abandoned DOS long ago, we damned well better abandon DX9.

By now I am actually 100% confident that you guys are in fact running titles that are more GPU hungry than the titles I am running. It is the sole explanation for why the faster backend (Gallium Nine) is doing nothing for me and doing tonnes of work for you.

Tried all combinations and all possible tunables and knobs. Heck, even went so far as to blame the CPU scheduler and changing some knobs there. Still not a single shred of improvement with Gallium Nine, only regressions (stability). And yes, I was making sure Gallium Nine was actually being used. I'm happy for you that Gallium Nine is doing such great work for your configuration and use case but, I am done with it.

[oiaohm]

oiaohm Ok, it might have been broken, but I really never have experienced any problems whatsoever running multiple applications on single prefix with tons of redirects, so call me lucky i guess. I did experience problems with redirection recently since wine 3.x and implementation of nine by separate ninewinecfg.

The reality here is galluim nine people are are still learning the number of libraries that need to be overridden. DllRedirects means you got away with redirecting far to few libraries. So now that they don't have DllRedirects they have a learning curve for old system that is not perfect but so far we have not had applications we cannot make work.

The reality the Dllredirects system has been broken and you were lucky. At some point the hack has to go away. The old dlloverrides system means you have to provide the entry dlls to dx9 as well. So items like d3d9_XX.dll have to be overridden and replaced there is only 20 of those for dx9. This is where Microsoft did their quirk adjustment for dx9 version changes.

Why everything is going south is wine own libraries are using the driver replacement being wined3d where it should. Yes doing it correct does help with performance because you no longer relaying through extra dll files. So a lot of the old hack short cuts are now exploding. So people wanted wine main to address is performance issues and some of the price is hacks that galluim nine use to be able to depend on are disappearing from mainline and now they will have even more work to-do.

Ok, so DX9 is used as "shared library" by DX1x, it is still irrelevant if redirecting is working properly.

In fact no its not that simple.

Feature level that was added in DX 10 and newer enables you using DX 10 and use new api to init stuff with feature mode set for Dx 9 resulting in the shared driver DX setting stuff up then run DX9 code and expect everything initialised but nothing that was initialised by the DX 10 and newer code is initialised from the Dx9 code just the Dx9 code get purely presumes they exist. This is how you watch galluim nine explode. Wine DX 10 or newer is told it init something. Galluim nine gets told to use it and magically galluim nine has no clue about it.

DX 9,10,11 and 12 are cross linked at the driver. A newer version of DX can init stuff for an older version of DX at the driver. Same stunt is done in some games that on box claims to be dx9 to use 7 and 8 but this was not official method. What I described is with DX10 and newer is officially supported by Microsoft.

Well, you will always have applications that will not even work, forget about anti-cheat, just take an example of starforce protection, and even some versions of securom, in fact, in some games starforce is somehow used as anti-cheat protection making those games incompatible with wine while they would function without problem otherwise.

No one has had success against starforce yet. But it does not look impossible. But there are more securom titles working in current wine than use to. There are a lot of different copy protections that have been got to work. Some like punkbuster are pure impossible because that thing is checksuming the loaded dlls and other parts and comparing the checksum to valid known Microsoft ones.

Core wine project objective is to get as much as possible to run without users having to touch settings.

[duby229]

oiaohm
The main point here is that if you do not use nvidia hardware, you are basically sc**wed with current wined3d implementations, why that is the case, I have no clue, but it simply is. It's getting better to be honest, especially since 2.x versions, but it's nowhere near how it is on nvidia cards with proprietary drivers. That's where all this confusion about iyxwsoekthsv post comes from, but as I said in the recent posts, it is possible that it works better for his use case, but that doesn't change the fact that it doesn't for majority of other users. That was the point, how things will go into future, I will leave for much smarter people than myself to solve (or not solve).

So, yeah, that's pretty much spot on from a wine users perspective. For -years- wine devs really developed on nvidia exclusively. It -relies- on incorrect behavior exhibited by those drivers! Behavior that drivers alone exhibit on linux.. I think it's a bit better nowadays though, but it's not that they changed their minds, it's more that people have other hardware and contributed bug reports. I think it's pretty shameful honestly.