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 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 don't see a problem with that. EXT_texture_compression_latc and 3dc > use the DXT5 alpha encoding for both luminance and alpha. rgtc is the > same as latc, but the components are swizzled to rg. There is already > a DXT5 alpha encoder/decoder included in Mesa to support rgtc, latc, > and 3dc. There are no IP claims for those extensions whatsoever. > > Marek > _______________________________________________ > 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
