mesa3d-dev

[Mesa3d-dev] Texture formats

[Gareth H. <ga...@va...>]

I'm restoring the behaviour of texImage->Format, and will set
texImage->IntFormat to the GL format corresponding to the internal Mesa
format instead of the internalFormat parameter given by the user.  This
gives the behaviour I'm looking for (ie. users can find out what format
the texture is stored in, and by checking the individual component sizes
can acurately determine how the image is stored).

As far as I can tell, the texImage->Type field is redundant.  We have
the number of bytes per texel stored in texImage->TexFormat->TexelBytes,
and can thus remove the use of texImage->Type in texstore.c.  We'll need
to keep the information around so the software rasterizer can determine
if it can use an optimize CHAN_TYPE texture sampling function.  Thus,
I'll remove the BaseFormat field from gl_texture_format, but keep and
rename the BaseType field.  The software rasterizer will then check the
gl_texture_format's Type field as required.

-- Gareth

Re: [Mesa3d-dev] Texture formats

[Gareth H. <ga...@va...>]

Gareth Hughes wrote:
> 
> I'm restoring the behaviour of texImage->Format, and will set
> texImage->IntFormat to the GL format corresponding to the internal Mesa
> format instead of the internalFormat parameter given by the user.

Man, I need a coffee...

Old:

   texImage->Format
   texImage->Type
   texImage->IntFormat

New:

   texImage->Format			/* Regular base format */
   texImage->TexFormat->Type		/* Internal format type */
   texImage->TexFormat->IntFormat	/* Internal GL format */

Still:

   texImage->TexFormat->MesaFormat	/* MESA_FORMAT_* */

So, texImage->Format is initialized by core Mesa before the DD texture
image function is called.  All the driver (or texstore utils) needs to
do plug in an appropriate format into texImage->TexFormat.

-- Gareth

Re: [Mesa3d-dev] Texture formats

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

Gareth Hughes wrote:
> 
> I'm restoring the behaviour of texImage->Format, and will set
> texImage->IntFormat to the GL format corresponding to the internal Mesa
> format instead of the internalFormat parameter given by the user.  This
> gives the behaviour I'm looking for (ie. users can find out what format
> the texture is stored in, and by checking the individual component sizes
> can acurately determine how the image is stored).
> 
> As far as I can tell, the texImage->Type field is redundant.  We have
> the number of bytes per texel stored in texImage->TexFormat->TexelBytes,
> and can thus remove the use of texImage->Type in texstore.c.  We'll need
> to keep the information around so the software rasterizer can determine
> if it can use an optimize CHAN_TYPE texture sampling function.  Thus,
> I'll remove the BaseFormat field from gl_texture_format, but keep and
> rename the BaseType field.  The software rasterizer will then check the
> gl_texture_format's Type field as required.

In the s/w rasterizer I've been replacing the texture Format and Type
checks with comparisons against the new MESA_FORMAT_* tokens.

And in the texture-object-completeness function, I'm going to check
if all mipmaps are of the same format by comparing the TexFormat field
instead of the Format/Type fields.

So, the Type field really might not be needed anymore.  However, it
wouldn't be bad to keep it around a bit longer, I think.

-Brian

Re: [Mesa3d-dev] Texture formats

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> In the s/w rasterizer I've been replacing the texture Format and Type
> checks with comparisons against the new MESA_FORMAT_* tokens.
> 
> And in the texture-object-completeness function, I'm going to check
> if all mipmaps are of the same format by comparing the TexFormat field
> instead of the Format/Type fields.
> 
> So, the Type field really might not be needed anymore.  However, it
> wouldn't be bad to keep it around a bit longer, I think.

Sounds good.

I have a quick question regarding color lookup tables.  If a driver
doesn't support paletted textures, the only failure case is when the
data format is a GL_COLOR_INDEX(_*) type and the internalFormat is
GL_COLOR_INDEX, right?  If the internalFormat is anything else, it goes
through the color lookup table, which defaults to 0 for all channels,
right?

So, if I've got this right, the driver would have to inspect
internalFormat if the data format was GL_COLOR_INDEX(_*) and choose an
appropriate final destination format, skip the first conversion pass,
call the texstore functions to perform the LUT conversion, and then call
_mesa_convert_texsubimage*() to convert the GLchan-based post-LUT image
to the final image format.  Does this sound correct?

-- Gareth

Re: [Mesa3d-dev] Texture formats

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > In the s/w rasterizer I've been replacing the texture Format and Type
> > checks with comparisons against the new MESA_FORMAT_* tokens.
> >
> > And in the texture-object-completeness function, I'm going to check
> > if all mipmaps are of the same format by comparing the TexFormat field
> > instead of the Format/Type fields.
> >
> > So, the Type field really might not be needed anymore.  However, it
> > wouldn't be bad to keep it around a bit longer, I think.
> 
> Sounds good.
> 
> I have a quick question regarding color lookup tables.  If a driver
> doesn't support paletted textures, the only failure case is when the
> data format is a GL_COLOR_INDEX(_*) type and the internalFormat is
> GL_COLOR_INDEX, right?  If the internalFormat is anything else, it goes
> through the color lookup table, which defaults to 0 for all channels,
> right?

Right.  Though it's the format that would be GL_COLOR_INDEX and the
internalFormat would be GL_COLOR_INDEX_*.


> So, if I've got this right, the driver would have to inspect
> internalFormat if the data format was GL_COLOR_INDEX(_*) and choose an
> appropriate final destination format, skip the first conversion pass,
> call the texstore functions to perform the LUT conversion, and then call
> _mesa_convert_texsubimage*() to convert the GLchan-based post-LUT image
> to the final image format.  Does this sound correct?

That sounds right.  I'd have to review the code to say for certain.

I think a few more utility routines may be in order.  Because in all
the drivers' TexImage*() functions we always have to do something
like this (lots of details omitted):

if (anyPixelTransferOps) {
    allocate tempBuffer
    _mesa_transfer_teximage(dest = tempBuffer, source = userData)
    _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);
    free tempBuffer
}
else {
   _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);

}


In the 3dfx driver it's more complicated because of the image
rescaling that's sometimes needed.

-Brian

Re: [Mesa3d-dev] Texture formats

[Gareth H. <ga...@va...>]

Brian Paul wrote:
> 
> Right.  Though it's the format that would be GL_COLOR_INDEX and the
> internalFormat would be GL_COLOR_INDEX_*.

Indeed :-)

> That sounds right.  I'd have to review the code to say for certain.

Cool.

> I think a few more utility routines may be in order.  Because in all
> the drivers' TexImage*() functions we always have to do something
> like this (lots of details omitted):
> 
> if (anyPixelTransferOps) {
>     allocate tempBuffer
>     _mesa_transfer_teximage(dest = tempBuffer, source = userData)
>     _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);
>     free tempBuffer
> }
> else {
>    _mesa_convert_texsubimage2d(dest = texImage->Data, src = tempBuffer);
> 
> }
> 
> In the 3dfx driver it's more complicated because of the image
> rescaling that's sometimes needed.

Hence my earlier argument that _mesa convert_texsubimage2d() shouldn't
be allowed to fail :-)

-- Gareth