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

[Emil Velikov]

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.


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

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

HTH
Emil