Re: [Intel-gfx] [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation

[Bastien Nocera]

On Sun, 2017-04-30 at 21:34 +0200, Hans de Goede wrote:
> Hi,
> 
> On 27-04-17 18:39, Bastien Nocera wrote:
> > On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote:
> > > On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
> > > > On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > > > I've a patch for iio-sensor-proxy which fixes the rotation
> > > > > > under
> > > > > > Xorg /
> > > > > > Wayland when using a desktop environment which honors iio-
> > > > > > sensor-
> > > > > > proxy's
> > > > > > rotation detection:
> > > > > > https://github.com/hadess/iio-sensor-proxy/pull/162
> > > > > 
> > > > > Or is it just this thing that clobbers what the DDX inherited
> > > > > from
> > > > > the
> > > > > kernel as the initial rotation?
> > > > 
> > > > I think it's mostly got to do with the compositor (or X) not
> > > > knowing
> > > > what "normal" or "0 degrees rotation" corresponds to.
> > > 
> > > Well, there are really two cases to consider:
> > > 
> > > 1. BIOS/whatever configures display hardware rotation in a way
> > > that matches the orientation of the physical display
> > > 2. BIOS didn't do that. Either the hardware can't do what
> > > would be required, or the BIOS just chose not to do it.
> > > 
> > > Case 1 should work with these patches as long as the DDX will set
> > > up
> > > the
> > > initial randr rotation to match what it read out from the kms
> > > rotation
> > > property of the primary plane. >
> > 
> > Yes. My problem was that instead of fixing the DDX to behave
> > properly,
> > reusing the same orientation as already configured, we were using
> > iio-
> > sensor-proxy to trigger the initial rotation. This doesn't work if
> > there's no accelerometer, or orientation is locked, which is
> > counter-
> > intuitive.
> 
> Right, so the iio-sensor-proxy approach was a quick fix attemp and
> I agree with you that with e.g. orientation locking breaking this
> it is not a good fix.
> 
> Also note that with wayland we have no DDX and relying on reading
> the current primary plane rotation and assuming that that is the
> hw lcd panel orientation seems fragile in general, what if the
> xserver crashes while the display is rotated ? Then the next instance
> will assume that this is hardware panel orientation.
> 
> > > Case 2 can't work without some mechanism to query the orientation
> > > of the display from the firmware/etc.
> > 
> > Yes. I'm not sure where we'd be exporting this quirk though, as we
> > need
> > it available early enough so that it can be used by boot splashes.
> > DMI
> > matches in the graphics driver?
> 
> Looking at what gnome currently does on both wayland and X11 AFAICT,
> I
> would like to solve both cases in the same manner in both cases we
> need the compositor to be aware that it needs to apply some rotation.
> 
> Also taking into account thing like the monitor configuration panel
> I think we need to fix this at the compositor level by having some
> sort of "lcd-panel-hardware-rotation" property which gets added to
> the rotation selected by the user at the compositor level.
> 
> As for where to store this for case 1 we have the info in the kernel
> from the firmware (once these patches land) so we just need to export
> it somehow.
> 
> For case 2 we do need a dmi quirk in the kernel to set fbcon.rotate
> properly, and once we have it there we can export it in what is
> hopefully the same manner.
> 
> Note that the GPD-win (which is an example of case 2) seems to be
> a rare example and case 1 is the more common case, so lets focus
> on fixing that first. It seems that these 2 patches get us quite
> far with fixing this, we just need to add some property (sysfs file?)
> to the drm_connector where the initial rotation as inherited from
> the firmware can be read by the compositor. Once we have that in
> place we can add a dmi quirk to set that property for e.g. the
> GPD-win and somehow propagate it to fbcon.rotate (case 2 needs to
> be done with software rotation in fbcon because the hw cannot handle
> all rotation cases).

Sounds like a good plan!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/fb-helper: Make fbdev inherit the crtc's rotation

[Bastien Nocera]

On Sun, 2017-04-30 at 21:22 +0200, Hans de Goede wrote:
> Hi,
> 
> On 26-04-17 14:13, Bastien Nocera wrote:
> > On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> > > From: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > 
> > > If a connector added through drm_fb_helper_add_one_connector()
> > > has
> > > a crtc attached and that crtc has a rotation configured make the
> > > fbdev inherit the crtc's rotation.
> > > 
> > > This is useful on e.g. some tablets which have their lcd panel
> > > mounted
> > > upside down, which before this commit would result in the kernel
> > > boot
> > > messages switching from being shown the right way up in efifb to
> > > being
> > > shown upside down as soon as a native kms driver loads.
> > > 
> > > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> > > Cc: Ville Syrjala <ville.syrj...@linux.intel.com>
> > > [hdego...@redhat.com: Split the drm/fb-helper bits out of Ville's
> > >   "drm/fb-helper: Inherit rotation wip" patch]
> > > Tested-by: Hans de Goede <hdego...@redhat.com>
> > > Signed-off-by: Hans de Goede <hdego...@redhat.com>
> > > ---
> > >   drivers/gpu/drm/drm_fb_helper.c | 51
> > > ++---
> > >   include/drm/drm_fb_helper.h |  2 ++
> > >   2 files changed, 50 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 324a688..c97e00ab 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -159,6 +159,8 @@ int drm_fb_helper_add_one_connector(struct
> > > drm_fb_helper *fb_helper, struct drm_
> > >   {
> > >   struct drm_fb_helper_connector **temp;
> > >   struct drm_fb_helper_connector *fb_helper_connector;
> > > + struct drm_crtc *crtc = connector->encoder ?
> > > + connector->encoder->crtc : NULL;
> > >   
> > >   if (!drm_fbdev_emulation)
> > >   return 0;
> > > @@ -180,6 +182,11 @@ int drm_fb_helper_add_one_connector(struct
> > > drm_fb_helper *fb_helper, struct drm_
> > >   
> > >   drm_connector_reference(connector);
> > >   fb_helper_connector->connector = connector;
> > > + if (crtc && crtc->primary->state)
> > > + fb_helper_connector->rotation = crtc->primary-
> > > > state->rotation;
> > > 
> > > + if (!fb_helper_connector->rotation)
> > > + fb_helper_connector->rotation = DRM_ROTATE_0;
> > 
> > That's equivalent to:
> > if (fb_helper_connector->rotation = DRM_ROTATE_0)
> > fb_helper_connector->rotation = DRM_ROTATE_0;
> 
> No it is not equivalent:
> 
> include/drm/drm_blend.h
> 40:#define DRM_ROTATE_0 BIT(0)
> 
> and BIT(0) is (1 << 0)

Urgh. I'd have a "DRM_ROTATE_UNSET = 0" added either to the public
header, or to this file and compare to it instead of "!rotation".
Because this really wasn't clear or obvious.

Cheers
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation

[Bastien Nocera]

On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote:
> > On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> > > 
> > 
> > 
> > 
> > > > I've a patch for iio-sensor-proxy which fixes the rotation
> > > > under
> > > > Xorg /
> > > > Wayland when using a desktop environment which honors iio-
> > > > sensor-
> > > > proxy's
> > > > rotation detection:
> > > > https://github.com/hadess/iio-sensor-proxy/pull/162
> > > 
> > > Or is it just this thing that clobbers what the DDX inherited
> > > from
> > > the
> > > kernel as the initial rotation?
> > 
> > I think it's mostly got to do with the compositor (or X) not
> > knowing
> > what "normal" or "0 degrees rotation" corresponds to.
> 
> Well, there are really two cases to consider:
> 
> 1. BIOS/whatever configures display hardware rotation in a way
>    that matches the orientation of the physical display
> 2. BIOS didn't do that. Either the hardware can't do what
>    would be required, or the BIOS just chose not to do it.
> 
> Case 1 should work with these patches as long as the DDX will set up
> the
> initial randr rotation to match what it read out from the kms
> rotation
> property of the primary plane.

Yes. My problem was that instead of fixing the DDX to behave properly,
reusing the same orientation as already configured, we were using iio-
sensor-proxy to trigger the initial rotation. This doesn't work if
there's no accelerometer, or orientation is locked, which is counter-
intuitive.

> Case 2 can't work without some mechanism to query the orientation
> of the display from the firmware/etc.

Yes. I'm not sure where we'd be exporting this quirk though, as we need
it available early enough so that it can be used by boot splashes. DMI
matches in the graphics driver?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation

[Bastien Nocera]

On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> 


> > I've a patch for iio-sensor-proxy which fixes the rotation under
> > Xorg /
> > Wayland when using a desktop environment which honors iio-sensor-
> > proxy's
> > rotation detection:
> > https://github.com/hadess/iio-sensor-proxy/pull/162
> 
> Or is it just this thing that clobbers what the DDX inherited from
> the
> kernel as the initial rotation?

I think it's mostly got to do with the compositor (or X) not knowing
what "normal" or "0 degrees rotation" corresponds to.

I would expect the baseline test for this wouldn't involve iio-sensor-
proxy at all, and boot to the desktop with the expected orientation
showing up in the desktop env/XRandR as "not rotated".

Eg. for the GPD Win which does have this problem, this should appear as
being rotated (image 1):
https://c.slashgear.com/wp-content/uploads/2016/11/gpd-win-book-2.jpg
But not this (image 2):
https://c.slashgear.com/wp-content/uploads/2016/11/gpd-win-0-800x420.jpg

After that, the problem is whether the accelerometer is mounted the
same way as the "non-rotated screen" (option 2), or the "non-rotated
screen" (option 1), which would show what quirking is needed.

Cheers
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make get_initial_plane_config also get the initial rotation config

[Bastien Nocera]

On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala 

> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 344f238..63623dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -418,6 +418,7 @@ struct intel_initial_plane_config {
>   unsigned int tiling;
>   int size;
>   u32 base;
> + uint8_t rotation;

Mentioning what this is (DRM_ROTATE_* or something else) is even more
important here.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/fb-helper: Make fbdev inherit the crtc's rotation

[Bastien Nocera]

On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala 
> 
> If a connector added through drm_fb_helper_add_one_connector() has
> a crtc attached and that crtc has a rotation configured make the
> fbdev inherit the crtc's rotation.
> 
> This is useful on e.g. some tablets which have their lcd panel
> mounted
> upside down, which before this commit would result in the kernel boot
> messages switching from being shown the right way up in efifb to
> being
> shown upside down as soon as a native kms driver loads.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> Cc: Ville Syrjala 
> [hdego...@redhat.com: Split the drm/fb-helper bits out of Ville's
>  "drm/fb-helper: Inherit rotation wip" patch]
> Tested-by: Hans de Goede 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 51
> ++---
>  include/drm/drm_fb_helper.h |  2 ++
>  2 files changed, 50 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 324a688..c97e00ab 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -159,6 +159,8 @@ int drm_fb_helper_add_one_connector(struct
> drm_fb_helper *fb_helper, struct drm_
>  {
>   struct drm_fb_helper_connector **temp;
>   struct drm_fb_helper_connector *fb_helper_connector;
> + struct drm_crtc *crtc = connector->encoder ?
> + connector->encoder->crtc : NULL;
>  
>   if (!drm_fbdev_emulation)
>   return 0;
> @@ -180,6 +182,11 @@ int drm_fb_helper_add_one_connector(struct
> drm_fb_helper *fb_helper, struct drm_
>  
>   drm_connector_reference(connector);
>   fb_helper_connector->connector = connector;
> + if (crtc && crtc->primary->state)
> + fb_helper_connector->rotation = crtc->primary-
> >state->rotation;
> + if (!fb_helper_connector->rotation)
> + fb_helper_connector->rotation = DRM_ROTATE_0;

That's equivalent to:
if (fb_helper_connector->rotation = DRM_ROTATE_0)
   fb_helper_connector->rotation = DRM_ROTATE_0;

Maybe:
if (crtc && crtc->primary->state)
   ...
else
   ...->rotation = DRM_ROTATE_0;
would be clearer? Or simply omit it if the connector is zero'ed.   


> diff --git a/include/drm/drm_fb_helper.h
> b/include/drm/drm_fb_helper.h
> index 6f5aceb..19fc313 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -48,6 +48,7 @@ struct drm_fb_helper_crtc {
>   struct drm_mode_set mode_set;
>   struct drm_display_mode *desired_mode;
>   int x, y;
> + uint8_t rotation;
>  };
>  
>  /**
> @@ -159,6 +160,7 @@ struct drm_fb_helper_funcs {
>  
>  struct drm_fb_helper_connector {
>   struct drm_connector *connector;
> + uint8_t rotation;

In both those cases, I'd add a mention of the type of enum/mask etc.
for the rotation, for example:
uint8_t rotation; /* DRM_ROTATE_* */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote:
> 

> > So I'd push DIGD to the switch sysfs entry on boot. But I'm
> > guessing
> > that won't turn off the other output we're not interested in.
> IGD and DIGD switch to the integrated GPU and also turn off the
> discrete
> GPU. However if the machine is already switched to the integrated
> GPU,
> the commands are no-ops and the discrete GPU is not turned off.
> 
> In other words you need to check (by reading the switch file) which
> GPU
> the machine is switched to. If it's the integrated GPU, write OFF to
> the
> switch file. If it's the discrete GPU, write DIGD to the switch file.
> 
> Once runtime pm works, writing DIGD is sufficient.

I tested the runtime patches for Radeon on top of 4.6.0-rc2, and
writing DIGD failed. I also saw a number of messages with the
vga_switcheroo core in the kernel trying to switch GPUs but failed
because "client 1" was keeping it busy.

Is there any way to see what this "client 1" actually is? I'm guessing
plymouth. In any case, once I'm logged in, the "DIS" is powered and
used, and the IGD is powered as well.

Cheers
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Tue, 2016-03-15 at 21:10 +1000, Dave Airlie wrote:
> > 
> > 
> > I guess that's only useful until we get runtime PM support.
> For the discrete GPUs on regular laptops we have runtime PM support
> for
> powerdown already. Some newer laptops need a bit of work in the PCIE
> layer
> but for most things we have it covered. The known broken ones are
> Apple
> laptops. If the apple-gmux code is working well enough to power off
> GPUs,
> then it should be possible to hook up runtime-pm on those machines
> pretty
> simply.
> 
> So there shouldn't really be a case we care about.
> 
> runtime PM for the Intel GPU isn't as important. We don't even want
> to
> turn the i915 fully off anymore.

Fair enough. And it's not that big a problem if we want to try and run
the compositor on the integrated card by default either.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote:
> Hi Bastien,
> 
> sorry for the delay.
> 
> On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote:
> > 
> > We could, on boot, force using the integrated GPU, turning off the
> > discrete GPU that we're not interested in.
> Yes, many people "solve" this by having grub write the requisite
> commands
> to gmux' I/O ports, however this approach won't work with gummiboot.
> Also, the commands that need to be sent to gmux differ between
> retinas
> and pre-retinas.

Which is why I'd be fine with having user-space doing it later on. I
don't think users should have to poke at the boot parameters under
normal circumstances.

> > So I'd push DIGD to the switch sysfs entry on boot. But I'm
> > guessing
> > that won't turn off the other output we're not interested in.
> IGD and DIGD switch to the integrated GPU and also turn off the
> discrete
> GPU. However if the machine is already switched to the integrated
> GPU,
> the commands are no-ops and the discrete GPU is not turned off.
> 
> In other words you need to check (by reading the switch file) which
> GPU
> the machine is switched to. If it's the integrated GPU, write OFF to
> the
> switch file. If it's the discrete GPU, write DIGD to the switch file.
> 
> Once runtime pm works, writing DIGD is sufficient.

This isn't the greatest API, but let me make a note of that:
https://github.com/hadess/switcheroo-control/issues/1

I guess that's only useful until we get runtime PM support.

> > DIGD and DDIS should help (you need to log out/log in again), and
> > if
> > the current GPU is the integrated one, you could force running,
> > say, a
> > game on the discrete GPU using DRI_PRIME=1, correct?
> If runtime pm works, then yes. Otherwise you'd have to manually power
> up
> the GPU before using DRI_PRIME=1 and power it down afterwards.

Another need for run-time PM.

> > FWIW, using OFF at runtime made my machine hang, and without any
> > ways
> > for me to get debug output.
> Which GPU were you switched to? Did you issue the command while X11
> was
> running? Since the machine is switched to the AMD on boot, I guess
> you
> were powering down the Intel GPU. This works on my machine, I get a
> log
> entry "i915: switched off". If this doesn't work on your machine it
> might
> be an i915 bug on your Sandy Bridge GPU or it might be because X11 is
> running.
> 
> Try booting with "drm.debug=0xf log_buf_len=10M" and see if this gets
> you
> log output. If it doesn't, netconsole might help if the hang occurs
> while
> the console is locked.

I'll try it out with your runtime PM patches on top of the latest
upstream one.

> > Ok, so using GIGD or DDIS would just switch the output, but not
> > turn
> > off the unused GPU without runtime PM management.
> No. They do switch off the other GPU if runtime pm is disabled.
> 
> 
> > 
> > > 
> > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz   => gpu
> > > switching
> > > for 4.5
> > That's the same patch that's already applied to the kernel above
> > (the
> > ones from this patchset thread), right?
> I'm not sure, the patches in the copr repository might be an earlier
> test version.

Might explain the problems I had.

> > My concerns here would be:
> > - Do we know how to turn off the integrated GPU automatically, if
> > the
> > user only used the internal screen and wanted to use the discrete
> > GPU?
> Runtime pm is currently disabled by default for i915. The Intel folks
> are on it. Until that works, the integrated GPU will be powered down
> when the user manually switches to the discrete GPU with DIS / DDIS
> and powered up when switching back with IGD / DIGD.

Do we have a way to know whether runtime PM is available for one/both
GPUs in the machine? Otherwise this really explodes the testing grid,
and it really makes everything harder.

> > - If only the discrete GPU is powered on, do we know how to power
> > on
> > the integrated GPU so it can drive the external screen when plugged
> > in?
> On the MBP5 2008/09 and MBP6 2010, the external DP port can be
> switched
> between GPUs and we switch it together with the panel. So if you
> switch
> to the discrete GPU, you can also drive the external DP port on these
> models and the integrated GPU can be turned off.
> 
> On the MBP8 2011 and newer, external ports are combined
> DP/Thunderbolt
> ports which can only be driven by the discrete GPU. For some reason
> the
> HPD/AUX pins of the ports can still be switched but not the other
> pins.
> We should nail these ports to 

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

Hey Dave,

On Thu, 2016-03-10 at 09:30 +1000, Dave Airlie wrote:

> Okay so I'm not sure you are heading in the best direction here.
> 
> My first suggestion is to stop using the MBP, start using the Lenovo.
> At least from a Fedora perspective, that is the hw we have more
> installs of and
> care more about.

The Lenovo has an NVidia GPU, and there's no runtime PM support for
nouveau.

> Apple HW is not the same as PC hw in this case and we aren't going to
> achieve
> the same level of integration that OSX has, not without some serious
> rewrites of
> mutter and the whole X stack.

That's not the target goals. Did you read the wiki page I pointed to
listing the goals?

https://wiki.gnome.org/Design/OS/DualGPU

> You shouldn't be caring about the MUX.

I never talked about the MUX, didn't plan on using it either.



> So I'm missing what the overall goal here is. To provide better
> support for dual-gpu
> laptops and hotpluggable USB devices in the DE?

Just dual-GPU devices for now.

I'd be interested in supporting USB displays, but I only have
proprietary drivers for my USB3 DisplayLink dock, and possibly
networked display devices, but the AirTame I have is also still using
an undocumented protocol.

> Under X, Fedora carries a server patch to autoconfigure providers,
> we'd need to drop
> that and have something in the DE notice when a new provider shows up
> and configures it,
> perhaps something to allow removal of providers that are already
> bound
> (so we could detach
> a secondary GPU for boxes to passthrough).

I'd rather have that be automated so that Boxes can tell you what is
using the 2nd GPU, not requiring any manual intervention.

> Then we need something in the DE to allow us to launch or have some
> app info that would
> decide to launch certain 3D using apps on the more powerful
> processor.

That's what I started working on, exporting the fact that 2 GPUs are
available through a D-Bus service, which also ensures that we only 

> However since
> nouveau doesn't quite reclock most of the secondary GPUs that can
> often end up not being
> that much more powerful.

There are supported laptops with Radeon GPUs as well, not sure whether
that's more powerful.

> We also want reverse prime to work properly, so if you plug in an
> external monitor to
> a port connected to the secondary GPU that we can pick it up and
> configure it just like
> all the other monitors.

I don't think I have any hardware that works this way.

> As for the MBP, if we want to spend time chasing the rainbow of OS X,
> then we've a lot of work
> to do. OSX can smoothly switch the compositor from rendering on the
> intel gpu to the nvidia
> gpu in a vblank. It's truly seamless. To do that we'd need to a) move
> to wayland, b) get mutter
> to be a lot smarter than mutter currently is.

That's not what I'm aiming for right now.

Cheers
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Thu, 2016-03-10 at 16:29 +0100, Bastien Nocera wrote:
> > Then we need something in the DE to allow us to launch or have some
> > app info that would
> > decide to launch certain 3D using apps on the more powerful
> > processor.
> 
> That's what I started working on, exporting the fact that 2 GPUs are
> available through a D-Bus service, which also ensures that we only 

And I missed a bit of text there:

which also ensures that we only enable and use the internal GPU by
default:
https://github.com/hadess/switcheroo-control/blob/master/src/switcheroo-control.c#L196

The full D-Bus service is at:
https://github.com/hadess/switcheroo-control

I guess I should start with disabling the Fedora specific X patch to
autoconfigure outputs and start adding code to mutter to set those up.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Sat, 2016-03-05 at 15:16 +0100, Lukas Wunner wrote:
> Hi Bastien,
> 
> On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote:
> > 
> > Lukas Wunner  wunner.de> writes:
> > > 
> > > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013),
> > > v5.
> > I've tested your patchset on a MacBookPro8,1, with an integrated
> > Intel and
> > discrete AMD/ATI GPUs.
> Hm, it must be either an 8,2 or 8,3. The 8,1 was a 13" machine and
> only
> had an integrated GPU.

Sorry, it's an "8,2". That's what I get for having not having my mail
on that machine.

> > 
> > I've used the COPR repository here to cut down on my compilation
> > time:
> > https://copr.fedorainfracloud.org/coprs/firstyear/kernel-mbp/
> > 
> > I'm not certain how to test out your changes, or what the
> > consequences should
> > be on a stock Fedora 23/GNOME 3.18 installation. After booting
> > (note that I
> > did not change any command-line options in grub), a gnome-shell/gdm 
> > X11
> > session comes up (I disabled Wayland, to rule out behavioural
> > changes), I'd
> > log in to GNOME and gnome-shell (which starts another X11 session
> > on
> > another VT).
> Switching and power control currently requires manual intervention
> by echoing commands to /sys/kernel/debug/vgaswitcheroo/switch
> as documented here:
> https://01.org/linuxgraphics/gfx-docs/drm/modes_of_use.html

Right, though I would intend on automating this.

> As you've correctly observed, the machine is initially switched to
> the discrete GPU and both GPUs are turned on. By echoing "IGD" to
> the sysfs file, you'll switch to the integrated GPU and turn off
> the discrete GPU.
> 
> It's possible to let the EFI firmware switch to the integrated GPU
> on boot by using this tool: https://github.com/0xbb/gpu-switch
> However still both GPUs will be powered up, so you have to issue
> the "OFF" command to sysfs to power the discrete GPU down. Also,
> once you boot into OS X, the setting made by the gpu-switch tool
> will be overwritten and the machine will be switched to the discrete
> GPU again the next time you boot Linux.

We could, on boot, force using the integrated GPU, turning off the
discrete GPU that we're not interested in.
So I'd push DIGD to the switch sysfs entry on boot. But I'm guessing
that won't turn off the other output we're not interested in.

> Note that switching is only possible from the text console, with
> X11/Wayland shut down. Obviously this is not great in terms of UX.
> A few years ago there was a GSoC proposal to get hot GPU switching
> to work on Linux (akin to what OS X does) but nothing ever came of
> it:
> http://www.phoronix.com/scan.php?page=news_item=OTIyMQ
> https://lists.x.org/archives/xorg/2011-March/052522.html
> 
> Unfortunately this seems to be a low priority item for kernel
> graphics
> developers since nowadays most dual GPU notebooks no longer have a
> mux
> and cannot switch. The MacBook Pro seems to be the last one
> supporting
> this but I've witnessed a bit of an anti-Apple sentiment among kernel
> graphics developers since everything is non-standard there. Which is
> unfortunate because these machines have a large market share and
> Apple
> software quality is deteriorating rapidly so a lot of Mac users are
> ripe for converting to Linux.

DIGD and DDIS should help (you need to log out/log in again), and if
the current GPU is the integrated one, you could force running, say, a
game on the discrete GPU using DRI_PRIME=1, correct?

FWIW, using OFF at runtime made my machine hang, and without any ways
for me to get debug output.

> Anyway, one short-term improvement will be to add runtime pm support
> (called "Driver power control" in the vga_switcheroo documentation
> linked above). That way it'll no longer be necessary to power the
> discrete GPU up and down manually, this will happen automatically
> as needed (when switching or using render offloading with DRI PRIME).

Ok, so using GIGD or DDIS would just switch the output, but not turn
off the unused GPU without runtime PM management.

> I have patches to enable this for radeon but they're completely
> untested:
> 
> http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz   => gpu switching
> for 4.5

That's the same patch that's already applied to the kernel above (the
ones from this patchset thread), right?

> http://wunner.de/mbp_switcheroo_v5-4.5-runpm.tar.gz => runtime pm for
> radeon

OK, will test those out.

> I have an Nvidia based machine and runtime pm doesn't work there yet
> because of bugs in nouveau that I haven't had the time to look into.
> 
> 
> > 
> > I di

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Sat, 2016-03-05 at 15:16 +0100, Lukas Wunner wrote:
> Hi Bastien,
> 
> On Fri, Mar 04, 2016 at 04:12:27PM +, Bastien Nocera wrote:
> > 
> > Lukas Wunner  wunner.de> writes:
> > > 
> > > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013),
> > > v5.
> > I've tested your patchset on a MacBookPro8,1, with an integrated
> > Intel and
> > discrete AMD/ATI GPUs.
> Hm, it must be either an 8,2 or 8,3. The 8,1 was a 13" machine and
> only
> had an integrated GPU.

On the 8,2, still, and with the kernel from the COPR repo[1].

I tried running:
echo DIGD > switch

to (later) switch to the integrated GPU. Log out, get to gdm, log back
in to a black screen with the cursor visible and nothing else.

I'm wondering if it's the gdm X11 session running in the background
that makes this fail.

I'd like to try and get this working properly before bringing the
runtime PM support into it.

[1]: That's the list of patches in the kernel:
http://copr-dist-git.fedorainfracloud.org/cgit/firstyear/kernel-mbp/kernel.git/tree/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro

[Bastien Nocera]

Lukas Wunner  wunner.de> writes:
> 
> Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5.


Hey Lukas,

I've tested your patchset on a MacBookPro8,1, with an integrated Intel and
discrete AMD/ATI GPUs.
I've used the COPR repository here to cut down on my compilation time:
https://copr.fedorainfracloud.org/coprs/firstyear/kernel-mbp/

I'm not certain how to test out your changes, or what the consequences should
be on a stock Fedora 23/GNOME 3.18 installation. After booting (note that I
did not change any command-line options in grub), a gnome-shell/gdm X11
session comes up (I disabled Wayland, to rule out behavioural changes), I'd
log in to GNOME and gnome-shell (which starts another X11 session on
another VT).

I did not use any external screens to test this.

From a terminal there, I can see that both the integrated and discrete GPUs
are turned on, and I believe that the HDMI audio on the AMD/ATI card is
also powered on.

I've seen that the patch is now queued for 4.6, and was wondering what
changes would be necessary to make sure that only the integrated card is
used by default, and the discrete GPU only used when the VGA switcheroo is
actually enabled (or maybe through DRI_PRIME=1?)

Cheers

PS: Please CC: me as I'm not subscribed to this list.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx