[PATCH v6 10/11] modesetting: Disable Reverse PRIME for i915
Alex Goins
agoins at nvidia.com
Tue Jun 14 01:27:22 UTC 2016
Inline
> > 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.
Thanks for the explanation, and the really quick reply. It does make more sense
with that context. It's easy for me to overlook the offloading functionality
since the current implementation is incompatible with our driver.
> FYI I'm fine with the black/whitelist changes for now, we'd need kernel queries
> I suspect to do better.
Well, definitely don't merge them until I send out the revised versions fixing
the leak/lack of NULL check and blacklisting Hans' driver. The rest of the
patches are probably good to go, unless there's any more feedback. I'll send out
the revised versions of the blacklist changes in a day or two to make sure the
feedback is resolved, or ASAP if you'd prefer. None of the other patches
strictly depend on them.
Thanks again,
Alex
More information about the xorg-devel
mailing list