Announcement

Collapse
No announcement yet.

AMD's RadeonSI Driver Sped Up A Lot This Summer

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

  • AMD's RadeonSI Driver Sped Up A Lot This Summer

    Phoronix: AMD's RadeonSI Driver Sped Up A Lot This Summer

    Compared to the state of AMD's RadeonSI Gallium3D driver stack shipped in Ubuntu 14.04 LTS back in April, the latest open-source graphics driver code for the Radeon HD 7000 series GPUs and newer is a heck of a lot faster. Here's some tests showing how much progress has been made the past few months.

    http://www.phoronix.com/vr.php?view=20791

  • #2
    The PPA is using llvm-3.5 since some time.

    Coming up in the next few days are even some other more exciting Linux GPU tests. If you appreciate all of the Linux hardware testing, please make a contribution or join Phoronix Premium.
    You may also consider supporting the PPA, which also include gallium-nine currently .

    Comment


    • #3
      Good timing cause I got a 7850 off Ebay for $80. Gotta love how everyone is now selling their Bit Coin cards for cheap.

      Comment


      • #4
        Maybe around this time next year, the FOSS radeon driver has caught up with Catalyst in performance. At least for the cards that are out today.

        Comment


        • #5
          In general you see a lag in performance along major architectural lines, not year-to-year generation lines. In other words performance improvements for SI should also benefit later cards using GCN. The big "break" in terms of performance benefits rolling forward was between VLIW and GCN.

          Comment


          • #6
            Originally posted by bridgman View Post
            In general you see a lag in performance along major architectural lines, not year-to-year generation lines. In other words performance improvements for SI should also benefit later cards using GCN. The big "break" in terms of performance benefits rolling forward was between VLIW and GCN.
            Awesome to hear. Forgive my ignorance, but do you work on the FOSS driver or Catalyst?

            I'm hoping to exchange my GTX 670 for a Radeon card in the future, and get a performance upgrade while using the FOSS driver.

            Comment


            • #7
              Originally posted by xeekei View Post
              Awesome to hear. Forgive my ignorance, but do you work on the FOSS driver or Catalyst?

              I'm hoping to exchange my GTX 670 for a Radeon card in the future, and get a performance upgrade while using the FOSS driver.
              I volunteered to set up the open source graphics effort back in 2007 and was its pointy-haired boss until a couple of years ago, then I moved to Linux HSA. The Linux HSA stack is also going to be open source - the kernel driver and libdrm-level userspace lib are already public, and we're working on getting the remaining bits out now.

              The HSA stack needs to work with both open and closed source graphics drivers, so I guess the best answer to your question is "yes"
              Last edited by bridgman; 08-22-2014, 03:12 PM.

              Comment


              • #8
                Speed is nice, but hopefully stability can be worked on a bit. Random lockups with just web browsing and picture viewing wasn't too ideal :/ But I guess that's the cost of running bleeding-edge stuff/

                Comment


                • #9
                  Originally posted by Espionage724 View Post
                  Speed is nice, but hopefully stability can be worked on a bit. Random lockups with just web browsing and picture viewing wasn't too ideal :/ But I guess that's the cost of running bleeding-edge stuff/
                  Some users reported great stability with current agd5f's drm-fixes-3.17 kernel so i installed it and will try hard to broke it in the next few days

                  Of course that by reading bugzilla and trying to avoid known bugs .

                  Comment


                  • #10
                    Originally posted by bridgman View Post
                    I volunteered to set up the open source graphics effort back in 2007 and was its pointy-haired boss until a couple of years ago, then I moved to Linux HSA. The Linux HSA stack is also going to be open source - the kernel driver and libdrm-level userspace lib are already public, and we're working on getting the remaining bits out now.

                    The HSA stack needs to work with both open and closed source graphics drivers, so I guess the best answer to your question is "yes"
                    Can you give a ballpark estimate on when the OSS support or GPU based OpenCL/HSA will be ready? Looking at http://dri.freedesktop.org/wiki/GalliumCompute/ it looks like theres still a ton of work to be done to reach OpenCL 1.0 even after all this time, let alone 1.1, 1.2 and 2.0.
                    Last edited by Kivada; 08-23-2014, 02:26 AM.

                    Comment


                    • #11
                      Originally posted by Kivada View Post
                      Can you give a ballpark estimate on when the OSS support or GPU based OpenCL/HSA will be ready? Looking at http://dri.freedesktop.org/wiki/GalliumCompute/ it looks like theres still a ton of work to be done to reach OpenCL 1.0 even after all this time, let alone 1.1, 1.2 and 2.0.
                      For HSA on Kaveri we're aiming to have everything finished and open in 2014, although opening the Finalizer may drag on past that. For OpenCL not sure yet -- we're trying to get more people working on it and open up more code from our proprietary implementation, so rate of progress should improve but I don't know how much yet.

                      Comment


                      • #12
                        Originally posted by bridgman View Post
                        For HSA on Kaveri we're aiming to have everything finished and open in 2014, although opening the Finalizer may drag on past that. For OpenCL not sure yet -- we're trying to get more people working on it and open up more code from our proprietary implementation, so rate of progress should improve but I don't know how much yet.
                        Is linux HSA support for APU Kaveri and later architectures?

                        Comment


                        • #13
                          Originally posted by Bucic View Post
                          Is linux HSA support for APU Kaveri and later architectures?
                          Yes, it needs two things -- CP support for usermode queues (anything CI or higher) and the ability to run 48-bit GPU addresses through ATS/PRI logic into an IOMMU with v2 functionality (basically support for ATS/PRI). Kabini has the first but not the second, as an example, but Kaveri has both.

                          IOMMUv2 functionality is described in the AMD IOMMU Architectural Spec document at :

                          http://www.hsafoundation.com/standards/

                          Basically the GPU needs to have an Address Translation Cache (ATC) which gets maintained via the PCI standard ATS/PRI mechanism, allowing the IOMMU to map GPU accesses to physical memory using the same mappings as the CPU's MMU. That is what provides the ability to share VA pointers between CPU and GPU.

                          Comment


                          • #14
                            Originally posted by bridgman View Post
                            Yes, it needs two things -- CP support for usermode queues (anything CI or higher) and the ability to run 48-bit GPU addresses through ATS/PRI logic into an IOMMU with v2 functionality (basically support for ATS/PRI). Kabini has the first but not the second, as an example, but Kaveri has both.

                            IOMMUv2 functionality is described in the AMD IOMMU Architectural Spec document at :

                            http://www.hsafoundation.com/standards/

                            Basically the GPU needs to have an Address Translation Cache (ATC) which gets maintained via the PCI standard ATS/PRI mechanism, allowing the IOMMU to map GPU accesses to physical memory using the same mappings as the CPU's MMU. That is what provides the ability to share VA pointers between CPU and GPU.
                            Any hope for Kabini to get partial support?

                            Comment


                            • #15
                              Originally posted by bridgman View Post
                              Yes, it needs two things -- CP support for usermode queues (anything CI or higher) and the ability to run 48-bit GPU addresses through ATS/PRI logic into an IOMMU with v2 functionality (basically support for ATS/PRI). Kabini has the first but not the second, as an example, but Kaveri has both.

                              IOMMUv2 functionality is described in the AMD IOMMU Architectural Spec document at :

                              http://www.hsafoundation.com/standards/

                              Basically the GPU needs to have an Address Translation Cache (ATC) which gets maintained via the PCI standard ATS/PRI mechanism, allowing the IOMMU to map GPU accesses to physical memory using the same mappings as the CPU's MMU. That is what provides the ability to share VA pointers between CPU and GPU.
                              Thank you!
                              Any idea whether your average office/internet browser mole is going to benefit from KAveri HSA on Linux?

                              Comment

                              Working...
                              X