Announcement

Collapse
No announcement yet.

AMD Radeon Gallium3D More Competitive With Catalyst On Linux

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

  • #31
    It would be really great if Michael could maintain a dynamic feature table comparing all the available linux open and closed graphic drivers

    Comment


    • #32
      As an owner of a 6870 (on the desktop), I really can't muster the enthusiasm to care about the discrepancies.

      So if I played Doom 3 (which I won't until it comes to Steam), I get highly playable framerates even on the open source driver. If I'm running 60FPS on open source then I'll stick to that. And that's just about the most demanding game on Linux that I want to play. At the moment I'm actually just playing Half Life.

      If I were playing Crysis 3 on Linux, then a decision would have to be made, and I'd probably choose Catalyst (or buy an Nvidia card). But, as it is, there's absolutely nothing on Linux that requires the power and advanced OpenGL features which the closed source driver brings.

      Comment


      • #33
        Some Steamgames benchmarks would be awesome.

        Comment


        • #34
          Originally posted by pingufunkybeat View Post
          this could be an amazing year for AMD users!
          Nope. No HD7000 support.

          Comment


          • #35
            Originally posted by Calinou View Post
            Nope. No HD7000 support.
            RadeonSI is working well feature wise. You can run games from this benchmark run on RadeonSI.

            (And Michael probably saved them for bigger page hit number 7xxx test will generate :P, not that current test can be considered "small")


            PS I wanted to say class-DX10. As is hw that is mandated by DX10.

            Comment


            • #36
              Dynamically checking mesa features

              Originally posted by Michael View Post
              texture-float was passed when building Mesa and S2TC is present by default in Ubuntu (sure wish there was a way to automatically parse the Mesa build configuration of the resulting binaries; similar to gcc -v, so that the information could be presented...)
              Michael,

              You can check at runtime for S3TC by looking for the GL_S3_s3tc extension in glxinfo and Floating Point textures is reported by the ARB_texture_float extension. I found this when I was creating a GTK version of glxinfo

              https://code.google.com/p/gtk-glxinfo/

              Kevin

              Comment


              • #37
                I am very happy with these benchmarks, the opensource drivers are gaining on the closed ones.

                Comment


                • #38
                  Originally posted by Drago View Post
                  He probably meant DX11 features, which could be back-ported on DX10 class hardware.
                  Maybe I am not understanding this right, but the HD5750 is D11 hardware.

                  It one of the reasons I bought one, when Aliens vs Predator 3 was released.

                  Comment


                  • #39
                    Originally posted by kdekorte View Post
                    Michael,

                    You can check at runtime for S3TC by looking for the GL_S3_s3tc extension in glxinfo and Floating Point textures is reported by the ARB_texture_float extension. I found this when I was creating a GTK version of glxinfo

                    https://code.google.com/p/gtk-glxinfo/

                    Kevin
                    Hosted on OpenBenchmarking.org are all the system logs including the glxinfo and people are allowed to go scan those manually, but doesn't make sense to overload the UI with all sorts of GL extensions by default, but a simple build configuration line would be convenient.
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #40
                      Originally posted by Michael View Post
                      Hosted on OpenBenchmarking.org are all the system logs including the glxinfo and people are allowed to go scan those manually, but doesn't make sense to overload the UI with all sorts of GL extensions by default, but a simple build configuration line would be convenient.
                      glxinfo is OSS right? I'm just guessing but i think it is open source. Have you ever looked at the code to see what it would take to make it do what you need?

                      Comment


                      • #41
                        Originally posted by Michael View Post
                        Hosted on OpenBenchmarking.org are all the system logs including the glxinfo and people are allowed to go scan those manually, but doesn't make sense to overload the UI with all sorts of GL extensions by default, but a simple build configuration line would be convenient.
                        You wouldn't have to overload the UI with all the extensions, just the ones that are in question from time to time (Eg: they may not ALWAYS be available.) and those two would only be s3tc and texture_float which you could capture by running glxinfo | grep "s3tc" ; glxinfo | grep "texture_float."

                        I completely agree on not declaring EVERY extension that's loaded, but having those 2 explicitly checked and declared would be nice

                        Comment


                        • #42
                          Originally posted by Ericg View Post
                          You wouldn't have to overload the UI with all the extensions, just the ones that are in question from time to time (Eg: they may not ALWAYS be available.) and those two would only be s3tc and texture_float which you could capture by running glxinfo | grep "s3tc" ; glxinfo | grep "texture_float."

                          I completely agree on not declaring EVERY extension that's loaded, but having those 2 explicitly checked and declared would be nice
                          For anyone interested in seeing changes, patches always welcome. Particularly if anyone wants to clean-up and make nice information around what I already started with this: http://www.phoronix.com/scan.php?pag...tem&px=MTA5MDM
                          Michael Larabel
                          http://www.michaellarabel.com/

                          Comment


                          • #43
                            Originally posted by ModplanMan View Post
                            Interesting that the 6450 in particular has some anomalies. Anyone possible reason why?
                            Seconded.

                            Otherwise these results are really nice for most parts. Even where it is multiple times behind fglrx the framerate is already playable. It's wonderful to see that project growing. I still remember the times when there was radeonhd which was in the beginning not much more than a slightly better VESA driver. And now we're playing games, having good static PM and better video accel than eve before.

                            Comment


                            • #44
                              Yep, please investigate the 6450. Not only did it beat Catalyst, it beat more powerful cards in many tests.

                              Comment


                              • #45
                                Originally posted by curaga View Post
                                Yep, please investigate the 6450. Not only did it beat Catalyst, it beat more powerful cards in many tests.
                                Very funny. It's still pwned by an HD 4000 or an A10-5800K's IGP; if you needed to upgrade from an older graphics card, just pick a 6950 which seems to work well with the open source driver, it's not that expensive now.
                                Last edited by Calinou; 04-19-2013, 09:48 AM.

                                Comment

                                Working...
                                X