[PATCH v3] PCI: create revision file in sysfs

Bjorn Helgaas helgaas at kernel.org
Fri Nov 18 14:29:16 UTC 2016


On Fri, Nov 18, 2016 at 10:48:46AM +0100, Daniel Vetter wrote:
> 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).

Sigh.  AFAIK, this userspace enumeration is really unique to X, and
it's been a PITA for years because it puts too much arch knowledge in
userspace, e.g., PCI segment/domain knowledge, PCI BAR details,
hotplug events, etc.  I personally wouldn't object to udev or
whatever, since that's the supported mechanism everybody else uses.

> I guess in the end I don't really get why caching the revision in the
> kernel is a problem ...

It's not that it's such a problem, I just object to adding things to
enable what seems like a broken design.  But I guess I'm trying to
boil the ocean here, and that energy would be better spent elsewhere,
so I'll apply it.

Bjorn


More information about the dri-devel mailing list