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. >>> 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? Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
