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

[Jose Fonseca]

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.

Jose
________________________________________
From: mesa-dev-bounces+jfonseca=vmware.com at lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware.com at lists.freedesktop.org] On Behalf Of Dave Airlie [airlied at gmail.com]
Sent: Wednesday, April 28, 2010 3:26
To: Roland Scheidegger
Cc: mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] r300g + mesa/st support for EXT_texture_swizzle

>>     There's hw we care about which can't do this (i965, svga) and
>>     it seems unreasonable to expect them to do workarounds just so this
>>     extension can be always exposed.
>>
>>
>> With all respect, when I ask for a cap bit for an unsupported feature in
>> the driver I work on, I am always told to implement a bloody-slow
>> workaround with a lot of code around, but when comes to the drivers you
>> guys care about, it's just "let's add a cap". Can we be fair here?
>
> Well it's a somewhat advanced feature because it's only required by GL
> 3.3, and the functionality is not present in DX10.
> Personally I'm not really against requiring drivers to implement this
> (though I'd like to hear more opinions), however whoever introduces this
> feature should then also try to unbreak the drivers.

Well the upstream 965 driver already implements this so I expect our
i965g port should also do it if worked.

Everytime you guys introduce a feature that you consider necessary for
svga, someone from r300g (MAD or Marek) fixes up r300 pretty quickly
afterwards, again I'm seeing a bit of a double standard here. I'm not
against a CAP bit but I'm quite willing to fix softpipe + r300g to
pass the glean test and other driver writers can notice in their
regular piglit runs the test fails for them and they can fix as and
when.

Dave.
_______________________________________________
mesa-dev mailing list
mesa-dev at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev