Announcement

Collapse
No announcement yet.

Trying Out The New OpenGL Threaded Dispatch In Mesa 17.1

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

  • #51
    Many Linux OpenGL Steam games are unable to maintain smooth 60 FPS with medium CPU and high-end AMD GPU. For example, rotating the view 360 degrees results in stuttering. The solution I am using is to limit the FPS to 30 (vblank interval = 2) which makes the stuttering much less frequent. Because there is a sequential component involved I would need the equivalent of an 8GHz CPU to maintain smooth 60 FPS, or the equivalent of an 4GHz CPU with two times higher IPC (instruction per clock) than my current CPU.

    Comment


    • #52
      At this point I truly believe that with the threaded dispatch on the reported fps is wrong since I can't believe that running at ~20fps gives a much smoother results than ~28fps just because the CPU spikes have been sorted out.

      since I'm not an expert though just writing what I see/feel I would appreciate more input from an expert to sort this out.

      Comment


      • #53
        Originally posted by mitch074 View Post

        A smoother gameplay usually comes from:
        * much higher low fps (but one has to remove graph spikes and dips: if you get a tenth of a second of 10 fps for shaders to be loaded and then min fps is 30 fps, it's much better than getting 15 fps every 2 seconds)
        * much less frame rate variance (see above for spikes)
        * less micro-stuttering (frame time variance, they're usually so fast they don't appear on a graph but are very jarring during play)

        The two latest Mesa improvements (shaders on-disk cache, GL thread) are major improvements towards smoother gameplay by reducing CPU spikes without the game's developer having to do much, if anything, to make use of them. Personally, I don't MIND max fps dropping as long as average remains pretty much the same but stuttering goes away.
        Frame-rate variance is a good point, that would makes sense!

        Thanks!
        Last edited by geearf; 03-20-2017, 09:45 AM.

        Comment


        • #54
          Originally posted by gbil View Post
          At this point I truly believe that with the threaded dispatch on the reported fps is wrong since I can't believe that running at ~20fps gives a much smoother results than ~28fps just because the CPU spikes have been sorted out.

          since I'm not an expert though just writing what I see/feel I would appreciate more input from an expert to sort this out.
          Here's an example of one of Mitch's case, that would explain it (it's just an example):

          In the original case you have an average of 28 FPS. Since it's an average it doesn't represent the whole distribution by itself, so let's say you usually are between 6 FPS and 50 FPS (for simplicity's sake, we'll just say that 28 is not just the average but also the median).
          In the threads case your average is 20 FPS, let's say that this time you are between 16 and 24 FPS. This case has a smaller step between the min and max, the lower FPS is also much higher in this case. This would probably look smoother.

          Comment


          • #55
            Originally posted by LeJimster View Post

            Maybe I can buy that as an explanation. But then why does radv performance tank so bad. Vulkan is multi threaded by design.
            Vulkan is by design. RADV isn't as of yet. Testing DOTA 2 I get twice the frame rate if I limit it to two cores as opposed to letting it use all 16 logical cores.

            Comment


            • #56
              Originally posted by geearf View Post

              Here's an example of one of Mitch's case, that would explain it (it's just an example):

              In the original case you have an average of 28 FPS. Since it's an average it doesn't represent the whole distribution by itself, so let's say you usually are between 6 FPS and 50 FPS (for simplicity's sake, we'll just say that 28 is not just the average but also the median).
              In the threads case your average is 20 FPS, let's say that this time you are between 16 and 24 FPS. This case has a smaller step between the min and max, the lower FPS is also much higher in this case. This would probably look smoother.
              But when you are talking about averages you are talking about benchmarking I guess, while I'm talking about realtime numbers while playing the game, or I understood wrong?

              Comment


              • #57
                Originally posted by gbil View Post

                But when you are talking about averages you are talking about benchmarking I guess, while I'm talking about realtime numbers while playing the game, or I understood wrong?
                What's the difference between those 2? Unless you've looked at every frame's time for the whole time you played...

                Comment


                • #58
                  Originally posted by L_A_G View Post

                  It's probably conflicting with games trying to do the same thing themselves. I guess it's a good thing the way it's supposed to work is with a whitelist of games that benefit from it and not even try to use it on games that aren't on that whitelist.
                  This.

                  Game devs know opengl is single threaded so they make the engine work in the the exact same way, one thread as a command buffer the rest of the game logic into other threads. So the difference should be none or even performance worse because you have two command buffers instead of one. Or am i misunderstanding how this is supposed to work now?

                  Comment


                  • #59
                    Originally posted by geearf View Post

                    What's the difference between those 2? Unless you've looked at every frame's time for the whole time you played...
                    No but the fps counter in both cases was pretty much steady and if as you wrote the variation was bigger I should have seen in many occasions the fps counter going way down or way up.

                    When I have again some time I'll use the gallium hud which instead of a single value it presents fps with a graph therefore possibly any up and downs will be way more visible.

                    Comment


                    • #60
                      Originally posted by LinuxID10T View Post

                      Vulkan is by design. RADV isn't as of yet. Testing DOTA 2 I get twice the frame rate if I limit it to two cores as opposed to letting it use all 16 logical cores.
                      It makes much more sense to spawn a worker thread only when your existing worker threads reach 100%. Not only will it allow Turbo to kick in if two worker threads are enough but its also more efficient. And also allows cores to be completely available for other things running. In contrast to server logic where you want requests scattered over your cores as much as possible.

                      Comment

                      Working...
                      X