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

[Tomasz Figa]

On Thu, Feb 22, 2018 at 7:23 AM, Rob Herring <robh at kernel.org> wrote:
>
> On Wed, Feb 21, 2018 at 1:22 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> > 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 ;-)
>
> I'll trade you Android for any thing else. :)
>
>
> >>>>> 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 :-\
>
> Better slow than not booting. There are also usecases such as running
> in the cloud for running tests where performance is not too important.
> AOSP has "devices" now that build images for GCE. CrOS does something
> similar from what Tomasz has said.
>
> Software rendering should be the easy case, but some reason is not.

I think software fallback can be done reasonably right. Perhaps it
could kick in by default only if there is no matching hardware driver?
If there is a matching driver, but initialization fails, perhaps it
could make sense to boil out.

>
> >>> 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.
>
> How does this work across platforms? Feels like just punting the
> problem to someone else. Currently it's in gralloc, so let's move it
> to init to set a property? Also, I'm not sure that setting a property
> is going to work in the future with Treble.
>
> But suppose we do make it a property. Does it really matter that the
> property be a h/w device id and not be the device path? Whatever sets
> the property can figure out the path based on bus info or whatever
> logic it wants. And then for my simple uses, that logic can just be
> hardcoded (as we have today).

Well, we could have property that forces the probing logic to only
match requested driver or bus ID. If no property is set, it could use
the first one that matches any driver, which should cover 90% of the
systems.

Best regards,
Tomasz