[Mesa-dev] r300g + mesa/st support for EXT_texture_swizzle

[Keith Whitwell]

On Wed, 2010-04-28 at 02:26 -0700, Dave Airlie wrote:
> On Wed, Apr 28, 2010 at 7:13 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
> > No need to go into this blame game, especially not for this feature. Which is pretty easy to implement on svga pipe driver -- we already generate shader variants, so it is just the matter of baking a swizzle in there. This might actually fix some bugs there.
> >
> > I also think this is a feature basic enough to be required, however I have no idea how useful EXT_texture_swizzle is.
> >
> > But I don't recall we ever introducing an interface change and then exposing them in a way that break other drivers. Most of interface changes we've been doing has nothing to do with svga pipe driver anyway, an we do expose it in mesa conditionally. master svga is often more broken than anything else, as everybody on that project is still focused on mesa_7_7_branch.
> 
> Interface changes are easy to keep drivers building, but feature
> changes that require something like shader additions in each driver
> are certainly something that should be in the domain of the driver
> writer, as I don't think anyone is qualified to add the fix to every
> gallium driver. I'd certainly have no idea where to start in svga or
> how to test. I can push to a branch and the other driver writes can
> fix up their drivers there before pushing to master, assuming people
> are bothered to fix it in a reasonable timeframe.
> 
> I need to compare what the EXT_texture_swizzle expects vs what the g3d
> swizzle interface expects, I'll probably do some piglit tests for the
> wierd BGRA vs RGBA type cases.
> 

Right now, I think the idea of reducing the number of cap bits or
restricting their addition is pretty much dead.  In an ideal world,
maybe we could have done that, but pragmatically it isn't happening &
isn't going to happen.

What I'd like to pursue instead is permitting the drivers to advertise
more or less exactly what they can support, maybe have the state tracker
also advertise exactly what it *requires*, and have an intermediate
layer bridge the gap.

Keith