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 Seborp...@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
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 19 March 2011 12:24, Petr Sebor p...@scssoft.com wrote: 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. Sure. All I'm saying is that as far as Wine is concerned, we wouldn't use that kind of undocumented hack. There would have to be a proper GL extension offering compressed formats but not runtime compression / decompression. That doesn't necessarily mean you won't be able to convince other Mesa developers that this is a good idea, just that usefulness to Wine isn't one of the arguments. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
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.commailto: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
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 19.3.2011 16:33, Jose Fonseca wrote: 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. Jose, you are probably better lawyer than I am. I haven't realized that such thing might happen - I mean - the need to have a license to use the hardware on specific operating system and more, on a particular stack. That's absolutely totally crazy. Even though I personally internally don't believe* this is the case, the truth is that I don't know. And I agree that knowing it is what really matters. However, at least a part of your message carries good news. It happened quite some time ago, but you're right that nVidia na S3 cross-licensed some of their technology, including S3TC. And according to the FAQ you have linked it seems it might be actually possible to realize the proposed approach at least on their hardware if nothing else. That might be a nice first step. (*) I _believe_ that the S3TC relates mainly to the hardware decoding. This is where it becomes useful when saving memory and bandwidth. The situation when the hardware vendor obtains such narrow license - say - this chip on that operating system and such 3D stack sounds pretty strange to me. But yes, it might be possible, but I somehow believe that AMD and Intel got the S3TC license under similar terms like NV did. Just my $0.02. Maybe the others (Intel, AMD) might (or might not) follow after it becomes more clear what is covered under their license? It would be great if someone of Intel, AMD reading this list could shed some light on this. However, even if Mesa for any reason decides not to implement the compressed format passthrough in well defined terms of ARB_texture_compression, it is not a tragedy. I just thought that I could point out that there might be a simple solution to have at least some S3TC support in the free GL stack. Where people would learn it is perfectly ok to ignore the implementation ability to compress/decompress data on the fly when they already have precompressed data and there is a simple passthrough available. And more, this is not a hack - it is well defined interface which you can already depend on at least with NV hardware on Windows (this is what I can see here right now) and it was already used as the only way on some particular drivers in the past (sorry, my memory prevents me to be more specific, I just know we just had to use it to get S3TC). 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
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 19.3.2011 16:06, Henri Verbeet wrote: On 19 March 2011 12:24, Petr Seborp...@scssoft.com wrote: 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. Sure. All I'm saying is that as far as Wine is concerned, we wouldn't use that kind of undocumented hack. There would have to be a proper GL extension offering compressed formats but not runtime compression / decompression. That doesn't necessarily mean you won't be able to convince other Mesa developers that this is a good idea, just that usefulness to Wine isn't one of the arguments. Henri, I apologize for touching Wine. It just immediately came to my mind knowing all D3D games that can be played under it (and care about S3TC) already come with precompressed data. I just thought this might be good thing for its users. Probably not. And this is not an undocumented hack. ARB_texture_compression explicitly defines mechanisms to work with 'unknown' formats providing a safe passthrough. Thats what glCompressedTexImage actually is for. 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
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 20 March 2011 00:42, Petr Sebor p...@scssoft.com wrote: And this is not an undocumented hack. ARB_texture_compression explicitly defines mechanisms to work with 'unknown' formats providing a safe passthrough. Thats what glCompressedTexImage actually is for. Sure, the CompressedTexImage* calls are in principle agnostic to the specific format. But without the s3tc extension there's nothing that defines e.g. GL_COMPRESSED_RGBA_S3TC_DXT5_EXT. So you can't use those tokens, unless you have another extension that defines them. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
