Announcement

Collapse
No announcement yet.

AMD R600g Performance Patches Yield Mixed Results

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

  • #31
    Posted in another thread, elaborating on why S3TC is no magic bullet:
    Originally posted by curaga View Post
    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


    • #32
      Intel already enabled S3TC decompression and fake S3TC compression. Eventually mesa could do a further step and natively integrate S2TC.

      Comment


      • #33
        Originally posted by curaga View Post
        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.
        I don't think any game provides 1x textures when used without S3TC and 2x when using S3TC. And anyway 2x S3TC textures looks much better than uncompressed 1x textures.

        Comment


        • #34
          Marek The Man...
          AMD isn't closing down Dresden, they're just making space for Marek to have the whole building for himself ;D

          Comment


          • #35
            So what happens with Xonotic Low Quality vs High Quality on a card with 1GB VRAM? Or with 2GB VRAM?

            Comment


            • #36
              Originally posted by oibaf View Post
              Intel already enabled S3TC decompression and fake S3TC compression. Eventually mesa could do a further step and natively integrate S2TC.
              I wouldn't see this as a step further. S3TC is higher quality, so if S2TC is the fall back compression (in the event that applications have not provided pre-compressed S3TC textures, or the S3TC library has not been installed) then it should be transparent (and developers would always code to S3TC). No need to implement S2TC specifically.

              Comment


              • #37
                Originally posted by Craig73 View Post
                I wouldn't see this as a step further. S3TC is higher quality, so if S2TC is the fall back compression (in the event that applications have not provided pre-compressed S3TC textures, or the S3TC library has not been installed) then it should be transparent (and developers would always code to S3TC). No need to implement S2TC specifically.
                What do you mean? What I suggested was to embed the S2TC algorithm in mesa to provide S3TC extension. It will be transparent to the application, they think it's S3TC, but in reality it's using S2TC algorithm and giving a little lower quality. It's just a convenience alternative to using the external library that was kept separated because of the patent which it's not in S2TC.

                Comment


                • #38
                  Originally posted by oibaf View Post
                  What do you mean? What I suggested was to embed the S2TC algorithm in mesa to provide S3TC extension. It will be transparent to the application, they think it's S3TC, but in reality it's using S2TC algorithm and giving a little lower quality. It's just a convenience alternative to using the external library that was kept separated because of the patent which it's not in S2TC.
                  Just a misinterpretation of what you meant by intel's fake S3TC vs native S2TC... I believe we agree. S3TC decompression is already handled by the card, and the S2TC algorithm implemented in place of S3TC for compression (where pre-compressed textures are not available).

                  [I thought you meant S2TC implemented as a separate extension, which an app would have to be coded to use]

                  Comment


                  • #39
                    Originally posted by Craig73 View Post
                    Just a misinterpretation of what you meant by intel's fake S3TC vs native S2TC... I believe we agree. S3TC decompression is already handled by the card, and the S2TC algorithm implemented in place of S3TC for compression (where pre-compressed textures are not available).

                    [I thought you meant S2TC implemented as a separate extension, which an app would have to be coded to use]
                    Ah, OK, I mean this for fake S3TC compression: http://cgit.freedesktop.org/mesa/mes...49aeb951ba1c57

                    Comment


                    • #40
                      Originally posted by marek View Post
                      No, the performance regression affects everybody, but users without S3TC are likely to run out of VRAM more often.
                      Ahh yes. I hadn't meant to imply that using S3TC made you immune to running out of memory, just less likely to run into the issue.

                      Comment


                      • #41
                        Of course Xonotic is going to be texture starved on a low end 512MB card! they should run it again with a midrage 1GB card, like the 67xx/68xx cards

                        Comment


                        • #42
                          Why not ASTC?

                          Originally posted by marek View Post
                          ....

                          However, we're fighting a battle we can't win. S3TC textures need 4x to 8x less memory and would help a lot with this problem. Any driver with S3TC support has a great advantage over a driver without one.

                          We could also cheat by using the BC7 format for plain RGBA8 textures. That would be a win if we implemented the BC7 encoding on the GPU.
                          Could ASTC be the go-to algo for the texture compression instead of BC7? My understanding is that it's royalty free and a part of the more recent OpenGL specs. IIRC, it's also "better" than S3TC in many respects. If so, could calls for S3TC use be silently made ASTC calls? If not, what makes BC7 a better candidate?

                          Comment


                          • #43
                            I don't think the hardware can do ASTC. BC7 is a good choice, because it has the same compression ratio as DXT5 and it's not encumbered by patents.

                            Comment


                            • #44
                              Originally posted by Lemonzest View Post
                              Of course Xonotic is going to be texture starved on a low end 512MB card! they should run it again with a midrage 1GB card, like the 67xx/68xx cards
                              What's your point? It's performance significantly decreased on the same card, how does it have to do with the graphics RAM amount?

                              Comment


                              • #45
                                Here's some update. We believe the huge performance regression is actually caused by TTM. Put simply, it always synchronizes the CPU with the GPU before a buffer is moved, which is a total performance killer. I think it's a huge mistake that TTM does the synchronization at all, because it's completely unnecessary in our case.

                                Comment

                                Working...
                                X