> In this situation, the DXTn (S3TC) related agorithms were all implemented and > used outside of the > Mesa body and as far as I can see, nothing of the patent applies here.
Petr, You're assuming that the IHV licensed the S3TC patent for all uses of their hardware. Although NVIDIA appears to have done so (per http://code.google.com/p/nvidia-texture-tools/wiki/FAQ), other vendors may have not: the S3TC patent is often licensed to be used only on particular platforms. driver stacks, or use cases. Enabling S3TC decompression on hardware for which IHV does not have a license covering Linux OS and Mesa driver stack may lead to S3 suing somebody -- the developer, the user, the linux distribution, or the hardware vendor -- typically whoever has the deepest pocket. So although it _appears_(*) to be safe to enable S3TC decompression on NVIDIA GPUs, there is no reason to think that of AMD, or Intel GPUs. Jose (*) I am not a lawyer. ________________________________________ From: mesa-dev-bounces+jfonseca=vmware....@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware....@lists.freedesktop.org] On Behalf Of Petr Sebor [p...@scssoft.com] Sent: Saturday, March 19, 2011 11:24 To: Henri Verbeet Cc: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression? On 18.3.2011 16:50, Henri Verbeet wrote: On 18 March 2011 14:19, Petr Sebor <p...@scssoft.com><mailto:p...@scssoft.com> wrote: I know that at least our games would benefit from this feature immediately, but I guess Wine people might welcome this as well, where 'benefit' means - do not have to painfully install the external DXT library, which is very likely not needed at all. As far as Wine is concerned, not without a proper extension. At this stage having the external library or driconf option is good enough for Wine. In the end this is a legal problem rather than a technical problem though. Henri, with all respect, I encourage you to lookup the S3TC patent US 5956431 once more to see what is actually claimed. The patent relates to image processing systems that actually actively perform image compression or decompression. This is actually the reason why the Mesa uses external processing library to be free of this legally covered stuff. Of course, without the help of such external library, Mesa cannot claim to support GL_EXT_texture_compression_s3tc, because if it does, it has to implement the patented algorithm. The situation is different in this case. I am just saying - please, relax the enforcement of the existence of the external image processing library in the Mesa in the cases when hardware natively supports DXTn formats and the Mesa client provides DXTn precompressed data, merely allowing a binary passthrough via well documented and available interface defined in the abstract ARB_texture_compression extension, allowing exactly for such cases where the OpenGL implementation doesn't claim the availability of given compressed format processing, but allowing the data to be just passed through. In this situation, the DXTn (S3TC) related agorithms were all implemented and used outside of the Mesa body and as far as I can see, nothing of the patent applies here. In the past days, applications (games) relied on the existence of the GL_S3_s3tc or GL_EXT_texture_compression_s3tc extensions, because they expected the implementation to optionally compress the data for them to save video memory and bandwidth, without precompressing the data themselves. Nowadays the situation is quite different, whereas almost any modern game relies on the existence of the hardware s3tc and provides preauthored data in the form it wants the implementation to use it, without actually requesting on-the-fly image compression. But just because we are all 'used to' simply check for the existence of the GL_EXT_texture_compression_s3tc doesn't mean we really want to use it at all. Many of the current applications do not. Limited ARB_texture_compression is sufficient enough for all our needs. Regards, Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
