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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
