[Intel-gfx] [RFC] drm/i915/skl: Use plane update function from mmio flips

[Daniel Vetter]

On Fri, Apr 24, 2015 at 09:31:56AM +0100, Tvrtko Ursulin wrote:
> 
> On 04/23/2015 08:15 PM, Daniel Vetter wrote:
> >On Tue, Apr 21, 2015 at 01:18:57PM +0100, Tvrtko Ursulin wrote:
> >>On 04/21/2015 11:07 AM, Chris Wilson wrote:
> >>>On Tue, Apr 21, 2015 at 11:01:03AM +0100, Tvrtko Ursulin wrote:
> >>>>
> >>>>Hi,
> >>>>
> >>>>On 04/21/2015 10:51 AM, Chris Wilson wrote:
> >>>>>On Tue, Apr 21, 2015 at 10:29:52AM +0100, Tvrtko Ursulin wrote:
> >>>>>>From: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>>>>>
> >>>>>>Avoids duplicating the code.
> >>>>>>
> >>>>>>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> >>>>>>Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>>>>>Cc: Sonika Jindal <sonika.jindal at intel.com>
> >>>>>>Cc: Damien Lespiau <damien.lespiau at intel.com>
> >>>>>>---
> >>>>>>Can we do this?
> >>>>>
> >>>>>Sure, but I'd like to see update_primary_plane split into two in that
> >>>>>case. One to precalcuate the parameters, then the second to apply them
> >>>>>as we skip the first here (due to doing the setup in process context)
> >>>>>and want the second to run inside the vblank evasion logic (and the
> >>>>>unbounded nature of the current update_primary_plane logic scares me).
> >>>>
> >>>>What part is unbounded? I don't see anything blocking?
> >>>
> >>>The GTT view lookup may have to search through an arbitrary list, it's
> >>>even controllable by the user. Expect synmark nastiness. This is
> >>>"trivially" fixable, but this is only the current issue. The bigger issue
> >>
> >>That would have to be a framebuffer object operated on from multiple
> >>contexts so that there are multiple vms? And a lot of them.
> >>
> >>>is simply that we have not said that this is a timing critical function
> >>>and now we are intending to use it from such a context.
> >>
> >>It feels like this area is slowly going towards the "too many cooks" state,
> >>if not already there.
> >>
> >>>>As a side note, watermarks seem to be not handled at all in the flip
> >>>>path as well...
> >>>
> >>>The flip path should reject anything that requires a change in line size
> >>>i.e. a change in WM.
> >>
> >>Interesting, well, I had a look around and this means all sorts of "trouble"
> >>(refactoring) if proper wm param comparison is to be done.
> >>
> >>Alternatively, in (more) cheating via embedding knowledge approach, then
> >>rejecing a change in tiling is simple, but rotation is only known in plane
> >>state and page flip is not able to compare old vs. new.
> >>
> >>In fact, I don't even know if possible since plane properties and page flips
> >>look disjoint, each living in it's own timeline. If sampled when flip is
> >>queued it will be bad, if sampled with the flip then it is too late and/or
> >>properly slow.
> >
> >With atomic we can't do such tricks anymore anyway, we always have to
> >recompute the full state. We'll we could set dirty bits and similar tricks
> >to avoid recomputing some state and the corresponding setup, but imo that
> >needs to come with performance data attached. And atm pageflips are
> >limited to refresh rate.
> 
> The thing I was raising, and which isn't clear to me, is what ties plane
> properties with the page flips?
> 
> Not only what ties them, but what ensures plane properties remain stable
> between queuing a flip and flipping?

We only allow one in-flight flip atm, and stall before doing any
synchronous updates. That won't be the case any more once we have a queue,
but then we should also be converted fully to atomic state objects. And
with those we can build up a queue of updates. so the flip always knows
which set of states to pick for a given flip.

Or do I still misunderstand your question?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch