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