Switchable graphics and radeon PX runtime

Switchable graphics and radeon PX runtime

[Takashi Iwai]

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.)

How are such machines supposed to work with the recent system?  Is PX
wrongly detected on them, or something else missing?

If it shouldn't be treated as PX, would we put them in
radeon_px_quirk_list[]?  Of course, this won't scale.  So, any better
way to detect such machines?


thanks,

Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Dave Airlie]

On 14 November 2014 18:12, Takashi Iwai <tiwai@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.

> 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.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Takashi Iwai]

At Fri, 14 Nov 2014 19:33:00 +1000,
Dave Airlie wrote:
> 
> On 14 November 2014 18:12, Takashi Iwai <tiwai@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


thanks,

Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Alex Deucher]

On Fri, Nov 14, 2014 at 5:09 AM, Takashi Iwai <tiwai@suse.de> wrote:
> At Fri, 14 Nov 2014 19:33:00 +1000,
> Dave Airlie wrote:
>>
>> On 14 November 2014 18:12, Takashi Iwai <tiwai@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?  The X logs look fine.  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.

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.

Setting radeon.runpm=0 does not disable PX, it just stops the kernel
driver from dynamically turning the dGPU on and off on demand.

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Takashi Iwai]

At Fri, 14 Nov 2014 10:40:08 -0500,
Alex Deucher wrote:
> 
> On Fri, Nov 14, 2014 at 5:09 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > At Fri, 14 Nov 2014 19:33:00 +1000,
> > Dave Airlie wrote:
> >>
> >> On 14 November 2014 18:12, Takashi Iwai <tiwai@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?

> Setting radeon.runpm=0 does not disable PX, it just stops the kernel
> driver from dynamically turning the dGPU on and off on demand.

Yes.  The user seem more happy with explicit power control.  At least,
better than this kind of surprises...


thanks,

Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Alex Deucher]

