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