Announcement

Collapse
No announcement yet.

ATI R300: Open v. Closed Drivers

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

  • ATI R300: Open v. Closed Drivers

    We at Phoronix have just finished up comparing the open-source R300 display drivers against the fglrx drivers -- similar to our R200 article that coincidently came out five months ago to the day. Our comparison can be found @ http://www.phoronix.com/vr.php?view=7481

    Feel free to discuss the R300 drivers in this thread. If you are also interested in any other performance metrics or information, just ask.

    Some X800 open v. closed results will likely wrap up soon.
    Michael Larabel
    http://www.michaellarabel.com/

  • #2
    Thanks! Just read the review, it'll be helpful in the future.

    I'm curious about one thing though.......

    Towards the end of the review you mentioned that "The image quality was also noticeably better with the fglrx drivers."

    What did you mean by that? Did you get horrible video artifacting on screen? Or was it more subtle... colors blending better using ATI's drivers?

    Screenshots might be helpful, but unnecessary. Thanks for all you do.

    Comment


    • #3
      The fglrx drivers seemed to present a greater level of detail/clarity and colors. There really wasn't much artifacting with the R300 drivers in ET and UT2k3. Screenshots will likely be presented when additional R300 tests occur.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        I'm not suprised by the differences in performance.

        Not to bad I guess considering that they had to be reverse engineered completely. I would expect that there would be some OpenGL extensions missing that would account for a lot of the differences. Just guessing.

        It'll be interesting to see how they are able to do with the Intel X3000 in comparision.

        The sad part about it is that these cards seem to have a much shorter lifespan then the r200 stuff. The way the pricing goes they aren't aviable and the ones that are aviable are not much cheaper then the mostly superior R500 series cards.. of which I haven't even heard of the faintest tinkling of in regards to free software drivers.

        Oh well.

        Comment


        • #5
          The numbers aren't too surprising although I'd like to request that images be also posted for Image Quality comparison.

          I'm actually quite impressed with how the open source drivers did in the benchmark.

          Michael, would it be possible to benchmark the open source driver against as many ATi cards as there are in your test labs? I think it would give readers a good idea which graphics card would be their best bet if they are to forego fglrx for open source drivers.

          Comment


          • #6
            I am trying out that railgun demo.

            I think I have to be doing something wrong here. So this is what I do..
            I go and set the video mode. Maybe something like the default 'normal' mode with it at 800x600.

            Then I go into the console and type:
            timedemo 1
            demo railgun

            Alright then I get a final score of 38-39FPS... on every single video setting.
            From 800x600 on normal to setting it to 'high' and running it at 1600x1200.

            The only way I can get it to increase is to disable dynamic lighting.. then it goes to 44-45 on every single resolution.

            I guess I am hitting a cpu limitation or whatnot.

            Comment


            • #7
              nt, double post mistake
              Last edited by drag; 10-06-2006, 08:49 PM.

              Comment


              • #8
                Originally posted by niniendowarrior View Post
                Michael, would it be possible to benchmark the open source driver against as many ATi cards as there are in your test labs? I think it would give readers a good idea which graphics card would be their best bet if they are to forego fglrx for open source drivers.
                When time allows we can probably run benchmarks on all major R300/400 components.

                Originally posted by drag View Post
                R500 series cards.. of which I haven't even heard of the faintest tinkling of in regards to free software drivers.
                Correct, no open-source R500 drivers at this time. Hopefully early next year we will see some open-source X1k drivers in some form.

                Originally posted by drag View Post
                I am trying out that railgun demo.

                I think I have to be doing something wrong here. So this is what I do..
                I go and set the video mode. Maybe something like the default 'normal' mode with it at 800x600.

                Then I go into the console and type:
                timedemo 1
                demo railgun

                Alright then I get a final score of 38-39FPS... on every single video setting.
                From 800x600 on normal to setting it to 'high' and running it at 1600x1200.

                The only way I can get it to increase is to disable dynamic lighting.. then it goes to 44-45 on every single resolution.

                I guess I am hitting a cpu limitation or whatnot.
                What are your system specs? It could very well be a CPU bottleneck.
                Michael Larabel
                http://www.michaellarabel.com/

                Comment


                • #9
                  What are your system specs? It could very well be a CPU bottleneck.
                  At the time it was a dual core with one of the cores disabled (for other reasons nothing to do with the machine) but with it dual core it doesn't make a difference (I tried it to make sure, but obviously since the game is single threaded)

                  model name : Intel(R) Pentium(R) D CPU 2.80GHz
                  stepping : 2
                  cpu MHz : 2800.553
                  cache size : 2048 KB

                  1 gig of 533 DDR2 RAM (I beleive it's 533, don't remember for sure.)
                  945g chipset.
                  Gigabyte x800 with 256megs of RAM.

                  Comment


                  • #10
                    Hello, this is my first post here. First of all, I have to say it's a pretty interesting article.

                    However, I have one question : you seem to have used the default r300 ubuntu packages. These packages are compiled using the default Mesa optimizations options, which use -O. Would you mind testing again with a home-compiled version of r300 using, say, -O2 ? You have to get the Mesa tree for that, and touch the config/linux-dri target. I would expect that to make a difference.

                    Comment


                    • #11
                      Welcome to the forums.

                      The packages used were the latest for Edgy Eft.

                      I'll compile the drivers with the argument you mentioned when time permits and see how things change.
                      Michael Larabel
                      http://www.michaellarabel.com/

                      Comment


                      • #12
                        I doubt you'd see much of a difference, I've tried playing around with compile options and it's almost unnoticable. Not that I used any scientific benchmarks or anything.

                        Check out http://dri.freedesktop.org/wiki/Building

                        It'll tell you how to compile sources from CVS. In my experiance the cvs drivers offer better performance then standard stuff. Although that may just be because I am using a x800 card and the default distro drivers that I had installed at the time failed to accurately identify it and treated it as a generic r300 card rather then use any device-specific optimizations or features.

                        Also for best stability it may be wise to compile the kernel drm .ko modules for the kernel.

                        For the packaged software for the librm I did:
                        configure --prefix=/usr --exec-prefix=/usr

                        And for the Mesa stuff I copied the libGL stuff over the existing Debian package supplied software in /usr/lib

                        That way I didn't have to mess around with any Debian packaging stuff or ldconfig tricks and everythign works fine. The only snafu is that applications look for the *_dri.so files in the old monolythic X.org spot, so I setup a symbolic link to those from were the *_dri.so drivers are installed by default and that works fine.


                        edit:

                        Also it's nice to keep the source code tree relatively prestine so you don't have to worry about any compile stuff getting mixed up with the cvs tree which you may want to update time to time when you feel like compiling new drivers.

                        To do that you can use lndir.. You go like this..
                        Say you have ~/sources/Mesa
                        so you can go:
                        cd ~/sources
                        mkdir -p build/Mesa
                        cd build/Mesa
                        lndir ../../Mesa

                        and it should make a duplicate directory structure for you.
                        Last edited by drag; 10-09-2006, 08:42 PM.

                        Comment


                        • #13
                          Originally posted by marcheu View Post
                          However, I have one question : you seem to have used the default r300 ubuntu packages. These packages are compiled using the default Mesa optimizations options, which use -O. Would you mind testing again with a home-compiled version of r300 using, say, -O2 ? You have to get the Mesa tree for that, and touch the config/linux-dri target. I would expect that to make a difference.
                          I've been thinking about this a bit. I suspect that the biggest performance difference on ET is r300's lack of acceleration for compiled vertex arrays. All Quake 3 based games make heavy use of this extension to reduce the geometry transfer load. It's only my todo list to add a generic acceleration path in Mesa for compiled vertex arrays for drivers that support buffer objects.

                          Of course, none of that will help the UT performance, and we really get spanked there...

                          Comment

                          Working...
                          X