Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Wed, Aug 10, 2011 at 7:11 AM, Rudolf Polzer divver...@xonotic.org wrote: On Tue, Aug 09, 2011 at 11:45:23PM +0200, Marek Olšák wrote: On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca jfons...@vmware.com wrote: I don't have time for a longer reply now, but I do think your S2TC work is interesting, and that you've successfully contoured the patent claims, at least for the decompression, as I didn't look at the compression bits. But, there was never anything you could have done to improve the situation for GPU S3TC decompression. It's not just a US patent system vs the rest. It's complex, but it's all in the archives, as it has all been discussed before. Well, actually, there is a solution. A solution which has not been available until now. The solution is not to use GPU S3TC decompression, obviously. Instead, let's use GPU S2TC decompression. We have integer opcode support coming, right? We can use those to decompress S2TC textures, which would be loaded as integer textures. Of course, we'd have to implement filtering as well and maintain a few shader variants in case somebody binds an S2TC texture, so that we can switch a shader to S2TC decompression for a particular sampler. The only problem is S2TC can't correctly decompress every S3TC texture, so we'd be noncompliant. Noncompliant is probably better than not working at all. So what do you guys think? If we go there... wouldn't it be an alternative to trivially convert S3TC to S2TC, by mapping all pixel values to values that don't use inferred colors? Not sure. It would be safer to avoid anything that assumes full knowledge of S3TC. That way, we'd still be using the S3TC circuits, but we'd only feed S2TC into them. Would this be enough to evade the patent - as we'd basically not care if that circuit does any more than S2TC decoding? I would rather avoid that circuit altogether. To exaggerate again: what if we upload null bytes into that decompressor circuit? The decoding algorithms would still run on the hardware, but all we would get out of it is it expanding a sequence of null bytes to 8 times its length. Would even this still infringe, just because that circuit is a S3TC decoder? I think so. Obviously, the same quality loss would be incurred by this, which is - from my tests - big enough to consider such a decoder noncompliant. Because of this I would suggest that - if we go one of these two ways - we should add a separate extension string for support of S2TC. The problem is there is no adoption of S2TC in the industry. The current state is that Unigine products don't run without full S3TC. Neither does the id Tech 4 engine. Most, if not all, D3D games consider S3TC a standard. In order to succeed, S2TC must become a standard too. The OpenGL ARB cannot incorporate S3TC into a core spec anyway. Perhaps they would be interested in S2TC as a temporary replacement. Proprietary drivers could implement S2TC easily using their hardware (patented) S3TC decoder. Mesa would have to decode it using shaders. But there would be at least something in the core spec that is one-way compatible with S3TC and has comparable quality, even though the algorithms are different. You can see for yourself here (screenshot of a scene using S3TC-decoded-as-S2TC - note the already visible dithering moire that comes from the S2TC decoder case that handles S3TC without using color ramps): https://github.com/divVerent/s2tc/wiki/img/s3tcnv-dds-s2tc.png and here (texture comparison, temporary URL): http://rm.rm.rm-f.org/~xonotic/temp/s3tc-to-s2tc/ Also, s2tc now comes with a tool to quickly convert S3TC to S2TC: https://github.com/divVerent/s2tc/blob/master/s2tc_from_s3tc.cpp Together: GL_EXT_texture_compression_s3tc: - upload of any S3TC texture - only possible if the HW vendor has a broad enough license of the patents, i.e. only possible for nouveau - encoding of existing textures to S3TC or S2TC (here, S2TC is good enough to claim compliance) GL_MESA_texture_compression_s2tc: - upload of any S2TC texture - decoding can take place using S3TC circuits, or using code on the GPU - attempts to upload S3TC using this will yield reduced quality - encoding of existing textures to S2TC - uses same constants as S3TC for uploading the texture - basically, these two extensions define the very same interface, but expect different data I am currently field testing S2TC in Xonotic, and got no complaints about reduced texture quality yet (although I found a few non-optimal cases myself which I will fix by manually excluding these textures from S2TC compression - and the same places were already bad with AMD Compressonator, so I consider it good that these are a bit easier to find now). So, if we go this route, all I'd have to do for Xonotic, is to have
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Wed, 2011-08-10 at 08:50 +0200, Marek Olšák wrote: On Wed, Aug 10, 2011 at 7:11 AM, Rudolf Polzer divver...@xonotic.org wrote: On Tue, Aug 09, 2011 at 11:45:23PM +0200, Marek Olšák wrote: On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca jfons...@vmware.com wrote: I don't have time for a longer reply now, but I do think your S2TC work is interesting, and that you've successfully contoured the patent claims, at least for the decompression, as I didn't look at the compression bits. But, there was never anything you could have done to improve the situation for GPU S3TC decompression. It's not just a US patent system vs the rest. It's complex, but it's all in the archives, as it has all been discussed before. Well, actually, there is a solution. A solution which has not been available until now. The solution is not to use GPU S3TC decompression, obviously. Instead, let's use GPU S2TC decompression. We have integer opcode support coming, right? We can use those to decompress S2TC textures, which would be loaded as integer textures. Of course, we'd have to implement filtering as well and maintain a few shader variants in case somebody binds an S2TC texture, so that we can switch a shader to S2TC decompression for a particular sampler. The only problem is S2TC can't correctly decompress every S3TC texture, so we'd be noncompliant. Noncompliant is probably better than not working at all. So what do you guys think? If we go there... wouldn't it be an alternative to trivially convert S3TC to S2TC, by mapping all pixel values to values that don't use inferred colors? Not sure. It would be safer to avoid anything that assumes full knowledge of S3TC. That way, we'd still be using the S3TC circuits, but we'd only feed S2TC into them. Would this be enough to evade the patent - as we'd basically not care if that circuit does any more than S2TC decoding? I would rather avoid that circuit altogether. I'm still very confused as to why this'd be a problem... I can only imagine how many patents get violated by just telling the GPU to render a triangle.. Wtf is the difference here? Ben. To exaggerate again: what if we upload null bytes into that decompressor circuit? The decoding algorithms would still run on the hardware, but all we would get out of it is it expanding a sequence of null bytes to 8 times its length. Would even this still infringe, just because that circuit is a S3TC decoder? I think so. Obviously, the same quality loss would be incurred by this, which is - from my tests - big enough to consider such a decoder noncompliant. Because of this I would suggest that - if we go one of these two ways - we should add a separate extension string for support of S2TC. The problem is there is no adoption of S2TC in the industry. The current state is that Unigine products don't run without full S3TC. Neither does the id Tech 4 engine. Most, if not all, D3D games consider S3TC a standard. In order to succeed, S2TC must become a standard too. The OpenGL ARB cannot incorporate S3TC into a core spec anyway. Perhaps they would be interested in S2TC as a temporary replacement. Proprietary drivers could implement S2TC easily using their hardware (patented) S3TC decoder. Mesa would have to decode it using shaders. But there would be at least something in the core spec that is one-way compatible with S3TC and has comparable quality, even though the algorithms are different. You can see for yourself here (screenshot of a scene using S3TC-decoded-as-S2TC - note the already visible dithering moire that comes from the S2TC decoder case that handles S3TC without using color ramps): https://github.com/divVerent/s2tc/wiki/img/s3tcnv-dds-s2tc.png and here (texture comparison, temporary URL): http://rm.rm.rm-f.org/~xonotic/temp/s3tc-to-s2tc/ Also, s2tc now comes with a tool to quickly convert S3TC to S2TC: https://github.com/divVerent/s2tc/blob/master/s2tc_from_s3tc.cpp Together: GL_EXT_texture_compression_s3tc: - upload of any S3TC texture - only possible if the HW vendor has a broad enough license of the patents, i.e. only possible for nouveau - encoding of existing textures to S3TC or S2TC (here, S2TC is good enough to claim compliance) GL_MESA_texture_compression_s2tc: - upload of any S2TC texture - decoding can take place using S3TC circuits, or using code on the GPU - attempts to upload S3TC using this will yield reduced quality - encoding of existing textures to S2TC - uses same constants as S3TC for uploading the texture - basically, these two extensions define the very same interface, but expect different data I am currently field testing S2TC in Xonotic, and got no
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Am 10.08.2011 11:34, schrieb Rudolf Polzer: The OpenGL ARB cannot incorporate S3TC into a core spec anyway. But it already is core part of OpenGL 3.0. No. Making S3TC part of OpenGL was discussed, but rejected. OpenGL only requires RGTC (since OpenGL 3.0) and BPTC (since OpenGL 4.2). Philipp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Wed, Aug 10, 2011 at 11:42:11AM +0200, Philipp Klaus Krause wrote: Am 10.08.2011 11:34, schrieb Rudolf Polzer: The OpenGL ARB cannot incorporate S3TC into a core spec anyway. But it already is core part of OpenGL 3.0. No. Making S3TC part of OpenGL was discussed, but rejected. OpenGL only requires RGTC (since OpenGL 3.0) and BPTC (since OpenGL 4.2). Ah, okay then. Speaking of BPTC - what is its patent situation? From a quick glance at the extension spec, it does seem to use S3TC's interpolation method, so it likely is not safe from S3's patents. But I may be wrong there, as BPTC is quite messy and convoluted, and I may have misinterpreted that interpolation value sequence. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Am 10.08.2011 11:46, schrieb Rudolf Polzer: Speaking of BPTC - what is its patent situation? From a quick glance at the extension spec, it does seem to use S3TC's interpolation method, so it likely is not safe from S3's patents. But I may be wrong there, as BPTC is quite messy and convoluted, and I may have misinterpreted that interpolation value sequence. The ARB says No known IP claims.. HTC probably says that the S3TC patent applies to virtually all kinds of texture compression. Philipp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Wed, Aug 10, 2011 at 11:46:00AM +0200, Philipp Klaus Krause wrote: Am 10.08.2011 08:50, schrieb Marek Olšák: The problem is there is no adoption of S2TC in the industry. The current state is that Unigine products don't run without full S3TC. Neither does the id Tech 4 engine. Most, if not all, D3D games consider S3TC a standard. In order to succeed, S2TC must become a standard too. Which would take so much time, it wouldn't make sense - by then all hardware probably supports BPTC, since it is required by OpenGL 4.2. AFAIK BPTX most of the time provides better quality than S3TC, and thus better quality than S2TC. Right. Plus, I doubt the ARB would accept an extension that is a subset of an already existing extension, and even temporary. Which is why I would rather suggest Mesa to design and implement a S2TC extension spec that tries to be as compatible as possible to S3TC. The general idea is that an existing game engine should only require minimal changes to use S2TC, and have S3TC decode S2TC easily too. The one big problem could be the texture format identifier. If the S2TC extension is to use GL_COMPRESSED_RGBA_S3TC_DXT1_EXT this would minimize changes to the software affected - all that changes, is that S2TC supporting software would test BOTH extension strings. However, then S3TC-expecting software that uses GL_ARB_texture_compression and enumerates texture formats would still find GL_COMPRESSED_RGBA_S3TC_DXT1_EXT in the list, and expect full S3TC decoding. So likely, a different texture format identifier would be required. Also, this would require both compression and upload (e.g. shader decompression) in Mesa, as this should serve as full replacement for GL_EXT_texture_compression_s3tc. If we use a different identifier for the texture format, which we'd likely have to, an application would need to be changed to support S2TC like this: Change initialization code from: - check for GL_EXT_texture_compression_s3tc - if available, set s3tc_supported = 1 to - check for GL_EXT_texture_compression_s3tc; if available: - set s3tc_supported = 1 and s2tc_supported = 1 - set S2TC_DXT1 = GL_COMPRESSED_RGB_S3TC_DXT1_EXT - set S2TC_DXT1A = GL_COMPRESSED_RGBA_S3TC_DXT1_EXT - set S2TC_DXT3 = GL_COMPRESSED_RGBA_S3TC_DXT3_EXT - set S2TC_DXT5 = GL_COMPRESSED_RGBA_S3TC_DXT5_EXT - otherwise, check for GL_MESA_texture_compression_s2tc; if available: - set s3tc_supported = 0 and s2tc_supported = 1 - set S2TC_DXT1 = GL_COMPRESSED_RGB_S2TC_DXT1_MESA - set S2TC_DXT1A = GL_COMPRESSED_RGBA_S2TC_DXT1_MESA - set S2TC_DXT3 = GL_COMPRESSED_RGBA_S2TC_DXT3_MESA - set S2TC_DXT5 = GL_COMPRESSED_RGBA_S2TC_DXT5_MESA - otherwise: - set s3tc_supported = 0 and s2tc_supported = 0 Change all references to s3tc_supported to s2tc_supported, where it is applicable to the case (e.g. depending on input source). Change all references to GL_COMPRESSED_*_S3TC_*_EXT to S2TC_* where applicable. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
- Original Message - On Tue, Aug 09, 2011 at 03:25:05AM -0700, Jose Fonseca wrote: How should you brought this? You should have assumed that we have our reasons -- after all we've been living under the frustration of these patents, walking on a mine field, for a decade --, instead of assuming we have NIH syndrome. So I should never try to do anything new, as likely someone else may have already done it and rejected it. We must be talking different things. I was answering on how you should have approached this subject on the mailing list _after_ doing S2TC work. Essentially you started to wrongly accuse the developers of already doing illegal things, when your proposal was refused, which totally pissed me off. We strive to keep legal risk under check, and you were trying to tip the scale. If you are talking of what you should have done before doing the S2TC work, then my opinion is that you should have: - a) read all threads about S3TC on mesa3d-dev mailing list -- if you had done so you would have noticed that several times now people have proposed to develop a variant of the S3TC GL extension that would not require any software (de)compression (therefore completely avoiding the software side of the issue), but that it was always abandoned, because the hardware licensing terms were potentially too narrow -- the intuitive idea that if I bought the hardware I must have the license simply is not true in the general case. The recent Apple/S3 lawsuit corroborates that. and/or b) contacted the developers before doing the work -- they would have told you the same. Either would have saved everybody grief. That said, I still think that S2TC work is interesting for software rendererers (although that may not be your intention), or even if one day the IHVs do get a S3TC license for Mesa/Linux, we can use it to solve the software compression issue. But the hardware use, is and always has been in the IHV/S3 hands. (Furthermore b) applies not only to patent issues but any contribution to any open source project. The only way to ensure one does not waste time is to get the maintainers' buy in for the general concept beforehand.) Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Wed, Aug 10, 2011 at 04:32:20AM -0700, Jose Fonseca wrote: - Original Message - On Tue, Aug 09, 2011 at 03:25:05AM -0700, Jose Fonseca wrote: How should you brought this? You should have assumed that we have our reasons -- after all we've been living under the frustration of these patents, walking on a mine field, for a decade --, instead of assuming we have NIH syndrome. So I should never try to do anything new, as likely someone else may have already done it and rejected it. We must be talking different things. I was answering on how you should have approached this subject on the mailing list _after_ doing S2TC work. Essentially you started to wrongly accuse the developers of already doing illegal things, when your proposal was refused, which totally pissed me off. We strive to keep legal risk under check, and you were trying to tip the scale. I did not. It was proof by contradiction, or reductio ad absurdum, a common mathematical method of proof. I was saying, your claim that uploading texture data to a S3TC decoding sircuit is a reason against S2TC must be void, because Mesa does the same already, and thus your interpretation must be wrong. It was not meant as an accusation that Mesa is breaking any law. But rather as a proof that in this specific aspect, S2TC is not. If you are talking of what you should have done before doing the S2TC work, then my opinion is that you should have: - a) read all threads about S3TC on mesa3d-dev mailing list -- if you had done so you would have noticed that several times now people have proposed to develop a variant of the S3TC GL extension that would not require any software (de)compression (therefore completely avoiding the software side of the issue), but that it was always abandoned, because the hardware licensing terms were potentially too narrow -- the intuitive idea that if I bought the hardware I must have the license simply is not true in the general case. The recent Apple/S3 lawsuit corroborates that. I never understood that part, and still do not. But if US law is that insane, it is. If only voters had any actual power to get rid of such nonsense... and apparently, US law forbids public explanations of such issues, so it is impossible to learn about it. Not my fault though. b) contacted the developers before doing the work -- they would have told you the same. Before doing the work, it likely would have been shot down because of potential quality issues. Without actually trying it out, it is not obvious at all that S2TC still yields sufficient quality. Plus, my only contact to the mesa developers IS this list. Either would have saved everybody grief. That said, I still think that S2TC work is interesting for software rendererers (although that may not be your intention), or even if one day the IHVs do get a S3TC license for Mesa/Linux, we can use it to solve the software compression issue. But the hardware use, is and always has been in the IHV/S3 hands. Supposedly, by some post elsewhere in this thread, nvidia has the sufficient license, and thus nouveau could use it. For other but sufficiently new chipsets, it was suggested to implement S2TC decoding via shader. No idea how that would work though, and what performance impact it would have. (Furthermore b) applies not only to patent issues but any contribution to any open source project. The only way to ensure one does not waste time is to get the maintainers' buy in for the general concept beforehand.) In this case, that clearly is not possible without having an implementation already, as a quality comparison was necessary. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Die, 2011-08-09 at 06:42 +0200, Rudolf Polzer wrote: On Mon, Aug 08, 2011 at 02:03:59PM -0700, Corbin Simpson wrote: Unless I missed something, we (the Mesa developers) do not endorse using S3TC at all, anywhere in the stack, as long as it is patented. Here, you reference the full S3TC implementation: http://dri.freedesktop.org/wiki/S3TC All I am asking for is ALSO a reference to the restricted S2TC implementation there. I'd do it myself, if the page were not immutable. You just need to log in to edit it (just like any other page). -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
- Original Message - On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. I couldn't let this statements go unchallenged.. The option in question is disabled by default, and I don't agree this is inducing in infringement in any way as we always highlighted the S3TC pitfalls in the mailing lists, and the IHV's S3TC licensing terms have not been disclosed, but I agree that at the very least we should better document this option in docs/patents.txt, to avoid misunderstandings as you're having, and yes, probably also have the option disabled by default with a configure option, as we do with floating point textures, which the drivers may override or not, as the breadth of S3TC license of the target hardware is known. Thanks for pointing this issue out, Rudolf. Thanks for playing devil's advocate in a public forum, and forcing us to take a stricter stand on this matter. I am confused though, because I thought you were trying to help the Linux community, not the patent trolls. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Tue, Aug 09, 2011 at 02:01:44AM -0700, Jose Fonseca wrote: - Original Message - On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. I couldn't let this statements go unchallenged.. The option in question is disabled by default, and I don't agree this is inducing in infringement in any way as we always highlighted the S3TC pitfalls in the mailing lists, and the IHV's S3TC licensing terms have not been disclosed, but I agree that at the very least we should better document this option in docs/patents.txt, to avoid misunderstandings as you're having, and yes, probably also have the option disabled by default with a configure option, as we do with floating point textures, which the drivers may override or not, as the breadth of S3TC license of the target hardware is known. Thanks for pointing this issue out, Rudolf. Thanks for playing devil's advocate in a public forum, and forcing us to take a stricter stand on this matter. I am confused though, because I thought you were trying to help the Linux community, not the patent trolls. I was trying to help the Linux communtiy, but apparently I failed. Looks like all this work I did was for nothing. Nothing is appreciated, all is Not Invented Here. How else should I have brought this up? I still don't understand WHY this is an issue. Is US patent law really that retarded? I still can't believe this, as to me that would mean that Apache would have needed a patent license in order to transport GIF files back then (or at least, to assign the content type image/gif in the default config). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
- Original Message - On Tue, Aug 09, 2011 at 02:01:44AM -0700, Jose Fonseca wrote: - Original Message - On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. I couldn't let this statements go unchallenged.. The option in question is disabled by default, and I don't agree this is inducing in infringement in any way as we always highlighted the S3TC pitfalls in the mailing lists, and the IHV's S3TC licensing terms have not been disclosed, but I agree that at the very least we should better document this option in docs/patents.txt, to avoid misunderstandings as you're having, and yes, probably also have the option disabled by default with a configure option, as we do with floating point textures, which the drivers may override or not, as the breadth of S3TC license of the target hardware is known. Thanks for pointing this issue out, Rudolf. Thanks for playing devil's advocate in a public forum, and forcing us to take a stricter stand on this matter. I am confused though, because I thought you were trying to help the Linux community, not the patent trolls. I was trying to help the Linux communtiy, but apparently I failed. Looks like all this work I did was for nothing. Nothing is appreciated, all is Not Invented Here. How else should I have brought this up? I still don't understand WHY this is an issue. Is US patent law really that retarded? I still can't believe this, as to me that would mean that Apache would have needed a patent license in order to transport GIF files back then (or at least, to assign the content type image/gif in the default config). I don't have time for a longer reply now, but I do think your S2TC work is interesting, and that you've successfully contoured the patent claims, at least for the decompression, as I didn't look at the compression bits. But, there was never anything you could have done to improve the situation for GPU S3TC decompression. It's not just a US patent system vs the rest. It's complex, but it's all in the archives, as it has all been discussed before. How should you brought this? You should have assumed that we have our reasons -- after all we've been living under the frustration of these patents, walking on a mine field, for a decade --, instead of assuming we have NIH syndrome. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Tue, Aug 09, 2011 at 03:25:05AM -0700, Jose Fonseca wrote:
- Original Message -
I was trying to help the Linux communtiy, but apparently I failed.
Looks like all this work I did was for nothing. Nothing is
appreciated, all is
Not Invented Here.
How else should I have brought this up? I still don't understand WHY
this is an
issue. Is US patent law really that retarded? I still can't believe
this, as to
me that would mean that Apache would have needed a patent license in
order to
transport GIF files back then (or at least, to assign the content
type
image/gif in the default config).
I don't have time for a longer reply now, but I do think your S2TC work is
interesting, and that you've successfully contoured the patent claims, at
least for the decompression, as I didn't look at the compression bits.
The compression bits are even simpler. Decompression is a BIT dodgy, due to the
(i^j)1 decision which, but could be fixed by always using 0 or 1 there,
reducing quality a bit, but being safer.
As for compression: the compressed format is basically each 4x4 block is a
2-color optimum palette image. Similar schemes have existed way before S3TC
(e.g. in some video codecs used by DOS games - see ffmpeg for implementations
of these), and even way before Apple's RPZA, which I still see as obvious prior
art that should render any S3TC related patents invalid (which is apparently
exactly what Apple now is trying to achieve in court). Whether my specific
algorithms for choosing the 2 colors, or for finding the nearest color of the
two for each pixel, violate any patents, I cannot say, but these two things are
quite interchangable. Too bad the standard color reduction algorithm Median
cut does not work well if the target is just two colors, as it would have been
a VERY safe choice.
Still, this apparently isn't useful for anything.
But, there was never anything you could have done to improve the situation
for GPU S3TC decompression. It's not just a US patent system vs the rest.
It's complex, but it's all in the archives, as it has all been discussed
before.
Still makes absolutely no sense to me, but if it's that insane, it is (see my
Apache/GIF example, which is THE VERY SAME THING).
However, I still am wondering - what if the data fed to the GPU is not S3TC
compressed at all? Do we still need the patent license if we e.g. feed a block
of null bytes to it, jzst because that circuit is a S3TC decoder? Hopefully
not, as this would be EVEN more insane.
If the null byte example is legal, however, then likely, feeding S2TC
compressed textures is fine as well, as the methods described in the S3TC
patents are not used by them. So one idea to support precompressed textures
would be converting S3TC to S2TC the following way, for the DXT1 case:
- if the block is a DXT1-alpha block:
- map 10 to either 00 or 01 at random (or using (i^j)1 dithering)
- keep all other bit values as is
- if the block is a DXT1-without-alpha block:
- possibly, to make the block types indistinguishable, swap c0 and c1, and
XOR each pixel data byte by 0101010
- map 10 and 11 to either 00 or 01 (at random, with (i^j)1 dithering, or 10
to 00, 11 to 01)
- keep all other bit values as is
- when going the move interpolated values to borders way, this would be
doable by an AND of each byte by 01010101)
a lazy low-quality implementation of this could be like this:
// extract colors to c0 and c1
// extract pixel data to an uint32_t pixels
if(c0 = c1)
{
// DXT1-alpha block
// either:
// map any 10 to 00:
// 00 - 00
// 01 - 01
// 10 - 00
// 11 - 11
//pixels = pixels ~((~pixels 0x) 1);
// or:
// map any 10 to 01:
// 00 - 00
// 01 - 01
// 10 - 01
// 11 - 11
//pixels = (pixels ~((~pixels 0x) 1)) | ((pixels
0x) 1);
// or:
// dither between the two methods (the ij method)
pixels = (pixels ~((~pixels 0x) 1)) | ((pixels
0x88228822) 1);
}
else
{
// DXT1-noalpha block
// optionally, to make sure the decoder always sees the c0 = c1 case:
swap(c0, c1);
pixels = ~pixels;
// actually: pixels ^ 0x, but the difference to this gets ANDed
away in the next step
pixels = pixels 0x;
// or, we could do the same dithering method as above for possibly
better display (not sure):
// 00 - 00
// 01 - 01
// 10 - 00 or 01
// 11 - 00 or 01
pixels = (pixels ((~pixels 0x) 1)) | ((pixels
0x88228822) 1);
}
For DXT5, further processing would be needed for handling the alpha channel, or
maybe not, depending on interpretation of the S3TC patents. If color in there
is not interpreted to also include scalar values, then DXT5's alpha part is
fine as is - if not, converting DXT5's alpha to S2TC alpha
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Am 09.08.2011 13:10, schrieb Rudolf Polzer: As for compression: the compressed format is basically each 4x4 block is a 2-color optimum palette image. Similar schemes have existed way before S3TC […] See Beers et al., Rendering from compressed textures in the SIGGRAPH '96 proceedings for the AFAIK first use of this technique in texture compression. Philipp ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Tue, Aug 09, 2011 at 03:16:34PM +0200, Philipp Klaus Krause wrote: Am 09.08.2011 13:10, schrieb Rudolf Polzer: As for compression: the compressed format is basically each 4x4 block is a 2-color optimum palette image. Similar schemes have existed way before S3TC […] See Beers et al., Rendering from compressed textures in the SIGGRAPH '96 proceedings for the AFAIK first use of this technique in texture compression. Graham Campbell, Thomas A. DeFanti, Jeff Frederiksen, Stephen A. Joyce, and Lawrence A. Leske. 1986. Two bit/pixel full color encoding. SIGGRAPH Comput. Graph. 20, 4 (August 1986), 215-223. describes a scheme that is VERY similar, except that that scheme additionally uses a global palette for the two colors of the blocks, while S2TC stores the two reference colors in the blocks directly. They achieve twice the compression ratio that way. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 08/09/11 02:29, Rudolf Polzer wrote: Is US patent law really that retarded? US patent law shares a common feature with most other patent systems: No matter how carefully you word the patent or read the patent, the only way to really find out whether something is a patent violation is to go to court and see if a judge or jury, all made up of non-engineers who don't understand the details, decide you're guilty of patent infringement. All attempts to apply carefully reasoned logic to patents fail when they hit this one illogical and unpredictable step, with potentially expensive results. The US patent system has a bonus feature though - if you knew about that patent in advance, then they can triple the amount of money you lose in the lawsuit, which is why most companies advise their engineers to avoid knowing anything about another companies patents, much less how to engineer around them. Sadly, the much needed patent reform doesn't seem to be coming, while the patent trolls and lawsuits keep rising. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
I should point out something not immediately obvious about S3TC: It's believed that the patents cover any complete pipeline which decompresses S3TC textures according to the S3TC algorithm. It's stupidly broad that way. On Tue, Aug 9, 2011 at 8:12 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 08/09/11 02:29, Rudolf Polzer wrote: Is US patent law really that retarded? US patent law shares a common feature with most other patent systems: No matter how carefully you word the patent or read the patent, the only way to really find out whether something is a patent violation is to go to court and see if a judge or jury, all made up of non-engineers who don't understand the details, decide you're guilty of patent infringement. All attempts to apply carefully reasoned logic to patents fail when they hit this one illogical and unpredictable step, with potentially expensive results. The US patent system has a bonus feature though - if you knew about that patent in advance, then they can triple the amount of money you lose in the lawsuit, which is why most companies advise their engineers to avoid knowing anything about another companies patents, much less how to engineer around them. Sadly, the much needed patent reform doesn't seem to be coming, while the patent trolls and lawsuits keep rising. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Tue, 2011-08-09 at 19:49 +0200, Rudolf Polzer wrote: On Tue, Aug 09, 2011 at 10:46:12AM -0700, Corbin Simpson wrote: I should point out something not immediately obvious about S3TC: It's believed that the patents cover any complete pipeline which decompresses S3TC textures according to the S3TC algorithm. It's stupidly broad that way. Sure is, which is why S2TC is not able to decode full S3TC, but has a weird fallback handling that does not make use of inferred colors. If only it weren't for the glaring similarity to RPZA's 0xC0 opcode... which is VERY similar to S3TC's encoding scheme, and was invented 8 years earlier. That can get very interesting, as I assume that Apple tries to defend against the S3TC patent exactly by pointing out the similarity to RPZA (the Quicktime 1 codec). Best regards, Rudolf Polzer According to people who actually know about software patent cases, prior art is near impossible to pull off. The problem is simple: unless you had the exact same thing bit for bit prior to the patent, it won't work. Just shy of changing the name, ANY change will invalidate the case for prior art. The best (and probably only) way to help mesa would be to obtain a license for both encoding and decoding of S3TC for it. Alternatively you could wait till 2017 when the patent expires. Sorry to disappoint. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca jfons...@vmware.com wrote: I don't have time for a longer reply now, but I do think your S2TC work is interesting, and that you've successfully contoured the patent claims, at least for the decompression, as I didn't look at the compression bits. But, there was never anything you could have done to improve the situation for GPU S3TC decompression. It's not just a US patent system vs the rest. It's complex, but it's all in the archives, as it has all been discussed before. Well, actually, there is a solution. A solution which has not been available until now. The solution is not to use GPU S3TC decompression, obviously. Instead, let's use GPU S2TC decompression. We have integer opcode support coming, right? We can use those to decompress S2TC textures, which would be loaded as integer textures. Of course, we'd have to implement filtering as well and maintain a few shader variants in case somebody binds an S2TC texture, so that we can switch a shader to S2TC decompression for a particular sampler. The only problem is S2TC can't correctly decompress every S3TC texture, so we'd be noncompliant. Noncompliant is probably better than not working at all. So what do you guys think? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 9 August 2011 23:45, Marek Olšák mar...@gmail.com wrote: texture, so we'd be noncompliant. Noncompliant is probably better than not working at all. So what do you guys think? In the general case, no. A missing extension is something applications can deal with if they care to, a broken extension isn't. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/2011 03:44 PM, Petr Sebor wrote: On 4.8.2011 12:19, Rudolf Polzer wrote: On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: On 08/03/2011 12:11 PM, Bryan Cain wrote: Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. Ian, I think it is really not the same issue. The S3TC patent is about the algorithm itself, not about copying blocks of memory. The quote from Two words: contributory infringement. The Mesa code would be doing something that enables something else to infringe. No distro will ship it because it makes them liable. Don't look for logic or reason or sense in the legal system. You won't find it. EXT_texture_compression_s3tc only underlines the fact that Direct3D stack (both runtime and driver) does not have to provide S3TC compression/decompression algorithm at all, whereas driver providing EXT_tc_s3tc typically has to be able to compress the textures in the software (and thus implement the patented stuff). Direct3D serves as a pass-through to the hardware, they don't have to mess with the patent at all while the hw vendor typically has the decompression part covered. Microsoft has a license that they sublicense to DX implementations. None of what you say here is relevant to any court in the USA. See my previous comments about logic and reason. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk5BsOoACgkQX1gOwKyEAw/PawCeKzTELXL/Q4qhw7/qv1EOmJE7 TaMAoKEQ2it/cgohyLyUyvOLsRPYT8dY =iezG -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/09/2011 02:29 AM, Rudolf Polzer wrote: On Tue, Aug 09, 2011 at 02:01:44AM -0700, Jose Fonseca wrote: - Original Message - On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. I couldn't let this statements go unchallenged.. The option in question is disabled by default, and I don't agree this is inducing in infringement in any way as we always highlighted the S3TC pitfalls in the mailing lists, and the IHV's S3TC licensing terms have not been disclosed, but I agree that at the very least we should better document this option in docs/patents.txt, to avoid misunderstandings as you're having, and yes, probably also have the option disabled by default with a configure option, as we do with floating point textures, which the drivers may override or not, as the breadth of S3TC license of the target hardware is known. Thanks for pointing this issue out, Rudolf. Thanks for playing devil's advocate in a public forum, and forcing us to take a stricter stand on this matter. I am confused though, because I thought you were trying to help the Linux community, not the patent trolls. I was trying to help the Linux communtiy, but apparently I failed. Looks like all this work I did was for nothing. Nothing is appreciated, all is Not Invented Here. Not invented here has nothing to do with it. You did some fine work that will help the software rasterizers. How else should I have brought this up? I still don't understand WHY this is an issue. Is US patent law really that retarded? I still can't believe this, as to me that would mean that Apache would have needed a patent license in order to transport GIF files back then (or at least, to assign the content type image/gif in the default config). It's like any sort of licensing. If I own some particular thing, I can license you to use it under any terms I want. It turns out that the licensing terms for the S3TC patents are *extremely* restrictive. Combine that with the licensing fees being the primary source of S3's income, and there can be only trouble. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk5Bs3IACgkQX1gOwKyEAw/TfACZAZEuY90UY5l6/oPt9btT7+0e ZCUAn3s5RuuESSMKdyZUImPUJlw2e3xL =5kZ0 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/09/2011 04:10 AM, Rudolf Polzer wrote: As for compression: the compressed format is basically each 4x4 block is a 2-color optimum palette image. Similar schemes have existed way before S3TC (e.g. in some video codecs used by DOS games - see ffmpeg for implementations of these), and even way before Apple's RPZA, which I still see as obvious prior art that should render any S3TC related patents invalid (which is apparently exactly what Apple now is trying to achieve in court). Whether my specific algorithms for choosing the 2 colors, or for finding the nearest color of the two for each pixel, violate any patents, I cannot say, but these two things are quite interchangable. Too bad the standard color reduction algorithm Median cut does not work well if the target is just two colors, as it would have been a VERY safe choice. Yes. Getting some legal confirmation that the patents are invalid and that we can just do the right thing is the way forward here. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk5BtB4ACgkQX1gOwKyEAw+L8wCcClNbtU28UDQEGnzDdxqCvRIR diMAnjSwEmMNQhk2tU5+CgWoAdXJPtQv =NRKD -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Tue, Aug 09, 2011 at 11:45:23PM +0200, Marek Olšák wrote: On Tue, Aug 9, 2011 at 12:25 PM, Jose Fonseca jfons...@vmware.com wrote: I don't have time for a longer reply now, but I do think your S2TC work is interesting, and that you've successfully contoured the patent claims, at least for the decompression, as I didn't look at the compression bits. But, there was never anything you could have done to improve the situation for GPU S3TC decompression. It's not just a US patent system vs the rest. It's complex, but it's all in the archives, as it has all been discussed before. Well, actually, there is a solution. A solution which has not been available until now. The solution is not to use GPU S3TC decompression, obviously. Instead, let's use GPU S2TC decompression. We have integer opcode support coming, right? We can use those to decompress S2TC textures, which would be loaded as integer textures. Of course, we'd have to implement filtering as well and maintain a few shader variants in case somebody binds an S2TC texture, so that we can switch a shader to S2TC decompression for a particular sampler. The only problem is S2TC can't correctly decompress every S3TC texture, so we'd be noncompliant. Noncompliant is probably better than not working at all. So what do you guys think? If we go there... wouldn't it be an alternative to trivially convert S3TC to S2TC, by mapping all pixel values to values that don't use inferred colors? That way, we'd still be using the S3TC circuits, but we'd only feed S2TC into them. Would this be enough to evade the patent - as we'd basically not care if that circuit does any more than S2TC decoding? To exaggerate again: what if we upload null bytes into that decompressor circuit? The decoding algorithms would still run on the hardware, but all we would get out of it is it expanding a sequence of null bytes to 8 times its length. Would even this still infringe, just because that circuit is a S3TC decoder? Obviously, the same quality loss would be incurred by this, which is - from my tests - big enough to consider such a decoder noncompliant. Because of this I would suggest that - if we go one of these two ways - we should add a separate extension string for support of S2TC. You can see for yourself here (screenshot of a scene using S3TC-decoded-as-S2TC - note the already visible dithering moire that comes from the S2TC decoder case that handles S3TC without using color ramps): https://github.com/divVerent/s2tc/wiki/img/s3tcnv-dds-s2tc.png and here (texture comparison, temporary URL): http://rm.rm.rm-f.org/~xonotic/temp/s3tc-to-s2tc/ Also, s2tc now comes with a tool to quickly convert S3TC to S2TC: https://github.com/divVerent/s2tc/blob/master/s2tc_from_s3tc.cpp Together: GL_EXT_texture_compression_s3tc: - upload of any S3TC texture - only possible if the HW vendor has a broad enough license of the patents, i.e. only possible for nouveau - encoding of existing textures to S3TC or S2TC (here, S2TC is good enough to claim compliance) GL_MESA_texture_compression_s2tc: - upload of any S2TC texture - decoding can take place using S3TC circuits, or using code on the GPU - attempts to upload S3TC using this will yield reduced quality - encoding of existing textures to S2TC - uses same constants as S3TC for uploading the texture - basically, these two extensions define the very same interface, but expect different data I am currently field testing S2TC in Xonotic, and got no complaints about reduced texture quality yet (although I found a few non-optimal cases myself which I will fix by manually excluding these textures from S2TC compression - and the same places were already bad with AMD Compressonator, so I consider it good that these are a bit easier to find now). So, if we go this route, all I'd have to do for Xonotic, is to have it also accept the GL_MESA_texture_compression_s2tc extension string if the user/mod declares that the textures that come with it are S2TC. One other question: is the alpha encoding of DXT5 generally considered NOT covered by the S3TC patents? Personally I am unsure about that, as it depends a lot on HOW you interpret the S3TC patents. The only thing that makes the S3TC patents possibly not also include the alpha encoding, is the use of the word color - but exactly this may be enough to make it not apply there. I am asking, as S2TC currently also avoids inferred alpha values. But that this is necessary seems to generally not be agreed on, given lots of related stuff on various mailing lists I find on the net. S2TC also has a branch s2tc+alpha that uses full DXT5 alpha encoding instead, but I am unsure whether this branch is still fulfilling the entire purpose of S2TC or not. Best regards, Rudolf Polzer
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D Greetings Egon Ashrafinia ( IRC: Wubbbi ) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 01:01:14AM -0700, Corbin Simpson wrote: On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. This then is what S2TC is for. Distros could ALREADY take S2TC and include that, while most gamers wouldn't see a difference, while feeling safer from those patents (whether it is actually a successful evasion, only a judge can decide). The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
- Original Message - On Mon, Aug 08, 2011 at 01:01:14AM -0700, Corbin Simpson wrote: On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. This then is what S2TC is for. Distros could ALREADY take S2TC and include that, while most gamers wouldn't see a difference, while feeling safer from those patents (whether it is actually a successful evasion, only a judge can decide). Please stop this just because people can something it mean it is OK fallacy. That's what's ridiculous. Anybody can punch another in the face anytime, doesn't mean that a) he should; b) we should condemn or induce such practice. Without analogies, yes, people can do all sort of things with our software, but we developers should not condone, nor induce wrong/dubious practices. The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 08/08/11 00:58, Egon Ashrafinia wrote: I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? Incorrect. There's also quite a few other countries which allow software patents directly, such as Japan, South Korea, Australia, etc. Even if you believe the oversimplified (and incorrect) view that the EU has no software patents, European courts have enforced patents such as the MP3 ones when built into a hardware device such as an MP3 player. If you want to ensure Mesa is never built into a phone, or included as part of a preinstalled Linux bundle on a laptop, doing the wrong thing with patents is a good way to accomplish that. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 6:12 AM, Rudolf Polzer divver...@xonotic.org wrote: On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
It is not transparent if applications must opt into using it. Please go ask distributions to pick this up; we aren't going to do it without the legal issues being cleared up. Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 6:12 AM, Rudolf Polzer divver...@xonotic.org wrote: On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 12:52:14PM -0700, Corbin Simpson wrote: [force_s3tc_enable] It is not transparent if applications must opt into using it. Applications must also opt into using the regular S3TC extension, by using the appropriate texture format constant. No difference there, just a different way of doing it. Please go ask distributions to pick this up; we aren't going to do it without the legal issues being cleared up. All I'd be asking for is a link to it as an alternate implementation of libtxc_dxtn on http://dri.freedesktop.org/wiki/S3TC (immutable page). Possibly with a text like An alternate implementation using a restricted format subset of S3TC to possibly evade the aforementioned patent problems is available on https://github.com/divVerent/s2tc/ - however, even though it is plausible, Mesa or DRI give no guarantee that using this does not violate any less patent claims than the full implementation of libtxc_dxtn does, so please consult a lawyer if unsure. Without that, it'll be hard for me to get distros interested in it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Unless I missed something, we (the Mesa developers) do not endorse using S3TC at all, anywhere in the stack, as long as it is patented. Have you actually talked to any distros? This is my last post; we aren't getting anywhere. Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 1:02 PM, Rudolf Polzer divver...@xonotic.org wrote: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 8, 2011 at 8:02 PM, Rudolf Polzer divver...@xonotic.org wrote: Without that, it'll be hard for me to get distros interested in it. I'll make sure it's available in Gentoo very soon. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 02:03:59PM -0700, Corbin Simpson wrote: Unless I missed something, we (the Mesa developers) do not endorse using S3TC at all, anywhere in the stack, as long as it is patented. Here, you reference the full S3TC implementation: http://dri.freedesktop.org/wiki/S3TC All I am asking for is ALSO a reference to the restricted S2TC implementation there. I'd do it myself, if the page were not immutable. Have you actually talked to any distros? I have no contact person to these, thus no influence. I am at the moment preparing a PKGBUILD for Arch Linux, but that is about all I can do without having contact to people at the distros who decide such things. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 4.8.2011 12:19, Rudolf Polzer wrote: On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: On 08/03/2011 12:11 PM, Bryan Cain wrote: Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. Ian, I think it is really not the same issue. The S3TC patent is about the algorithm itself, not about copying blocks of memory. The quote from EXT_texture_compression_s3tc only underlines the fact that Direct3D stack (both runtime and driver) does not have to provide S3TC compression/decompression algorithm at all, whereas driver providing EXT_tc_s3tc typically has to be able to compress the textures in the software (and thus implement the patented stuff). Direct3D serves as a pass-through to the hardware, they don't have to mess with the patent at all while the hw vendor typically has the decompression part covered. Feeding precompressed data, however, is also none of Mesa's business - and also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is taking. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds a data block as is. So, if anyone needs IP rights then, it's the author of the game that comes with precompressed S3TC textures - and not the graphics driver! I had the similar argument several weeks ago. I have suggested that Mesa could use similar approach I have seen several years ago with GL drivers on windows - ie. drivers reporting DXTn formats in the available compressed format list through the ARB_texture_compression, whereas _not_ listing EXT_tc_s3tc in the extension string, effectively doing the same thing as the Direct3D, allowing a passthrough of such data. I can only guess that the vendor didn't have had the compression part covered nor wanted to pay for that part at the given time. It worked well. 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] S2TC - yet another attempt to solve the S3TC issue
- Original Message - On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2011 12:11 PM, Bryan Cain wrote: On 08/03/2011 01:58 PM, Ian Romanick wrote: I think this solves the issue for the compressor and for the software decompressor. I don't think this solves the problem for the decompressor for hardware drivers, so that may still pose a problem for Linux distros. Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. Why should exactly Mesa be the one to have IP rights then? Mesa doesn't feed S3TC data anywhere, when using S2TC or another alternative. Feeding self-compressed S2TC data is no issue, as it doesn't use any of the S3TC IP. How the GPU actually decodes it, is none of Mesa's business. It's not black and white: there can be both direct and indirect infringement on certain certain countries. Please read patent law and/or contract a real lawyer. Feeding precompressed data, however, is also none of Mesa's business - and also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is taking. False. Mesa does NOT already do this. It needs an additional component to enable S3TC, which is clearly marked as third-party IP sensitive, and advise people to contact a lawyer or obtain a license. So please stop making false accusations. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds a data block as is. So, if anyone needs IP rights then, it's the author of the game that comes with precompressed S3TC textures - and not the graphics driver! More conclusions based on false premises... At least that's my opinion (IANAL too). Don't get me wrong, I think S2TC's an interesting piece of work, but how do you dare to presume to tell us what we should or should not do in legal matters, while claiming to not be a lawyer, nor offering to pay legal expenses resulting from following your advice? You must think really highly of yourself, or think we are really dumb to not have thought/discussed this till now. We need this sort of IANAL opinions just as much as we need chronic tooth pain. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Sun, Aug 07, 2011 at 06:48:39PM -0700, Jose Fonseca wrote: - Original Message - On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2011 12:11 PM, Bryan Cain wrote: On 08/03/2011 01:58 PM, Ian Romanick wrote: I think this solves the issue for the compressor and for the software decompressor. I don't think this solves the problem for the decompressor for hardware drivers, so that may still pose a problem for Linux distros. Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. Why should exactly Mesa be the one to have IP rights then? Mesa doesn't feed S3TC data anywhere, when using S2TC or another alternative. Feeding self-compressed S2TC data is no issue, as it doesn't use any of the S3TC IP. How the GPU actually decodes it, is none of Mesa's business. It's not black and white: there can be both direct and indirect infringement on certain certain countries. Please read patent law and/or contract a real lawyer. I am German. So you say US patent law is more ridiculous than I could ever imagine. To summarize: If you feed data X to decoder circuit A, you may not need a patent license, while feeding the VERY SAME data X to decoder circuit B you may suddenly need one, ONLY because of the nature of how the circuits A and B work? Ridiculous, but if this is law, we have to accept it. Feeding precompressed data, however, is also none of Mesa's business - and also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is taking. False. Mesa does NOT already do this. It needs an additional component to enable S3TC, which is clearly marked as third-party IP sensitive, and advise people to contact a lawyer or obtain a license. So please stop making false accusations. Wrong, Mesa does. There is a driconf option that enables S3TC uploading (by claiming extension support) even if libtxc_dxtn is not present. So the code to do this already comes with Mesa, it just needs a configuration option to be enabled. Furthermore, IIRC some games ALREADY toggle this option on startup so they can upload S3TC textures with Mesa (I forgot which game that is, though). At least that's my opinion (IANAL too). Don't get me wrong, I think S2TC's an interesting piece of work, but how do you dare to presume to tell us what we should or should not do in legal matters, while claiming to not be a lawyer, nor offering to pay legal expenses resulting from following your advice? You must think really highly of yourself, or think we are really dumb to not have thought/discussed this till now. We need this sort of IANAL opinions just as much as we need chronic tooth pain. We have a problem and need to work towards a solution. I am not saying that my solution is the right one. I am saying we have to work towards one, and need people who are actually qualified to do it. I provided an idea, and we need to find ou if this idea is viable. As, Mesa not supporting S3TC, ever will be the end of linux gaming before it really started. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2011 12:11 PM, Bryan Cain wrote: On 08/03/2011 01:58 PM, Ian Romanick wrote: I think this solves the issue for the compressor and for the software decompressor. I don't think this solves the problem for the decompressor for hardware drivers, so that may still pose a problem for Linux distros. Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. Why should exactly Mesa be the one to have IP rights then? Mesa doesn't feed S3TC data anywhere, when using S2TC or another alternative. Feeding self-compressed S2TC data is no issue, as it doesn't use any of the S3TC IP. How the GPU actually decodes it, is none of Mesa's business. Feeding precompressed data, however, is also none of Mesa's business - and also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is taking. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds a data block as is. So, if anyone needs IP rights then, it's the author of the game that comes with precompressed S3TC textures - and not the graphics driver! Or does this cause a ridculous interpretation where Mesa COULD legally use this interface ONLY if it verifies the bitstream of the texture to see that no S3TC IP is used by it, or fixes it by turning S3TC into S2TC by a proper mapping of pixel values? At least that's my opinion (IANAL too). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 1, 2011 at 11:44 AM, Rudolf Polzer divver...@xonotic.org wrote: Hi, I developed, together with Maik Merten, a replacement for S3TC with the following properties: - does not use any interesting algorithms (no color ramps, each 4x4 block is just a 2 colors palette - basically, this is Color Cell Compression from August 1986) - is perfectly decodable by any S3TC decoder - can somewhat (at a noticeable quality loss) attempt to decode S3TC - due to the simpler nature of the algorithm, it outperforms the S3TC libtxc_dxtn - due to the compression being simpler, it was easier to write a good compression algorithm for it, and it sometimes yields better quality than NVidia Texture Tools encoding to full S3TC It is called S2TC because each block only has 2 colors, and expands to Super Simple Texture Compression. It comes in form of a libtxc_dxtn replacement library, so it can be used with Mesa right now. You can find more info on https://github.com/divVerent/s2tc/wiki including quality comparison pictures that compare it to full S3TC. When used in conjunction with an OpenGL driver, this would mean: - when a precompressed texture is uploaded, nothing changes - it is uploaded as full S3TC - when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder, which typically yields less quality than a S3TC encoder, but still renders correctly and usually good enough (see screenshots on my wiki) - in case a software fallback hits (or llvmpipe is used), S2TC is used for decoding - due to some bit values only being defined in the full S3TC format spec, this will be somewhat wrong and yields reduced quality when precompressed S3TC textures are used - I believe this suffices to claim support for GL_EXT_texture_compression_s3tc without having an actual S3TC compressor, as compressing to a sub-format of S3TC is the same as just having a less clever S3TC compressor. Decompressing being incorrect (but still good enough for most uses) in case of software fallbacks however may be a problem, but then one could still instead upload it to the GPU, let it decode it, and download the decoded texture instead The question now is: - does Mesa have any interest in integrating this method (doesn't have to be my reference implementation, which implements quite many selectable variations of the encoding methods), and still using full S3TC if a libtxc_dxtn is found? - or would Mesa be interested in linking to this implementation as an alternative to full libtxc_dxtn especially for the USA, as it's likely that less licenses are required to use this method? One possible implementation BTW could be Linux distros shipping S2TC libtxc_dxtn by default, and providing a simple way for users to upgrade to a full S3TC library, if they are aware of the issues with it and see themselves not affected by them? Hi, I saw the story about this on Phronix a couple weeks ago. I like it. As far as I'm concerned, I think it would be OK to integrate this into Mesa to use as a fallback when libtxc_dxtn isn't available. Does anyone else have an opinion? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2011 08:04 AM, Brian Paul wrote: On Mon, Aug 1, 2011 at 11:44 AM, Rudolf Polzer divver...@xonotic.org wrote: Hi, I developed, together with Maik Merten, a replacement for S3TC with the following properties: - does not use any interesting algorithms (no color ramps, each 4x4 block is just a 2 colors palette - basically, this is Color Cell Compression from August 1986) - is perfectly decodable by any S3TC decoder - can somewhat (at a noticeable quality loss) attempt to decode S3TC - due to the simpler nature of the algorithm, it outperforms the S3TC libtxc_dxtn - due to the compression being simpler, it was easier to write a good compression algorithm for it, and it sometimes yields better quality than NVidia Texture Tools encoding to full S3TC It is called S2TC because each block only has 2 colors, and expands to Super Simple Texture Compression. It comes in form of a libtxc_dxtn replacement library, so it can be used with Mesa right now. You can find more info on https://github.com/divVerent/s2tc/wiki including quality comparison pictures that compare it to full S3TC. When used in conjunction with an OpenGL driver, this would mean: - when a precompressed texture is uploaded, nothing changes - it is uploaded as full S3TC - when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder, which typically yields less quality than a S3TC encoder, but still renders correctly and usually good enough (see screenshots on my wiki) - in case a software fallback hits (or llvmpipe is used), S2TC is used for decoding - due to some bit values only being defined in the full S3TC format spec, this will be somewhat wrong and yields reduced quality when precompressed S3TC textures are used - I believe this suffices to claim support for GL_EXT_texture_compression_s3tc without having an actual S3TC compressor, as compressing to a sub-format of S3TC is the same as just having a less clever S3TC compressor. Decompressing being incorrect (but still good enough for most uses) in case of software fallbacks however may be a problem, but then one could still instead upload it to the GPU, let it decode it, and download the decoded texture instead The question now is: - does Mesa have any interest in integrating this method (doesn't have to be my reference implementation, which implements quite many selectable variations of the encoding methods), and still using full S3TC if a libtxc_dxtn is found? - or would Mesa be interested in linking to this implementation as an alternative to full libtxc_dxtn especially for the USA, as it's likely that less licenses are required to use this method? One possible implementation BTW could be Linux distros shipping S2TC libtxc_dxtn by default, and providing a simple way for users to upgrade to a full S3TC library, if they are aware of the issues with it and see themselves not affected by them? Hi, I saw the story about this on Phronix a couple weeks ago. I like it. As far as I'm concerned, I think it would be OK to integrate this into Mesa to use as a fallback when libtxc_dxtn isn't available. Does anyone else have an opinion? I think this solves the issue for the compressor and for the software decompressor. I don't think this solves the problem for the decompressor for hardware drivers, so that may still pose a problem for Linux distros. Of course, all of this may actually be irrelevant soon: http://www.litigatingapple.com/blog/2011/7/24/why-htcs-courtship-of-s3-might-be-too-clever-by-half.html I think the ideal solution would be to have something in core Mesa that could eventually evolve into full S3TC support. When this happens, I don't think libtxc_dxtn is the best answer. I think libsquish (http://code.google.com/p/libsquish/) is probably a better answer. This library is used in other projects, and it has quite a bit more optimized implementation. What we really want is to just do the compression on the GPU, but that's a bit larger project. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk45ml4ACgkQX1gOwKyEAw9A7wCeL5ZUq/9uGekga8n+Okc64hFT qmgAoIEWClN8Tsc19ZqXS41BBfGa8ujX =+djR -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 08/03/2011 01:58 PM, Ian Romanick wrote: On 08/03/2011 08:04 AM, Brian Paul wrote: On Mon, Aug 1, 2011 at 11:44 AM, Rudolf Polzer divver...@xonotic.org wrote: Hi, I developed, together with Maik Merten, a replacement for S3TC with the following properties: - does not use any interesting algorithms (no color ramps, each 4x4 block is just a 2 colors palette - basically, this is Color Cell Compression from August 1986) - is perfectly decodable by any S3TC decoder - can somewhat (at a noticeable quality loss) attempt to decode S3TC - due to the simpler nature of the algorithm, it outperforms the S3TC libtxc_dxtn - due to the compression being simpler, it was easier to write a good compression algorithm for it, and it sometimes yields better quality than NVidia Texture Tools encoding to full S3TC It is called S2TC because each block only has 2 colors, and expands to Super Simple Texture Compression. It comes in form of a libtxc_dxtn replacement library, so it can be used with Mesa right now. You can find more info on https://github.com/divVerent/s2tc/wiki including quality comparison pictures that compare it to full S3TC. When used in conjunction with an OpenGL driver, this would mean: - when a precompressed texture is uploaded, nothing changes - it is uploaded as full S3TC - when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder, which typically yields less quality than a S3TC encoder, but still renders correctly and usually good enough (see screenshots on my wiki) - in case a software fallback hits (or llvmpipe is used), S2TC is used for decoding - due to some bit values only being defined in the full S3TC format spec, this will be somewhat wrong and yields reduced quality when precompressed S3TC textures are used - I believe this suffices to claim support for GL_EXT_texture_compression_s3tc without having an actual S3TC compressor, as compressing to a sub-format of S3TC is the same as just having a less clever S3TC compressor. Decompressing being incorrect (but still good enough for most uses) in case of software fallbacks however may be a problem, but then one could still instead upload it to the GPU, let it decode it, and download the decoded texture instead The question now is: - does Mesa have any interest in integrating this method (doesn't have to be my reference implementation, which implements quite many selectable variations of the encoding methods), and still using full S3TC if a libtxc_dxtn is found? - or would Mesa be interested in linking to this implementation as an alternative to full libtxc_dxtn especially for the USA, as it's likely that less licenses are required to use this method? One possible implementation BTW could be Linux distros shipping S2TC libtxc_dxtn by default, and providing a simple way for users to upgrade to a full S3TC library, if they are aware of the issues with it and see themselves not affected by them? Hi, I saw the story about this on Phronix a couple weeks ago. I like it. As far as I'm concerned, I think it would be OK to integrate this into Mesa to use as a fallback when libtxc_dxtn isn't available. Does anyone else have an opinion? I think this solves the issue for the compressor and for the software decompressor. I don't think this solves the problem for the decompressor for hardware drivers, so that may still pose a problem for Linux distros. Pardon my ignorance, but why do hardware drivers need a decompressor? Bryan Of course, all of this may actually be irrelevant soon: http://www.litigatingapple.com/blog/2011/7/24/why-htcs-courtship-of-s3-might-be-too-clever-by-half.html I think the ideal solution would be to have something in core Mesa that could eventually evolve into full S3TC support. When this happens, I don't think libtxc_dxtn is the best answer. I think libsquish (http://code.google.com/p/libsquish/) is probably a better answer. This library is used in other projects, and it has quite a bit more optimized implementation. What we really want is to just do the compression on the GPU, but that's a bit larger project. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2011 12:11 PM, Bryan Cain wrote: On 08/03/2011 01:58 PM, Ian Romanick wrote: I think this solves the issue for the compressor and for the software decompressor. I don't think this solves the problem for the decompressor for hardware drivers, so that may still pose a problem for Linux distros. Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk45peMACgkQX1gOwKyEAw9p+ACgiCiOZLUcLM4ItXGtCKWvlRTl +wMAnA3wUg5WcXsgwsZZQnq+iCT2Rr7h =6myP -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
Hi, I developed, together with Maik Merten, a replacement for S3TC with the following properties: - does not use any interesting algorithms (no color ramps, each 4x4 block is just a 2 colors palette - basically, this is Color Cell Compression from August 1986) - is perfectly decodable by any S3TC decoder - can somewhat (at a noticeable quality loss) attempt to decode S3TC - due to the simpler nature of the algorithm, it outperforms the S3TC libtxc_dxtn - due to the compression being simpler, it was easier to write a good compression algorithm for it, and it sometimes yields better quality than NVidia Texture Tools encoding to full S3TC It is called S2TC because each block only has 2 colors, and expands to Super Simple Texture Compression. It comes in form of a libtxc_dxtn replacement library, so it can be used with Mesa right now. You can find more info on https://github.com/divVerent/s2tc/wiki including quality comparison pictures that compare it to full S3TC. When used in conjunction with an OpenGL driver, this would mean: - when a precompressed texture is uploaded, nothing changes - it is uploaded as full S3TC - when an uncompressed texture is uploaded as a compressed format, it is converted using the S2TC encoder, which typically yields less quality than a S3TC encoder, but still renders correctly and usually good enough (see screenshots on my wiki) - in case a software fallback hits (or llvmpipe is used), S2TC is used for decoding - due to some bit values only being defined in the full S3TC format spec, this will be somewhat wrong and yields reduced quality when precompressed S3TC textures are used - I believe this suffices to claim support for GL_EXT_texture_compression_s3tc without having an actual S3TC compressor, as compressing to a sub-format of S3TC is the same as just having a less clever S3TC compressor. Decompressing being incorrect (but still good enough for most uses) in case of software fallbacks however may be a problem, but then one could still instead upload it to the GPU, let it decode it, and download the decoded texture instead The question now is: - does Mesa have any interest in integrating this method (doesn't have to be my reference implementation, which implements quite many selectable variations of the encoding methods), and still using full S3TC if a libtxc_dxtn is found? - or would Mesa be interested in linking to this implementation as an alternative to full libtxc_dxtn especially for the USA, as it's likely that less licenses are required to use this method? One possible implementation BTW could be Linux distros shipping S2TC libtxc_dxtn by default, and providing a simple way for users to upgrade to a full S3TC library, if they are aware of the issues with it and see themselves not affected by them? Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
