Announcement

Collapse
No announcement yet.

AMD: GPU Specifications Without NDAs!

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

  • #16
    Originally posted by Thetargos View Post
    Only in this case, it would be a hardware patent, as even if it is an algorithm, it has a hardware component where it runs.
    The big deal would be any software components that would, like in the case of the S3TC situation, would be used to produce the preferred format from other formats- this is the main problem with the DRI drivers when it's distilled down to it's basics. You don't need to worry about the patents if the game uses the already compressed texture sets- the vendor already HAS paid your royalties for that part. It's when you want to use OpenGL to compress the textures for you (Common trick to get the compressed textures, have your driver compress them for you...) is when the S3TC patent becomes a problem for an Open Source driver.

    Comment


    • #17
      Originally posted by Svartalf View Post
      The big deal would be any software components that would, like in the case of the S3TC situation, would be used to produce the preferred format from other formats- this is the main problem with the DRI drivers when it's distilled down to it's basics. You don't need to worry about the patents if the game uses the already compressed texture sets- the vendor already HAS paid your royalties for that part. It's when you want to use OpenGL to compress the textures for you (Common trick to get the compressed textures, have your driver compress them for you...) is when the S3TC patent becomes a problem for an Open Source driver.
      So if I understand you correctly (and this is in fact an issue that really matters to me) is that if the textures are already compressed (like those present in UT'99) in the right format, the hardware will all the same decompress them, despite of the driver (provided the driver knows how to interpret these textures)? can the DRI R200/300 drivers do this?; however if the application requires that the driver (either in the CPU or GPU, but before the textures hit the VRAM) do the compression (dynamic compression?) through the use of the GL_EXT_texture_compression_s3tc | GL_S3_s3tc, is that there'd be a patent issue? Talking about the specific case of S3TC here, dunno if it applies to other portions like Z-compression and/or MPEG decoding or textured video.
      Last edited by Thetargos; 09-12-2007, 02:15 AM.

      Comment


      • #18
        Originally posted by Thetargos View Post
        So if I understand you correctly (and this is in fact an issue that really matters to me) is that if the textures are already compressed (like those present in UT'99) in the right format, the hardware will all the same decompress them, despite of the driver (provided the driver knows how to interpret these textures)? can the DRI R200/300 drivers do this?; however if the application requires that the driver (either in the CPU or GPU, but before the textures hit the VRAM) do the compression (dynamic compression?) through the use of the GL_EXT_texture_compression_s3tc | GL_S3_s3tc, is that there'd be a patent issue? Talking about the specific case of S3TC here, dunno if it applies to other portions like Z-compression and/or MPEG decoding or textured video.
        The patent of S3TC is on the algorithm which do the compression and decompression. I believe this summer someone finished a compressor/decompressor not using the same algorithm so free from the patent issue, so we should see S3TC support soon. Otherwise you can send S3TC texture already compressed to the card even on R300 but you won't be able to fallback to software, anyway you don't want.

        Comment


        • #19
          Well either way, this is a huge help. Will we ever be able to use open source drivers to play games like Doom 3 at decent quality levels? I think so. I don't think we'll ever get as fast as say a proprietary driver. But it will surely avoid the bugs of one and be solid and reliable.

          Mesa will only continue to get better, alternatives to things such as S3TC are coming along by the sounds of it. I am willing to bet we'll be able to play Doom 3 at maybe 1024x768 at medium/high at decent speeds in about a year or two on a open source driver.

          Comment


          • #20
            Originally posted by Thetargos View Post
            So if I understand you correctly (and this is in fact an issue that really matters to me) is that if the textures are already compressed (like those present in UT'99) in the right format, the hardware will all the same decompress them, despite of the driver (provided the driver knows how to interpret these textures)? can the DRI R200/300 drivers do this?; however if the application requires that the driver (either in the CPU or GPU, but before the textures hit the VRAM) do the compression (dynamic compression?) through the use of the GL_EXT_texture_compression_s3tc | GL_S3_s3tc, is that there'd be a patent issue? Talking about the specific case of S3TC here, dunno if it applies to other portions like Z-compression and/or MPEG decoding or textured video.
            Yes, if the textures are already compressed, you can supply them to the card as compressed, using a different OpenGL call. Typically, this is what is done if the card advertises that it supports that compression. If you do this, you don't trip yourself up on the patent as the royalties, etc. have already been paid by the hardware vendor. The same applies for the other issues of concern to you. In the case of S3TC, you just can't compress them from the regular API edge (supplying uncompressed textures to the card and telling it that it's internal representation is compressed with S3TC...) as this would require stepping on the patent until recent times.

            It's not patents preventing the uses of this stuff or technical information being released. It's companies listening to their patent attorney and feeding the general public a line about that. The only thing that would have IP encumbrances would be the proprietary driver- that might well have some 3rd party stuff in it that precludes opening it. That's okay, though, give us enough time- we'll have comparable performance without all that stuff in ours if they give us what they're telling us they're giving.

            Comment


            • #21
              And now (like pretty much every year ever since 3dfx disappeared) I have to wonder: Why didn't FXTC made into widespread adoption? Supposedly it had better compression ratio than S3TC and [MUCH] better quality, it was made open from the get go, and alas, didn't pickup steam. I know of no other cards that support it, other than the V100 Voodoo 4-5 cards of late '99 early 2000.

              Comment


              • #22
                Originally posted by Thetargos View Post
                Why didn't FXTC made into widespread adoption?
                I remember reading that there were possible patent problems with it. It's just a shame that possible patent problems were enough to scare people out of supporting it.

                Comment

                Working...
                X