Announcement

Collapse
No announcement yet.

AMDGPU Feature Updates Submitted For Linux 4.18, Bringing Vega M & More

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

  • AMDGPU Feature Updates Submitted For Linux 4.18, Bringing Vega M & More

    Phoronix: AMDGPU Feature Updates Submitted For Linux 4.18, Bringing Vega M & More

    Alex Deucher of AMD today submitted the initial batch of Radeon/AMDGPU DRM driver feature updates to DRM-Next that in turn are slated to land in the Linux 4.18 merge window in June. There's a fair amount of notable feature work this round for Radeon Linux users...

    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
    Where's the link to the pull request?

    Comment


    • #3
      I haven't really noticed if freesync is now working with the recent kernels.
      Since I am using a R9 290 I can't test it because it is not useable by default until 4.17

      If it is working, how much can you expect from it? Is it working just how you would expect it to work?
      Are there any differences to freesync with windows?

      Comment


      • #4
        Originally posted by Morbis55 View Post
        I haven't really noticed if freesync is now working with the recent kernels.
        Since I am using a R9 290 I can't test it because it is not useable by default until 4.17

        If it is working, how much can you expect from it? Is it working just how you would expect it to work?
        Are there any differences to freesync with windows?
        It won't be working until there are user-space implementations. Just having the right kernel isn't enough, so there will be quite some time until we can start enjoying Freesync yet.

        Comment


        • #5
          While I appreciate the continued support of the Carrizo family with the addition now of scatter gather DMA (my Bristol Ridge laptop and desktop should also benefit) I do wonder why this feature is just now coming into play. The whole purpose of the Fusion/APU/HSA model was to lessen if not eliminate copies across the bus to and from both CPU memory and GPU memory. This is even less a factor with APUs since not only is the GPU embedded on-die both the CPU and GPU share system memory. Why wasn't this Day 1 support, especially for Carrizo, particularly after Kaveri? Or am I missing something,which is probably the case.

          Comment


          • #6
            Originally posted by Jumbotron View Post
            While I appreciate the continued support of the Carrizo family with the addition now of scatter gather DMA (my Bristol Ridge laptop and desktop should also benefit) I do wonder why this feature is just now coming into play. The whole purpose of the Fusion/APU/HSA model was to lessen if not eliminate copies across the bus to and from both CPU memory and GPU memory. This is even less a factor with APUs since not only is the GPU embedded on-die both the CPU and GPU share system memory. Why wasn't this Day 1 support, especially for Carrizo, particularly after Kaveri? Or am I missing something,which is probably the case.
            "Scatter/Gather Display" All AMD GPUs support scatter/gather DMA. Display hardware has very strict latency requirements and going through page tables adds latency. All dGPUs and until Carrizo, all APUs required that displays be in contiguous memory pools (vram on dGPUs and UMA carve out on APUs) that do not go through page tables. With Carrizo and newer APUs, display buffers don't have to be in carve out. It gives more flexibility for placement of display buffers on APUs.

            Comment


            • #7
              Originally posted by agd5f View Post

              "Scatter/Gather Display" All AMD GPUs support scatter/gather DMA. Display hardware has very strict latency requirements and going through page tables adds latency. All dGPUs and until Carrizo, all APUs required that displays be in contiguous memory pools (vram on dGPUs and UMA carve out on APUs) that do not go through page tables. With Carrizo and newer APUs, display buffers don't have to be in carve out. It gives more flexibility for placement of display buffers on APUs.
              Thanks agd5f ! I had already intuited this beforehand, although your more technical explanation helped. I wasn't questioning support by the AMD APU's themselves but the Linux Kernel support. Why is the kernel just now getting to supporting something that 2-3+ year old processors have been capable of from the start? Is it something that hard to code for? Seriously asking...not being snarky.

              Comment


              • #8
                There's no really profound reason - just that new HW capabilities arrive in big slugs but we can't ramp the SW teams up and down to match, so while open source driver development was catching up with new HW projects the "important" features generally got supported at launch and the remaining features got supported later.

                Now that we have caught up with new HW introductions (remember that we were ~5 generations behind when we restarted open source driver work) we have been beginning work on driver support for new product support earlier each cycle, so you should see less of this in the future.
                Test signature

                Comment


                • #9
                  Originally posted by bridgman View Post
                  There's no really profound reason - just that new HW capabilities arrive in big slugs but we can't ramp the SW teams up and down to match, so while open source driver development was catching up with new HW projects the "important" features generally got supported at launch and the remaining features got supported later.

                  Now that we have caught up with new HW introductions (remember that we were ~5 generations behind when we restarted open source driver work) we have been beginning work on driver support for new product support earlier each cycle, so you should see less of this in the future.
                  As always, bridgman for the win. Not surprising to read this. I think we all would like new feature sets to be supported Day 1 or near about. But, on the flip side, it's also a great thing that open source allows aging platforms to get a new breadth of life and vitality ( look at the news of Kaveri's performance boost from the upcoming Mesa 18.2.x. And the fact, as bridgman stated, that this gap is narrowing for the future is great news. Thanks again, bridgman, for the clarification !

                  Comment

                  Working...
                  X