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

Dave Airlie airlied at gmail.com
Wed Apr 28 02:26:12 PDT 2010


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.

Dave.


More information about the mesa-dev mailing list