Announcement

Collapse
No announcement yet.

Ubuntu 12.10: Open-Source Radeon vs. AMD Catalyst Performance

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

  • #61
    IMHO AMD should pay more attention to open driver. Learn from Intel, dudes

    I think AMD should learn the lesson from Intel guys who did a really good job with their drivers and consider open driver to be a 1st class citizen. Binary blob is doomed to have a dozens of problems in Linux and will always be very unwelcome and troublesome part of system. So AMD and Nvidia shouldn't get surprised when they lose market share to Intel in this part of market as well. As for, Catalyst has been always causing nasty issues here and there. OTOH opensource driver works very well for me. But it's slower and lacks some features. Most notably, OpenCL and recent OpenGLs.

    Comment


    • #62
      I am going to say something you will not like....

      If we had S3TC support by default, we wouldn't be getting such low framerates, because S3TC uses 1/4 to 1/8 of memory needed for ordinary RGB8/RGBA8 textures. All textures would fit in VRAM and we would get full speed. While we may try to fight back and implement better heuristics, so that more textures can be in VRAM and not in RAM, we will never be able to get close to the performance of Catalyst. 1/8 of used memory also means that only 1/8 of bandwidth is needed.

      So if you want the open driver to be more comparable to Catalyst, get S3TC support.

      There seem to be exceptions though. Reaction Quake prints this: "...ignoring GL_EXT_texture_compression_s3tc" Anybody knows why?

      Comment


      • #63
        Yep, at the cost of quality. And this leads game devs to use 2x the resolution for the S3TC-compressed textures, creating a net zero VRAM change. (512x512 uncompressed to 1024x1024 compressed, for example).

        Not in all cases of course, but this is rather common.

        Comment


        • #64
          Originally posted by marek View Post
          If we had S3TC support by default, we wouldn't be getting such low framerates...
          It thought S2TC compression gave good (not great) results, is open, and is backwards compatible with S3TC, no?

          Could you not just implement S3TC compression interfaces using S2TC by default. This would address the speed concern at a small (perhaps generally unnoticeable loss in quality).

          With interfaces not patentable, could pre-compressed S3TC textures just be passed through for the card to handle [for those apps that provide them / thus no loss in quality in those cases]

          Users who are super concerned about quality and not constrained by patents could turn on the true S3TC library as an alternative (or perhaps the patent would finally be confirmed to be invalid).

          Comment


          • #65
            @marek

            Maybe it is similar to the Doom 3/Id Tech 4 engine that will use uncompressed textures in Ultra quality mode. I could really see the compression artefacts in the bfg variant with all textured precompressed used by the optimizied engine. So from a quality point of view uncompressed looks a bit sharper but of course a normal user would use a lower setting for more speed (often just the default) and get compressed textures anyway.

            Comment


            • #66
              Originally posted by marek View Post
              [...]
              There seem to be exceptions though. Reaction Quake prints this: "...ignoring GL_EXT_texture_compression_s3tc" Anybody knows why?
              yeah, compressed textures are disabled as default in that game.

              Comment


              • #67
                Originally posted by marek View Post
                I am going to say something you will not like....

                If we had S3TC support by default, we wouldn't be getting such low framerates, because S3TC uses 1/4 to 1/8 of memory needed for ordinary RGB8/RGBA8 textures. All textures would fit in VRAM and we would get full speed. While we may try to fight back and implement better heuristics, so that more textures can be in VRAM and not in RAM, we will never be able to get close to the performance of Catalyst. 1/8 of used memory also means that only 1/8 of bandwidth is needed.

                So if you want the open driver to be more comparable to Catalyst, get S3TC support.

                There seem to be exceptions though. Reaction Quake prints this: "...ignoring GL_EXT_texture_compression_s3tc" Anybody knows why?
                Why don't you do like Intel does, and provide S3TC support by default then?

                They do without the S3TC lib, and even provide compression by returning a generic compressed texture instead of S3TC.

                Sure, it's not 100% spec compliant, but it works in 99.9% of games, and isn't that what matters?

                And if Ian Romanick is ok with that for Intel, i'm really surprised the other drivers haven't done the same thing.
                Last edited by smitty3268; 11-04-2012, 01:37 AM.

                Comment

                Working...
                X