Announcement

Collapse
No announcement yet.

GCC 4.5 vs. 4.6 On AMD's FX-4100 Bulldozer

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

  • #11
    Originally posted by DaemonFC View Post
    And every time he benchmarks VDrift, he claims that Mesa is faster because it doesn't handle shaders correctly, and is then corrected by Marek Olsak who obviously knows what Mesa does and doesn't do who tells him that it is Vdrift that is to blame for shaders that shouldn't even compile on standards-compliant OpenGL drivers in the first place.
    He should be running the latest VDrift (2011-09) instead of the one from 2010-06, perhaps that is a lot better. I've taken the old GLSLValidator from 3DLabs and updated it to compile on a "modern" Linux distribution with wxWidgets 2.8. I was planning on running their shaders through that since it only supports up to GLSL1.2. I tested some of their shaders and some of those fragment shaders failed.
    The code/program can be found at https://github.com/AzP/GLSL-Validate/

    Comment


    • #12
      Originally posted by Azpegath View Post
      He should be running the latest VDrift (2011-09) instead of the one from 2010-06, perhaps that is a lot better. I've taken the old GLSLValidator from 3DLabs and updated it to compile on a "modern" Linux distribution with wxWidgets 2.8. I was planning on running their shaders through that since it only supports up to GLSL1.2. I tested some of their shaders and some of those fragment shaders failed.
      The code/program can be found at https://github.com/AzP/GLSL-Validate/
      I only had a few minutes before to look into VDrift 2011 but the source package now for it is only 1MB (it should be several hundred MB), and haven't had the time to look into see what changed or how the VDrift build system was altered.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #13
        Originally posted by Michael View Post
        I only had a few minutes before to look into VDrift 2011 but the source package now for it is only 1MB (it should be several hundred MB), and haven't had the time to look into see what changed or how the VDrift build system was altered.
        You can have a look at the archlinux PKGBUILDS from the repositories. They have version 2011.09.01. Should be quite easy to read and guess what it does. (the source data gets extracted to $srcdir and the files in $pkgdir will end up in the package).
        game binary: http://projects.archlinux.org/svntog...86_64/PKGBUILD
        game data: http://projects.archlinux.org/svntog...y-any/PKGBUILD
        Last edited by ChrisXY; 10-21-2011, 06:12 AM.

        Comment


        • #14
          Originally posted by Michael View Post
          I only had a few minutes before to look into VDrift 2011 but the source package now for it is only 1MB (it should be several hundred MB), and haven't had the time to look into see what changed or how the VDrift build system was altered.
          Yes they split the packages into src and data, and haven't released a data package for it. Sadly they just seem to want to distribute data via svn since their previous version. I've been trying to get them to release a data tar file matching the source release so we can get an updated package in Gentoo, but the devs doesn't reply on IRC. Their channel is just quiet. I've only tried for 2 whole days, but you'd think that somebody would reply.

          There's a bug on the Gentoo bugzilla about it describing the issue furter (https://bugs.gentoo.org/show_bug.cgi?id=351409#c7)

          Comment


          • #15
            Originally posted by Azpegath View Post
            Yes they split the packages into src and data, and haven't released a data package for it. Sadly they just seem to want to distribute data via svn since their previous version. I've been trying to get them to release a data tar file matching the source release so we can get an updated package in Gentoo, but the devs doesn't reply on IRC. Their channel is just quiet. I've only tried for 2 whole days, but you'd think that somebody would reply.

            There's a bug on the Gentoo bugzilla about it describing the issue furter (https://bugs.gentoo.org/show_bug.cgi?id=351409#c7)
            I'll check with the main developer when I have the time. Last I knew I even had SVN commit access to VDrift from when I was doing the benchmark mode for it, so hopefully he will listen.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #16
              Cool, perhaps he can comment on the bug in bugzilla if he gets time. It's sad to have a release that's one and a half years old in portage when they've done two of them since.

              Comment


              • #17
                New entry in the openbenchmarking database, with kernel 3.1, GCC 4.5: normalized result compared to the article's data
                Only C-Ray is tested, though apparently a 27% boost. Is Bulldozer the only CPU getting such improvement?

                Comment


                • #18
                  Originally posted by PsynoKhi0 View Post
                  New entry in the openbenchmarking database, with kernel 3.1, GCC 4.5: normalized result compared to the article's data
                  Only C-Ray is tested, though apparently a 27% boost. Is Bulldozer the only CPU getting such improvement?
                  What compiler and compiler options were used? It really does matter!

                  From what I've seen until now, only Bulldozer-based CPUs get a hefty performance boost with new kernels and compilers which makes perfectly sense. It's an entirely new architecture and quite a big step from the previous one as well everything else that's been around until now.

                  Most notable peculiarities of the Bulldozer module-design are the shared early pipeline stages, L1 instruction and L2 caches. Without OS kernels and compilers take into account and optimizing for this new design they will be inherently crippling the module and turning the per-module performance into closer to single rather than 1.5-2 core performance.

                  Comment


                  • #19
                    Originally posted by pszilard View Post
                    What compiler and compiler options were used? It really does matter!

                    From what I've seen until now, only Bulldozer-based CPUs get a hefty performance boost with new kernels and compilers which makes perfectly sense. It's an entirely new architecture and quite a big step from the previous one as well everything else that's been around until now.

                    Most notable peculiarities of the Bulldozer module-design are the shared early pipeline stages, L1 instruction and L2 caches. Without OS kernels and compilers take into account and optimizing for this new design they will be inherently crippling the module and turning the per-module performance into closer to single rather than 1.5-2 core performance.
                    Column On Left > Result File Information (at bottom of column) > Click > Click System Information > cc output. e.g. http://openbenchmarking.org/system/1...GCC%204.5.2/cc among other data from that area
                    Michael Larabel
                    http://www.michaellarabel.com/

                    Comment


                    • #20
                      Originally posted by Michael View Post
                      Column On Left > Result File Information (at bottom of column) > Click > Click System Information > cc output. e.g. http://openbenchmarking.org/system/1...GCC%204.5.2/cc among other data from that area
                      Thanks, still haven't taken the time to figure out the OpenBenchmarking.com interface, it might be only me, but I find it a little confusing...

                      Btw, the CC info lines (most notably the "Configured with" line) are not wrapped which makes it unreadable unless copy-pasted out...

                      Comment

                      Working...
                      X