[Mesa-dev] [RFC 0/2] mesa/st: support for YUV EGLImages

[Rob Clark]

On Mon, Sep 5, 2016 at 12:37 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Mon, Sep 5, 2016 at 12:32 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>>  + single plane (interleaved) YUV formats?  And seems like android
>>>>    wants YV12 (which is I420 with the 2nd and 3rd planes swapped).
>>>>    In general I don't want to go too crazy and add every YUV format
>>>>    under the sun, but try and limit it to the must-have formats.
>>>
>>> Have you considered using PIPE_FORMAT_R8G8_R8B8_UNORM and the BGR version?
>>
>> Hmm, no.. (I also don't support it in freedreno, so not entirely sure
>> what that format is.)
>>
>> How did you expect that to help?
>
> It's the UYVY/YUYV sampler formats (i.e. single-plane YUV formats). I
> don't think they do the YUV -> RGB conversion, but you just get the
> relevant YUV values. From the docs:
>
> """
> Format names with an embedded underscore are subsampled. R8G8_B8G8 is
> a single 32-bit block of two pixels, where the R and B values are
> repeated in both pixels.
> """
>
> Supported on nouveau, and I think a few other drivers.
>

On Mon, Sep 5, 2016 at 12:36 PM, Marek Olšák <maraeo at gmail.com> wrote:
>
> It would help if the texture were not layered.

Ahh, gotcha.. tbh I haven't given too much thought to support for
interleaved/422 yuv formats, although I suspect that android would
want that too for camera sorta use-cases.  (All the sensors I have
seen are either raw/bayer or interleaved yuv.)

Some hw seems to support YUYV/UYUV natively.. at least it looked like
vc4 did, and I think a3xx does too (although probably sans the matrix
multiply).  So we might end up wanting some shader cap(s)?

Otoh, I don't mind punting on interleaved YUV.  Just getting video
playback use-case (which is all about planar formats) going is a good
step in the right direction.  (Plus camera support in upstream kernel
is a whole other big mess.)

Fyi, I updated https://github.com/freedreno/mesa/commits/wip-yuv ..
depending on decision about non-FS stages, I might drop some of the
fixup patches and maybe some of the prep-work variant handling
patches.  (Although some of the prep patches might be worth keeping
just to make it easier to resurrect the YUV bits for other stages if
we ever need that.  idk)

BR,
-R