On Sun, Jun 12, 2016 at 02:35:43PM +0100, Emil Velikov wrote: > Hi all, > > On 11 June 2016 at 01:21, Alex Goins <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
