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

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

[Tvrtko Ursulin]

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Avoids duplicating the code.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
---
Can we do this?
---
 drivers/gpu/drm/i915/intel_display.c | 44 ++++--------------------------------
 1 file changed, 4 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 4d37f74..0ed181e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10477,47 +10477,11 @@ static bool use_mmio_flip(struct intel_engine_cs *ring,
 
 static void skl_do_mmio_flip(struct intel_crtc *intel_crtc)
 {
-	struct drm_device *dev = intel_crtc->base.dev;
-	struct drm_i915_private *dev_priv = dev->dev_private;
-	struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
-	const enum pipe pipe = intel_crtc->pipe;
-	u32 ctl, stride;
-
-	ctl = I915_READ(PLANE_CTL(pipe, 0));
-	ctl &= ~PLANE_CTL_TILED_MASK;
-	switch (fb->modifier[0]) {
-	case DRM_FORMAT_MOD_NONE:
-		break;
-	case I915_FORMAT_MOD_X_TILED:
-		ctl |= PLANE_CTL_TILED_X;
-		break;
-	case I915_FORMAT_MOD_Y_TILED:
-		ctl |= PLANE_CTL_TILED_Y;
-		break;
-	case I915_FORMAT_MOD_Yf_TILED:
-		ctl |= PLANE_CTL_TILED_YF;
-		break;
-	default:
-		MISSING_CASE(fb->modifier[0]);
-	}
-
-	/*
-	 * The stride is either expressed as a multiple of 64 bytes chunks for
-	 * linear buffers or in number of tiles for tiled buffers.
-	 */
-	stride = fb->pitches[0] /
-		 intel_fb_stride_alignment(dev, fb->modifier[0],
-					   fb->pixel_format);
-
-	/*
-	 * Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
-	 * PLANE_SURF updates, the update is then guaranteed to be atomic.
-	 */
-	I915_WRITE(PLANE_CTL(pipe, 0), ctl);
-	I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
+	struct drm_crtc *crtc = &intel_crtc->base;
+	struct drm_i915_private *dev_priv = crtc->dev->dev_private;
 
-	I915_WRITE(PLANE_SURF(pipe, 0), intel_crtc->unpin_work->gtt_offset);
-	POSTING_READ(PLANE_SURF(pipe, 0));
+	dev_priv->display.update_primary_plane(crtc, crtc->primary->fb,
+					       crtc->x, crtc->y);
 }
 
 static void ilk_do_mmio_flip(struct intel_crtc *intel_crtc)
-- 
2.3.5

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Chris Wilson]

On Tue, Apr 21, 2015 at 10:29:52AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Avoids duplicating the code.
> 
> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Sonika Jindal <sonika.jindal@intel.com>
> Cc: Damien Lespiau <damien.lespiau@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).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Tvrtko Ursulin]

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@intel.com>
>>
>> Avoids duplicating the code.
>>
>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Cc: Sonika Jindal <sonika.jindal@intel.com>
>> Cc: Damien Lespiau <damien.lespiau@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?

As a side note, watermarks seem to be not handled at all in the flip 
path as well...

Regards,

Tvrtko

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Chris Wilson]

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@intel.com>
> >>
> >>Avoids duplicating the code.
> >>
> >>Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >>Cc: Sonika Jindal <sonika.jindal@intel.com>
> >>Cc: Damien Lespiau <damien.lespiau@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
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.
 
> 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.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Tvrtko Ursulin]

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@intel.com>
>>>>
>>>> Avoids duplicating the code.
>>>>
>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> Cc: Sonika Jindal <sonika.jindal@intel.com>
>>>> Cc: Damien Lespiau <damien.lespiau@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.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Daniel Vetter]

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

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Chris Wilson]

On Thu, Apr 23, 2015 at 09:15:41PM +0200, Daniel Vetter wrote:
> On Tue, Apr 21, 2015 at 01:18:57PM +0100, Tvrtko Ursulin wrote:
> > 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.

And in a helper process/thread. Though we need to be sure that it
doesn't take more than a frame to queue a flip ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Tvrtko Ursulin]

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@intel.com>
>>>>>>
>>>>>> Avoids duplicating the code.
>>>>>>
>>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>> Cc: Sonika Jindal <sonika.jindal@intel.com>
>>>>>> Cc: Damien Lespiau <damien.lespiau@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?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [RFC] drm/i915/skl: Use plane update function from mmio flips

[Tvrtko Ursulin]

On 05/04/2015 02:20 PM, Daniel Vetter wrote:
> 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@intel.com>
>>>>>>>>
>>>>>>>> Avoids duplicating the code.
>>>>>>>>
>>>>>>>> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>>>> Cc: Sonika Jindal <sonika.jindal@intel.com>
>>>>>>>> Cc: Damien Lespiau <damien.lespiau@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?

No idea any longer, I just did not see that flips look (or get) the 
state so was uncertain whether rotation changes from one flip to another 
are possible etc.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx