Page 6 of 11 FirstFirst ... 45678 ... LastLast
Results 51 to 60 of 110

Thread: A Possible Workaround For The S3TC Patent Situation

  1. #51
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by droidhacker View Post
    V!NCENT, Jonno: I don't think that you can take Q's statement to be so literal. I think he's more talking about economics than about actual patent law -- if its no good in Germany, its no good in the rest of Europe even if it is kinda legal. Its similar in North America. If its no good in the US, its also no good in Canada, even if it is kinda legal.
    sure thats it.,.. Germany is the economic biggest part in Europe..

    you can't talk its free to use in Europe if the biggest part can't use it.

    Germany overall is the EU pay master if some Greek needs money Germany pay.

    even if Spain needs money to Germany pay. and maybe Italy next.

    pay means give unlimited credit.

    but hey the Germans people do have 10 000 000 000 000 euro... they pay this in cash on hand LOL

    sure they do have owe of 2 000 000 000 000 but how care?

  2. #52
    Join Date
    Jan 2009
    Posts
    466

    Default FXT1 ?

    This announcement makes me wonder why this approach was never attempted with FXT1 (mixed mode) or other open source TC specs.

  3. #53
    Join Date
    Apr 2009
    Posts
    17

    Default

    Quote Originally Posted by Plombo View Post
    S2TC might be a solution for games that ask the driver to compress their S3TC textures for them, but virtually no one does that anymore.

    The vast majority of games compress their S3TC textures in advance and send them to the OpenGL implementation compressed. S2TC doesn't help there.
    This is correct. But, to upload a precompressed texture, you need the OpenGL extension GL_EXT_texture_compression_s3tc, which contains both compressing in the driver, and uploading precompressed textures.

    Basically, the situation is: Mesa currently cannot offer GL_EXT_texture_compression_s3tc because they ONLY support uploading precompressed data. If they added that string to the extensions list, they would violate the spec of the extension and could cause all kinds of incorrectness. With S2TC, they can add GL_EXT_texture_compression_s3tc to their extensions list, and games then detect the extension and can upload their precompressed data - without actually calling S2TC!

    So you are right, in normal use, S2TC wouldn't even be called. It'd mainly serve to fulfill the extension spec of GL_EXT_texture_compression_s3tc, so the driver can claim support for it, which is necessary for applications/games to use it. "S2TC must be there, but it doesn't matter what it does"

    If the OpenGL guys would have put compressing textures, and uploading precompressed data, into two separate extensions, we wouldn't need S2TC now.

    However, there is another thing we can all gain from S2TC: being a worse compression scheme than S3TC, problems in the compressor are more visible. So, I learned many things - and documented them - from writing the S2TC compressor, most of which can be applied to S3TC compressors too. I would bet that, if anyone went there and turned the S2TC compressor into a full S3TC one, it would beat nvidia texture tools, and AMD Compressonator, in quality.
    Last edited by divVerent; 07-20-2011 at 01:40 AM.

  4. #54
    Join Date
    Oct 2008
    Posts
    3,216

    Default

    Quote Originally Posted by divVerent View Post
    With S2TC, they can add GL_EXT_texture_compression_s3tc to their extensions list, and games then detect the extension and can upload their precompressed data - without actually calling S2TC!

    So you are right, in normal use, S2TC wouldn't even be called. It'd mainly serve to fulfill the extension spec of GL_EXT_texture_compression_s3tc, so the driver can claim support for it, which is necessary for applications/games to use it. "S2TC must be there, but it doesn't matter what it does"
    Ahh, that makes sense now. Clever, because most of the time it would just work on the hardware, but in the rare cases it really is needed you can still use the hardware with a lower quality but compatible compression scheme.

    I haven't seen any discussion of this on the mailing list - are you talking with the mesa devs privately?

  5. #55
    Join Date
    Apr 2009
    Posts
    17

    Default

    I currently had no contact to the mesa devs yet.

  6. #56

    Default

    Another simpler solution would be to add a Mesa specific extension for S3TC decompression only, as I suggested some years ago: https://bugs.freedesktop.org/show_bug.cgi?id=24207

  7. #57
    Join Date
    Apr 2009
    Posts
    17

    Default

    And then wait for 5 years till commercial games for Linux start actually checking for it?

    The idea is otherwise not bad.

  8. #58

    Default

    Quote Originally Posted by divVerent View Post
    And then wait for 5 years till commercial games for Linux start actually checking for it?

    The idea is otherwise not bad.
    I think that open source games + wine games (both could support it quite fast) will cover 90%+ of the market.

  9. #59
    Join Date
    Apr 2009
    Posts
    17

    Default

    Still, that suggestion was shot down by the mesa devs mainly for lack of support for software fallbacks, from what I see.

    With S2TC, software fallbacks would work - although at lower quality, if fed S3TC compressed input. Probably still acceptable for most users - if they accept the fallback at all.

  10. #60

    Default

    Xonotic could still implement the hack to force S3TC decompression when using mesa even if S3TC extension is not available, like 0 A.D. do: http://trac.wildfiregames.com/wiki/CompressedTextures

    Obliviously only if it provides precompressed textures.

Posting Permissions

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