[Mesa-dev] GBM YUV planar support

[Rob Herring]

As discussed on irc yesterday, I've been looking at adding YUV planar
(YV12) to GBM as it is a requirement for Android gralloc. It is
possible to disable the requirement as that is what the Android
emulator and android-x86 do. But that results in un-optimized s/w CSC.

Given most/all Android targeted h/w can support YUV overlays (except
virgl?), I only need to allocate, map, and import (to GBM only)
buffers. The outputting of YUV would remain the responsibility of HWC
(also a missing feature in drm_hwcomposer), and the gpu never touches
the YUV buffers.

With that, I see a couple of options:

For allocation, at some level we need to translate to a single buffer
perhaps using R8 format. This could be done in gralloc, GBM, gallium
ST, or individual drivers. Also, somewhere we'd have to adjust stride
or height. I don't know what assumptions like the U or V stride is
half the Y stride are acceptable? Trying to propagate per plane stride
and offsets all the way down to the drivers looks difficult.

Then for importing, we can translate the planes to R8/GR88 and use the
import support Stanimir is doing[1]. Again, the question is at what
level to do this: either gralloc or GBM? The complicating factor here
is I don't think we want to end up with 2 GBM BOs. So maybe GBM BOs
need to support multiple DRIImages? However, it seems that we're
creating 2 ways to import planar buffers either as a single DRIimage
with planes (as i965 does) or a DRIimage per plane.

Another option is make gralloc open both render and card nodes using
the card GBM device to just allocate dumb buffers for YUV buffers.
This complicates gralloc a bit and the answer is always don't use dumb
buffers. :) However, the assumption here is the buffers are just
scanout buffers.

Any feedback on direction would be helpful.

Rob

[1] https://lists.freedesktop.org/archives/mesa-dev/2016-May/117528.html