Announcement

Collapse
No announcement yet.

The Linux 3.13 Kernel Is A Must-Have For AMD RadeonSI Users

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

  • #11
    Originally posted by Michael View Post
    See the note in the article why Source Engine games weren't used.
    LOL. When I saw that in the article, I was wondering if anyone would ask the question and what your response would be. I'm surpised and impressed.

    Comment


    • #12
      Originally posted by darkbasic View Post
      I didn't notice any performance increase with 3.13 on HD 7950.
      If you forced DPM on and had 3.12.7 or later you had most of the bulk performance increases.

      What I'm worried about is now that the driver is using all its render cores at their rated speeds, the easy performance grabs are gone, and yet performance is still abyssal. The same cards under Catalyst would still be performing twice as fast in most cases. So what else is there to fix?

      Comment


      • #13
        Originally posted by zanny View Post
        If you forced DPM on and had 3.12.7 or later you had most of the bulk performance increases.

        What I'm worried about is now that the driver is using all its render cores at their rated speeds, the easy performance grabs are gone, and yet performance is still abyssal. The same cards under Catalyst would still be performing twice as fast in most cases. So what else is there to fix?
        Two guesses, and one factoid...

        Guess One: Poorly optimized shader generation. LLVM was supposed to be better than r600, but maybe its not perfect yet.

        Guess Two: Poorly (or not at all) optimized code paths. Development is: make it work THEN make it fast.

        Factoid: Radeon in general has fairly poor memory allocation in comparison to Catalyst, and the better your card is the more obvious this becomes because then Memory becomes the bottleneck. By poor memory allocation I mean the driver is kind of 'dumb' about where things should be in memory, whats safe to move out of GPU memory / just drop completely, and the likes. Its on the 'volunteer todo list' last I heard, because optimized memory algorithms were never on the original AMD roadmap and plans.

        One additional note... In most cases, especially high end cards, Catalyst will ALWAYS BE FASTER. Kernel and Mesa would never accept code that said

        If (CardID == 7970)
        {
        Codepath 1
        }
        else If (CardId == 7770)
        {
        Codepath 2
        }
        else // See: Low and medium cards
        {
        CodePath 3
        }

        Meanwhile Catalyst just might, and probably does, because they have a financial incentive to make sure that every single card gets the most performance that it can get, even if it means micro-managing code paths. The Kernel and Mesa devs will accept the code that works the best on the most cards as possible, and is the most maintainable, even if that means maybe only hitting 90% performance of the possible because you've got a high end card
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #14
          ohhhhhh.....



          I like the number of games that are getting close (and a few surpasing!) catalyst.

          It will be interesting to see Micheal's comparison (please include the ungine benchmark :-)

          Comment


          • #15
            Originally posted by zanny View Post
            If you forced DPM on and had 3.12.7 or later you had most of the bulk performance increases.

            What I'm worried about is now that the driver is using all its render cores at their rated speeds, the easy performance grabs are gone, and yet performance is still abyssal. The same cards under Catalyst would still be performing twice as fast in most cases. So what else is there to fix?
            Ok first see what Ericg posted. his
            Guess Two: Poorly (or not at all) optimized code paths. Development is: make it work THEN make it fast.
            is the big issue. The 7000 series just got caught up with openGL support late last year. So they are just now starting work on optimization.


            So what else is there to fix?
            * There are several optimizations that they have implemented for r600 cards that haven't been ported yet.
            * 2D (GLAMOR) has allot of potential optimizations. Its almost completely unoptimized. They have just started working on speeding it up. Interestingly, since glamor uses 3d calls, some of the 3d optimizations should speed up 2D.
            * Ram usage.
            * Shader compilation.

            Comment


            • #16
              Question:

              RadeonSI requires GLAMOR for 2D accel, and is needed for hardware-accelerated compositing desktops like GNOME 3 (Mutter? Clutter? Can't remember...) and KDE's Kwin.

              How's the 2D accel performance under GLAMOR in RadeonSI?

              Comment


              • #17
                Originally posted by Sonadow View Post
                How's the 2D accel performance under GLAMOR in RadeonSI?
                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
                Michael Larabel
                https://www.michaellarabel.com/

                Comment


                • #18
                  How's the 2D accel performance under GLAMOR in RadeonSI?
                  The last benchmark I saw a couple days ago showed that it currently isn't very good. Normal 2d programs will actually lag because of it. But there are apparently a couple patches just released that help fix some of the major slowdowns (fixes hangs on several programs, but not all). A couple developers have started to work on optimizing GLAMOR recently... so hopefully it will improve to acceptable levels quickly.


                  EDIT:

                  Hah. Micheal beat me to the punch! :-D

                  Comment


                  • #19
                    Originally posted by Ericg View Post
                    One additional note... In most cases, especially high end cards, Catalyst will ALWAYS BE FASTER. Kernel and Mesa would never accept code that said

                    If (CardID == 7970)
                    {
                    Codepath 1
                    }
                    else If (CardId == 7770)
                    {
                    Codepath 2
                    }
                    else // See: Low and medium cards
                    {
                    CodePath 3
                    }
                    maybe that would not be accepted but then, it shouldn't be too difficult to refactor the code into separate kernel modules one module for each model.

                    or, maybe you would be surprise of the kernel maintainers flexibility. snd_hda_intel does almost exactly what you have described. not with big if/elsif blocks but they extensively use function pointers to customize the driver behavior based on the model. please take a look at sound/pci/hda/patch_xxx.c

                    Comment


                    • #20
                      So, an important performance fix for RadeonSI... plus some important performance regressions (here and here). Nice...

                      Comment

                      Working...
                      X