[Mesa-dev] [PATCH v1 0/7] Implement commont gralloc_handle_t in libdrm
robh at kernel.org
Wed Feb 21 18:50:14 UTC 2018
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?
More information about the mesa-dev