Announcement

Collapse
No announcement yet.

AMD Catalyst vs. Linux 3.7 + Mesa 9.1-devel Gallium3D Performance

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

  • #16
    Originally posted by danwood76 View Post
    Marc Driftmeyer the kernel actually has nothing (much) to do with the AMD proprietary drivers.

    The later kernel is used in testing the OS driver because of the later kernel drivers.

    Looking at the figures most of those games are more than playable on the OS driver.
    But he's betting that it stomps. And you know that already.

    How can argue with THAT? Huh?

    Comment


    • #17
      I try to compare Intel vs. AMD here:
      Nexuviz 2.5.2
      AMD 6 times faster than Intel

      OpenArena 0.8.8
      Intel about 5 fps faster than AMD

      Warsow 0.61 and 1.0
      About the same speed

      Xonotic 0.6
      depends
      Intel is 30 times faster than the newer AMD driver and mesa
      About the same speed with the older AMD driver and mesa

      http://www.phoronix.com/scan.php?pag..._win1210&num=2
      http://www.phoronix.com/scan.php?pag...t2012chr&num=2

      Comment


      • #18
        I applaud the efforts that have been made with the radeon driver. It came from nothing - to the offer good stability and a good subset of the OpenGL requirements for modern 3D gaming. But last time I tested it on my laptop with a **real** game (S.T.A.L.K.E.R. : SOC via Wine) I got something like 6 FPS (Catalyst gives more like 30 FPS). The lack of full shadows isn't too noticeable - but the lamentable framerate is...

        Since I have a (very recent!!) legacy 4650M I guess most distros are gradually going to stop supporting it (my ARCH and Gentoo installs might limp on longer than the likes of Ubuntu - which xorg-server updates are the killer).

        I only have an AMD GPU in my laptop because Nvidia had nothing decent when I bought it. While the Catalyst driver was very slowly getting better over the years - I'm now stuck on some stupid legacy driver (limiting xorg-server and kernel updates).

        Trouble is I can't help looking at my truly ancient desktop Geforce 8800GTX with the bleeding edge 310.xx Nvidia beta driver - working like a champ and playing Black Mesa Source (via Wine) rather well!

        Comment


        • #19
          Hi,

          I guess the explanation for such a constant gap between the open source driver and fglrx is one single fundamental design difference between the two drivers, that's causing such an inefficiency on kernel/mesa/xf86-video-ati.

          If TTM is the culprit, why isn't there any patches already (4 years!) for addressing the buffers migration issue? AFAIK, that's what's Chris W. has done w/ SNA for the Xorg Intel driver.

          -Ilyes

          Comment


          • #20
            I expect the performance gap is caused by a dozen or more design differences, not one. Just a few off the top of my head :

            - tiling (mostly done AFAIK)
            - hyper-z (started)
            - shader compiler (WIP)
            - threading (command submission is in separate thread on r300g, not sure about r600g)
            - memory manager heuristics (this is what would probably help with buffer migration)
            - adaptive load balancing
            - adaptive memory reconfiguration

            BTW I don't think Marek is saying "we've known this for 4 years", I think he's saying "I just looked recently and the problem with these specific applications seems to be buffer migration".

            If the developers believed that one single issue was responsible for most of the performance differences then I think it's pretty safe to assume they would be all over it, but I don't think that is the case.

            Some apps (typically the very slowest) may have one single issue that contributes most of the slowdown RELATIVE TO OTHER APPLICATIONS but that's not the same as saying one single issue contributes to most of the performance gap between the open source stack and the Catalyst stack.

            Comment


            • #21
              Originally posted by bobwya View Post
              I applaud the efforts that have been made with the radeon driver. It came from nothing - to the offer good stability and a good subset of the OpenGL requirements for modern 3D gaming. But last time I tested it on my laptop with a **real** game (S.T.A.L.K.E.R. : SOC via Wine) I got something like 6 FPS (Catalyst gives more like 30 FPS). The lack of full shadows isn't too noticeable - but the lamentable framerate is...

              Since I have a (very recent!!) legacy 4650M I guess most distros are gradually going to stop supporting it (my ARCH and Gentoo installs might limp on longer than the likes of Ubuntu - which xorg-server updates are the killer).

              I only have an AMD GPU in my laptop because Nvidia had nothing decent when I bought it. While the Catalyst driver was very slowly getting better over the years - I'm now stuck on some stupid legacy driver (limiting xorg-server and kernel updates).

              Trouble is I can't help looking at my truly ancient desktop Geforce 8800GTX with the bleeding edge 310.xx Nvidia beta driver - working like a champ and playing Black Mesa Source (via Wine) rather well!
              This is why I use Nvidia ... for now.. I hope.
              In fact, when I got HD4670 back in days to use opensource driver, I had 5 FPS in old version of OpenArena.. Now it *would* run @ 90 fps.

              The problem is that STALKER uses DX features that are not implemented in MESA yet, and it causes massive slowdowns. Absence of shadows is one of the indices.

              Comment


              • #22
                Originally posted by ilyes View Post
                If TTM is the culprit, why isn't there any patches already (4 years!) for addressing the buffers migration issue?
                The reason is simple - there is a lack of manpower. I myself won't have time to do anything big until February.

                I think the issue with TTM was there all long, we just didn't know it has such an impact. Since we started enforcing VRAM buffer placements, we've seen both great improvements (because of faster access to VRAM) and terrible regressions in perfomance (because of TTM when we start running out of memory).
                Last edited by marek; 11-27-2012, 08:27 PM.

                Comment


                • #23
                  Hi,

                  Originally posted by bridgman View Post
                  I expect the performance gap is caused by a dozen or more design differences, not one. Just a few off the top of my head :

                  - tiling (mostly done AFAIK)
                  - hyper-z (started)
                  - shader compiler (WIP)
                  - threading (command submission is in separate thread on r300g, not sure about r600g)
                  - memory manager heuristics (this is what would probably help with buffer migration)
                  - adaptive load balancing
                  - adaptive memory reconfiguration

                  BTW I don't think Marek is saying "we've known this for 4 years", I think he's saying "I just looked recently and the problem with these specific applications seems to be buffer migration".

                  If the developers believed that one single issue was responsible for most of the performance differences then I think it's pretty safe to assume they would be all over it, but I don't think that is the case.

                  Some apps (typically the very slowest) may have one single issue that contributes most of the slowdown RELATIVE TO OTHER APPLICATIONS but that's not the same as saying one single issue contributes to most of the performance gap between the open source stack and the Catalyst stack.
                  All I'm saying is: Likely a bunch of different applications (like in Michael's benchmark, or a subset of them) exhibiting the same performance gap *factor* would likely mean a common root cause. This would be a constant and systematic driver behavior.

                  I might be wrong!

                  Originally posted by bridgman View Post
                  Some apps (typically the very slowest) may have one single issue that contributes most of the slowdown RELATIVE TO OTHER APPLICATIONS but that's not the same as saying one single issue contributes to most of the performance gap between the open source stack and the Catalyst stack.
                  Yes, this is what benchmarking is all about. The goal is to exercise the stack and detect isolated vs. generalized performance issues.

                  Originally posted by bridgman View Post
                  - tiling (mostly done AFAIK)
                  - hyper-z (started)
                  - shader compiler (WIP)
                  - threading (command submission is in separate thread on r300g, not sure about r600g)
                  - memory manager heuristics (this is what would probably help with buffer migration)
                  - adaptive load balancing
                  - adaptive memory reconfiguration
                  Would love to see all these featured in the kernel/mesa!

                  Regards,
                  -Ilyes

                  Comment


                  • #24
                    Hi Marek,

                    Originally posted by marek View Post
                    The reason is simple - there is a lack of manpower. I myself won't have time to do anything big until February.

                    I think the issue with TTM was there all long, we just didn't know it has such an impact. Since we started enforcing VRAM buffer placements, we've seen both great improvements (because of faster access to VRAM) and terrible regressions in perfomance (because of TTM when we start running out of memory).
                    Is there any way to trace TTM's allocations and visualize the dynamics (such as via a tool, in real-time)?

                    -Ilyes

                    Comment


                    • #25
                      Originally posted by marek View Post
                      The reason is simple - there is a lack of manpower. I myself won't have time to do anything big until February.

                      I think the issue with TTM was there all long, we just didn't know it has such an impact. Since we started enforcing VRAM buffer placements, we've seen both great improvements (because of faster access to VRAM) and terrible regressions in perfomance (because of TTM when we start running out of memory).
                      We have bug in bugzilla or thread in maillist?

                      Comment


                      • #26
                        Originally posted by ilyes View Post
                        Is there any way to trace TTM's allocations and visualize the dynamics (such as via a tool, in real-time)?
                        No, there isn't.

                        Originally posted by stalkerg View Post
                        We have bug in bugzilla or thread in maillist?
                        We have bug reports that some apps are too slow.

                        Comment


                        • #27
                          Originally posted by ilyes View Post
                          Would love to see all these featured in the kernel/mesa!
                          It's a community developed driver, more contributors would be welcomed.

                          Comment


                          • #28
                            Originally posted by stalkerg View Post
                            We have bug in bugzilla or thread in maillist?
                            I am following the mesa-dev list. Jerome has tried a few heuristics without positive results:
                            http://lists.freedesktop.org/archive...er/029834.html

                            The issue with radeon performance is clearly a serious lack of developers imho. The AMD guys are only doing basic stuff, and even there they can't manage to have a working driver in time. So what remains are Marek and Jerome contributing as time allows...

                            Comment


                            • #29
                              Originally posted by marek View Post
                              No, there isn't.


                              We have bug reports that some apps are too slow.
                              IMHO need some documentation or ticket for TTM heuristics.

                              Comment


                              • #30
                                Originally posted by Beve3rly
                                I could write some more about it. Maybe even a full-blow essay. Unfortunately I am not a good writer, so I will let it be in my mind.
                                That would be amazing! And it is very difficult to understand the code.

                                Comment

                                Working...
                                X