Deadline Scheduling Policy Being Experimented With For Linux Graphics Drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • phoronix
    Administrator
    • Jan 2007
    • 67377

    Deadline Scheduling Policy Being Experimented With For Linux Graphics Drivers

    Phoronix: Deadline Scheduling Policy Being Experimented With For Linux Graphics Drivers

    Tvrtko Ursulin with Igalia sent out a "request for comments" patch series today working on a deadline scheduling policy for the DRM scheduler that is used across different Direct Rendering Manager kernel graphics drivers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
  • Kjell
    Senior Member
    • Apr 2019
    • 690

    #2
    AMDGPU's new default scheduler (FIFO) has a negative impact on gaming performance

    This change is really needed
    Last edited by Kjell; 30 December 2024, 10:26 PM.

    Comment

    • Mitch
      Senior Member
      • May 2017
      • 375

      #3
      Originally posted by Kjell View Post
      AMDGPU's new default scheduler (FIFO) has a negative impact in gaming

      This change is really needed
      Yeah, hopefully this ends up being a great default for most/all scenarios. Good latency, throughput, and priority management, while also not letting anybody starve the party because any one app gets in trouble.

      Comment

      • MrCooper
        Senior Member
        • Aug 2008
        • 636

        #4
        Originally posted by Kjell View Post
        AMDGPU's new default scheduler (FIFO) has a negative impact on gaming performance
        Author of the Gitlab comment you linked to here.

        The main problem in that issue was that Xwayland was doing GPU copies for presentation. That should no longer be the case with current Xwayland, which should thus work better with FIFO scheduling.

        Even better is running the game as Wayland native, which takes Xwayland out of the picture: https://gitlab.freedesktop.org/drm/a...6#note_2679509

        This change is really needed
        We can't know at this point if deadline scheduling would work better than FIFO for the issue above.

        Comment

        • Kjell
          Senior Member
          • Apr 2019
          • 690

          #5
          Originally posted by MrCooper View Post
          Author of the Gitlab comment you linked to here.
          Anecdotal experience but I've successfully fixed nasty micro-stuttering by running round-robin schduler instead of FIFO in a full Wayland pipeline

          Also had to run a preempt=full kernel to fix desktop responsiveness

          This might stem from the fact that I have a lot of background tasks

          Originally posted by MrCooper View Post
          We can't know at this point if deadline scheduling would work better than FIFO for the issue above.
          "Deadline scheduling policy should be a fairer flavour of FIFO with two main advantages being that it can naturally connect with the dma-fence deadlines, and secondly that it can get away with multiple run queues per scheduler"

          Makes me wonder if this new schduler could aid the performance regression in Explicit Sync with Wlroots:

          "For explicit sync, the cost of vkAcquireNextImage is 5x to 10x higher than with implicit sync. This cost is not avoidable with today's APIs. This results in vkAcquireNextImage being a few microseconds slower than with implicit sync which, at 30k FPS, has an impact of several thousand FPS. Most time is spent querying the status of syncobjs, not actually waiting for them to get signaled"

          Comment

          • nuetzel
            Senior Member
            • May 2016
            • 754

            #6
            Originally posted by MrCooper View Post

            Author of the Gitlab comment you linked to here.

            The main problem in that issue was that Xwayland was doing GPU copies for presentation. That should no longer be the case with current Xwayland, which should thus work better with FIFO scheduling.

            Even better is running the game as Wayland native, which takes Xwayland out of the picture: https://gitlab.freedesktop.org/drm/a...6#note_2679509



            We can't know at this point if deadline scheduling would work better than FIFO for the issue above.
            One sentence:

            'Show me the numbers.' ...;-)))

            Happy New Year! πŸ€πŸ„πŸΎπŸ₯‚πŸŽ‰πŸš€

            Comment

            • MrCooper
              Senior Member
              • Aug 2008
              • 636

              #7
              Originally posted by Kjell View Post
              Anecdotal experience but I've successfully fixed nasty micro-stuttering by running round-robin schduler instead of FIFO in a full Wayland pipeline

              Also had to run a preempt=full kernel to fix desktop responsiveness

              This might stem from the fact that I have a lot of background tasks
              If some of those background processes use the GPU, that might explain why the GPU scheduling policy makes a difference.

              "Deadline scheduling policy should be a fairer flavour of FIFO with two main advantages being that it can naturally connect with the dma-fence deadlines, and secondly that it can get away with multiple run queues per scheduler"

              Makes me wonder if this new schduler could aid the performance regression in Explicit Sync with Wlroots:

              "For explicit sync, the cost of vkAcquireNextImage is 5x to 10x higher than with implicit sync. This cost is not avoidable with today's APIs. This results in vkAcquireNextImage being a few microseconds slower than with implicit sync which, at 30k FPS, has an impact of several thousand FPS. Most time is spent querying the status of syncobjs, not actually waiting for them to get signaled"
              It can't. Per the text you quoted, it's purely CPU overhead of querying drm_syncobjs / waiting for them to signal, nothing directly related to the GPU scheduler (which only deals with dma-fences, not drm_syncobjs).

              It might be possible to optimize this somewhat, not sure explicit sync can ever match implicit sync for this specific scenario (GPU-light & CPU-bound app) though. That's just not what explicit sync is designed for. I described the issue and optimized it a bit in mesa!29199, there didn't seem to be interest in even getting the full benefit of all the changes I proposed though, which still would have closed only about half of the gap.

              Comment

              • Kjell
                Senior Member
                • Apr 2019
                • 690

                #8
                Originally posted by MrCooper View Post
                It might be possible to optimize this somewhat, not sure explicit sync can ever match implicit sync for this specific scenario (GPU-light & CPU-bound app) though. That's just not what explicit sync is designed for. I described the issue and optimized it a bit in mesa!29199, there didn't seem to be interest in even getting the full benefit of all the changes I proposed though, which still would have closed only about half of the gap.
                That's unfortunate, I appreciate your effort!

                There doesn't seem to be enough people like you guarding the performance of Linux

                Comment

                • Developer12
                  Senior Member
                  • Dec 2019
                  • 1584

                  #9
                  "I was only able to test it with amdgpu. Other drivers may not even compile."

                  Given how much of an utter tangled mess this code has been revealed to already be, I'm not surprised at all.

                  Comment

                  Working...
                  X