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

[Grigori Goronzy]

On 29.08.2014 10:19, Christian König wrote:
> 
> That sounds like something doesn't work correctly.
> 
> The resources are created with the subsamled formats R8G8_R8B8 or
> G8R8_B8R8, but since this can't be accessed by the CB we need to use
> R8G8B8A8 as surface format for writing to them.
> 
> If that doesn't work the whole blitter and transfer code won't work
> either and we obviously have a problem. Can you figure out what's the
> real cause of this? Maybe we use the wrong tiling mode with such surfaces?
>

I don't really know how tiling works, but it looks like formats disagree
in how width is specified. Even though 4:2:2 subsampled formats are
logically organized in 32 bit blocks of 2x1 luma pixels with one chroma
value, the width needs to be specified in single pixels, not 2x1 blocks
of pixels. This is similar to compressed texture formats. If you now try
to reinterpret the surface as plain RGBA, the width is incorrect.

The blitting code (resource_copy_region) also reinterprets subsampled
formats as RGBA, but it adjusts the width (uses number of blocks as
width) [1].

By the way, on my system, the 4:2:2 video buffers are by default mapped
directly, so broken blitting won't have any effect. If I force usage of
a staging texture, the dma_copy and resource_copy_region paths work
correctly, though.

>> 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.
> 
> Interesting, from the docs I thought that linear interpolation should
> also work for G and B components but I might remember that incorrectly.
>

Maybe some special incantation is required to enable chroma filtering? I
don't have any detailed docs and couldn't find anything in the register
docs. :) However, there's a GL extension that exposes subsampled, packed
4:2:2 formats, GL_APPLE_rgb_422. The spec explicitly states that chroma
filtering is undefined. My guess is that the extension was modeled after
existing hardware and was written that way because some hardware like
Radeon lacks good chroma filtering.

> Anyway, it might be easier to handle YUYV and UYVY as planar formats
> anyway and only to the transformation while we upload the data to them.
> 

A planar format might also be useful for deinterlacing 4:2:2, so that
would be a useful addition.

Grigori

[1]
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_blit.c#n559

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20140829/aa73b0cc/attachment.sig>