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
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
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 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
would be necessary too. In case the DXT5 alpha encoding is commonly seen as NOT infringing the S3TC patents, which personally I am unsure about, then the S2TC tools could be changed to encode full DXT5 alpha (and S2TC code doing that is provided in the s2tc+alpha branch of my repository). This would obviously lose quality, but not any more than what the S2TC decompressor does when fed with S3TC data. But, even if this is _legally_ sound, it might be a bad idea to have a non-conforming implementation of GL_EXT_texture_compression_s3tc which this would be - especially, as a game that includes both S3TC and RGB encoded textures may, due to this quality loss, rather want to prefer RGB over S3TC. If the input is compressed using S2TC, though, no further quality loss would occur at this stage, as the operation described above would be the identity. 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. Good to know. 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 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 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
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
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 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
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 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
[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
