Wine-Staging Has Been Revived, Working Towards New Release

[iyxwsoekthsv]

The thing about CPU cycles is largely about context switching, when it happens the pipeline flushes and refills and all logical threads running on that core stall. It costs thousands of cycles all total. It's the worst type of CPU bottleneck you can possibly think up.

True, true. But Wine is not an emulator (it's even its very name). As such, wineserver and the application's process are not necessarily operating on the same core. Hopefully not, actually. That would be a pretty damned poor CPU scheduler.

Which is another possible clue as to why I am seeing such dramatic different results from other people in this thread -- Scheduler and/or governor. I'm on MuQSS and on Schedutil.

Anyhow, just tried something else -- 64-bit prefix, Gallium enabled Wine and enforcing DX9 (by means of WINEDLLOVERRIDE-ing out DX10, 11 and 12). Still not seeing any difference between either CSMT or Gallium. Will continue testing though. I'll be damned if I don't get the results you guys are getting. WTB MOAR PERFORMANCE. Can't replace this PC for a good while longer, if I can keep at least partially up with titles by means of software optimizations, I'll take it.

[iive]

...
EDIT: The problem with gallium nine was the original authors refused to budge on their ideology so they couldn't get the wine bits upstreamed. And upstream has real valid concerns about it. The fact that it couldn't get upstreamed and the authors have ideological issues prevented real flaws from getting fixed. But regardless of all that it is still the better option, even today.

The legend says the gallium nine authors prefered to die rather accpet the changes...

I would like to see a link that proves your claims.

From what I've seen, Nine developers (the main one is @mannerov) have done everything they have been asked to and is technically feasible.

The Wine developers simply refuse to deal with Nine at all. They do claim there are some unresolved issues, but they do not and cannot tell you what these issues are, if you ask them. I have asked them. They might dig up some old threads that talk about issues that have been resolved years ago or where core Mesa3D and Radeon developers explain to them why doing that is bad idea.
If these are really the issues, then they are against the very concept of Gallium Nine and that cannot be fixed.

I heard from Wine developers a lot of concerns that, Gallium Nine is too niche, that it doesn't work on MacOSX, or with newest NVidia hardware and proprietary drivers. At that point I decided that they care only about NVidia.


---

About the people who have issues with Nine.
1. If for some reason Nine cannot work, it fallbacks to wined3d. So start wine in terminal and look for the green "enabled" text.
2. I do not like the vsync handling of Nine, so I disable it. At the moment Xorg Server 1.19.6 has a bug (should be fixed in next release) that causes game hang when vsync/vblank is enabled.
3. Nine also supports its own CSMT. Since 'meltdown' fixes (on intel cpus) it might be good idea to check if disabling it gives you better speed (`export csmt_force=0`)
4. If you are trying to find performance issues, I do recommend you to play with `GALLIUM_HUD`

[iyxwsoekthsv]

3. Nine also supports its own CSMT. Since 'meltdown' fixes (on intel cpus) it might be good idea to check if disabling it gives you better speed (`export csmt_force=0`)

The Meltdown/Spectre context switch performance penalty only applies when context switching between userspace and kernelspace. As in, when I/O is involved. csmt_force=0 will do nothing there. Look up some benchmarks, the largest hits are, for example, for databases. Which do a lot of I/O. Gaming suffers hardly anything at all, as many benchmarks even here on Phoronix have already shown.

[pal666]

Tomb Raider 2013 runs faster with CSMT than Nine

tr2013 is linux native game

[oiaohm]

So no difference at all? I'm starting to suspect you don't even have nine enabled (it's not enough to just download some package), I mean I've assumed that you know that, and that's not resonable to assume, so please double check if nine is actually enabled for your games. Also, I see you keep calling it "gallium wine", gallium is what 3D driver part of Mesa is called, "nine" state tracker is part of gallium, so we get "gallium nine" name, but, "nine" relates to DirectX 9 (nine), it's useless if you run it in DirectX 8 or DirectX 10+, however, it doesn't harm anything, since it simply loads "regular" wine libraries.

Wine 3.2 has reworked a lot of Direct x memory management. This is to make Dx 10+ applications calling multi versions of DX behave. So a DX 10+ application may be calling Dx9 and expecting the buffers and the like to transfer automatically inside the GPU. So using a DX10+ application disabling galluim nine if it miss behaving can be a good thing.

https://msdn.microsoft.com/en-us/library/windows/desktop/bb205075(v=vs.85).aspx

dxgi was introduced with DX10. Also there are some applications coded for dx9 time frame that used dx7 and dx8 for things are are also dependant on video driver behaviours of sharing buffers. Some of these are games that were shipped with Nvidia graphics cards. Using stock wine this stuff behaves loading nine this stuff does not behave because you have application using dx7 dx8 and dx9 api and expect synced buffers.

The reality is multi direct X version applications exist and due to galluim 9 and others only implement 1 version at a time this results in hard lock-ups and other really horrible things as the different direct x implementations with different back cat fight.

Everything lyxwsoekthsv is describing leipero is what goes wrong when you are using multi direct x version using applications. Since the introduction of dxgi a lot more programmers have been doing it since there is now an official way to-do it.

What galluim nine gains in performance it loses in over all compatibility.

Galluim 9 closed to windows does it my foot. Windows you have 1 driver shared between all the different direct x versions on the system doing buffer sharing this is what wine has in wined3d this missing from Galluim 9,

There known extra overheads in wined3d due to having to translate to GLSL. GLSL causes problem. HLSL->GLSL is a compile step Then GLSL to internal galluim is another step. Then internal galluim to NIR is another step. So galluim 9 comes HLSL to Galluim to NIR that is short and users a lot less CPU. But there is a catch the support for vulkan is HLSL to spirv to NIR. Interesting right. Spirv is also coming to opengl 4.6 so the number to steps to have HLSL ready for gpu should end up the same be it wine native or be it gallium 9 when video card drivers are providing Spirv and wine has caught to using it.

So there is a big question where is the CPU overhead in wine if it is the shader system galluim nine advantage could be tempory.

[leipero]

If I can switch between different Mesa stacks on a dime (which actually involves purging them, to negate configuration misshaps) and such, do you honestly think I would miss something as simple as a Checkbox? I think I know what I'm doing when installing Wine. For each of these tests, I do purge the entire wine prefix and start afresh. Call it part of my experience debugging software and diagnosing illnesses. The process of elimination requires changing single variables.

And I call it Gallium Wine because it's quite a bit shorter than calling it "Gallium Enabled Wine" or "Wine with Gallium Nine Support". It is supposed to hint at the combination of a Gallium enabled Mesa stack + Gallium enabled Wine, which is even a lot longer than Gallium Wine. Call it shorthand, if you will. I'm 40, I don't have time to type out everything.

Regarding the other point you made, about the titles in question -- It is conceivable that for some reason or another, Gallium Nine simply isn't used by Gallium enabled Wine as it's defaulting to a different DX version. Which further proves my personal preference -- To largely just ignore Gallium Nine. As it's targetted at just 1 version of just 1 API. A version that is slowly being completely abandoned by the game developers and the engine developers.

Oh, and one more thing -- Gallium enabled Wine + Gallium enabled Mesa makes for a hell of an unstable combination. At least one of the games I mentioned (Rimworld) suddenly has trouble closing in a clean manner. Forcing me to drop into a TTY (ALT+CTRL+F1) to do a kill -9 -1, to force-log me off. Since X (the display server) is a mess as well and just ends up all confused.

TL;DR -- No, you're not going to catch me in a noob mistake. You are however going to catch me actually confirming my original hypothesis -- Gallium Nine isn't worth it. Not for me at least. 0 gain, whole lot of headache.

I'm sorry if I came up as an person who wants to catch you on any mistake, that wasn't my intention at all, I just wanted to rule out that posibility. So we ruled it out now and it's fine .

The reason why I've wanted to clear that up is because your experience with gallium nine goes in direct conflict with experience of 99% of the users who use AMD hardware, and you are using also, so there is where confusion on my side comes from.

It is true it targets one API, but don't forget that DirectX 9 API is "longest standing" one, it's like from 2002 (or something, from top of my head...) till this day, there is wast number of titles that are based on DX9 API, in fact, when you combine all other API's (Vulkan, OpenGL, DirectX10+ etc.) excluding DX7/8, you end up with number of DX9 titles being at least 4 times larger (and probably more), if you include DX 7/8, you might come up on "parity" with DX9 vs. all other API's (I still doubt tho...). So, from that standpoint, it is not "just one API", it is over half of available game titles. Just because something is old, doesn't mean it is bad, to this day, by far best titles are done in DX9 API without any plan (or reason) whatsoever to be ported to newer API's. Next thing is totally subjective, but to this date there's no DX 10+ title on the market that is worth playing, but that also comes with age..., pattern of repetition without any sort of inovation (that most of it acidently happened in DX9 era = best games), plus unnecessary complexity that introduce latency in game engines with newer API's and ruin any potential for something close to the "worth playing" title, but again, this is totaly subjective. API's such as Vulkan and DX12 might have potential to fix that problem introduced by DX10 (continued with DX11), but that's not only on API's, but game engines/developers and studios also, and that's where market quality vs quantity, cost-effectivnes etc. comes into play.

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.

I don't know about those games you play, it might be the case it is not worth for you.

[leipero]

oiaohm Ok, fair point, but doing checkbox would solve the problem in that case (assuming there's no bug).

The reality is multi direct X version applications exist and due to galluim 9 and others only implement 1 version at a time this results in hard lock-ups and other really horrible things as the different direct x implementations with different back cat fight.

Please read my comment above, why it makes sense to target only one API, ofc. I agree, gallium 10/11 would be a great thing, but it is too much work no one is willing/have time to do.

So there is a big question where is the CPU overhead in wine if it is the shader system galluim nine advantage could be tempory.

Well, here is the thing, that advantage goes on for years, and without gallium nine, AMD hardware users would be basically sc**wed up, and what you said is a good question, because without it, there would be tons of users switching to nvidia GPU's.

[oiaohm]

oiaohm Ok, fair point, but doing checkbox would solve the problem in that case (assuming there's no bug).

Currently the checkbox option does not work. You run into the nightmare of another change. When microsoft started mandating application signing some games want to keep unsigned dll loadering so they are now shipping with their own OS independent .dll loader. This is why wine has had to swap from total fake .dll entries in wine prefix to executable stubs that are valid PE that call out to wine to access the dll.so files. So the files the application can find has to be right a simple switch is ceasing to work.

Long term wine own dll override system will have to become more and more restrictive due to the change since applications have their own .dll loaders wine is not in control of dll loading so even the current override system in wine is on the way to dead.

So your logic that checkbox can fix it is totally false. Anyone do wine support like I am knows that this change is a major pain in ass. Its very much put applications in own WINEPREFIX with own settings as the only valid way forwards.

Also you run into the other problem that lot of game are starting cache stuff on install. So changing between wine internal and galluim nine either way after install can bring issues that you would not see otherwise. Yes you have cases of dx10/11 application using dx9 in install to pre compile shades.

This is very much like movie ghost busters of don't cross the streams. Yes you can get away with it in some cases but when you don't it explode badly and strangely.

Please read my comment above, why it makes sense to target only one API, ofc. I agree, gallium 10/11 would be a great thing, but it is too much work no one is willing/have time to do.

This above is why wine mainline will not have a bar of galluim nine. Direct x design by Microsoft have all versions sharing the same driver. Galluim 9 was not designed to expose a common driver interface. wined3d library in wine does the driver interface jobs. So it makes anyone attempt to implement gallium 10 or 11 using Galliuim basic reinvent the wheel and this is why the gallium dx 10 state tracker was declared dead.

With Dx12 wine project is having to do a new driver based on vulkan because opengl just cannot cut it. In fact opengl cannot cut it for a lot of earlier direct x as well. But the HLSL shader compiler to spirv for the new Vulkan part will be shared with the prior versions of direct x in wine.

If you are only going to target 1 API out of direct x it should be the driver API.

Well, here is the thing, that advantage goes on for years, and without gallium nine, AMD hardware users would be basically sc**wed up, and what you said is a good question, because without it, there would be tons of users switching to nvidia GPU's.

That something performs better does not mean its a valid long term path to put resources into.

Also there are problems I was forgetting the internals.

HLSL->TGSI->NIR is the route galluim 9 is following.

wined3d in current drivers.
is HLSL->GLSL->GLSL iR->TGSI->NIR
Future opengl drivers. HLSL->GLSL->SPIRV->NIR

Of course with the direct interface to SPIRV from vulkan and opengl 4.6 it will get really short.

But there is a problem TGSI that galluim nine also depends on is heading to deprecated. So the future is not looking bright for galluim nine. Does galluim nine have the resouces to migrate their HLSL complier to SPIRV as well.

[leipero]

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.

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.

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).

Ok, we can talk about technical stuff (that I am not compentent to talk about anyway) and speculate if X will have resources to migrate Y to the bla bla bla, but what is the point of that? Nine state tracker is part of Mesa, it is accepted, and it will probably be maintained, where it was never accepted was wine-staging, for whatever reason. But same question you posed about gallium nine can be posed about wine itself, so I don't see the point in it.

Is there any other, potentially better way of implementation for what is now known as gallium nine? Probably, 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.

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).

[Naquatis]

You use a virus hover, what on on earth you do with wine or here.

You know that the creator of this Virus is a member of the Linux Foundation? If you read comments of Linus Torvalds carefully you will find that Microsoft doing more for the Linux kernel than Ubuntu ever had. Why I am here? First: I like Phoronix because it keeps track of stuff I am interested in. Second: I like to patch and compile Wine because it proves so many concepts. Third: I am sure there was a time where I did not spend extra money for my gaming rigs and working with Linux was more important than playing games.