On 22 February 2018 at 05:57, Tomasz Figa <tf...@chromium.org> wrote: > On Thu, Feb 22, 2018 at 7:23 AM, Rob Herring <r...@kernel.org> wrote: >> >> On Wed, Feb 21, 2018 at 1:22 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >> > On 21 February 2018 at 18:50, Rob Herring <r...@kernel.org> wrote: >> >> On Wed, Feb 21, 2018 at 10:01 AM, Emil Velikov <emil.l.veli...@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 <tf...@chromium.org> wrote: >> >>>> On Wed, Feb 21, 2018 at 4:03 AM, Rob Herring <r...@kernel.org> wrote: >> >>>>> On Tue, Feb 20, 2018 at 4:26 AM, Tomasz Figa <tf...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
