Announcement

Collapse
No announcement yet.

AMD Proposing Redesign For How Linux GPU Drivers Work - Explicit Fences Everywhere

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

  • AMD Proposing Redesign For How Linux GPU Drivers Work - Explicit Fences Everywhere

    Phoronix: AMD Proposing Redesign For How Linux GPU Drivers Work - Explicit Fences Everywhere

    Well known open-source AMD Linux graphics driver developer Marek Olšák published an initial proposal this week as "a redesign of how Linux graphics drivers work."..

    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
    This would affect vm/iommu/sr-iov I would imagine. Not a small undertaking.

    Comment


    • #3
      Any performance improvements are always welcomed

      Comment


      • #4
        I think moving more and more stuff entirely to user space (avoid system calls) is the way to go. This means that the hardware should be designed with that in mind. High performance networks also try to bypass the kernel as much as possible.

        Comment


        • #5
          Can't wait to see what comes of this. When Marek's involved good things tend to happen.

          Comment


          • #6
            Next they will propose some library to replace GBM, so the kernel actually has a chance to pick the best fitting synchronization.

            Comment


            • #7
              Which generations of driver will this affect? Probably going back to RadeonSI, but not R600?

              Comment


              • #8
                While I don't undestand the technicalities talked about at all, it makes me nervous to read that GFX10 regresses in terms of a major functionality (preemption/pagefault capabilities) and features where this makes a difference like their HMM-implementation are therefore implemented on GFX9 (see this post in particular).

                Comment


                • #9
                  Originally posted by ThoreauHD View Post
                  This would affect vm/iommu/sr-iov I would imagine. Not a small undertaking.
                  This would affect sr-iov, as the Linux kernel is in control of the hardware at that point. VM/IOMMU is about hardware addressing, which would not be affected by the changes here. (Barring bugs that might happen.)

                  Passing through the device to a VM essentially gives up control of the device to the VM, so this doesn't affect that. IOMMU is about partitioning the device, and is lower level than the driver. SR-IOV has some connections to the driver scheduling, so has a greater chance of being affected.

                  Comment


                  • #10
                    In conventional Windows-based PC systems, processors can only access a fraction of graphics memory (VRAM) at once, limiting system performance.

                    With AMD Smart Access Memory, the data channel gets expanded to harness the full potential of GPU memory, utilizing the bandwidth of PCI Express® to remove the bottlenecks and increase performance.
                    this will fix processors access a fraction of graphics memory VRAM without any good reason for this kind of behaviors ?

                    Comment

                    Working...
                    X