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

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

Gareth Hughes wrote:
> 
> Brian Paul wrote:
> >
> > > 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.
> 
> 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.


> > It seems redundant to store the bits/channel info in both structs, but
> > that's a minor issue.
> 
> No.  The texImage->TexFormat pointer gets initialized to the default
> format (the one that core Mesa will produce if the driver doesn't
> request a different format).  GL_RGBA textures are gl_texformat_rgba8888
> and so on.  The driver can change this if needed, as I described.
> There's an update_teximage_component_sizes() call that copies the sizes
> from the format structure to the teximage structure.  This is nice as
> it's all done with a single entry point.  If you change the format, you
> just call the update function and you're done.

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.


> > > 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.
> 
> 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. :)

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

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


> > The idea behind the texutil.c functions was to simply provide some
> > helper routines for drivers.  Drivers can take them or leave them.
> 
> Indeed.
> 
> > Core Mesa never directly calls the texutil.c functions at this time.
> 
> It might be nice to have the driver call a function, saying "I want this
> texture in ARGB4444 format, go and do it" and have it never fail.  It's
> a small extension to the layered architecture I have in place now, that
> basically adds the generic case support to the image conversion routines
> as a kind of fallback path.  I'll have to prototype this to see if it's
> worth it.  The current method isn't bad, don't get me wrong.

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.


> My highest priority at the moment in relation to this work is to move
> the Radeon driver over to this interface.  Perhaps we can partition the
> work after that's done.

I've started implementing the FetchTexel() function pointer stuff.
I'm in the process or removing the Driver.GetTexImage() code.

-Brian