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

[Keith W. <ke...@va...>]

Gareth Hughes wrote:
> 

> > > 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'll chime in without having read the whole thread.

Allowing DD functions to fail is always a bad idea.  It blurs the distinction
between the actuall work required in core mesa to implement a function, and
the fallback case.  These two pieces of code are at very different levels of
abstraction -- they are actually seperated by a whole level.  You can get the
same effect by bundling up the fallback case and giving it a well-known name. 
If the driver can't handle a case, it explicitly calls the fallback code.  

This is what 'swrast' is all about.  A good example is ctx->DD.Clear, which
used to be allowed to fail or perform a partial execution.  As a result the
core coded needed to either implement software fallbacks, or know about the
existence of 'swrast' and call into it itself -- this is pretty clunky.  Now,
the same behaviour is simply achieved by requiring the driver to call into
swrast if it is unable to fulfill the request from core mesa.  To my eye this
is cleaner, and the requirement on the driver is pretty trivial.

Keith