Announcement

Collapse
No announcement yet.

A Possible Workaround For The S3TC Patent Situation

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

  • #41
    Originally posted by Qaridarium
    the Europe patent law is similar in all eu countries.
    Actually, it's similar in all EU countries except Germany, which breaks the European Patent Convention (EPC) which explicitly excludes "programs for computers" from patentability...

    (they only get away with it because the only ones who can bring suite for not following a EU Directive is the European Commission, who has tried to introduce software patents twice, which has been voted down by the European Parliament)

    The EPC allows for patents on inventions that includes programming, such as say an industrial robot, but not on the software part itself. So in any jurisdiction with laws that follows the EPC (which, to my knowledge, is all of EU and EEA except for Germany), Mesa 3D, or a software distribution including Mesa 3D, can't infringe on any patents on it's own (though a computer with Mesa 3D pre-installed, or a boxed GPU with Mesa 3D on a driver disc, possibly could, if the patent covers more than just the software, such as for example specialized circuitry on the GPU).

    Originally posted by V!NCENT View Post
    Europe's (read=EU) laws are valid across all of Europe
    Technically, EU don't issue laws, they issue directives to the national parliaments, who issue laws. If a national parliament ignores a directive, the European Commission can then sue that national government for a large on-going fine, which lasts until they either secedes from the union or issue laws implementing the directive (though the commission can obviously choose to ignore the infraction, as with Germany and the EPC). If the national parliament hasn't issued a law, the Directive is not worth the paper it's printed on when you go to court.
    Last edited by Jonno; 19 July 2011, 03:12 PM.

    Comment


    • #42
      Originally posted by Prescience500 View Post
      Why not ask for permission specifically for mesa for Linux and only for mesa for Linux?
      Because there is no such thing!!!
      It still has to be licensed in a way that makes sense FOR mesa, which contradicts the notion of mesa-only since mesa is OPEN licensed.

      You can't be open and restricted like that at the same time. It just doesn't work like that.

      Comment


      • #43
        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.

        Comment


        • #44
          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.

          Comment


          • #45
            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.
            Even sending compressed textures, you have to get an original image, compress it, and store it for later sending to OpenGL in a compressed form. Think editors for a game, rather than the game itself.
            This is of particular interest to myself, but I need to decompress the textures too. Can't rely on the driver for it - well, one can, but it's hideously slow compared to using libtxc_dxtn and some multithreading.

            Comment


            • #46
              Originally posted by plonoma View Post
              Anyone knows when these patents will expire?

              That's really important information.

              You can also just wait until they expire and then implement them.
              I just did some searching and found the patent was published September 21, 1999. (source)
              Assuming that this patent lasts the full 20 years without being invalidated, it'll be around 2019 when it expires. I doubt it'll be of much relevance then.

              Comment


              • #47
                If you IMPLEMENT it after asking and being turned down, they MUST litigate to protect the validity of the patent.
                No that is not how patents work, you can only loose patents by having them invalidated by a court, and that cannot happen due to you letting others use the patent without litigating.

                What you are thinking about it copyright law, if you don't protect your copyright you loose it.

                I just did some searching and found the patent was published September 21, 1999
                Yes but it was filed in 1997 which is the date from which the 20 years should be added so it will expire in 2017.
                Last edited by F.Ultra; 19 July 2011, 07:15 PM.

                Comment


                • #48
                  FXT1 ?

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

                  Comment


                  • #49
                    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; 20 July 2011, 12:40 AM.

                    Comment


                    • #50
                      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?

                      Comment

                      Working...
                      X