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

[Rob Herring]

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.

>>> 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.

> 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.

>
> It should also help as one starts shipping devices with multiple GPUs,
> at some point in the future ;-)

Can we solve the simple cases first?

Rob