On Mon, Mar 29, 2010 at 1:20 AM, SpliFF <spl...@warriorhut.org> 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."
>
> 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.
Un-CCing nouveau and radeonhd; the former are all subscribed here, and
the latter isn't a 3D driver list.
After re-reading ARB_texture_compression, it does seem like it is
legal for extensions such as EXT_texture_compression_s3tc to fall
back, using a basic mechanism: glGetTexLevelParameter can return
GL_FALSE for GL_TEXTURE_COMPRESSED_ARB (now GL_TEXTURE_COMPRESSED) if
the texture could not successfully be compressed. Issue (10) of
ARB_texture_compression deals with this explicitly:
"""
(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.
"""
So this gives us a way to language-lawyer our way out of that entire
half of the implementation. The other half, decompression, works if
the compressed format is supported as a texture: see
decompress_with_blit in the Gallium source. Gallium actually
explicitly enables the basic parts of the extension based on whether
or not it can use the compressed formats as samplers. (I am not sure
if it's going to be that easy for classic Mesa.)
So I think this covers all the paths, assuming Mesa implements the
internal_format semantics necessary, although I haven't done any
code-reading this morning yet. Ian, Brian, could you check my
reasoning? We might be able to save this.
~ C.
--
When the facts change, I change my mind. What do you do, sir? ~ Keynes
Corbin Simpson
<mostawesomed...@gmail.com>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