[-- Attachment #1: Type: text/plain, Size: 5305 bytes --]

On Fri, Nov 14, 2014 at 11:14 AM, Takashi Iwai <tiwai@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@suse.de> wrote:
>> > At Fri, 14 Nov 2014 19:33:00 +1000,
>> > Dave Airlie wrote:
>> >>
>> >> On 14 November 2014 18:12, Takashi Iwai <tiwai@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.

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.

>
>> Setting radeon.runpm=0 does not disable PX, it just stops the kernel
>> driver from dynamically turning the dGPU on and off on demand.
>
> Yes.  The user seem more happy with explicit power control.  At least,
> better than this kind of surprises...

It should behave exactly the same if the user starts X without
explicitly powering down the dGPU.  The pci entry just happens to
disappear without runpm so X doesn't try and load the radeon ddx.  The
kernel driver is still loaded however.  So it's not really a fix per
se.

Alex

[-- Attachment #2: 0001-drm-radeon-report-disconnected-for-LVDS-eDP-with-PX-.patch --]
[-- Type: text/x-diff, Size: 2870 bytes --]

From c0f143ab912ea82f0863d6771e198cc8afb9a51a Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Fri, 14 Nov 2014 12:08:34 -0500
Subject: [PATCH] drm/radeon: report disconnected for LVDS/eDP with PX if ddc
 fails

If ddc fails, presumably the i2c mux (and hopefully the signal
mux) are switched to the other GPU so don't fetch the edid from
the vbios so that the connector reports disconnected.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
---
 drivers/gpu/drm/radeon/radeon_connectors.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 300c4b3..26baa9c 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -322,6 +322,12 @@ static void radeon_connector_get_edid(struct drm_connector *connector)
 	}
 
 	if (!radeon_connector->edid) {
+		/* don't fetch the edid from the vbios if ddc fails and runpm is
+		 * enabled so we report disconnected.
+		 */
+		if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
+			return;
+
 		if (rdev->is_atom_bios) {
 			/* some laptops provide a hardcoded edid in rom for LCDs */
 			if (((connector->connector_type == DRM_MODE_CONNECTOR_LVDS) ||
@@ -826,6 +832,8 @@ static int radeon_lvds_mode_valid(struct drm_connector *connector,
 static enum drm_connector_status
 radeon_lvds_detect(struct drm_connector *connector, bool force)
 {
+	struct drm_device *dev = connector->dev;
+	struct radeon_device *rdev = dev->dev_private;
 	struct radeon_connector *radeon_connector = to_radeon_connector(connector);
 	struct drm_encoder *encoder = radeon_best_single_encoder(connector);
 	enum drm_connector_status ret = connector_status_disconnected;
@@ -842,7 +850,11 @@ radeon_lvds_detect(struct drm_connector *connector, bool force)
 		/* check if panel is valid */
 		if (native_mode->hdisplay >= 320 && native_mode->vdisplay >= 240)
 			ret = connector_status_connected;
-
+		/* don't fetch the edid from the vbios if ddc fails and runpm is
+		 * enabled so we report disconnected.
+		 */
+		if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
+			ret = connector_status_disconnected;
 	}
 
 	/* check for edid as well */
@@ -1589,6 +1601,11 @@ radeon_dp_detect(struct drm_connector *connector, bool force)
 			/* check if panel is valid */
 			if (native_mode->hdisplay >= 320 && native_mode->vdisplay >= 240)
 				ret = connector_status_connected;
+			/* don't fetch the edid from the vbios if ddc fails and runpm is
+			 * enabled so we report disconnected.
+			 */
+			if ((rdev->flags & RADEON_IS_PX) && (radeon_runtime_pm != 0))
+				ret = connector_status_disconnected;
 		}
 		/* eDP is always DP */
 		radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DISPLAYPORT;
-- 
1.8.3.1


[-- Attachment #3: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Takashi Iwai]

At Fri, 14 Nov 2014 12:29:17 -0500,
Alex Deucher wrote:
> 
> On Fri, Nov 14, 2014 at 11:14 AM, Takashi Iwai <tiwai@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@suse.de> wrote:
> >> > At Fri, 14 Nov 2014 19:33:00 +1000,
> >> > Dave Airlie wrote:
> >> >>
> >> >> On 14 November 2014 18:12, Takashi Iwai <tiwai@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.

During debugging, I came up to a similar hack, too, but then changed
my mind later that the old good vgaswitcheroo might be more
straightforward (and indeed it "works" more or less). 

> >> Setting radeon.runpm=0 does not disable PX, it just stops the kernel
> >> driver from dynamically turning the dGPU on and off on demand.
> >
> > Yes.  The user seem more happy with explicit power control.  At least,
> > better than this kind of surprises...
> 
> It should behave exactly the same if the user starts X without
> explicitly powering down the dGPU.  The pci entry just happens to
> disappear without runpm so X doesn't try and load the radeon ddx.  The
> kernel driver is still loaded however.  So it's not really a fix per
> se.

That's true.  My intention was to avoid unexpected regressions.  It's
an old hardware, and users already are used to the old way.

If everything works, no reason to go back to old hacks :)


Takashi
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Takashi Iwai]

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@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@suse.de> wrote:
> > >> > At Fri, 14 Nov 2014 19:33:00 +1000,
> > >> > Dave Airlie wrote:
> > >> >>
> > >> >> On 14 November 2014 18:12, Takashi Iwai <tiwai@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Switchable graphics and radeon PX runtime

[Alex Deucher]

On Tue, Nov 25, 2014 at 3:11 PM, Takashi Iwai <tiwai@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@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@suse.de> wrote:
>> > >> > At Fri, 14 Nov 2014 19:33:00 +1000,
>> > >> > Dave Airlie wrote:
>> > >> >>
>> > >> >> On 14 November 2014 18:12, Takashi Iwai <tiwai@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel