Switchable graphics and radeon PX runtime

Tue Nov 25 12:11:20 PST 2014

At Fri, 14 Nov 2014 20:39:15 +0100,
Takashi Iwai wrote:
> 
> At Fri, 14 Nov 2014 12:29:17 -0500,
> Alex Deucher wrote:
> > 
> > On Fri, Nov 14, 2014 at 11:14 AM, Takashi Iwai <tiwai at suse.de> wrote:
> > > At Fri, 14 Nov 2014 10:40:08 -0500,
> > > Alex Deucher wrote:
> > >>
> > >> On Fri, Nov 14, 2014 at 5:09 AM, Takashi Iwai <tiwai at suse.de> wrote:
> > >> > At Fri, 14 Nov 2014 19:33:00 +1000,
> > >> > Dave Airlie wrote:
> > >> >>
> > >> >> On 14 November 2014 18:12, Takashi Iwai <tiwai at suse.de> wrote:
> > >> >> > Hi Alex,
> > >> >> >
> > >> >> > we've got a few bug reports about the behavior of radeon driver on
> > >> >> > machines with Intel+AMD "switchable graphics" (no Muxless).  So far,
> > >> >> > it seems that the sane only way to make the machine working is to get
> > >> >> > back to the old vgaswitcheroo behavior via radeon.runpm=0.  Without
> > >> >> > it, radeon GPU gives a spurious output as connected, eventually
> > >> >> > crashes GNOME.  (Also, from the nature of the switchable graphics,
> > >> >> > vgaswitcheroo looks more intuitive to me.)
> > >> >>
> > >> >> vgaswitcheroo only matters if there is a MUX, the point of it is to drive
> > >> >> the MUX.
> > >> >>
> > >> >> dynamic poweroff makes more sense, switcheroo on/off switch was
> > >> >> just a hack.
> > >> >
> > >> > Well, I find the current form fairly unintuitive, at least, for the
> > >> > switchable (not optimus) graphics.
> > >> > With dynamic PM, the card is activated on demand.  So you may enable
> > >> > outputs of both cards at any time, right?
> > >> >
> > >> > Currently, all outputs from both cards are exposed in Xrandr,
> > >> > e.g. LVDS1 DP1, HDMI1, VGA1, LVDS-1-1, HDMI-1-2, DisplayPort-1-2, and
> > >> > VGA-1-1.  How can user-space know which one should be activated and
> > >> > which not, when you can use effectively only a single card?
> > >> >
> > >> >> > How are such machines supposed to work with the recent system?  Is PX
> > >> >> > wrongly detected on them, or something else missing?
> > >> >>
> > >> >> It sounds like the connector is wrongly detected and that should be what
> > >> >> is fixed.
> > >> >
> > >> > Yeah, that's a problem indeed.  In the bug report, both LVDS1 and
> > >> > LVDS-1-1 are reported to be connected at the same time while the
> > >> > latter doesn't get any real size and position.  We didn't trace
> > >> > whether this is the culprit of crash of GNOME, but at least, it looks
> > >> > fairly weird.
> > >> >
> > >> > I forgot to give the original bug report:
> > >> >   http://bugzilla.opensuse.org/show_bug.cgi?id=904417
> > >> >
> > >> > and the xrandr output is found at
> > >> >   http://bugzilla.opensuse.org/show_bug.cgi?id=904417#c18
> > >>
> > >> It's not clear to me from the bug report what that problem is.  What
> > >> exactly is gnome complaining about?
> > >
> > > It simply crashes by some reason, showing a sad face and complaining
> > > something is wrong.  (And it's GNOME, not easy to get a proper log
> > > like kernel :)
> > > Some users complained about blank output, but I'm not sure whether
> > > this is the same cause.
> > >
> > >> The X logs look fine.
> > >
> > > I couldn't see any errors there, too.  So it's just a wild guess, so
> > > far...
> > >
> > >> From the
> > >> xrandr output, LVDS1 (connected to the intel) is connected and active.
> > >> LVDS-1-1 (connected to the radeon) is connected but not active.  That
> > >> should be a perfectly reasonable configuration.  If LVDS-1-1 is not
> > >> active, the radeon kernel driver will power down the GPU until the
> > >> user either activates the panel or uses the dGPU as an offscreen
> > >> renderer.
> > >
> > > Note that the xrandr output was taken on icewm or else.  So, right,
> > > this might be non-issue.  But, I guess now that the issue will happen
> > > when LVDS-1-1 is activated at the same time with LVDS.  GNOME tries to
> > > activate all connected outputs at the same time as default.
> > >
> > >> There are plenty of cases when you may have a secondary GPU with
> > >> attached displays that are not active. If gnome barfs on this it
> > >> should be fixed in gnome.
> > >
> > > Yeah, GNOME has definitely a problem about it.  At least, it shouldn't
> > > crash badly.
> > >
> > > But, it's still not clear to me how the activation of the radeon GPU
> > > is supposed to work in switchable graphics case.  For PX or Otpimus,
> > > it's clear.  But for switchable case, there is no offload rendering.
> > > If you enable the output on radeon GPU while Intel output is being
> > > used, what's going on?  Shouldn't they be handled exclusively, as user
> > > expected?
> > 
> > You can still do offload rendering with a switchable system, it just
> > happens to also have a mux which you can use or not use.  That's how
> > it works today.
> > 
> > If you enable the outputs on both gpus, they will both power up the
> > display hw on the GPU, but only the signals from the gpu selected by
> > the mux will actually make it to the display.
> 
> Yes, that's the problem.  The desktop expects that the connected
> output can be shown properly at the desired place and size. (GNOME
> will try to place all connected outputs from left to right as default,
> IIRC.) 
> But, in this case, it's not informed that some connected outputs are
> actually not visible.
> 
> > Does the attached hack help?  It basically attempts to determine
> > whether the mux is switched to the radeon or not and report
> > disconnected or not for the local displays.  To handle handle it
> > properly, vgaswitcheroo would need to track the signal and ddc/hpd
> > muxes and propagate them to the drivers.
> 
> Thanks!  I'll provide a test KMP including this patch to reporters to
> give a try.

Got a positive feedback, the patch works.  Thanks!

Takashi