[PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915

[Chris Wilson]

On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote:
> Hi all,
> 
> On 11 June 2016 at 01:21, Alex Goins <agoins at nvidia.com> wrote:
> > Reverse PRIME seems to be designed with discrete graphics as a sink in
> > mind, designed to do an extra copy from sysmem to vidmem to prevent a
> > discrete chip from needing to scan out from sysmem.
> >
> > The criteria it used to detect this case is if we are a GPU screen and
> > Glamor accelerated. It's possible for i915 to fulfill these conditions,
> > despite the fact that the additional copy doesn't make sense for i915.
> >
> > Normally, you could just set AccelMethod = none as an option for the device
> > and call it a day. However, when running with modesetting as both the sink
> > and the source, Glamor must be enabled.
> >
> > Ideally, you would be able to set AccelMethod individually for devices
> > using the same driver, but there seems to be a bug in X option parsing that
> > makes all devices on a driver inherit the options from the first detected
> > device. Thus, glamor needs to be enabled for all or for none until that bug
> > (if it's even a bug) is fixed.
> >
> > Nonetheless, it probably doesn't make sense to do the extra copy on i915
> > even if Glamor is enabled for the device, so this is more user friendly by
> > not requiring users to disable acceleration for i915.
> >
> IMHO the proposed patch does not sound like a reasonable long-term
> solution. Ideally the driver will expose a flag, based on which Xorg
> will enable/disable reverse prime. That said, as a short-term fix this
> is fine, barring the issues mentioned below.

The decision as to whether or not the slave can use the passed pixmap as
its own scanout (or whether it requires a copy) is not part of the
master's policy.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre