Announcement

Collapse
No announcement yet.

R500 Mesa Is Still No Match To An Old Catalyst Driver

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

  • #21
    Originally posted by bash View Post
    Is there any general idea when the end-user can start seeing the sorts of improvements everyone is crying/waiting for? Is there a change faster 3d accel is coming this year? Or more likely next year? Or even after? (But before 2012 as we all know the world ends then)
    Significantly faster 3D is probably still a year away. I think right now there is still a lot more focus on getting things working - evergreen acceleration, power management, more glsl support in the compiler, and they're still trying to work through the remaining issues caused by the big TTM/KMS/Gallium changes. Then they've got to port the r600 driver over to gallium as well. People will be working on performance in the meantime, but I doubt it will really be focused on until the drivers mature a bit more.

    Comment


    • #22
      Originally posted by Pickup View Post
      We were told it was almost impossible to write good drivers with no specifications. Then, 3 years ago, AMD released the specs. Thank you, AMD.
      Three years passed. More specs were released. Developers worked very hard on them. Thank you all, developers.

      But the open driver still does not break the 30fps wall.

      "with Gallium everything will boost to the stars!" we are told. Maybe. But Gallium has been around for a while, and... (i'm keeping my ears shut...)
      Uh, the softpipe Gallium3D driver has been around for a while- the R300 driver's still in it's infancy and still has a bit yet to go for development purposes. Moreover, Gallium3D is fairly similar in nature to what the Big 2 do (having worked for one of them in the distant past...)- but it takes LOADS of time to get this stuff right. Stream processing of this nature isn't simple or easy down at the device programming level of things. Having specs makes it possible to do without wasting efforts on reverse engineering like the Nouveau team have had to do.

      Eventually the driver will be within 60-70% of fglrx' peak- but it's still a while out.

      Comment


      • #23
        Originally posted by bridgman View Post
        Fair question, but the thing to remember is that developer efforts have been divided between improving "user visible" support (using the hardware specs) and re-architecting the lower levels of the driver stack (KMS, GEM/TTM, DRI2, Gallium3D etc...), with more than half of the effort over the last 2 years going into re-architecture work.
        Heh... I'd suspected that was where all the time was spent on things.

        What you had 2 years ago was basic drivers on a relatively old architecture which was limiting both performance and functionality (eg GL support was capped at 1.x). What you have today is equally basic drivers running on a significantly improved architecture. The drivers aren't much faster than they were 2 years ago (heck, they're slower in some cases), and you could argue that the code is even less mature in some ways, but the work that *has* been done over the last couple of years was a pre-requisite to the kind of functionality and performance that users want to see.

        From an end-user perspective it looks like "gee, after 2-1/2 years they're finally at GL 2 and even that is still buggy", but what really happened was more like 2 years of rearchitecture work that didn't give you *any* visible benefits plus a big spurt of progress in the last 6 months built on the previous 2 years of behind-the-scenes work.
        Folks, Mr. Bridgman is telling you the full ands straight truth on this. Keep telling yourself this over and over again. Yes, it's not helping right now. But it'll actually pay off. I'll say it again- it's neither simple nor easy and there's a lot of pain, suffering, and time that've been put into those closed source drivers the Big 2 have.

        We're putting in our pain, suffering, and time right now...it'll pay off later

        Comment


        • #24
          Actually

          It's 2010.

          Here in lies the same arguments/excuses:

          1. Volunteer developers.
          2. Not enough time outside day job.
          3. It's only a matter of time.

          I think we should quit buying into the hysterical belief that OSS versions of the drivers will ever be as good as the Paid Development Versions.

          There are patented algorithms. I remember wasting a lot of time waiting for the Intel crew to get their act together. 2006-2010. For three years I waited for a marginal increase in 3D performance on my I945GM.

          N/M

          Comment


          • #25
            It's not "paid development" that makes the difference - there are paid developers working on the open source drivers as well.

            The difference is "proprietary code sharing across 100% of the PC market where the number of paid developers is a function of the size of the entire PC market" vs "Linux-specific development where the number of paid resources is roughly tied to Linux market share".

            Bottom line is that the 3D stack is larger and more complicated than the 2D/video stack, so even though the same developers have manged to give a 2D/video experience that is often *better* than what you get from the proprietary drivers that won't be so easy on the 3D side. Right now open source 3D performance averages maybe 30% of what the proprietary drivers give - it seems likely that can get to maybe 60-70% on average which you'll probably find to be fast enough.

            Note that the Intel open source devs went through all the same rearchitecture efforts, and were leading the way on some of them, so they were dealing with all the same constraints I described above.

            There is no proprietary Linux driver to use as a reference on the Intel side, but my understanding was that the Intel open source devs were coming pretty close to Windows performance already on the same hardware (minus any slowdowns that happened during the move to KMS, which I think are being addressed or have been already).

            I guess the key point is that none of the open source devs have been doing much performance work in the last few years since any work they did would have been thrown away after moving to the new stack. Now the transition is more or less finished I think you'll see performance work happening this year.
            Test signature

            Comment


            • #26
              Originally posted by homerhomer View Post
              Recently I upgrade to the latest 10.04 beta and I've noticed that the OSS radeon driver is slower than it was with 9.10 /w xorg-edgers updates. I'm just happy the suspend is working correctly. I know that glxgear is not a bench, but I went from 5500 to 2500.
              Note that 10.04 uses KMS by default whereas 9.10 didn't, which probably accounts for the difference. Try booting 10.04 with "nomodeset" to run the old non-KMS path.

              BTW, suspend is broken for me in 10.04 (RV515/M26) unless I upgrade to a 2.6.34 kernel.

              Comment


              • #27
                Originally posted by squirrl View Post
                It's 2010.

                Here in lies the same arguments/excuses:

                1. Volunteer developers.
                2. Not enough time outside day job.
                3. It's only a matter of time.

                I think we should quit buying into the hysterical belief that OSS versions of the drivers will ever be as good as the Paid Development Versions.

                There are patented algorithms. I remember wasting a lot of time waiting for the Intel crew to get their act together. 2006-2010. For three years I waited for a marginal increase in 3D performance on my I945GM.

                N/M
                2D and video is FAR superior in open drivers. They are also ALOT more stable. And they are free (libre).

                Already better IMO.

                Comment


                • #28
                  Originally posted by yesterday View Post
                  2D and video is FAR superior in open drivers. They are also ALOT more stable. And they are free (libre).

                  Already better IMO.
                  Yes, in your opinion. Faster 2D in the open source drivers is in everybody's mouths, but I'm yet to see it, empirically by myself or from synthetic benchmarks. Speaking of which, in the "Catalyst vs Mesa" round from barely two weeks ago, Catalyst was well ahead of Radeon in 2 out of 4 GtkPerf tests, loosing in one of them and tying in the other. The same goes for video playback, I had no problems with Fglrx or Radeon, and the same benchmarks suggest a difference in CPU usage of ~2%. "Far superior" to Fgrlx is not how I would define the state of the open driver in these areas. Stability is difficult to measure; it's true that by installing Radeon I had suspend back (yay), and I can switch to VTs without experiencing lockups. On the other hand, I do get random lockups with the newest driver, while I used Fgrlx for over a year without any issues (as long as I didn't try to suspend).

                  Add to this the still being worked out but not ready yet power management features and the 3D performance differences, and one finds it difficult to qualify Radeon as already better than Fgrlx. In the not-so-distant future? I hope so.

                  Comment


                  • #29
                    Originally posted by tormod View Post
                    Note that 10.04 uses KMS by default whereas 9.10 didn't, which probably accounts for the difference. Try booting 10.04 with "nomodeset" to run the old non-KMS path.

                    BTW, suspend is broken for me in 10.04 (RV515/M26) unless I upgrade to a 2.6.34 kernel.
                    Note that having KMS support enables the DRI2 paths, which are known to cut gears framerate in half due to the extra memory copy it requires. This is expected behavior, and won't affect any "real" application, or at least not anything running under 2000 fps. Before concluding that the new driver is slower (and it might very well be), please try using it on something else. Like you said, glxgears IS NOT A BENCHMARK.

                    Comment


                    • #30
                      Originally posted by yotambien View Post
                      The same goes for video playback, I had no problems with Fglrx or Radeon, and the same benchmarks suggest a difference in CPU usage of ~2%. "Far superior" to Fgrlx is not how I would define the state of the open driver in these areas.
                      That benchmark used Xv and only looked at CPU usage, not picture quality. This is where radeon is far superior to fglrx. Basiclly Xv is useless with fglrx. Sure with fglrx you can get similar picture quality to radeon if you use GL but that also restricts you in your choice of video player.

                      Comment

                      Working...
                      X