Announcement

Collapse
No announcement yet.

AMD RadeonSI Graphics Driver Still Troublesome On Linux

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

  • AMD RadeonSI Graphics Driver Still Troublesome On Linux

    Phoronix: AMD RadeonSI Graphics Driver Still Troublesome On Linux

    Back in June I ran some RadeonSI Gallium3D benchmarks showing the performance had a ways to improve, but sadly the situation hasn't improved months. There's been progress on the RadeonSI Gallium3D driver and from the kernel side with Radeon DRM improvements and new features, but in testing out the latest code it's still a buggy experience and the performance isn't close to matching the closed-source AMD Catalyst Linux graphics driver for Radeon HD 7000 series hardware. At least though for some Linux games we're now in the range of 50% the OpenGL speed of Catalyst.

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

  • #2
    Don't worry, probably in five years we will have fully working open source drivers for the HD 7000 series...

    Comment


    • #3
      ???

      what the point to use kernel without dpm enable?

      Comment


      • #4
        As it seems that AMD is focusing more Linux-related efforts to the open source module, what is the implication for the future? If the FOSS module is the future of AMD drivers on Linux, does this mean that acceptable performance on the radeon module will always be 2 or 3 generations behind the latest and greatest?

        Comment


        • #5
          Tropics

          What was the problem with Tropics? It works fine for me.

          Also, which version of LLVM was used for these tests? 3.4 SVN is recommended for Mesa master.

          Comment


          • #6
            You can see the effects of the clocks between the 3.8 and 3.11 and 3.12 tests. Prior to 3.11, the kernel left the clocks at their boot up levels which are usually very low. In 3.11, the default clocks are now programmed. The default clocks vary from board to board. Sometimes they are low like the boot up clocks, sometimes they are higher like on older dGPUs. So depending on your board, you are not likely to see much of a difference in performance if your particular board already has high default clocks. You will save power however since the clocks will be reduced when the GPU is not busy.

            Comment


            • #7
              For us with a lack of understanding. Just what pieces are missing/needs to be done in the free driver to make perform as well as the closed driver?

              Comment


              • #8
                Micheal is there any way to do a single test (for example Xonotic) when benchmarking an openbenchmarking.org ID (1309171-SO-AMDRADEON66)?
                Did you receive my last e-mail? I wasn't able to submit the results...
                ## VGA ##
                AMD: X1950XTX, HD3870, HD5870
                Intel: GMA45, HD3000 (Core i5 2500K)

                Comment


                • #9
                  Originally posted by CrvenaZvezda View Post
                  For us with a lack of understanding. Just what pieces are missing/needs to be done in the free driver to make perform as well as the closed driver?
                  Mostly porting of additional hardware and software optimizations from r600g to radeonsi. Of the top of my head:
                  - hyperZ support
                  - fast color clears
                  - enabling 2D tiling by default on SI (can probably done now that mesa 9.2 has been released)
                  - using the sDMA engines for blits and uploads
                  - shader compiler improvements

                  Comment


                  • #10
                    Originally posted by darkbasic View Post
                    Micheal is there any way to do a single test (for example Xonotic) when benchmarking an openbenchmarking.org ID (1309171-SO-AMDRADEON66)?
                    Did you receive my last e-mail? I wasn't able to submit the results...
                    No I didn't get any email. Michael at phoronix.com.

                    Not without hand editing the XML, though would be a good feature to come up with a good way to add that support, it would be easy but would just be a matter of thinking of a good way to expose/input that request to only benchmark a select portion(s) of the comparison.
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #11
                      Kudos Michael, that was a good set of benchmarks. Relevant variables clearly seperated out and compared, with some demanding tests included (even if most of them failed!) rather than just open source games with ridiculous frame rates.

                      Thanks!

                      Comment


                      • #12
                        Don't panic

                        They've got Marek.

                        Comment


                        • #13
                          Hello, Alex,

                          I have muxless laptop with intel hd 4000 + radeon 7750M. So physically there is no display connected to discrete graphic card. I have the following results of unigine tropics benchmark (1024x768 with all high settings):
                          Code:
                          intel hd 4000                   22.7 fps
                          radeon 7750M (fglrx)            44.9 fps
                          radeon 7750M (radeonsi auto)     9.6 fps
                          radeon 7750M (radeonsi high)    24.1 fps
                          Software:
                          kernel 3.11.1 with dpm enabled
                          The rest is from today's git

                          With auto my radeon GPU is always in low state:
                          Code:
                          uvd    vclk: 0 dclk: 0
                          power level 0    sclk: 30000 mclk: 15000 vddc: 850 vddci: 900 pcie gen: 2
                          Only using high performance level helps me. In bug report 69395 you attached a patch. Will it help in my laptop's case?

                          Also do you know what is the state of dynamic switching of discrete GPU? Dave merged nouveau patches for nvidia and his branch for radeons wasn't touched for three weeks. Is there a chance to have this support in 3.12 kernel?

                          Comment


                          • #14
                            Originally posted by Rakot View Post
                            Only using high performance level helps me. In bug report 69395 you attached a patch. Will it help in my laptop's case?
                            Yes, that patch should help in your case. I just need to sort out how to properly handle that dynamically.

                            Originally posted by Rakot View Post
                            Also do you know what is the state of dynamic switching of discrete GPU? Dave merged nouveau patches for nvidia and his branch for radeons wasn't touched for three weeks. Is there a chance to have this support in 3.12 kernel?
                            The merge window for 3.12 has closed. Hopefully we'll have something for 3.13.

                            Comment


                            • #15
                              Originally posted by agd5f View Post
                              Yes, that patch should help in your case. I just need to sort out how to properly handle that dynamically.
                              The merge window for 3.12 has closed. Hopefully we'll have something for 3.13.
                              Alex, just for clarification of those reading this forum thread..

                              Whats the status (whats possible, what can be handled?) of multi-GPU's under linux?

                              DMA-buf was merged months ago (if not over a year ago)-- Does radeon have support for DMA-buf buffers?

                              DMA-sync was a work in progress last I heard. Still a work in progress? Or was it merged? If it was merged, whats radeon's support?

                              Whats the default behavior for radeon currently when there's two graphics cards in one system? One discrete, one dedicated. Does radeon know to automatically keep the dedicated card off (unless there's a cable hooked into it) unless a load is being ran on it? Or does it keep it powered on burning power?


                              I'm asking because im building an amd(+amd in the future) system and I want to know what to expect from it. I won't need the dedicated card all the time, so plugging the HDMI cable into its port would be a massive waste of energy and heat. Therefore I'm curious what the state of support is for amd+amd hybrid graphics in the open source driver, if its enough to where I can have the cable be plugged into the motherboard (not the dedicated) but just use the dedicated card for gaming rendering when needed.

                              Comment

                              Working...
                              X