[Mesa-dev] r300g + mesa/st support for EXT_texture_swizzle
sroland at vmware.com
Tue Apr 27 19:09:29 PDT 2010
On 27.04.2010 18:29, José Fonseca wrote:
> On Tue, 2010-04-27 at 08:59 -0700, Roland Scheidegger wrote:
>> On 27.04.2010 17:32, Roland Scheidegger wrote:
>>> On 27.04.2010 13:13, Dave Airlie wrote:
>>>> Another trying to figure out gallium patch from me,
>>>> This is in theory EXT_texture_swizzle support, r300g passes the glean
>>>> test with this now.
>>>> Some caveats in the patch (i.e. I'm not sure what exactly is correct
>>>> state tracker behaviour wrt sampler views).
>>> Basically looks good but I have some concerns. First, I think the
>>> extension should not be announced unconditionally but rather based on a
>>> cap bit. 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.
>>> Also, I think it won't work correctly if the pipe format itself has a
>>> swizzle (which is different to rgba). There are really two swizzles
>>> here, one coming from the extension the other inherited from the format,
>>> and they need to be combined. Either in the driver or the state tracker,
>>> I think it's underspecified right now but I think the swizzle parameter
>>> should express the hardware view, hence the combining should take place
>>> in the state tracker. (Also, for depth textures it should also take the
>>> depth texture mode into account, but that might be out of the scope of
>>> what you're trying to do.)
>> Actually right now the swizzle seems to represent only the "GL swizzle",
>> not the format one (looking at the u_sampler_view_default_template). Not
>> sure though if that's really the right design. In this case the driver
>> would need to combine the format and extension swizzle.
> I think it is worthwhile to keep the format swizzle orthogonal to the
> sampler view swizzles. It is actually more complex trying to describe
> swizzles in terms of the packed vector, since they not always have
> unambiguous meaning (bitmasks, subsampled formats, compressed textures).
ok. Can we still express depth texture mode though in the sampler view
swizzle? I guess it's not unreasonable to let drivers handle combining
the swizzles, if necessary could use some util code (for the normal
formats at least).
More information about the mesa-dev