Announcement

Collapse
No announcement yet.

Wine-Staging Has Been Revived, Working Towards New Release

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by nuetzel View Post

    Yes, mannerov tell us more, please.
    So would I. How does one get Gallium Nine to work without needing a patched Wine? That seems impossible.

    Comment


    • #42
      Originally posted by duby229 View Post
      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.

      Comment


      • #43
        Originally posted by duby229 View Post
        ...
        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.
        Originally posted by nomadewolf View Post
        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`

        Comment


        • #44
          Originally posted by Naquatis View Post

          I am ok with that! I did not say I like to replace one with another and I am also not the guy who say do everything to remove Windows. I like diversity and before I try to use Wine for gaming I would use Steams inhome streaming. ;-)
          You use a virus hover, what on on earth you do with wine or here.

          Comment


          • #45
            Originally posted by iive View Post
            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.

            Comment


            • #46
              Originally posted by debianxfce View Post
              Tomb Raider 2013 runs faster with CSMT than Nine
              tr2013 is linux native game

              Comment


              • #47
                Originally posted by leipero View Post
                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/lib...(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.

                Comment


                • #48
                  Originally posted by iyxwsoekthsv View Post
                  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.

                  Comment


                  • #49
                    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.

                    Comment


                    • #50
                      Originally posted by pal666 View Post
                      tr2013 is linux native game
                      I did you post you the startup of my TR 20123 game. Many Linux games have virus hoover version and games are published to virus hoover first.

                      Comment

                      Working...
                      X