[Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm

Tomasz Figa tfiga at chromium.org
Fri Feb 16 04:10:37 UTC 2018

On Fri, Feb 9, 2018 at 11:06 PM, Rob Herring <robh at kernel.org> wrote:
> On Fri, Feb 9, 2018 at 3:58 AM, Tomasz Figa <tfiga at chromium.org> wrote:
>> On Fri, Feb 2, 2018 at 11:51 PM, Tomasz Figa <tfiga at chromium.org> wrote:
>>> On Fri, Feb 2, 2018 at 11:00 PM, Rob Herring <robh at kernel.org> wrote:
>>>> On Fri, Feb 2, 2018 at 2:01 AM, Tomasz Figa <tfiga at chromium.org> wrote:
>>>>> Hi Rob,
>>>>> On Tue, Jan 30, 2018 at 9:36 PM, Robert Foss <robert.foss at collabora.com> wrote:
>>>>>>>>>>>       uint32_t (*get_fd)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>>>       uint64_t (*get_modifier)(buffer_handle_t handle, uint32_t
>>>>>>>>>>> plane);
>>>>>>>>>>>       uint32_t (*get_offsets)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>>>       uint32_t (*get_stride)(buffer_handle_t handle, uint32_t plane);
>>>>>>>>>>>       ...
>>>>>>>>>>> } gralloc_funcs_t;
>>>>>>> These ones? >
>>>>>>> Yeah, if we could retrieve such function pointer struct using perform
>>>>>>> or any equivalent (like the implementation-specific methods in
>>>>>>> gralloc1, but not sure if that's going to be used in practice
>>>>>>> anywhere), it could work for us.
>>>>>> So this is where you and Rob Herring lose me, I don't think I understand
>>>>>> quite how the gralloc1 call would be used, and how it would tie into this
>>>>>> handle struct. I think I could do with some guidance on this.
>>>>> This would be very similar to gralloc0 perform call. gralloc1
>>>>> implementations need to provide getFunction() callback [1], which
>>>>> returns a pointer to given function. The list of standard functions is
>>>>> defined in the gralloc1.h header [2], but we could take some random
>>>>> big number and use it for our function that fills in provided
>>>>> gralloc_funcs_t struct with necessary pointers.
>>>>> [1] https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#300
>>>>> [2] https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/gralloc1.h#134
>>>> This is a deadend because it won't work with a HIDL based
>>>> implementation (aka gralloc 2.0). You can't set function pointers (or
>>>> any pointers) because gralloc runs in a different process. Yes,
>>>> currently gralloc is a pass-thru HAL, but AIUI that will go away.
>>> Part of it. I can't see IMapper being implemented by a separate
>>> process. You can't map a buffer into one process from another process.
>>> But anyway, it's a good point, thanks, I almost forgot about its
>>> existence. I'll do further investigation.
>> Okay, so IMapper indeed breaks the approach I suggested. I'm not sure
>> at the moment what we could do about it. (The idea of a dynamic
>> library of a pre-defined name, exporting functions we specify, might
>> still work, though.)
>> Note that the DRM_GRALLOC_GET_FD used currently by Mesa will also be
>> impossible to implement with IAllocator/IMapper. (Although I still
>> think Mesa and Gralloc are free to have separate logic for choosing
>> the DRM device to use.)
> I think the need for GET_FD goes away when the render node is used. We
> may still need the card node for s/w rendering (if I can ever get that
> working) though. Of course, if we use the vgem approach like CrOS then
> we wouldn't.

Hmm, if so, then we probably wouldn't have any strict need for these
function pointers anymore. We already have a makeshift format resolve
in place and the only missing bits that we still need to patch up
downstream are removing GET_FD, dropping drm_gralloc.h and adding a
fallback to kms_swrast if hw driver loading fails.

Best regards,

More information about the mesa-dev mailing list