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

[Stefan Schake]

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.

Thanks,
Stefan