[Mesa-dev] [PATCH 2/3] radeonsi: add sampling of 4:2:2 subsampled textures

[Andy Furniss]

Grigori Goronzy wrote:
> On 29.08.2014 12:31, Andy Furniss wrote:
>>> As for that 4:2:2 "doesn't work", AFAICT it absolutely does, but
>>> there is no linear interpolation for chroma, so quality isn't ideal.
>>> This seems to be a hardware restriction, unfortunately.
>>
>> Hmm, we may have to disagree on the definition of working here :-)
>>
>> Of course I don't understand the hardware - but are you saying that
>> because the chrome needs horizontal interpolation you have to have
>> vertical interpolation too?
>>
>
> No, I just observed that there is no linear interpolation horizontally.
> I.e. the exact same chroma value is used for two pixels of the same block.

Ahh, I have seen and mentioned that one long ago, but compared to the 
vertical issue it's less noticable to me - still be nice to have 
working, though.

>
>>
>> Tests were 1:1 vertical scale.
>>
>> With weave shader a test pattern rgbymc 422 chroma looked much like it
>> would if I had used ffmpeg to convert to it 420 (ie none of those at all
>> rendered). On real video it bled between fields, so my use case of
>> feeding it to a TV to deinterlace would fail - luma was OK.
>>
>
> Hmm - where can I find this test pattern?

lines-576.png is a version with black and white as well.

lines-all.png is the result of me using your mpv command with --loop=inf 
and taking an xwd for analysis.

I notice that on this one luma does get slightly borked also.

https://drive.google.com/folderview?id=0BxP5-S1t9VEEOGNKUHdDcUEtQ1U&usp=drive_web

Also there is a "real" test, snook-ilpack.png is master and again 
snook-all is the result.

This one is of interest because as you can see the chroma on the weave 
has bled between fields.
This will be noticeable when deinterlaced.
I didn't zoom it on the all, but the luma on the white ball is still 
correct WRT fields, hence me thinking luma was OK previously.
Looking closely it is tinted green a bit.

> I just made a simple test pattern myself: http://i.imgur.com/hsLFBxy.png
> I displayed it in mpv with the following command line:
>> mpv --vo=vdpau --vf=format=uyvy422 422-chroma.png
>
> I clearly see separate chroma for each line, but chroma cositing seems
> to be a bit off, i.e. chroma is shifted downwards by about half a pixel.
> That doesn't happen with forced progressive mode. So this is most
> probably it.

Yea, your test doesn't show it quite as well, but there are new colours 
there.

I guess the 1/2 pix error is to blame - can it be fixed?