Announcement

Collapse
No announcement yet.

RadeonSI/AMDGPU Switches Over To New Command Submission API

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

  • RadeonSI/AMDGPU Switches Over To New Command Submission API

    Phoronix: RadeonSI/AMDGPU Switches Over To New Command Submission API

    Landing today within Mesa Git is a switchover for the AMDGPU winsys layer to using the new command submission (CS) API...

    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

  • #2
    Sounds like dealing with micro stuttering? I'm all for low overhead!

    Comment


    • #3
      Is there any visible performance impact?

      Comment


      • #4
        Originally posted by shmerl View Post
        Is there any visible performance impact?
        Asking the real questions!

        Comment


        • #5
          Sounds useful if in CPU-limited scenarios. GPU-limited scenarios proobably won't notice a difference, so the best we can hope for with this change is a smoother experience when using a strong GPU + weak CPU combo, or just a reduction in CPU usage similar to what we see in Vulkan titles vs OpenGL (though this time it's GL vs GL...)

          Comment


          • #6
            No difference in Nier, but tbh I didn't expect any difference, especially with mesa_glthread enabled - Mesa seems to be threaded well enough to hide any such overhead anyway as long as you have CPU cores to spare.

            Comment


            • #7
              Not so fast... it's not really working yet: https://lists.freedesktop.org/archiv...er/012979.html

              Here's on example of benefit, before the above bugfix...
              Ok, found something that works. Xonotic in lowest resolution, lowest effects quality (e.g. totally CPU bound):

              Without per process BOs:

              Xonotic 0.8:
              pts/xonotic-1.4.0 [Resolution: 800 x 600 - Effects Quality: Low]
              Test 1 of 1
              Estimated Trial Run Count: 3
              Estimated Time To Completion: 3 Minutes
              Started Run 1 @ 21:13:50
              Started Run 2 @ 21:14:57
              Started Run 3 @ 21:16:03 [Std. Dev: 0.94%]

              Test Results:
              187.436577
              189.514724
              190.9605812

              Average: 189.30 Frames Per Second
              Minimum: 131
              Maximum: 355

              With per process BOs:

              Xonotic 0.8:
              pts/xonotic-1.4.0 [Resolution: 800 x 600 - Effects Quality: Low]
              Test 1 of 1
              Estimated Trial Run Count: 3
              Estimated Time To Completion: 3 Minutes
              Started Run 1 @ 21:20:05
              Started Run 2 @ 21:21:07
              Started Run 3 @ 21:22:10 [Std. Dev: 1.49%]

              Test Results:
              203.0471676
              199.6622532
              197.0954183

              Average: 199.93 Frames Per Second
              Minimum: 132
              Maximum: 349

              Well that looks like some improvement.

              Regards,
              Christian.

              Comment


              • #8
                Originally posted by ernstp View Post
                Not so fast... it's not really working yet: https://lists.freedesktop.org/archiv...er/012979.html
                That is unrelated. The change the article is about is mostly just skipping the libdrm abstraction, which has been annoying when adding new features. Using the new interface is needed for some of the interprocess synchronization extensions. radv already uses it for that reason.

                Comment


                • #9
                  Originally posted by BNieuwenhuizen View Post

                  That is unrelated. The change the article is about is mostly just skipping the libdrm abstraction, which has been annoying when adding new features. Using the new interface is needed for some of the interprocess synchronization extensions. radv already uses it for that reason.
                  Is there any CPU overhead benefit from this new Command Submission API? Or did you develop it purely to avoid having to jump through unnecessary hoops during driver/feature bring-up?

                  Comment


                  • #10
                    Okay, that's it. I don't like it. And you know why? Me either. I don't even use my AMD card under Linux anymore. But what the heck, I thought I'd register my nonsensical disapproval anyway ...

                    Comment

                    Working...
                    X