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@xxxxxxxxx> > >>>>>> > >>>>>>Avoids duplicating the code. > >>>>>> > >>>>>>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > >>>>>>Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > >>>>>>Cc: Sonika Jindal <sonika.jindal@xxxxxxxxx> > >>>>>>Cc: Damien Lespiau <damien.lespiau@xxxxxxxxx> > >>>>>>--- > >>>>>>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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
