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

[Emil Velikov]

On 22 February 2018 at 05:57, Tomasz Figa <tfiga at chromium.org> wrote:
> 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.
>
An explicit fallback or using SW on cloud-like services is perfectly reasonable.
FWIW there is an EGL API for explicit device selection, Mesa
implementation is WIP tough.

>>
>> >>> 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.
>
This sounds perfectly reasonable, IMHO.

Thanks
Emil