On 11/28/2017 07:38 PM, Rob Herring wrote:
On Tue, Nov 28, 2017 at 8:42 AM, Tomasz Figa <tf...@chromium.org> wrote:
On Tue, Nov 28, 2017 at 11:27 PM, Rob Herring <r...@kernel.org> wrote:
On Tue, Nov 28, 2017 at 5:49 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
On 28 November 2017 at 10:45, Tapani Pälli <tapani.pa...@intel.com> wrote:
Hi;
On 11/27/2017 04:14 PM, Robert Foss wrote:
[...]
+ /* HACK: See droid_create_image_from_prime_fd() and b/32077885. */
+ { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, 0, 2,
__DRI_IMAGE_FOURCC_NV12 },
+ { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, 0, 1,
__DRI_IMAGE_FOURCC_YUV420 },
+ { HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, 1, 1,
__DRI_IMAGE_FOURCC_YVU420 },
One alternative way would be to ask gralloc about these formats. On gralloc0
this would need a perform() hook and gralloc1 has getFormat(). This is how
it is done currently on Android-IA, see following commits:
https://github.com/intel/external-mesa/commit/deb323eafa321c725805a702ed19cb4983346b60
https://github.com/intel/external-mesa/commit/7cc01beaf540e29862853561ef93c6c4e86c4c1a
Do you think this approach would work with Chromium as well?
i think the Android-IA approach looks good, although it depends on
local gralloc0 changes. With gralloc1 on the horizon, I don't know how
much sense it makes to extend the predecessor.
AFAICT the patch should not cause any issues and it's nicely documented.
Perhaps someone from the Google/CrOS team can assist in making the bug
public, although even then it might be better to focus on a 'perfect'
gralloc1?
IMHO the patch looks perfectly reasonable and we could merge it even,
if we were to switch to gralloc1 in the not too distant future ;-)
gralloc1 has already come and gone. The interface is now (in O+)
IAllocator and IMapper aka gralloc 2.0.
I heard about those but havent seen the actual API so I thought this
will just be the same old gralloc but via binder.
Oh, that was a new one for me. Do you have any idea about real world
adoption of this interface? We're still using gralloc0 in Chrome OS
Android.
Pretty sure everyone else is too and will be until something forces
them to move. Maybe P will be stricter and not allow pass-thru
implementations (though I don't see how you could ever binderize
mmap).
There is neither perform nor
getFormat(). Seemed to me gralloc1 was moving in the right direction,
but I guess making cross process calls to retrieve buffer metadata was
not a good design. Other than standardizing the native_handle_t
fields, I'm not sure how one would solve this in a gralloc2 world.
Well, the ideal solution would be to extend IMapper in next version of
the interface to have a method that gives us the data we need.
Vendors can extend interfaces. AIUI, the rule is the HALs have to work
with stock AOSP without the extensions.
If default API is not enough IMO would be good to define some set of
functions that are required when using Mesa driver.
If not, one could still do some hacks like a library exporting some
semi-standard functions which take a handle as an argument and provide
the data we need as a result.
You can still have private interfaces amongst vendor components. We
can also just standardize how we sub-class the native_handle. That was
my intention with moving it from gralloc to drm_hwc. We can debate
whether we expose the struct or helper functions.
Rob
// Tapani
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
