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

[Dave Airlie]

On 14 June 2016 at 10:39, Alex Goins <agoins at nvidia.com> wrote:
>> > >> 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.
>> > Hi Chris, it's this precisely what I've said/meant :-)
>> >
>> > To put in other words:
>> > IMHO the master/slave device should expose all their capabilities.
>> > Based on these, Xorg should {en,dis}able reverse prime/etc.
>>
>> Yes. But I would prefer it if the user made the choice, it may require
>> to jump through 20 different hoops, but if it is the only way to achieve
>> the user's configuration, that is what is need to be done.
>>
>> This patch seems to be second guessing what the slave might be doing
>> instead, as you said, exposing a method by which the master/slave can
>> negotiate on what is being passed between them.
>> -Chris
>
> I'm not a huge fan of the term "reverse PRIME," since to me, reverse PRIME is
> just PRIME. PRIME can be used for display sink support with any two
> devices/drivers that expose the capabilities. I don't see why it should be
> considered "reverse PRIME" just because the sink happens to be a dGPU (and
> assumed that the source is an iGPU). What if sink and source are both dGPUs, or
> both iGPUs? Is that still "reverse PRIME?" To me, it's all just PRIME, and the
> extra copy is just an implementation detail in the slave.

Well the naming came from the fact that the way PRIME was designed
isn't the way that Windows does "Optimus".

On Windows with optimus they have dynamic compositor switching (and on OSX).

So the two use cases the Optimus model handles are:

a) compositor runs on Integrated GPU, panel is connected to Intel GPU, no other
outputs are connected. 3D apps can be offloaded to sleeping discrete GPU.

b) external output is connected. compositor runs on discrete GPU, slaves Intel
GPU to run the panel, everything is rendered on the dGPU, it doesn't sleep.

However to do that model you really need runtime smooth compositor switching.

So when I added the hack to have the Intel GPU be the master, and the discrete
GPU outputs be slaves, I called it "reverse PRIME" because it really
is a backwards
use case for how the hw was designed.

FYI I'm fine with the black/whitelist changes for now, we'd need kernel queries
I suspect to do better.

Dave.