Switchable graphics and radeon PX runtime

[Alex Deucher]

On Tue, Nov 25, 2014 at 3:11 PM, Takashi Iwai <tiwai at suse.de> wrote:
> 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!

Great!  Just sent it to Dave for -fixes.

Alex

>
>
> Takashi