Announcement

Collapse
No announcement yet.

Linux+Mesa Git Remains Problematic For Some Regressed R9 290 GPUs

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

  • #31
    Neither devs responded in a bug, so that is about that

    I also think llvm 3.9 is shit, GCN 1.1 users better to stay with release 12.0.3 builded against recent llvm 3.8... otherwise if they use git of all, then at least be ready to bisect something sometimes

    Comment


    • #32
      Originally posted by JPFSanders View Post
      In my case R9 290 (Saphire) the patches make no difference.

      The game I always test with is Borderlands the pre-sequel, there is no way I can get more than 27-28fps with Mesa, in fact no "AAA" game runs faster than that on this card with Mesa, the funny thing is that I have an old r600 that gives me the same performance and barelly stalls, whereas the R9 290 stalls all the time an effect appears the first time.

      Same computer with Windows 7 120fps with no drops.

      I do not need 120fps, however 27ish is kind of shit :-(

      The thing that I find more puzzling is why the resolution change does not affect the speed, whatever screen resolution I use always runs at the same fps. 800x600 or 1920x1080 makes no difference with Mesa.
      If atomsymbol hadn't notified me, I wouldn't have noticed this.

      If Borderlands The Pre-Sequel uses the same engine as Borderlands 2 the Linux version, there is no easy answer. The game performs much worse on Linux because of the design of OpenGL, or the way it was ported to Linux, or because UE3 doesn't use OpenGL efficiently. Trust me, I was debugging and profiling Borderlands 2 a lot.

      25 fps is what I would expect to be normal at the moment. The card doesn't matter much. You can have a high-end and it won't get better. The game is limited by the CPU. It's possible to improve performance by 20% at most, but that's a lot of work (using OpenGL multithreading).

      The stalls are caused by shader compilation. The problem is BL2 is compiling shaders while a user is playing. That's bad, it should do it when it's loading assets. The only way to alleviate that in most cases is to use a shader cache, but the stalls will always be there immediately after a driver update. They are not 100% fixable for all cases due to the game engine design.

      Comment


      • #33
        Exactly Pre-Sequel same as B2, then we have Serious Sam 3, The Talos Principle, Victor Vran (i would safely guess Tropico 5 too as that is same engine as VV but did not tried that)... so 3 different engines i know which do same thing. Those games actually all compile shaders during startup, but also during gameplay too... so without shader cache one can expect stalls

        Comment


        • #34
          I measured it: If BL2 compiled all its shaders on startup, the startup loading time would take more than 30 seconds on a good CPU. Imagine you would have to wait for 30 seconds at startup!!! The game developers made the stupid decision and decided that the game should do the compilation while the user is playing, so that you as a player can enjoy 30 seconds of stalls.

          Comment


          • #35
            There is not what to imagine i have example of it in reality ... if you test Serious Sam 3 on Windows, so if you compare startup of DX11 and OGL renderers.

            DX11 startup is utter slow *every time* as everything compile there, while OGL startup is slow only first time but once cached is very fast... so that is two kind of approach, also DX11 renderer does not cache it during gameplay, but OGL do it there too as on Linux.

            Comment


            • #36
              But let say, you have user who does not change driver at all, some Ubuntu LTS user which stay with one driver... then OGL render approach sounds much better because you will never wait on startup . Some Ubuntu user who does not change driver, it would be fast and beautuful startup once cached

              On the other hand all git every day user approach, sounds like - i have a lot of reson to not care

              Comment


              • #37
                And that is about, all git user should skip-jump often

                Really the best is to have a feature and let user decide... like blobs does it

                Comment


                • #38
                  Whatever fps range is, if you have same/similar amount of fps with lower settings that is CPU bound... or just watch a CPU in HUD

                  Comment


                  • #39
                    Originally posted by atomsymbol
                    Rhetoric question: Why so many posts?
                    Becuse post counter works i guess

                    Comment


                    • #40
                      Originally posted by atomsymbol

                      I am getting about 65 FPS @1080p at max settings with A10-7850K + R9-390 in the 1st level of Borderlands 2. [llvm-git, mesa-git, kernel-git]

                      I don't know how this relates to performance of Borderlands The Pre-Sequel.
                      At the beginning of Tundra Express, you have a wide open view over the location. That's my CPU-limited spot. I get 25 fps when looking over the view. It can drop to 18 fps when transitioning to and from aiming down the sights. There are 4000 draw calls per frame.

                      Comment

                      Working...
                      X