Announcement

Collapse
No announcement yet.

RX 480 users: Can you play CSGO, SOMA, ... without lockups?

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

  • RX 480 users: Can you play CSGO, SOMA, ... without lockups?

    The model I have is: XFX Radeon RX 480 XXX OC, 8GB GDDR5.

    I am currently using the stable stack:
    Linux 4.8, mesa 13.0.1, llvm 3.9. Yet I still have severe problems with GPU hangs and lockups.

    In CSGO it can take a while to trigger. Maybe after 3 seconds, maybe after 6 games.
    In SOMA it happens usually while the intro video plays.

    It's one of thwo things. Either the screen goes beige or black, the sound loops and I am looking at a hard lockup with nothing in the logs. Or everything hangs for a moment and then it tries to reset the GPU (I have amdgpu.lockup_timeout=10000 in my boot options), but fails and eventually locks up too.

    The thing is that more demanding things like the unigine benchmarks or the X-Plane 11 Demo run fine.

    Here is my survey question: Is the "RX 480 XXX OC" a bad series? Do I have a specifically bad GPU? Or is this a widespread issue?

  • #2
    Update: https://bugs.freedesktop.org/show_bug.cgi?id=98905

    Comment


    • #3
      Thanks for the heads-up. I have the same card and just bought CS:GO over the weekend. However, I also ordered a few Steam controllers which for some reason have not even shipped yet. Once I get them I'll test it out, at least on that one game. I don't own SOMA.

      In the meantime, you can try going to the game in Steam, right click and select Properties then Select Launch Options. In the text box put the following (minus quotes) "-force-gfx-direct". I worked with the game devs for 7 Days To Die recently and was experiencing hard locks like yours after a min or so of gameplay. This trick solved it for me and the issue has not resurfaced since. YMMV.

      Comment


      • #4
        And I keep telling you, 4.10-wip has noticeably worse performance. For example csgo with gallium nine. Runs much better with 4.8.

        Comment


        • #5
          Yes, the amdgpu kernel driver affects fps, when it fucks up memory management or power management for example.
          Here is an example of native csgo:

          4.8: https://i.imgur.com/91T3iCJ.png
          4.10-wip: https://i.imgur.com/BQZrFpW.png
          Look at the CPU usage. There is a large difference and on 4.10-wip it is arguably worse, probably because the overall cpu usage is down a lot. My guess is that the one thread that is constantly at 100% CPU usage is slowing down everything else. I would bisect, but 4.10-wip was completely broken on my RX 480 for quite some time so I'm not sure that would work well.

          I play the windows version because I get about twice the performance out of it. Here is an image with gallium nine on 4.8: https://i.imgur.com/t6cvMgR.png
          Notice how the CPU load is just slightly higher, but the GPU load is about twice has high? That's why it also has twice the performance. Also notice how the buffer wait time is more than 10 times lower on gallium nine.

          Ignore the last two graphs, I am just experimenting a bit. It counts frames that come more than 1/fps *1000 milliseconds later than the last frame. The first problem is that it counts the frame time when gallium hud update is called, which might not be the time the frame is actually presented. I believe a relatively accurate time is available here in the glx loader, where LIBGL_SHOW_FPS does its work: https://cgit.freedesktop.org/mesa/me..._helper.c#n240 but I'm not sure how to get the value over to the hud without linking glx and hud. The second problem is that I'm counting late frames and not missing frames. More late frames could actually be better than less, because if there is an almost 0.25 second stall (0.5 second is default gallium hud update period) without new frames and then the rest of the frames is rendered at 120+fps, one late frame is counted, but there are a lot more frames missing for 60 fps rendering in that period.

          I mean, what I really want to measure is how bad the "stuttering" is. The talos principle has a nice FPS counter that shows low and high fps and there you can see the problem that sometimes your average FPS are way over 60 fps, yet the low value is 15 fps, which means on average you have good fps, but at least one frame took 1/15s instead of the desired 1/60s, which means lag. I thought about a histogram over the last hud update period, but in the hud you really want to have a visible history and you can't really have that with a histogram. I'm not really sure yet what is best to display. At one point I want to add up all delays that are more than 1/FPS s so I can plot "how bad" the stuttering was over the last period.
          Hm...
          Last edited by haagch; 03 December 2016, 11:25 AM.

          Comment


          • #6
            I think I have the same issue with 4.9-rc* with just using the 4.8 config + default values and on 4.8 it works fine. I'm 99% sure it's not the config, but an issue in the driver.

            Comment


            • #7
              Originally posted by debianxfce View Post

              If you use kernel config file from a distro, then compilation is slow and kernel settings testing is not possible. Remove unneeded drivers and tune the kernel, then it will compile in 10-15 minutes. I did notice that kernel developers do have faster cpus than my Carrizo, so I needed to make the kernel faster than distro kernels. Use wine staging csmt instead of gallium nine, csmt will distribute the load to multiple cpu cores.
              The dumbest shit I ever heard.... Really completely retarded.... You advise people to use an abstraction layer that intentionally adds many multitudes higher overhead than a native implementation. Stupid.

              EDIT: So what will your advice be for games that are already properly multithreaded? The real bottom line fact is that OpenGL is -NOT- made to be multithreaded. It's a dirty nasty hack with many times higher overhead. The only place where threading belongs for OpenGL titles is in the game engine and no where else.

              EDIT: And if the game engine isn't multithreaded properly then, too bad so sad, imo.

              EDIT: On the other hand, the mesa devs could develop some standardized methods that driver developers can implement to ease multithreading OpenGL. That would be totally acceptable to me of course.
              Last edited by duby229; 04 December 2016, 05:27 PM.

              Comment


              • #8
                Of course I am using the csmt branch of gallium nine: https://github.com/iXit/Mesa-3D/commits/csmt

                Comment


                • #9
                  Originally posted by debianxfce View Post

                  Benchmarks do show that wine-staging csmt is faster than gallium nine.
                  Link ?
                  In all the benchmarks "wine staging csmt vs gallium nine" on radeonsi I have seen the last few years are a big win for gallium nine.

                  Comment


                  • #10
                    Originally posted by debianxfce View Post

                    New gpu cards, new games. History teach us nothing, says Sting.
                    Not sure what you mean by that. Do you have any link to a benchmark showing your argument ?

                    Comment

                    Working...
                    X