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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
