[Mesa-dev] r300g + mesa/st support for EXT_texture_swizzle
airlied at gmail.com
Tue Apr 27 23:45:32 PDT 2010
On Wed, Apr 28, 2010 at 12:09 PM, Roland Scheidegger <sroland at vmware.com> wrote:
> 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).
The main reason I'm doing EXT_texture_swizzle was to add depth
texturing using the sampler view afterwards, I just wanted to add this
extension while I was in the area.
so hopefully it works after I work this out.
More information about the mesa-dev