Announcement

Collapse
No announcement yet.

AMD Releases Cayman Documentation, Open Driver Is Close

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

  • #61
    Jerome,
    What is stopping S3TC being implemented for r600g, except patent stuff. I mean is it clear from technical point of view(described in the documentation) how to use it on >=R600 chips.

    Comment


    • #62
      Originally posted by glisse View Post
      It seems you are confusing things
      Sry, but I think you're the one confusing things.

      Originally posted by glisse View Post
      mipmap & st3c compressed texture are too different orthogonal things
      I don't know what you mean by orthogonal (since we lack a scalar product here *g*), but compressed textures are not limited to one base level, but can of course have mipmap levels. And that's what I'm taking about here:
      Texture compression (BC1, BC2 and BC3 tested) works (see (*)) in r600g for the texture base level. Something goes wrong for the mipmaps and these are rendered incorrectly. You can see this e.g. in quake4, for which texture compression support is mandatory. Disable mipmaps via r_textureMode and everything looks fine (apart from the aliasing artifacts). The same applies to ut2004 which can optionally use texture compression. Near textures are rendered fine, but as soon as mipmaps are used farther away the rendering is broken.

      (*) For this to work at all you have to:
      1) Enable the R600_ENABLE_S3TC envvar
      2) Patch the CS checker for ignore texture checks (otherwise all commands are rejected because of invalid texture formats)

      Originally posted by glisse View Post
      mipmap works and all gl test using mipmap that we have prove it works
      Obviously they don't work for compressed texture formats.

      Originally posted by glisse View Post
      We don't support st3c or any kind of texture compression.
      And I never said you did. The only thing I'm doing here is some testing and fiddling around with the code. I very much _know_ that the support isn't there. Otherwise we wouldn't have this experimental envvar, right?


      Originally posted by glisse View Post
      In your bugs it's unclear wether you tried to force st3c adevertising or not, doing so might broke the driver as we don't support st3c texture yet.
      Wait, wait! This is _not_ my bug, ok?
      And actually it's pretty clear what I did. In comment #2 I described that I enabled the envvar that enables texture compression advertising. And I also describe that this makes the CS checker angry. Then in comment #4 I describe that I get 'partial' results by disabling the texture check in the CS checker.
      What is unclear for you now?

      Originally posted by glisse View Post
      Also quake4 might be doing something uncommon/out of normal GL spec with mipmap.
      I don't think so. This is a ID Tech engine after all

      Comment


      • #63
        Why not use BTC or AMBTC? It from the 70's. You're not going to tell me that that's still patented, are you?

        Comment


        • #64
          Originally posted by V!NCENT View Post
          Why not use BTC or AMBTC? It from the 70's. You're not going to tell me that that's still patented, are you?
          Probably because it needs to be supported by hardware.

          Comment


          • #65
            Originally posted by Drago View Post
            Probably because it needs to be supported by hardware.
            I thought GPUs were totaly generic these days? Except UVD...

            Comment


            • #66
              Originally posted by glisse View Post
              GL3 or 4 are not a no go, we will have 99% (% top of my head where 1% is patented stuffed) of it advertised through appropriate extension. Question will be do we advertise GL version 3 or 4 without the patented stuff and throw glerror to program trying to use those, or do we go another way.
              "1% is patented stuffed"
              you're referring to for instance this S3TC algorithm everyone keep's bringing up right ?

              if there's a patent on a given algorithm, then why dont you/mesa just write and use another algorithm that provides the same functionality and is OSS compliant ?

              its clear that for instance the FFmpeg version that does so called DXT1 and DXT3 but not DXT5 as yet (as no one's bothered to write that code yet, and the S3TC entry is old too, so get to it and make it better ) see:
              http://ffmpeg.org/doxygen/0.5/s3tc_8h-source.html and


              is fine to use as your base today and its not even an algorithm as such but using different parts of the ffmpeg code base to simply provide the encode/decode bit exact input/output as required by the standard, with no algorithm patent problems to date.

              Comment


              • #67
                Originally posted by LiquidAcid View Post
                Sry, but I think you're the one confusing things.


                I don't know what you mean by orthogonal (since we lack a scalar product here *g*), but compressed textures are not limited to one base level, but can of course have mipmap levels. And that's what I'm taking about here:
                Texture compression (BC1, BC2 and BC3 tested) works (see (*)) in r600g for the texture base level. Something goes wrong for the mipmaps and these are rendered incorrectly. You can see this e.g. in quake4, for which texture compression support is mandatory. Disable mipmaps via r_textureMode and everything looks fine (apart from the aliasing artifacts). The same applies to ut2004 which can optionally use texture compression. Near textures are rendered fine, but as soon as mipmaps are used farther away the rendering is broken.

                (*) For this to work at all you have to:
                1) Enable the R600_ENABLE_S3TC envvar
                2) Patch the CS checker for ignore texture checks (otherwise all commands are rejected because of invalid texture formats)


                Obviously they don't work for compressed texture formats.


                And I never said you did. The only thing I'm doing here is some testing and fiddling around with the code. I very much _know_ that the support isn't there. Otherwise we wouldn't have this experimental envvar, right?



                Wait, wait! This is _not_ my bug, ok?
                And actually it's pretty clear what I did. In comment #2 I described that I enabled the envvar that enables texture compression advertising. And I also describe that this makes the CS checker angry. Then in comment #4 I describe that I get 'partial' results by disabling the texture check in the CS checker.
                What is unclear for you now?


                I don't think so. This is a ID Tech engine after all
                I will make it crystal clear for you, provide a simple GL test program showing the issue with mipmap and no texture compression (ie something like RGB888 texture) and we will fix it. In all GL apps i use mipmap are working fine and i don't see any issue. You really need to be specific and to clearly shows the issue which you are not doing.

                Comment


                • #68
                  Originally posted by glisse View Post
                  I will make it crystal clear for you, provide a simple GL test program showing the issue with mipmap and no texture compression (ie something like RGB888 texture) and we will fix it.
                  There is no such issue. Read my post again.

                  Comment


                  • #69
                    Originally posted by glisse View Post
                    I will make it crystal clear for you, provide a simple GL test program showing the issue with mipmap and no texture compression (ie something like RGB888 texture) and we will fix it. In all GL apps i use mipmap are working fine and i don't see any issue. You really need to be specific and to clearly shows the issue which you are not doing.
                    I think he was pretty clear the issue only appears WITH texture compression, not without it. He also understands that Red Hat has no interest in fixing texture compression, which is why he's looking into the code in the first place.

                    Comment


                    • #70
                      Originally posted by LiquidAcid View Post
                      There is no such issue. Read my post again.
                      i have to agree with glisse here, it seems simple enough, whatever the problem is that you are referring to , then provide a way to show this problem and tell them

                      it seems you are a dev and so can provide a simple GL test program as requested, and if your not a dev and looking for support then at least describe the exact steps you took to see this problem you want fixed.

                      without that, you're just going around in circles and wasting time.

                      Comment

                      Working...
                      X