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

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

Brian Paul wrote:
> 
> > Yes they can.  The driver would only need to provide extractTexel
> > functionality if if defined custom texture formats.  Consider this: we
> > want to store a texture as ARGB4444.  So, we point texImage->TexFormat
> > at gl_texformat_argb4444 (defined as above) and use the utility
> > functions to produce a tightly-packed ARGB4444 texture.  The structure
> > includes one or more initialized extractTexel function pointers, which
> > are aimed at function(s) that know how to read ARGB4444 textures.
> > Depending on the mode (border/no border, 2D/3D is what the SI has), we
> > pick one of the texture format's extractTexel functions and plug it into
> > texImage->extractTexel().  I don't see the problem here.
> 
> No problem.  You didn't make the possibility of overriding explicit in
> your first message and I wanted to make sure what the intention was.

Okay, my mistake.

> I still don't see why the channel sizes have to be in both structures.
> If the gl_texture_image struct always points to a gl_texture_format struct,
> then glGetTexLevelParameter(GL_TEXTURE_RED_SIZE, &size) could get its
> info from the gl_texture_format struct.

When I was checking out the SI code I thought there was a good reason
for this.  Perhaps I was mistaken.

> > I'm still toying with a few ideas, but you make a good point.  Drivers
> > should be able to provide custom texture formats, with their custom
> > extractTexel functions, as needed.  What I want to avoid is the huge
> > performance hit we see from using the utility functions.
> 
> I think the existing texutil code is pretty good for plain C. :)

I'll accept that :-)  See my post to dri-devel with some updated
scores...

> Moving the image rescale operation into a separate function is something
> I've wanted to do for a while.

Yes, this makes it so much nicer.

> Also, the _mesa_convert_teximage() and _mesa_convert_texsubimage()
> functions could be merged into one with a little bit of work.

You really don't want to do that.  You can specifically optimize for
nice power-of-two dimensions with the full teximage convert, while you
have to handle the subimage with a little more care.  In fact, the
driver should check for a subimage update that updates the full image
and call _mesa_convert_teximage() instead of _mesa_convert_texsubimage()
-- the tdfx driver does this now.

> Right.  glTexImage2D should do error checking, then call Driver.TexImage2D().
> The driver function could either do all the work or call a fallback
> routine, like _mesa_store_teximage2D().
> 
> This sounds simple but things like image unpacking, image transfer ops,
> image rescaling, texture compression, etc make it a little complicated.

Sure, no argument there.  It sounds like we agree on the fact that once
Driver.TexImage*D returns, we should have a valid texture image, even if
the driver has to call the fallback routine manually.  Right?

-- Gareth