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

[Tapani Pälli]

On 03/23/2018 03:20 PM, Tomasz Figa wrote:
> 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.

One possibility for android-x86 project would be to have a separate 
lunch target (and libraries) for the old machines. Those ones unlikely 
support OpenGL ES 3.1?), hardware planes, Vulkan or other modern Android 
requirements anyway. These machines could run with old (and stable) 
Mesa, drm_gralloc and maybe the old hwcomposer from Intel that does hwc 
1.0/1.1, there were even patches to use planes there via drmModeSetPlane 
in video usecases IIRC.

> 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

// Tapani