On Wed, Feb 05, 2014 at 09:25:36PM +0530, Vijay Purushothaman wrote:
> On 2/5/2014 8:43 PM, Ville Syrjälä wrote:
> > On Wed, Feb 05, 2014 at 08:35:11PM +0530, Vijay Purushothaman wrote:
> >> Hello,
> >>
> >> In our current driver implementation we support flip notifications only
> >> for primary plane. So, in a full screen video playback scenario where
> >> only one sprite plane is active, the user space is forced to rely on
> >> primary plane flip notification even though there is no real need for
> >> this plane to be active. Ideally we should be able to support flip
> >> notifications for any given plane. Switching off the primary plane (when
> >> not used) will help in better memory self refresh & decent power savings..
> >>
> >> We do have a hack in android product trees which supports flip
> >> notifications for one sprite plane. unfortunately this hack in its
> >> current form cannot be considered for up streaming...
> >>
> >> My current thinking is to have an array of unpin_work items to match the
> >> number of planes. Is anyone working on this or thought about this
> >> scenario in detail? Any pointers / restrictions that needs to considered
> >> for a generic implementation of this feature?
> >
> > The plan is to implement the nuclear page flip which will take care of
> > all planes in the same way.
> >
> Thanks Ville. If the nuclear page flip is part of your bigger atomic
> mode set framework, is there a way you can split this into smaller sets
> for merge? Multiple product trees will benefit from the nuclear page flip.
I've split things up already somewhat. Some has landed some has not.
Currently I have my minimal "atomic update of sprite+primary during
setplane" series I need to get in. It shouldn't need major work anymore,
just some minor tweaks. But I realized I need to limit this to just
pch platforms for now. Making it work reliably on gmch platforms
require some extra interrupt related work. The main thing here is that
it adds the mechanism to do the update atomically for the entire pipe.
After that I need to post the last bits of my watermark update saga.
This too will initially be limited to pch platforms only. Obviously
watermarks need to updated correctly to avoid underruns when planes
get shuffled around.
> Is there anything that i can help with? Like testing your patches with
> android user space?
There's nothing to test at this point unless you want to test my old
branch from year ago or something.
What needs to be done:
- review the latest atomic framework patches from Rob Clark
- expose primary/cursor planes as drm_planes
* this could in theory be skipped, but it'll lead to cruft in the API
we need to maintain until the end of time. Also I think restructing
stuff internally to this direction will be a good idea anyway to make
the nuclear flip code neater. This more or less involves collecting
the plane state to some plane_config type of structure, and being
able to pre-compute that
- try to collect the necessary missing bits from my last
atomic branch to implement the nuclear flip
* the flip helper thing to update an arbitrary collection of planes
atomically, maybe could be simplified a bit
* mechanism to queue nuclear flips and make them wait for the
GPU to finish writing to all the relevant buffers before issuing
the actual flips/updates
- finally hook up the atomic ioctl to do the nuclear flip
* pre-pin all buffers, pre-compute plane configs, pre-compute
watermarks, check everything, wait for the GPU, and finally
do the update
For the atomic modeset side some of that's the same really. There too we
also need to pre-compute the plane configs and pre-pin buffers. Most of
the rest we already pre-compute via the pipe config. One major thing
left out of the pipe config pre-compute currently is PLLs. We compute
that stuff way too late still. We also need to massage the modeset code
some more to make it capable of modesetting multiple pipes at once.
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
