Re: [Mesa3d-dev] Proposed new DD texture interface

[Brian P. <br...@va...>]

Gareth Hughes wrote:
> 
> After looking into the current single-copy texture mechanism, I'd like
> to propose a couple of changes.  This will involve completely removing
> the old interface, as well as providing a much more driver-friendly
> approach to texture image storage.  Many of these ideas are similar to
> features found in the SI, at least from the top level.  The
> implementation of these ideas would be quite different in our case,
> however.
> 
> First, we add a struct gl_texture_format as follows:
> 
> struct gl_texture_format {
>    GLint internalFormat;        /* Mesa format */
> 
>    GLint redSize;
>    GLint greenSize;
>    GLint blueSize;
>    GLint alphaSize;
>    GLint luminanceSize;
>    GLint intensitySize;
>    GLint indexSize;
> 
>    GLint bytesPerTexel;
> 
>    /* Functions to return individual texels.
>     */
>    void (*extractTexel)(...);
>    ...
> };
> 
> We define a set of these structures:
> 
> const struct gl_texture_format gl_tex_format_argb8888 = {
>    MESA_FORMAT_ARGB8888,
>    8, 8, 8, 8, 0, 0, 0,
>    4,
>    ...
> };
> 
> const struct gl_texture_format gl_tex_format_rgb565 = {
>    MESA_FORMAT_RGB565,
>    5, 6, 5, 0, 0, 0, 0,
>    2,
>    ...
> };

Do these structs initialize the extractTexel function pointer?
I don't think they can.  Or the driver would have to override
the defaults.


> and so on.
> 
> We add a pointer to such a structure to struct gl_texture_image, and add
> a driver callback to allow the driver to select the best format.  Thus,
> _mesa_TexImage*() has something like the following:
> 
>    struct gl_texture_format *texFormat;
> 
>    texFormat = (*ctx->Driver.ChooseTextureFormat)( ... );
> 
>    texImage->texFormat = texFormat;
> 
>    texImage->RedBits = texFormat->redSize;
>    texImage->GreenBits = texFormat->greenSize;
>    texImage->BlueBits = texFormat->blueSize;
>    texImage->AlphaBits = texFormat->alphaSize;
>    texImage->IntensityBits = texFormat->intensitySize;
>    texImage->LuminanceBits = texFormat->luminanceSize;
>    texImage->IndexBits = texFormat->indexSize;

It seems redundant to store the bits/channel info in both structs, but
that's a minor issue.


> The Driver.TexImage* callbacks are now no longer allowed to fail.

Because it'll be up to core Mesa to unpack and store the texture image
under all circumstances?

I'm a bit worried about expecting core Mesa to do all this.  Consider
a card that uses some sort of tiled texture memory layout.  I think it
should be up to the driver to handle image conversion for something
like this and not burdon core Mesa with strange conversion routines.

The idea behind the texutil.c functions was to simply provide some
helper routines for drivers.  Drivers can take them or leave them.


> _mesa_TexImage* hands control over to the driver, which does any
> driver-specific work (such as the tdfx driver making sure the aspect
> ratio is okay), before calling the _mesa_convert_teximage helper
> function.  I still have to work out the nicest way to handle this, as
> _mesa_convert_teximage or equivalent has changed quite a bit.  It may be
> that the core Mesa code actually does the image conversion with the
> information returned from the driver callback.

Core Mesa never directly calls the texutil.c functions at this time.



> Basically, _mesa_convert_teximage has a couple of layers of conversion
> function tables, depending on the input and output formats etc.  This
> allows MMX-optimized conversion routines to be used in a variety of
> situations.  Things like the current pixelstore attributes, whether the
> image needs rescaling, and whether the input and output types are
> supported are used to determine if a fast conversion can be done.  If a
> fast conversion can be done, the function tables are used to select the
> correct function and we're done.  If not, _mesa_convert_teximage will
> fall back to doing a generic image conversion.

OK.


> The critical difference here is that the driver selects the internal
> format to be used (like MESA_FORMAT_ARGB4444, MESA_FORMAT_AL88 etc), and
> the conversion function is guaranteed to return a tightly-packed image
> with that type.  The conversion function is smart enough to pack RGB
> input data into RGBA textures, or alpha/luminance only data into an AL88
> texture and so on.  We do not need extra internal types to handle this.

Are you saying something new here?  This is the way things currently work.


> The software rasterizer uses the texFormat->extractTexel()-like
> functions to extract individual or blocks of texels.  The SI has a
> number of texel extraction functions per format, to support textures
> with and without borders and so on.  The correct one would be plugged
> into texImage->extract().  This means that the image can be converted
> once only, stored in a hardware-friendly format, and interacted with by
> the software rasterizer.  I think this is nicer than having to unconvert
> the entire image when there's a software fallback.

I like this too.  The trick is not penalizing the performance of software
Mesa (like the Xlib driver).  I think that the optimized textured triangle
functions (for example) could detect when the texture image is in a
simple GLubyte, GL_RGB format and directly address texels.  It would be
the unoptimized cases, like mipmapped textures, where we might be
incurring a new performance hit.  Even that could probably be avoided
with some extra code.


> Brian, I'm not sure if you're going to get this, and I know you said you
> were going to look into a texel extraction interface as well.  I wanted
> to let you know where I'm going with this to avoid duplicate work and
> let you comment on my thoughts.

I hadn't done any work on this yet.  We can do it together.

I think the first things to do are:

1. Add the ExtractTexel() function pointer to the gl_texture_image struct.

2. Remove the Driver.GetTexImage() code and write new code to use the
   ExtractTexel() function.

I'll need some clarifications on the issues above before doing more.

-Brian