[Mesa-dev] Removing ARB_imaging subset extensions

Ian Romanick idr at freedesktop.org
Wed Sep 22 11:29:25 PDT 2010

Hash: SHA1

Jakob Bornecrantz wrote:
> On 20 sep 2010, at 19.58, Luca Barbieri wrote:
>> nVidia dropped hardware support starting from nv40.
>> For texture compression, S3TC or R-component-only textures should
>> usually be a better option, and for other uses shader-based techniques
>> are more flexible.
> The advantage is that lookup is done before filtering, while with
> shaders you need to do the filtering yourself.
> IIRC from XDS weren't there some ES extension that actually fit what
> hardware does better, or doesn't it fit the needs of apps as well? Then
> again I'm not for keeping this code.

On OpenGL ES there is GL_OES_compressed_paletted_texture.


I got to thinking about paletted textures a bit more.  The OES extension
isn't that much better for us.  Hardware still can't really use palettes
because you can still have the case where there are more texture
palettes than hardware palettes.  This means that hardware with fewer
hardware palettes than texture units has to expand every texture to full
RGBA all the time.  That basically makes the extension worthless.

The one advantage of the OES extension over the EXT is that the palette
is fixed at texture upload in the OES version.  In the EXT version the
palette can change at any time.

It seems that if we want to support any of this, including the OES
extension, we want a way to have both a paletted and an RGBA version of
each texture.  This allows the driver to pick the version of the texture
that will work at any time.

If we care about supporting the OES extension, the existing palette
support should probably stay.
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the mesa-dev mailing list