Page 7 of 7 FirstFirst ... 567
Results 61 to 68 of 68

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

  1. #61
    Join Date
    Jun 2012
    Posts
    239

    Default 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.

  2. #62
    Join Date
    Jan 2009
    Posts
    598

    Default

    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?

  3. #63
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    4,729

    Default

    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.

  4. #64
    Join Date
    Dec 2008
    Posts
    160

    Default

    Quote 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).

  5. #65
    Join Date
    Aug 2007
    Posts
    6,598

    Default

    @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.

  6. #66
    Join Date
    Oct 2007
    Location
    Dresden
    Posts
    53

    Default

    Quote 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.

  7. #67
    Join Date
    Oct 2008
    Posts
    2,908

    Default

    Quote 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 at 01:37 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •