Status of s3tc patent in respect to open-source drivers and workarounds
Hi radeonhd, nouveau, mesa3d developers, Firstly, thank you all very much for all the important work you do. I've been working as a part-time developer on the "Spring RTS" project (open-source game engine) which runs on linux (and other os). Some time ago I tried the engine on the open-source ATI radeonhd driver, which I understand to be partly based on mesa 3d, and all textures were white. I originally assumed it was an engine bug but after some investigation tracked it down to s3tc texture (de)compression not being integrated in the open driver for legal reasons. It seems the same issue applies to Mesa3d and Nouveau - that is s3tc being patented and the patent owner refusing to comment or provide cover for open-source projects implementing the techniques discussed in US Patent 5956431 (http://v3.espacenet.com/publicationDetails/claims?DB=&locale=&FT=D&date=19990921&CC=US&NR=5956431A&KC=A&tree=true) I recently took inspiration from an article/talk presented by Andrew Trigell regarding patents where he claims developers often overestimate the scope of patents (http://news.swpat.org/2010/03/transcript-tridgell-patents/) because they fixate on the title and summary instead of the actual claims. The key point he was making is that in order to infringe a patent you apparently have to infringe on ALL ELEMENTS of a PRIMARY claim. If you don't do something in the primary claim then by definition you aren't doing the things in secondary claims that reference it (ie, where the claim reads "... in claim X ..."). In short if you workaround the primary claims you probably aren't infringing. Wikipeadia, with some jurisdictional hand-waving, appears to agree: "If all of the claim's elements are found in the technology, the claim is said to "read on" the technology; if a single element from the claim is missing from the technology, the claim does not literally read on the technology and the technology does not infringe the patent with respect to that claim." So I took a look at the 4 primary claims that apply to DECODING s3tc textures. All other claims either rely on these claims or involve encoding, which Mesa 3D / Xorg drivers should not need to do. Finding a workaround for these primary claims is necessary to avoid infringement for an s3tc decoder. I'll break these into seperate elements because a workaround (non-infringement) for ANY element is a workaround for the ENTIRE claim itself. The elements are seperated by semicolons and I've added line-breaks to make them clearer). To avoid confusion I've removed the preamble from each claim, they don't count as elements of the claim. In short, if anyone on these lists can see a way to decompress an s3tc image without doing just 1 of the items from EACH of the following 4 claims then a legal s3tc decoder should be possible. ================ 5. an encoded image decomposer, coupled to receive encoded image data file having at least one compressed image block, for breaking the encoded image data file into individual compressed image blocks, each compressed image block having at least one associated codeword, each codeword generated through selecting a block type for an original image block comprising the compressed image block, computing an analog curve for the block type, selecting a partition along the analog curve for the computed analog curve, and computing the set of codewords for the partition; at least one block decoder, coupled to the encoded image decomposer, for decompressing the compressed image blocks; and an image composer, coupled to each block decoder, for ordering the decompressed image blocks in an output file. ================== 16. receiving the encoded image data; decomposing the encoded image into the modified header and the individual encoded image blocks; reading the modified header to generate an output header; decoding each individual encoded image block to generate a decoded image block, including receiving each individual encoded image block, including a plurality of codewords, and a bitmap of at least one pixel, the plurality of codewords derived through selecting a block type for an original image block of the encoded image block, computing an analog curve for the block type, selecting a partition along the analog curve for the computed analog curve, and computing the plurality of codewords for the partition; and composing the output header and the individual decoded image blocks to generate an output file of the original image. ================== 21. a block address computation module, coupled to receive each codeword from the header information, for computing an address of an encoded image block having the identified pixel; a block fetching module, coupled to receive the encoded image block portion and the computed address, for fetching the encoded image block having the identified pixel; and a block decoder, coupled to receive the fetched encoded image block, for decoding the image block to generate a quantized color associated with the identified pixel. ================== 22. computing an address for an encoded image block having the identified pixel, the address computed from the at least one codeword for the encoded image block; fetching the encoded image block using the computed address; computing quantized color levels for the fetched encoded image block; and selecting a color of the identified pixel from the quantized color levels to output. =================== One thing that stands out to me are that none of the primary claims seem to describe the technical format itself (ie, no algorithms, keywords, block sizes, byte-alignment, etc..) This means the claims at issue seem to be *methods* of data handling, (and not particularly inventive ones in my opinion). That suggests to me that with a little thought it should be possible to generate the same results via a method that doesn't infringe one of the 4 specific claims listed above. To clarify, despite all the technical mumbling in the abstract the claimed invention does not appear to be a "format" as such, but a method of pulling "blocks" and a "header" out of an undefined format and generating "color pixels". Even the abstract claims all the presented examples of keywords, values and structure for s3tc are not the actual invention being claimed. Another important point is that some of the wording in the claims may not mean what it appears to mean (ie, the generally accepted definition), the full patent may redefine some common software terms in the wrapper. Some possible avenues of investigation, straight off the top of my head are: * Determine the patents' definition of a "unit" and/or "module", and use something else (ie, a monolithic function) * Determine the patents' definition of a "block", and use something else. (characters, a bytestream, ...) * Determine the patents' definition of "compose / decompose", and do something else. * Do we need to "compose a header" as a seperate stage (use a footer, temporary vars, registers) * Does the curve have to be "analog"? What about a lookup table with discreet points that approximate a curve? * Can the algorithms work on groups of blocks or sub-blocks instead of "individual blocks". More for DRI projects than Mesa, but I'll ask anyway: * Do we need to decode anything; could an X11 driver force-feed the raw bytes to hardware instead? Claim 22 seems like a pretty important step and possibly a hard one to workaround but it also appears to be claiming the invention of using a key lookup to fetch values with some vague notion of quantising them. Is it just me or are they claiming to have invented indexed color? PS. If some of the points above seem pedantic that's deliberate. My understanding is that patent claims are actually intended or required to be NARROW in scope as broad claims are usually rejected. That means a workaround that doesn't do PRECISELY the things in each claim above is, by definition, a new invention. I'm hoping an invention that members of this community are capable of finding before someone else patents it. I've CC'ed the EFF on this because I'd like to see it become a part of their patent-busting efforts. Fear of this patent is blocking an extremely important component of 3D gaming under linux (the use of DDS textures under an open-source driver). Not that I'm a fan of DDS, just that it's the format of choice for commercial and non-commercial games until hardware supports something better, and even then still a requirement for running many classic games under WINE + radeonhd/mesa3d/nouveau. It seems absurd that I can buy a product with a patent license granted (NVIDIA/ATI card) but then be denied the protection of that license because I don't use part of the product (the official driver). I really hope that as a community we can either invent around this patent or bust it (at least in US / EU where it is most problematic) without losing hardware support or requiring the reformatting/conversion of digital assets. Regards, SpliFF -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
If the application provides s3tc-encoded data through glCompressedTexImage (usually loaded from a pre-compressed texture stored on disk), Mesa will pass it unaltered to the graphics card (as long as the driver/card supports DXT* format ids) and will not need to use any encoding or decoding algorithms. The problem is that if the application supplies uncompressed data, Mesa would need to run an encoding algorithm to be able to use compressed textures. Conversely, if software rendering is necessary, and the application provides compressed textures, Mesa will need to run a decoding algorithm to be able to sample from the texture. So the workaround (and what commercial games usually do) is to ship pre-compressed textures along with the game, as well as uncompressed textures in case the card/rendered do not support texture compression. An end-user side solution is to download, compile and install libtxc_dxtn.so, which Mesa will use if present to decode and encode compressed textures. Furthermore, a GPU can be used to do decoding using its native sampling support, and some may also support encoding. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sun, Mar 28, 2010 at 4:47 AM, SpliFF
Hi radeonhd, nouveau, mesa3d developers,
Firstly, thank you all very much for all the important work you do.
I've been working as a part-time developer on the "Spring RTS" project (open-source game engine) which runs on linux (and other os). Some time ago I tried the engine on the open-source ATI radeonhd driver, which I understand to be partly based on mesa 3d, and all textures were white. I originally assumed it was an engine bug but after some investigation tracked it down to s3tc texture (de)compression not being integrated in the open driver for legal reasons. It seems the same issue applies to Mesa3d and Nouveau - that is s3tc being patented and the patent owner refusing to comment or provide cover for open-source projects implementing the techniques discussed in US Patent 5956431 (http://v3.espacenet.com/publicationDetails/claims?DB=&locale=&FT=D&date=19990921&CC=US&NR=5956431A&KC=A&tree=true)
I recently took inspiration from an article/talk presented by Andrew Trigell regarding patents where he claims developers often overestimate the scope of patents (http://news.swpat.org/2010/03/transcript-tridgell-patents/) because they fixate on the title and summary instead of the actual claims.
The key point he was making is that in order to infringe a patent you apparently have to infringe on ALL ELEMENTS of a PRIMARY claim. If you don't do something in the primary claim then by definition you aren't doing the things in secondary claims that reference it (ie, where the claim reads "... in claim X ..."). In short if you workaround the primary claims you probably aren't infringing. Wikipeadia, with some jurisdictional hand-waving, appears to agree: "If all of the claim's elements are found in the technology, the claim is said to "read on" the technology; if a single element from the claim is missing from the technology, the claim does not literally read on the technology and the technology does not infringe the patent with respect to that claim."
So I took a look at the 4 primary claims that apply to DECODING s3tc textures. All other claims either rely on these claims or involve encoding, which Mesa 3D / Xorg drivers should not need to do. Finding a workaround for these primary claims is necessary to avoid infringement for an s3tc decoder. I'll break these into seperate elements because a workaround (non-infringement) for ANY element is a workaround for the ENTIRE claim itself. The elements are seperated by semicolons and I've added line-breaks to make them clearer).
To avoid confusion I've removed the preamble from each claim, they don't count as elements of the claim.
In short, if anyone on these lists can see a way to decompress an s3tc image without doing just 1 of the items from EACH of the following 4 claims then a legal s3tc decoder should be possible.
================ 5. an encoded image decomposer, coupled to receive encoded image data file having at least one compressed image block, for breaking the encoded image data file into individual compressed image blocks, each compressed image block having at least one associated codeword, each codeword generated through selecting a block type for an original image block comprising the compressed image block, computing an analog curve for the block type, selecting a partition along the analog curve for the computed analog curve, and computing the set of codewords for the partition;
at least one block decoder, coupled to the encoded image decomposer, for decompressing the compressed image blocks;
and an image composer, coupled to each block decoder, for ordering the decompressed image blocks in an output file.
================== 16. receiving the encoded image data;
decomposing the encoded image into the modified header and the individual encoded image blocks;
reading the modified header to generate an output header;
decoding each individual encoded image block to generate a decoded image block, including receiving each individual encoded image block, including a plurality of codewords, and a bitmap of at least one pixel, the plurality of codewords derived through selecting a block type for an original image block of the encoded image block, computing an analog curve for the block type, selecting a partition along the analog curve for the computed analog curve, and computing the plurality of codewords for the partition;
and composing the output header and the individual decoded image blocks to generate an output file of the original image.
================== 21. a block address computation module, coupled to receive each codeword from the header information, for computing an address of an encoded image block having the identified pixel;
a block fetching module, coupled to receive the encoded image block portion and the computed address, for fetching the encoded image block having the identified pixel;
and a block decoder, coupled to receive the fetched encoded image block, for decoding the image block to generate a quantized color associated with the identified pixel.
================== 22. computing an address for an encoded image block having the identified pixel, the address computed from the at least one codeword for the encoded image block;
fetching the encoded image block using the computed address;
computing quantized color levels for the fetched encoded image block;
and selecting a color of the identified pixel from the quantized color levels to output.
===================
One thing that stands out to me are that none of the primary claims seem to describe the technical format itself (ie, no algorithms, keywords, block sizes, byte-alignment, etc..) This means the claims at issue seem to be *methods* of data handling, (and not particularly inventive ones in my opinion). That suggests to me that with a little thought it should be possible to generate the same results via a method that doesn't infringe one of the 4 specific claims listed above. To clarify, despite all the technical mumbling in the abstract the claimed invention does not appear to be a "format" as such, but a method of pulling "blocks" and a "header" out of an undefined format and generating "color pixels". Even the abstract claims all the presented examples of keywords, values and structure for s3tc are not the actual invention being claimed. Another important point is that some of the wording in the claims may not mean what it appears to mean (ie, the generally accepted definition), the full patent may redefine some common software terms in the wrapper.
Some possible avenues of investigation, straight off the top of my head are:
* Determine the patents' definition of a "unit" and/or "module", and use something else (ie, a monolithic function) * Determine the patents' definition of a "block", and use something else. (characters, a bytestream, ...) * Determine the patents' definition of "compose / decompose", and do something else. * Do we need to "compose a header" as a seperate stage (use a footer, temporary vars, registers) * Does the curve have to be "analog"? What about a lookup table with discreet points that approximate a curve? * Can the algorithms work on groups of blocks or sub-blocks instead of "individual blocks".
More for DRI projects than Mesa, but I'll ask anyway: * Do we need to decode anything; could an X11 driver force-feed the raw bytes to hardware instead?
Claim 22 seems like a pretty important step and possibly a hard one to workaround but it also appears to be claiming the invention of using a key lookup to fetch values with some vague notion of quantising them. Is it just me or are they claiming to have invented indexed color?
PS. If some of the points above seem pedantic that's deliberate. My understanding is that patent claims are actually intended or required to be NARROW in scope as broad claims are usually rejected. That means a workaround that doesn't do PRECISELY the things in each claim above is, by definition, a new invention. I'm hoping an invention that members of this community are capable of finding before someone else patents it.
I've CC'ed the EFF on this because I'd like to see it become a part of their patent-busting efforts. Fear of this patent is blocking an extremely important component of 3D gaming under linux (the use of DDS textures under an open-source driver). Not that I'm a fan of DDS, just that it's the format of choice for commercial and non-commercial games until hardware supports something better, and even then still a requirement for running many classic games under WINE + radeonhd/mesa3d/nouveau. It seems absurd that I can buy a product with a patent license granted (NVIDIA/ATI card) but then be denied the protection of that license because I don't use part of the product (the official driver). I really hope that as a community we can either invent around this patent or bust it (at least in US / EU where it is most problematic) without losing hardware support or requiring the reformatting/conversion of digital assets.\
Since neither you nor Andrew are lawyers, I would kindly ask that you
refrain from attempting to provide legal advice. :3
The scant legal advice that *has* been obtained suggests that the
current course of action, wherein S3TC is not advertised without the
aid of an external library or a configuration option force-enabling
it, is the best course of action. I for one would prefer to have
firsthand legal advice before making any changes, although I am not a
lawyer and cannot provide legal advice.
At any rate, since Spring is open-source, I would heavily advise the
Spring team to remember that OpenGL extensions that are not part of a
core version are not guaranteed to be available, and in this case,
there is a trivial workaround for when the extension is not present,
so you guys could (and should!) include an uncompressed texture path
and ship uncompressed textures.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
On 03/29/10 11:07, Corbin Simpson wrote:On 03/29/10 11:07, Corbin Simpson wrote:
Since neither you nor Andrew are lawyers, I would kindly ask that you refrain from attempting to provide legal advice. :3
If you know I'm not a lawyer (and my nick should be the first clue) then it isn't an issue is it? As for Andrew you'll have to ask him that yourself. Since it's also clear I'm not a mesa3d developer you assume no legal responsibility for what I say either and you are under no responsibility to listen. Which is all irrelevant anyway because proposing to create a new invention is not legal advice; it's an engineering suggestion. I describe the patent claims and Andrews interpretation of patent law only to emphasise things that a hypothetical new invention should *not* do.
The scant legal advice that *has* been obtained suggests that the current course of action, wherein S3TC is not advertised without the aid of an external library or a configuration option force-enabling it, is the best course of action. I for one would prefer to have firsthand legal advice before making any changes, although I am not a lawyer and cannot provide legal advice.
Solves nothing other than push the legal burden onto someone else (distributions) who further push the burden to the end-user. All of which makes it harder to use. As far as I can tell the official site of the "external project" claims the project is unmaintained and at any rate it's rather unpopular with certain distributions for reasons that should be obvious. I'm certainly not sugesting that knowingly infringing material be added to mesa3d. What I'm suggesting is that some resources be made available to write a new *non-infringing* decompressor and that it seems likely the community may have overestimated the difficulty of the task. I often wonder if the OSS community isn't becoming a victim of its own FUD. If we need lawyers before writing code then we can't write ANY code and we might as well all do something else. I want to reiterate that it is my belief (as in non-legal opinion) that the s3tc patent does not cover the s3tc format itself, or even specific algorithms. What it covers appear to be specific methods that can be used to encode it and some steps that can be used to decode it. The issue is whether those claimed steps are the ONLY way of achieving an acceptable result and I honestly don't think they are. You are free to form your own opinion on that point. Then again if the community plays ostrich and assumes the problem is now solved - and worse concludes that any discussion of it is heresy - then how can a new invention be developed (at least collaboratively)? Unfortunately I lack the indepth knowledge of mesa3d internals and s3tc processing requirements required to invent such a thing myself.
At any rate, since Spring is open-source, I would heavily advise the Spring team to remember that OpenGL extensions that are not part of a core version are not guaranteed to be available, and in this case, there is a trivial workaround for when the extension is not present, so you guys could (and should!) include an uncompressed texture path and ship uncompressed textures.
Unfortunately Spring is an engine, not a game. The issue is that people writing games which use the engine typically use DDS textures due to various community members bandying the format about like it's the second coming. At any rate other than not supporting DDS at all (which would be an extremely unpopular and unworkable decision) there isn't much I can do to guarantee Spring games don't depend on proprietary drivers until a non-infringing s3tc decoder exists. SpliFF -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Sun, Mar 28, 2010 at 6:39 PM, SpliFF
Solves nothing other than push the legal burden onto someone else (distributions) who further push the burden to the end-user. All of which makes it harder to use. As far as I can tell the official site of the "external project" claims the project is unmaintained and at any rate it's rather unpopular with certain distributions for reasons that should be obvious.
I'm certainly not sugesting that knowingly infringing material be added to mesa3d. What I'm suggesting is that some resources be made available to write a new *non-infringing* decompressor and that it seems likely the community may have overestimated the difficulty of the task. I often wonder if the OSS community isn't becoming a victim of its own FUD. If we need lawyers before writing code then we can't write ANY code and we might as well all do something else.
There is already a non-infringing decoder inside Mesa, wired up correctly, that kicks in when the HW supports it, but there's no extension that exposes only decoding and loading functionality. As Ian said, you need an encoder as well, and no HW has it, so you'd have to write some questionable code.
I want to reiterate that it is my belief (as in non-legal opinion) that the s3tc patent does not cover the s3tc format itself, or even specific algorithms. What it covers appear to be specific methods that can be used to encode it and some steps that can be used to decode it. The issue is whether those claimed steps are the ONLY way of achieving an acceptable result and I honestly don't think they are. You are free to form your own opinion on that point. Then again if the community plays ostrich and assumes the problem is now solved - and worse concludes that any discussion of it is heresy - then how can a new invention be developed (at least collaboratively)? Unfortunately I lack the indepth knowledge of mesa3d internals and s3tc processing requirements required to invent such a thing myself.
Cool, I'm glad that you share the opinion of other people on the Internets on this issue. Feel free to help keep libdxtn from bitrotting. However, many of the Mesa devs are paid, and their bosses have indicated that there are issues here, so don't hold your breath for any of us to do anything beyond maintain the interface to libdxtn. I'm kind of confused. Are you just trying to see if any of us can be convinced to write this code for you?
Unfortunately Spring is an engine, not a game. The issue is that people writing games which use the engine typically use DDS textures due to various community members bandying the format about like it's the second coming. At any rate other than not supporting DDS at all (which would be an extremely unpopular and unworkable decision) there isn't much I can do to guarantee Spring games don't depend on proprietary drivers until a non-infringing s3tc decoder exists.
SpliFF
Well, I can't help you there.
I'm sorry if I'm sounding antagonistic, but we've been over this many
times. The patents, to me and to many people who ostensibly have
received better legal advice, are too broadly written to be worked
around.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
On 03/29/10 15:34, Corbin Simpson wrote:
There is already a non-infringing decoder inside Mesa, wired up correctly, that kicks in when the HW supports it, but there's no extension that exposes only decoding and loading functionality. As Ian said, you need an encoder as well, and no HW has it, so you'd have to write some questionable code.
So to clarify, you're saying a partial implementation (decoder only) isn't an option at all? If you expose an extension it must be complete? Can't you just do a NOOP on encoding or handle it uncompressed? I don't see why the encoder is so important since it seems to me that uncompressed data would cause no issues for software rendering and compressed data should cause no issues for hardware rendering (as stated earlier, on most modern hardware you can pass it through to VRAM). The main problem seems to be the lack of a decoder as it makes assets completely unusable on certain platforms whereas lack of an encoder typically only impairs efficiency except in fringe cases (games that compress textures "on-the-fly").
I'm kind of confused. Are you just trying to see if any of us can be convinced to write this code for you?
Yes. Though not for me as I don't play the games in question. However that's an oversimplification. What I'm really asking is when it was concluded no workaround is possible, to what extent was it discussed or was it agreed that nobody should look at the patent at all (willful infringement defense)? Are the legal opinions you are referring to made public? Is the issue a lack or resources, lack of interest, lack of alternatives, lack of understanding or just a general fear of unspecified litigation or vague threats. It was also an attempt to see where the EFF sits on this issue and whether that would consider investigating some of the broader claims in the patent as part of their patent busting efforts. After all, if there really is NO possible workaround it kind of implies, to a layman at least, that the patents claims may be overly broad. I am simply following a sensible process of elimination, which is: a.) Determine what can't be done. b.) Determine what can be done. c.) Substitute b for a. If you won't touch it, then you won't. If you don't want to talk about it (again) I completely understand. I can't force you and I won't nag you. But there may be others out there, perhaps sitting on the sidelines, who might have something new to offer. At the least consider this a case of simple curiousity as the FAQ is somewhat vague on the matter and the specific claim(s) at issue unclear (at least to me). Even with access to the archives of this list I don't have the benefit of knowing the full extent to which this issue has been explored behind the scenes. I raised the points I raised to assist in a way that seems positive. That is to cut through several pages of patent legalese to the specific claim elements blocking a new type of decoder and then try build a preliminary technical assessment that could guide programmers around the hurdles or be reviewed by a patent attorney without completely wasting their time. SpliFF -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SpliFF wrote:
So to clarify, you're saying a partial implementation (decoder only) isn't an option at all? If you expose an extension it must be complete?
See the documentation for glGetCompressedTexImage. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuwQ3AACgkQX1gOwKyEAw9LIgCfemo+7toGx7bpVMjJs0Im6OF6 0bUAniJWsC75twOeyyS/7f3eu8OgueWM =26xL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On 03/29/10 17:06, Ian Romanick wrote:
SpliFF wrote:
So to clarify, you're saying a partial implementation (decoder only) isn't an option at all? If you expose an extension it must be complete?
See the documentation for glGetCompressedTexImage.
That does not appear to imply a run-time encoder. It seems to imply the data is already compressed - which could (and really should) be done prior to distribution (via the nvidia tools for example). The documentation does quite clearly state that the application should verify the texture really was compressed so you're only going to run into issues when the programmer made assumptions about the supported hardware. Not saying that's impossible, just that that's the programmers' responsibility, not the drivers. Runtime compression is actually performed by glTexImage2D with its internalFormat set to a supported *_S3TC_* value, however the 2.1 spec says: "If no corresponding internal format is available, or the GL can not compress that image for any reason, the internal format is instead replaced with a corresponding base internal format." For S3TC textures that is: GL_COMPRESSED_RGB_S3TC_DXT1_EXT -> RGB GL_COMPRESSED_RGBA_S3TC_DXT1_EXT -> RGBA GL_COMPRESSED_RGBA_S3TC_DXT3_EXT -> RGBA GL_COMPRESSED_RGBA_S3TC_DXT5_EXT -> RGBA So the spec specifically says you don't need runtime compression to be compliant, you can fall back to uncompressed and hide the distinction from the application (or expose it via glGetTexLevelParameteriv). Also, for the purpose of mesa3d software rendering, why would you really want to compress an image intended for system RAM? Chances are you'd lose significantly on rendering performance. The way I see it the worst case scenario is you use more memory than the developer intended but at least you're displaying the textures. I know from experience that any normal game rendered entirely without textures is basically unplayable. So really, what I'd like clarification on is whether anyone knows of potential non-infringing workarounds for the independent claims of the s3tc decoding process only (claims 5, 16, 21 and 22 in the patent). The rest (encoding) isn't as important as there are already free licensed tools available for that part (not to mention existing compressed assets to be rendered). Finally, if anyone on the nouveau/radeonhd lists would prefer I stop posting there please email me privately and I'll comply. If hardware passthrough of s3tc textures is in fact supported by those drivers (and the user has compatible hardware) then s3tc decoding is less relevant for that purpose and the discussion is really only relevant to mesa3d software rendering. I'm new to these lists and I didn't come here just to make people upset. I don't know how much crossover exists between the groups and who is getting three copies of these posts. SpliFF -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 SpliFF wrote:
On 03/29/10 17:06, Ian Romanick wrote:
SpliFF wrote:
So to clarify, you're saying a partial implementation (decoder only) isn't an option at all? If you expose an extension it must be complete? See the documentation for glGetCompressedTexImage.
That does not appear to imply a run-time encoder. It seems to imply the data is already compressed - which could (and really should) be done prior to distribution (via the nvidia tools for example). The documentation does quite clearly state that the application should verify the texture really was compressed so you're only going to run into issues when the programmer made assumptions about the supported hardware. Not saying that's impossible, just that that's the programmers' responsibility, not the drivers.
Runtime compression is actually performed by glTexImage2D with its internalFormat set to a supported *_S3TC_* value, however the 2.1 spec says:
"If no corresponding internal format is available, or the GL can not compress that image for any reason, the internal format is instead replaced with a corresponding base internal format."
I hate to admit it, but I think you are correct. Issue 10 in the GL_ARB_texture_compression, the first two bullets in particular, seems to support this. (10) Should functionality be provided to allow applications to save compressed images to disk and reuse them in subsequent runs without programming to specific formats? If so, how? RESOLVED: Yes. This can be done without knowledge of specific compression formats in the following manner: * Call TexImage with an uncompressed image and a generic compressed internal format. The texture image will be compressed by the GL, if possible. * Call GetTexLevelParameteriv with a <value> of TEXTURE_COMPRESSED_ARB to determine if the GL was able to store the image in compressed form. * Call GetTexLevelParameteriv with a <value> of TEXTURE_INTERNAL_FORMAT to determine the specific compressed image format in which the image is stored. * Call GetTexLevelParameteriv with a <value> of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB to determine the size (in ubytes) of the compressed image that will be returned by the GL. Allocate a buffer of at least this size. * Call GetCompressedTexImageARB. The GL will write the compressed texture image into the allocated buffer. * Save the returned compressed image to disk, along with the associated width, height, depth, border parameters and the returned values of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB and TEXTURE_INTERNAL_FORMAT. * Load the compressed image and its parameters, and call CompressedTexImage_[123]DARB to use the compressed image. The value of TEXTURE_INTERNAL_FORMAT should be used as <internalFormat> and the value of TEXTURE_COMPRESSED_IMAGE_SIZE_ARB should be used as <imageSize>. The saved images will be valid as long as they are used on a device supporting the returned <internalFormat> parameter. If the saved images are used on a device that does not support the compressed internal format, an INVALID_ENUM error would be generated by the call to CompressedTexImage_[123]D because of the unknown format. Note also that to reliably determine if the GL will compress an image without actually compressing it, an application need only define a proxy texture image and query TEXTURE_COMPRESSED_ARB as above. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuw6/wACgkQX1gOwKyEAw9cWQCfViC2igK2W7DvhtcDj8pXVd0F wJsAoJ0q1Pgp1sy6HVy9H9ihg/ms9oVR =OgUh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (4)
-
Corbin Simpson -
Ian Romanick -
Luca Barbieri -
SpliFF