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

[Emil Velikov]

On 21 February 2018 at 18:50, Rob Herring <robh at kernel.org> wrote:
> On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> Hi all,
>>
>> Pardon for dropping in late. I think you've got nearly everything
>> settled down, just sharing a couple of ideas.
>>
>> On 21 February 2018 at 04:19, Tomasz Figa <tfiga at chromium.org> wrote:
>>> On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring <robh at kernel.org> wrote:
>>>> On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa <tfiga at chromium.org> wrote:
>>
>>> It is actually incorrect to have the same device FD used for different
>>> screens, if PRIME is used, due to GEM namespace issues, e.g.
>>> - screen 0: drmPrimeFdToHandle(buffer A) -> 1,
>>> - screen 1: drmPrimeFdToHandle(buffer A) -> 1 (same handle in same
>>> namespace, due to semantics of PRIME import and same device FD used),
>>> - screen 0: GEM_CLOSE(handle = 1),
>>> - screen 1 still thinks handle 1 is valid...
>>>
>>> So this only works for control nodes using flink only. (Or if you
>>> always use libdrm_* for BO management and your particular
>>> implementation does its own GEM handle reference counting, but that's
>>> not guaranted.)
>>>
>> Had a sneaky feeling that that != 1 will be returned for screen 1's
>> drmPrimeFdToHandle call.
>> Regardless, moving to DRI3/dmabuf-only setups is the [really] long
>> term plan, I think.
>> I don't know if we can achieve it outside of CrOS - with all the
>> distros building and shipping things in subtly different manner.
>
> It's already possible for Android.
>
Great. Feel free to join me in pushing distributions forward ;-)

>>>> How would that work if you support different GPUs in one image?
>>>
>>> It wouldn't and that's why I prefer probing available devices.
>>>
>>> For Chrome OS, we don't include GPU bits in system image, but rather
>>> have vendor images built separately for each board (although sharing
>>> any possible contents across board family, chipset, GPU type and so
>>> on), so we can have a custom .rc script (which sets a property) as
>>> well. It would even be possible to have paths hardcoded, but that
>>> would be prone to probe ordering issues which, with software fallback,
>>> could be actually not obvious to notice, and so we'd rather not go
>>> this route.
>>>
>>> So I'd agree here that we should revisit probing.
>>>
>> As you pointed out the fallback is not a good idea.
>
> Software fallback is a desired feature. Basing it on the path is the bad idea.
>
Even considering that a) the transition is not obvious and b) it will
cause serve performance degradation?
For development and prototyping purposes it's great. For production
... very few users will like the abysmal performance :-\

>> Plus, as the drm
>> node vary, one can use an Android property and match it to the info.
>> from drmGetDevice2.
>> Say the HW bus location, (sub)device PCIID, other.
>
> That generally doesn't work for non-x86.
>
Errr... wrong. If PCI bus does not exist (some arm boards to have them
though), one can use usb, platform or host1x specifics.
If those are not enough, suggestions are welcome.

https://cgit.freedesktop.org/mesa/drm/tree/xf86drm.h#n836

-Emil