On Fri, Nov 18, 2016 at 10:42:07AM +0100, Daniel Vetter wrote: > On Thu, Nov 17, 2016 at 08:40:10PM -0600, Bjorn Helgaas wrote: > > On Fri, Nov 18, 2016 at 10:42:20AM +0900, Michel Dänzer wrote: > > > On 18/11/16 08:48 AM, Bjorn Helgaas wrote: > > > > > > > > Popping the stack all the way back to Emil's Nov 8 message: > > > > > > > > When using the Mesa drivers alongside firefox [1] (since Mesa 13.0), > > > > glxinfo (Mesa 10.0) and others, all the GPUs* will be awaken, > > > > causing unwanted delays and increased power usage. > > > > > > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=98502 > > > > > > > > The bug is about a delay in starting firefox, thunderbird, or > > > > chromium. I assume the browser starts on the current, powered-up, > > > > GPU. I don't understand why we care about the revision of other, > > > > powered-off, GPUs. > > > > > > We don't. The problem is that the current libdrm API unconditionally > > > provides the revision. The plan is to address this in two ways: > > > > > > * Add new libdrm API which allows the caller to say "I don't need the > > > revision", and make Mesa use that. Users having those changes will not > > > run into the problem even on older kernels. > > > > > > * Add the separate revision file in sysfs and make libdrm use that for > > > its current API. This means that even callers of the current libdrm API > > > will not run into the problem with newer kernels. > > > > Why do we care about *anything* for the other, powered-off, GPUs? > > Even users of the new libdrm API who say "I don't need the revision" > > are still getting the vendor/device/etc for those other GPUs. > > egl device enumeration, and for that you need to know what gpus you have > and load their drivers. Afaik. Yes by default they'll all select the > online gpu, but they can opt for the faster/other one on multi-gpu > machines. Now the only reason we can avoid parsing the revision flag is that most drivers don't care, and the one that does (i915) is generally the one that's on and only needs it after driver init. But fundamentally we can't avoid the enumeration, and imo it's better to cache this in the kernel than implement some userspace thingy (require udev or whatever). I guess in the end I don't really get why caching the revision in the kernel is a problem ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
