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

[Tomasz Figa]

On Fri, Mar 23, 2018 at 10:15 PM, Stefan Schake <stschake at gmail.com> wrote:
> On Fri, Mar 23, 2018 at 1:02 PM, Tomasz Figa <tfiga at chromium.org> wrote:
>> On Fri, Mar 23, 2018 at 8:52 PM, Robert Foss <robert.foss at collabora.com> wrote:
>>> Hey Chih-Wei,
>>>
>>>
>>> On 03/23/2018 03:43 AM, Chih-Wei Huang wrote:
>>>>
>>>> 2018-03-22 16:23 GMT+08:00 Tomasz Figa <tfiga at chromium.org>:
>>>>>
>>>>> Hi Chih-Wei,
>>>>>
>>>>> On Thu, Feb 22, 2018 at 2:53 PM, Chih-Wei Huang <cwhuang at linux.org.tw>
>>>>> wrote:
>>>>>>
>>>>>> 2018-02-21 3:03 GMT+08:00 Rob Herring <robh at kernel.org>:
>>>>>>>
>>>>>>>
>>>>>>> Perhaps worth revisiting. Given we've failed to progress at all since
>>>>>>> then may change opinions some. We already have to handle multiple
>>>>>>> opens share the same pipe_screen, so I don't think reusing the fd buys
>>>>>>> us anything.
>>>>>>>
>>>>>>> Maybe we're close to the point of removing the flink name support too.
>>>>>>> The android-x86 folks have been working to get dma-bufs working.
>>>>>>> Chih-Wei, any comments on this?
>>>>>>
>>>>>>
>>>>>> Ah! Sorry. I didn't catch or understand the details.
>>>>>> Did you mean the attempts to use drm_hwcomposer
>>>>>> in android-x86?
>>>>>> My understanding so far is most x86 GPUs won't work
>>>>>> except some very limited models.
>>>>>> It's due to kernel driver issues which may never be solved.
>>>>>> So we can't drop the flink name support.
>>>>>> Please correct me if I am wrong.
>>>>>
>>>>>
>>>>> Could you elaborate a bit more on those GPUs that won't work and
>>>>> corresponding driver issues? We're running cros_gralloc on Intel and
>>>>> AMD GPUs, with DMA-buf and render-node only setup and we haven't seen
>>>>> any problems.
>>>>
>>>>
>>>> Hi Tomasz,
>>>> I remember (in our previous discussion) you said
>>>> CrOS uses your own hwcomposer (proprietary?) so
>>>> the story may be different.
>>>>
>>>> What we have tried is gbm_gralloc + drm_hwcomposer
>>>> and I reported the issues here:
>>>>
>>>> https://lists.freedesktop.org/archives/dri-devel/2017-September/153580.html
>>>
>>>
>>> I took the liberty of moving you nouveau issue into the drm_hwc gitlab
>>> bugtracker.
>>>
>>> https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/issues/1
>>
>> Hmm, reading further in that thread, that seemed to be related to
>> missing nouveau.atomic=1 in kernel command line:
>> https://lists.freedesktop.org/archives/dri-devel/2017-September/153681.html
>>
>> It went further, but didn't work very well. I suspect that could have
>> been related to DRM_GRALLOC_GET_FD being used, which makes the mess
>> from the system due to gralloc and Mesa stepping on each other's GEM
>> handles (which aren't reference counted by design and importing a
>> buffer several time will always return the same handle).
>
> I think mixing in drm_hwcomposer here would be trying to do too much at once.
> It has a lot of requirements (atomic driver, fence fds, alpha/rotation props)
> and no fallback path to speak of. Coming from drm_gralloc where I think in
> practice all composition is punted to the hwui GL compositor and DRM is
> only around for putting the final framebuffer on a display, it's asking a lot
> of some of the (legacy) hardware used for Android-x86.

Do we have any feasible alternative?

Chih-Wei pointed me to the drm_gralloc used on android-x86 and it
seems to seriously pre-date any DMA-buf support. Everything there is
done with the assumption that GEM names are used and adding DMA-buf
would require a significant rework of all the code.

That leaves us with gbm_gralloc (or possibly Chromium minigbm, used by
Android-IA too), which doesn't implement the legacy FB management, so
some hwcomposer would be needed.

Best regards,
Tomasz