[Mesa-dev] [PATCH 5/9] gallium: add R8G8_R8B8 and G8R8_B8R8 format

[Roland Scheidegger]

Am 12.03.2012 15:00, schrieb Jose Fonseca:
> ----- Original Message -----
>> On 12.03.2012 13:26, Roland Scheidegger wrote:
>>> Hmm actually I think these new pipe formats are a mistake. Why do
>>> you need them and don't just use the existing R8G8_B8G8 and 
>>> G8R8_G8B8? Do you really care if Y ends up in G channel instead
>>> of R? And if you do why don't you just use a sampler swizzle? The
>>> R8G8_B8G8 and G8R8_G8B8 formats are there because these 
>>> correspond to the subsampled DX10 formats. I just see absolutely
>>> no point in introducing similar formats which just have different
>>> channel mapping - we generally don't have arbitrary swizzled
>>> formats, with the exception of "old" ones which can be used for
>>> legacy purposes. But no such case can be made for these new
>>> formats.
>> Well, we definitely already have separate formats for different 
>> channel mappings. otherwise we should handle the difference between
>> RGBA and BGRA with sampler swizzle’s also.
Only for "old" formats for which this makes sense (because some api uses
them). None of the sint/float formats for instance have different
formats which only differ in rgba ordering.

>> 
>>> (I just checked the i965 docs which doesn't support sampler 
>>> swizzling, and in fact these new formats wouldn't help you there
>>> neither, since all 4 subsampled ycbcr format map Y to the green
>>> channel. So with hw supporting sampler swizzling, these formats
>>> don't buy you anything, and with hw not supporting it they don't
>>> help neither as no hardware out there supports them anyway.) Or
>>> is there another reason why you need these formats I'm missing?
>> Nope, not really I just added them for consistency with the
>> existing format handling, and it actually makes the implementation
>> of YUV -> RGB conversion a bit easier.
I don't see why that makes handling yuv->rgb conversion easier.
I don't think that you can really say that's for consistency with other
formats handling, you don't have a api which claims it must be this
order when sampled (as yuyv does not imply anything about in what rgba
channels these values should end up).

> 
> I think it's fine to have additional formats if they help in anyway.
> I certainly rather have more formats than, e.g., jamming multiple
> semantics on an existing format.
Yes, jamming multiple semantics on existing formats is bad, but this is
not the case here. The only difference is really the sampler swizzle,
and the choice which one to use is somewhat arbitrary (as vl really has
u8y8_v8y8 data, the mapping to rgb is entirely up to the state tracker,
not api imposed). That's why I'd think it would be better to use the
formats we already have, these could be translated to other hw which
doesn't have native sampler swizzling, and drivers wouldn't need to care
about even more formats.

> 
> If formats eventually become unused we can always remove them.
That much is true, but why introduce unneeded ones in the first place?
Now if this really simplifies yuv->rgb conversion then there's a use for
it, but otherwise this just looks unnecessary to me. I think state
trackers should deal with something like that if if they just need an
arbitrary sampler swizzle, not impose that (admittedly tiny) additional
complexity on everything.

Anyway, I can certainly live with this, I just think it's not really the
best solution.

Roland