[Mesa-dev] [PATCH] egl/android: Partially handle HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED

[Tapani Pälli]

On 11/28/2017 07:38 PM, Rob Herring wrote:
> On Tue, Nov 28, 2017 at 8:42 AM, Tomasz Figa <tfiga at chromium.org> wrote:
>> On Tue, Nov 28, 2017 at 11:27 PM, Rob Herring <robh at kernel.org> wrote:
>>> On Tue, Nov 28, 2017 at 5:49 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 28 November 2017 at 10:45, Tapani Pälli <tapani.palli at 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