All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
@ 2016-01-06 11:09 Chris Wilson
  2016-01-06 11:09 ` [PATCH 2/3] drm: Skip the waitqueue setup for vblank queries Chris Wilson
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Chris Wilson @ 2016-01-06 11:09 UTC (permalink / raw)
  To: dri-devel; +Cc: Michel Dänzer, Laurent Pinchart, Dave Airlie, intel-gfx

On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper hardware sleep state,
touching registers becomes ever more expensive.  However, we know that if
the user wants the current vblank counter, they are also very likely to
immediately queue a vblank wait and so we can keep the interrupt around
and only turn it off if we have no further vblank requests queued within
the interrupt interval.

After vblank event delivery, this patch adds a shadow of one vblank where
the interrupt is kept alive for the user to query and queue another vblank
event. Similarly, if the user is using blocking drmWaitVblanks, the
interrupt will be disabled on the IRQ following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.

v2: Mario Kleiner -
After testing this, one more thing that would make sense is to move
the disable block at the end of drm_handle_vblank() instead of at the
top.

Turns out that if high precision timestaming is disabled or doesn't
work for some reason (as can be simulated by echo 0 >
/sys/module/drm/parameters/timestamp_precision_usec), then with your
delayed disable code at its current place, the vblank counter won't
increment anymore at all for instant queries, ie. with your other
"instant query" patches. Clients which repeatedly query the counter
and wait for it to progress will simply hang, spinning in an endless
query loop. There's that comment in vblank_disable_and_save:

"* Skip this step if there isn't any high precision timestamp
 * available. In that case we can't account for this and just
 * hope for the best.
 */

With the disable happening after leading edge of vblank (== hw counter
increment already happened) but before the vblank counter/timestamp
handling in drm_handle_vblank, that step is needed to keep the counter
progressing, so skipping it is bad.

Now without high precision timestamping support, a kms driver must not
set dev->vblank_disable_immediate = true, as this would cause problems
for clients, so this shouldn't matter, but it would be good to still
make this robust against a future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.

v3: Patch before coffee needs extra coffee.

Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
---
 drivers/gpu/drm/drm_irq.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 607f493ae801..ca5ef87c57c1 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1213,9 +1213,9 @@ void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
 	if (atomic_dec_and_test(&vblank->refcount)) {
 		if (drm_vblank_offdelay == 0)
 			return;
-		else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0)
+		else if (drm_vblank_offdelay < 0)
 			vblank_disable_fn((unsigned long)vblank);
-		else
+		else if (!dev->vblank_disable_immediate)
 			mod_timer(&vblank->disable_timer,
 				  jiffies + ((drm_vblank_offdelay * HZ)/1000));
 	}
@@ -1835,6 +1835,16 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
 	wake_up(&vblank->queue);
 	drm_handle_vblank_events(dev, pipe);
 
+	/* With instant-off, we defer disabling the interrupt until after
+	 * we finish processing the following vblank. The disable has to
+	 * be last (after drm_handle_vblank_events) so that the timestamp
+	 * is always accurate.
+	 */
+	if (dev->vblank_disable_immediate &&
+	    drm_vblank_offdelay > 0 &&
+	    !atomic_read(&vblank->refcount))
+		vblank_disable_fn((unsigned long)vblank);
+
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 
 	return true;
-- 
2.7.0.rc3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 2/3] drm: Skip the waitqueue setup for vblank queries
  2016-01-06 11:09 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
@ 2016-01-06 11:09 ` Chris Wilson
  2016-01-06 11:09 ` [PATCH 3/3] drm: Peek at the current counter/timestamp " Chris Wilson
  2016-01-06 13:20 ` ✗ failure: Fi.CI.BAT Patchwork
  2 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2016-01-06 11:09 UTC (permalink / raw)
  To: dri-devel; +Cc: Michel Dänzer, Laurent Pinchart, Dave Airlie, intel-gfx

Avoid adding to the waitqueue and reprobing the current vblank if the
caller is only querying the current vblank sequence and timestamp, where
we know that the wait would return immediately.

v2: Add CRTC identifier to debug messages

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
---
 drivers/gpu/drm/drm_irq.c | 26 ++++++++++++++------------
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index ca5ef87c57c1..866cf58a36c5 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1710,7 +1710,7 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
 
 	ret = drm_vblank_get(dev, pipe);
 	if (ret) {
-		DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
+		DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n", pipe, ret);
 		return ret;
 	}
 	seq = drm_vblank_count(dev, pipe);
@@ -1738,14 +1738,16 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
 		vblwait->request.sequence = seq + 1;
 	}
 
-	DRM_DEBUG("waiting on vblank count %d, crtc %u\n",
-		  vblwait->request.sequence, pipe);
-	vblank->last_wait = vblwait->request.sequence;
-	DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
-		    (((drm_vblank_count(dev, pipe) -
-		       vblwait->request.sequence) <= (1 << 23)) ||
-		     !vblank->enabled ||
-		     !dev->irq_enabled));
+	if (vblwait->request.sequence != seq) {
+		DRM_DEBUG("waiting on vblank count %d, crtc %u\n",
+			  vblwait->request.sequence, pipe);
+		vblank->last_wait = vblwait->request.sequence;
+		DRM_WAIT_ON(ret, vblank->queue, 3 * HZ,
+			    (((drm_vblank_count(dev, pipe) -
+			       vblwait->request.sequence) <= (1 << 23)) ||
+			     !vblank->enabled ||
+			     !dev->irq_enabled));
+	}
 
 	if (ret != -EINTR) {
 		struct timeval now;
@@ -1754,10 +1756,10 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
 		vblwait->reply.tval_sec = now.tv_sec;
 		vblwait->reply.tval_usec = now.tv_usec;
 
-		DRM_DEBUG("returning %d to client\n",
-			  vblwait->reply.sequence);
+		DRM_DEBUG("crtc %d returning %d to client\n",
+			  pipe, vblwait->reply.sequence);
 	} else {
-		DRM_DEBUG("vblank wait interrupted by signal\n");
+		DRM_DEBUG("crtc %d vblank wait interrupted by signal\n", pipe);
 	}
 
 done:
-- 
2.7.0.rc3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH 3/3] drm: Peek at the current counter/timestamp for vblank queries
  2016-01-06 11:09 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
  2016-01-06 11:09 ` [PATCH 2/3] drm: Skip the waitqueue setup for vblank queries Chris Wilson
@ 2016-01-06 11:09 ` Chris Wilson
  2016-01-06 13:20 ` ✗ failure: Fi.CI.BAT Patchwork
  2 siblings, 0 replies; 8+ messages in thread
From: Chris Wilson @ 2016-01-06 11:09 UTC (permalink / raw)
  To: dri-devel; +Cc: Michel Dänzer, Laurent Pinchart, Dave Airlie, intel-gfx

Bypass all the spinlocks and return the last timestamp and counter from
the last vblank if the driver delcares that it is accurate (and stable
across on/off), and the vblank is currently enabled.

This is dependent upon the both the hardware and driver to provide the
proper barriers to facilitate reading our bookkeeping outside of the
vblank interrupt and outside of the explicit vblank locks.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
---
 drivers/gpu/drm/drm_irq.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 866cf58a36c5..00298b39e7fc 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1659,6 +1659,17 @@ err_put:
 	return ret;
 }
 
+static bool drm_wait_vblank_is_query(union drm_wait_vblank *vblwait)
+{
+	if (vblwait->request.sequence)
+		return false;
+
+	return _DRM_VBLANK_RELATIVE ==
+		(vblwait->request.type & (_DRM_VBLANK_TYPES_MASK |
+					  _DRM_VBLANK_EVENT |
+					  _DRM_VBLANK_NEXTONMISS));
+}
+
 /*
  * Wait for VBLANK.
  *
@@ -1708,6 +1719,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
 
 	vblank = &dev->vblank[pipe];
 
+	/* If the counter is currently enabled and accurate, short-circuit queries
+	 * to return the cached timestamp of the last vblank.
+	 */
+	if (dev->vblank_disable_immediate &&
+	    drm_wait_vblank_is_query(vblwait) &&
+	    vblank->enabled) {
+		struct timeval now;
+
+		vblwait->reply.sequence =
+			drm_vblank_count_and_time(dev, pipe, &now);
+		vblwait->reply.tval_sec = now.tv_sec;
+		vblwait->reply.tval_usec = now.tv_usec;
+		return 0;
+	}
+
 	ret = drm_vblank_get(dev, pipe);
 	if (ret) {
 		DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n", pipe, ret);
-- 
2.7.0.rc3

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* ✗ failure: Fi.CI.BAT
  2016-01-06 11:09 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
  2016-01-06 11:09 ` [PATCH 2/3] drm: Skip the waitqueue setup for vblank queries Chris Wilson
  2016-01-06 11:09 ` [PATCH 3/3] drm: Peek at the current counter/timestamp " Chris Wilson
@ 2016-01-06 13:20 ` Patchwork
  2 siblings, 0 replies; 8+ messages in thread
From: Patchwork @ 2016-01-06 13:20 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Summary ==

Built on 89d0d1b6f0e9c3a6b90476bd115cfe1881646fd6 drm-intel-nightly: 2016y-01m-06d-10h-37m-17s UTC integration manifest

Test gem_basic:
        Subgroup create-close:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
        Subgroup basic:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test gem_ctx_param_basic:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup invalid-param-set:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup non-root-set-no-zeromap:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup root-set-no-zeromap-disabled:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap:
        Subgroup basic:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_mmap_gtt:
        Subgroup basic-read:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup basic-write:
                pass       -> DMESG-WARN (skl-i7k-2)
Test gem_storedw_loop:
        Subgroup basic-render:
                dmesg-warn -> PASS       (skl-i5k-2) UNSTABLE
Test kms_addfb_basic:
        Subgroup addfb25-modifier-no-flag:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup addfb25-x-tiled-mismatch:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-1024:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-63:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup bad-pitch-999:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup clobberred-modifier:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-high:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup too-wide:
                pass       -> DMESG-WARN (skl-i7k-2)
        Subgroup unused-offsets:
                pass       -> DMESG-WARN (skl-i7k-2)
Test kms_flip:
        Subgroup basic-plain-flip:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-b-frame-sequence:
                pass       -> DMESG-FAIL (skl-i7k-2)
Test pm_rpm:
        Subgroup basic-rte:
                pass       -> DMESG-WARN (byt-nuc) UNSTABLE
Test prime_self_import:
        Subgroup basic-with_two_bos:
                pass       -> DMESG-WARN (skl-i7k-2)

bdw-nuci7        total:132  pass:1    dwarn:0   dfail:0   fail:0   skip:131
bsw-nuc-2        total:135  pass:115  dwarn:0   dfail:0   fail:0   skip:20 
byt-nuc          total:135  pass:121  dwarn:1   dfail:0   fail:0   skip:13 
skl-i5k-2        total:135  pass:126  dwarn:1   dfail:0   fail:0   skip:8  
skl-i7k-2        total:135  pass:103  dwarn:20  dfail:3   fail:0   skip:8  
snb-dellxps      total:135  pass:123  dwarn:0   dfail:0   fail:0   skip:12 

Results at /archive/results/CI_IGT_test/Patchwork_1098/

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
  2017-03-22 15:06   ` Mario Kleiner
@ 2017-03-22 20:02     ` Ville Syrjälä
  0 siblings, 0 replies; 8+ messages in thread
From: Ville Syrjälä @ 2017-03-22 20:02 UTC (permalink / raw)
  To: Mario Kleiner
  Cc: Michel Dänzer, dri-devel, Laurent Pinchart, Dave Airlie, intel-gfx

On Wed, Mar 22, 2017 at 04:06:32PM +0100, Mario Kleiner wrote:
> On 03/15/2017 10:00 PM, Ville Syrjälä wrote:
> > On Wed, Mar 15, 2017 at 08:40:25PM +0000, Chris Wilson wrote:
> >> On vblank instant-off systems, we can get into a situation where the cost
> >> of enabling and disabling the vblank IRQ around a drmWaitVblank query
> >> dominates. And with the advent of even deeper hardware sleep state,
> >> touching registers becomes ever more expensive.  However, we know that if
> >> the user wants the current vblank counter, they are also very likely to
> >> immediately queue a vblank wait and so we can keep the interrupt around
> >> and only turn it off if we have no further vblank requests queued within
> >> the interrupt interval.
> >>
> >> After vblank event delivery, this patch adds a shadow of one vblank where
> >> the interrupt is kept alive for the user to query and queue another vblank
> >> event. Similarly, if the user is using blocking drmWaitVblanks, the
> >> interrupt will be disabled on the IRQ following the wait completion.
> >> However, if the user is simply querying the current vblank counter and
> >> timestamp, the interrupt will be disabled after every IRQ and the user
> >> will enabled it again on the first query following the IRQ.
> >>
> >> v2: Mario Kleiner -
> >> After testing this, one more thing that would make sense is to move
> >> the disable block at the end of drm_handle_vblank() instead of at the
> >> top.
> >>
> >> Turns out that if high precision timestaming is disabled or doesn't
> >> work for some reason (as can be simulated by echo 0 >
> >> /sys/module/drm/parameters/timestamp_precision_usec), then with your
> >> delayed disable code at its current place, the vblank counter won't
> >> increment anymore at all for instant queries, ie. with your other
> >> "instant query" patches. Clients which repeatedly query the counter
> >> and wait for it to progress will simply hang, spinning in an endless
> >> query loop. There's that comment in vblank_disable_and_save:
> >>
> >> "* Skip this step if there isn't any high precision timestamp
> >>  * available. In that case we can't account for this and just
> >>  * hope for the best.
> >>  */
> >>
> >> With the disable happening after leading edge of vblank (== hw counter
> >> increment already happened) but before the vblank counter/timestamp
> >> handling in drm_handle_vblank, that step is needed to keep the counter
> >> progressing, so skipping it is bad.
> >>
> >> Now without high precision timestamping support, a kms driver must not
> >> set dev->vblank_disable_immediate = true, as this would cause problems
> >> for clients, so this shouldn't matter, but it would be good to still
> >> make this robust against a future kms driver which might have
> >> unreliable high precision timestamping, e.g., high precision
> >> timestamping that intermittently doesn't work.
> >>
> >> v3: Patch before coffee needs extra coffee.
> >>
> >> Testcase: igt/kms_vblank
> >> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >> Cc: Daniel Vetter <daniel@ffwll.ch>
> >> Cc: Michel Dänzer <michel@daenzer.net>
> >> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >> Cc: Dave Airlie <airlied@redhat.com>,
> >> Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
> >
> > Yep. This seems like a good idea to me. I just neglected to review it
> > last time around (and maybe even before that?) for some reason. Locks
> > seem to be taken in the right order, so it at least looks safe to me.
> >
> > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> 
> Hi,
> 
> as a followup to this one, maybe we should move the 
> drm_handle_vblank_events(dev, pipe); down, immediately after Chris new 
> delayed disable code?
> 
> The idea was to avoid lots of redundant enable->disable->enable... calls 
> by having some 1 frame delay before disable. This works for pure vblank 
> count/ts queries.
> 
> But both DRI2 and DRI3/Present use vblank events to trigger a 
> pageflip-ioctl at the right target vblank. With the current ordering we 
> may dispatch the vblank swap trigger event to the X-Server and drop the 
> vblank refcount to zero due to the vblank_put inside 
> drm_handle_vblank_events for the dispatched event, then detect in this 
> patch that refcount == 0 and disable vblanks, but a few microseconds 
> later the server will queue a pageflip ioctl which bumps the refcount 
> and reenables vblank irqs, so we have a redundant disable->enable.
> 
> Also many kms drivers now use drm_crtc_arm_vblank_event() for pageflip 
> completion handling at vblank, the pageflip completion events are also 
> dispatched via drm_handle_vblank_events(). After a pageflip completes, 
> it makes sense to have this "swap shadow" of 1 full frame, as animations 
> would likely queue a new vblank query/event immediately for the next 
> animation frame.

That does seem like a decent idea. It won't actually change anything for
i915 page flips since we still hang on to our vblank reference after
drm_handle_vblank() returns. But if you, for example, just call
glXWaitVideoSyncSGI(1,0,...) in a loop the current code will still
result on enable<->disable ping-pong, whereas with your proposed
reordering we'd keep the vblank interrupt enabled all the time.

Chris, any thoughts?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
  2017-03-15 21:00 ` Ville Syrjälä
@ 2017-03-22 15:06   ` Mario Kleiner
  2017-03-22 20:02     ` Ville Syrjälä
  0 siblings, 1 reply; 8+ messages in thread
From: Mario Kleiner @ 2017-03-22 15:06 UTC (permalink / raw)
  To: Ville Syrjälä, Chris Wilson
  Cc: Michel Dänzer, dri-devel, Laurent Pinchart, Dave Airlie, intel-gfx

On 03/15/2017 10:00 PM, Ville Syrjälä wrote:
> On Wed, Mar 15, 2017 at 08:40:25PM +0000, Chris Wilson wrote:
>> On vblank instant-off systems, we can get into a situation where the cost
>> of enabling and disabling the vblank IRQ around a drmWaitVblank query
>> dominates. And with the advent of even deeper hardware sleep state,
>> touching registers becomes ever more expensive.  However, we know that if
>> the user wants the current vblank counter, they are also very likely to
>> immediately queue a vblank wait and so we can keep the interrupt around
>> and only turn it off if we have no further vblank requests queued within
>> the interrupt interval.
>>
>> After vblank event delivery, this patch adds a shadow of one vblank where
>> the interrupt is kept alive for the user to query and queue another vblank
>> event. Similarly, if the user is using blocking drmWaitVblanks, the
>> interrupt will be disabled on the IRQ following the wait completion.
>> However, if the user is simply querying the current vblank counter and
>> timestamp, the interrupt will be disabled after every IRQ and the user
>> will enabled it again on the first query following the IRQ.
>>
>> v2: Mario Kleiner -
>> After testing this, one more thing that would make sense is to move
>> the disable block at the end of drm_handle_vblank() instead of at the
>> top.
>>
>> Turns out that if high precision timestaming is disabled or doesn't
>> work for some reason (as can be simulated by echo 0 >
>> /sys/module/drm/parameters/timestamp_precision_usec), then with your
>> delayed disable code at its current place, the vblank counter won't
>> increment anymore at all for instant queries, ie. with your other
>> "instant query" patches. Clients which repeatedly query the counter
>> and wait for it to progress will simply hang, spinning in an endless
>> query loop. There's that comment in vblank_disable_and_save:
>>
>> "* Skip this step if there isn't any high precision timestamp
>>  * available. In that case we can't account for this and just
>>  * hope for the best.
>>  */
>>
>> With the disable happening after leading edge of vblank (== hw counter
>> increment already happened) but before the vblank counter/timestamp
>> handling in drm_handle_vblank, that step is needed to keep the counter
>> progressing, so skipping it is bad.
>>
>> Now without high precision timestamping support, a kms driver must not
>> set dev->vblank_disable_immediate = true, as this would cause problems
>> for clients, so this shouldn't matter, but it would be good to still
>> make this robust against a future kms driver which might have
>> unreliable high precision timestamping, e.g., high precision
>> timestamping that intermittently doesn't work.
>>
>> v3: Patch before coffee needs extra coffee.
>>
>> Testcase: igt/kms_vblank
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Daniel Vetter <daniel@ffwll.ch>
>> Cc: Michel Dänzer <michel@daenzer.net>
>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> Cc: Dave Airlie <airlied@redhat.com>,
>> Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
>
> Yep. This seems like a good idea to me. I just neglected to review it
> last time around (and maybe even before that?) for some reason. Locks
> seem to be taken in the right order, so it at least looks safe to me.
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>

Hi,

as a followup to this one, maybe we should move the 
drm_handle_vblank_events(dev, pipe); down, immediately after Chris new 
delayed disable code?

The idea was to avoid lots of redundant enable->disable->enable... calls 
by having some 1 frame delay before disable. This works for pure vblank 
count/ts queries.

But both DRI2 and DRI3/Present use vblank events to trigger a 
pageflip-ioctl at the right target vblank. With the current ordering we 
may dispatch the vblank swap trigger event to the X-Server and drop the 
vblank refcount to zero due to the vblank_put inside 
drm_handle_vblank_events for the dispatched event, then detect in this 
patch that refcount == 0 and disable vblanks, but a few microseconds 
later the server will queue a pageflip ioctl which bumps the refcount 
and reenables vblank irqs, so we have a redundant disable->enable.

Also many kms drivers now use drm_crtc_arm_vblank_event() for pageflip 
completion handling at vblank, the pageflip completion events are also 
dispatched via drm_handle_vblank_events(). After a pageflip completes, 
it makes sense to have this "swap shadow" of 1 full frame, as animations 
would likely queue a new vblank query/event immediately for the next 
animation frame.

-mario

>> ---
>>  drivers/gpu/drm/drm_irq.c | 14 ++++++++++++--
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index 9bdca69f754c..e64b05ea95ea 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -1198,9 +1198,9 @@ static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
>>  	if (atomic_dec_and_test(&vblank->refcount)) {
>>  		if (drm_vblank_offdelay == 0)
>>  			return;
>> -		else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0)
>> +		else if (drm_vblank_offdelay < 0)
>>  			vblank_disable_fn((unsigned long)vblank);
>> -		else
>> +		else if (!dev->vblank_disable_immediate)
>>  			mod_timer(&vblank->disable_timer,
>>  				  jiffies + ((drm_vblank_offdelay * HZ)/1000));
>>  	}
>> @@ -1734,6 +1734,16 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
>>  	wake_up(&vblank->queue);
>>  	drm_handle_vblank_events(dev, pipe);
>>
>> +	/* With instant-off, we defer disabling the interrupt until after
>> +	 * we finish processing the following vblank. The disable has to
>> +	 * be last (after drm_handle_vblank_events) so that the timestamp
>> +	 * is always accurate.
>> +	 */
>> +	if (dev->vblank_disable_immediate &&
>> +	    drm_vblank_offdelay > 0 &&
>> +	    !atomic_read(&vblank->refcount))
>> +		vblank_disable_fn((unsigned long)vblank);
>> +
>>  	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>>
>>  	return true;
>> --
>> 2.11.0
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
  2017-03-15 20:40 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
@ 2017-03-15 21:00 ` Ville Syrjälä
  2017-03-22 15:06   ` Mario Kleiner
  0 siblings, 1 reply; 8+ messages in thread
From: Ville Syrjälä @ 2017-03-15 21:00 UTC (permalink / raw)
  To: Chris Wilson
  Cc: Michel Dänzer, dri-devel, Laurent Pinchart, Dave Airlie, intel-gfx

On Wed, Mar 15, 2017 at 08:40:25PM +0000, Chris Wilson wrote:
> On vblank instant-off systems, we can get into a situation where the cost
> of enabling and disabling the vblank IRQ around a drmWaitVblank query
> dominates. And with the advent of even deeper hardware sleep state,
> touching registers becomes ever more expensive.  However, we know that if
> the user wants the current vblank counter, they are also very likely to
> immediately queue a vblank wait and so we can keep the interrupt around
> and only turn it off if we have no further vblank requests queued within
> the interrupt interval.
> 
> After vblank event delivery, this patch adds a shadow of one vblank where
> the interrupt is kept alive for the user to query and queue another vblank
> event. Similarly, if the user is using blocking drmWaitVblanks, the
> interrupt will be disabled on the IRQ following the wait completion.
> However, if the user is simply querying the current vblank counter and
> timestamp, the interrupt will be disabled after every IRQ and the user
> will enabled it again on the first query following the IRQ.
> 
> v2: Mario Kleiner -
> After testing this, one more thing that would make sense is to move
> the disable block at the end of drm_handle_vblank() instead of at the
> top.
> 
> Turns out that if high precision timestaming is disabled or doesn't
> work for some reason (as can be simulated by echo 0 >
> /sys/module/drm/parameters/timestamp_precision_usec), then with your
> delayed disable code at its current place, the vblank counter won't
> increment anymore at all for instant queries, ie. with your other
> "instant query" patches. Clients which repeatedly query the counter
> and wait for it to progress will simply hang, spinning in an endless
> query loop. There's that comment in vblank_disable_and_save:
> 
> "* Skip this step if there isn't any high precision timestamp
>  * available. In that case we can't account for this and just
>  * hope for the best.
>  */
> 
> With the disable happening after leading edge of vblank (== hw counter
> increment already happened) but before the vblank counter/timestamp
> handling in drm_handle_vblank, that step is needed to keep the counter
> progressing, so skipping it is bad.
> 
> Now without high precision timestamping support, a kms driver must not
> set dev->vblank_disable_immediate = true, as this would cause problems
> for clients, so this shouldn't matter, but it would be good to still
> make this robust against a future kms driver which might have
> unreliable high precision timestamping, e.g., high precision
> timestamping that intermittently doesn't work.
> 
> v3: Patch before coffee needs extra coffee.
> 
> Testcase: igt/kms_vblank
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Michel Dänzer <michel@daenzer.net>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Dave Airlie <airlied@redhat.com>,
> Cc: Mario Kleiner <mario.kleiner.de@gmail.com>

Yep. This seems like a good idea to me. I just neglected to review it
last time around (and maybe even before that?) for some reason. Locks
seem to be taken in the right order, so it at least looks safe to me.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> ---
>  drivers/gpu/drm/drm_irq.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 9bdca69f754c..e64b05ea95ea 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1198,9 +1198,9 @@ static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
>  	if (atomic_dec_and_test(&vblank->refcount)) {
>  		if (drm_vblank_offdelay == 0)
>  			return;
> -		else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0)
> +		else if (drm_vblank_offdelay < 0)
>  			vblank_disable_fn((unsigned long)vblank);
> -		else
> +		else if (!dev->vblank_disable_immediate)
>  			mod_timer(&vblank->disable_timer,
>  				  jiffies + ((drm_vblank_offdelay * HZ)/1000));
>  	}
> @@ -1734,6 +1734,16 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
>  	wake_up(&vblank->queue);
>  	drm_handle_vblank_events(dev, pipe);
>  
> +	/* With instant-off, we defer disabling the interrupt until after
> +	 * we finish processing the following vblank. The disable has to
> +	 * be last (after drm_handle_vblank_events) so that the timestamp
> +	 * is always accurate.
> +	 */
> +	if (dev->vblank_disable_immediate &&
> +	    drm_vblank_offdelay > 0 &&
> +	    !atomic_read(&vblank->refcount))
> +		vblank_disable_fn((unsigned long)vblank);
> +
>  	spin_unlock_irqrestore(&dev->event_lock, irqflags);
>  
>  	return true;
> -- 
> 2.11.0

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off)
@ 2017-03-15 20:40 Chris Wilson
  2017-03-15 21:00 ` Ville Syrjälä
  0 siblings, 1 reply; 8+ messages in thread
From: Chris Wilson @ 2017-03-15 20:40 UTC (permalink / raw)
  To: dri-devel; +Cc: Michel Dänzer, Laurent Pinchart, Dave Airlie, intel-gfx

On vblank instant-off systems, we can get into a situation where the cost
of enabling and disabling the vblank IRQ around a drmWaitVblank query
dominates. And with the advent of even deeper hardware sleep state,
touching registers becomes ever more expensive.  However, we know that if
the user wants the current vblank counter, they are also very likely to
immediately queue a vblank wait and so we can keep the interrupt around
and only turn it off if we have no further vblank requests queued within
the interrupt interval.

After vblank event delivery, this patch adds a shadow of one vblank where
the interrupt is kept alive for the user to query and queue another vblank
event. Similarly, if the user is using blocking drmWaitVblanks, the
interrupt will be disabled on the IRQ following the wait completion.
However, if the user is simply querying the current vblank counter and
timestamp, the interrupt will be disabled after every IRQ and the user
will enabled it again on the first query following the IRQ.

v2: Mario Kleiner -
After testing this, one more thing that would make sense is to move
the disable block at the end of drm_handle_vblank() instead of at the
top.

Turns out that if high precision timestaming is disabled or doesn't
work for some reason (as can be simulated by echo 0 >
/sys/module/drm/parameters/timestamp_precision_usec), then with your
delayed disable code at its current place, the vblank counter won't
increment anymore at all for instant queries, ie. with your other
"instant query" patches. Clients which repeatedly query the counter
and wait for it to progress will simply hang, spinning in an endless
query loop. There's that comment in vblank_disable_and_save:

"* Skip this step if there isn't any high precision timestamp
 * available. In that case we can't account for this and just
 * hope for the best.
 */

With the disable happening after leading edge of vblank (== hw counter
increment already happened) but before the vblank counter/timestamp
handling in drm_handle_vblank, that step is needed to keep the counter
progressing, so skipping it is bad.

Now without high precision timestamping support, a kms driver must not
set dev->vblank_disable_immediate = true, as this would cause problems
for clients, so this shouldn't matter, but it would be good to still
make this robust against a future kms driver which might have
unreliable high precision timestamping, e.g., high precision
timestamping that intermittently doesn't work.

v3: Patch before coffee needs extra coffee.

Testcase: igt/kms_vblank
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Dave Airlie <airlied@redhat.com>,
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
---
 drivers/gpu/drm/drm_irq.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 9bdca69f754c..e64b05ea95ea 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1198,9 +1198,9 @@ static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
 	if (atomic_dec_and_test(&vblank->refcount)) {
 		if (drm_vblank_offdelay == 0)
 			return;
-		else if (dev->vblank_disable_immediate || drm_vblank_offdelay < 0)
+		else if (drm_vblank_offdelay < 0)
 			vblank_disable_fn((unsigned long)vblank);
-		else
+		else if (!dev->vblank_disable_immediate)
 			mod_timer(&vblank->disable_timer,
 				  jiffies + ((drm_vblank_offdelay * HZ)/1000));
 	}
@@ -1734,6 +1734,16 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe)
 	wake_up(&vblank->queue);
 	drm_handle_vblank_events(dev, pipe);
 
+	/* With instant-off, we defer disabling the interrupt until after
+	 * we finish processing the following vblank. The disable has to
+	 * be last (after drm_handle_vblank_events) so that the timestamp
+	 * is always accurate.
+	 */
+	if (dev->vblank_disable_immediate &&
+	    drm_vblank_offdelay > 0 &&
+	    !atomic_read(&vblank->refcount))
+		vblank_disable_fn((unsigned long)vblank);
+
 	spin_unlock_irqrestore(&dev->event_lock, irqflags);
 
 	return true;
-- 
2.11.0

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

^ permalink raw reply related	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-03-22 20:02 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-06 11:09 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
2016-01-06 11:09 ` [PATCH 2/3] drm: Skip the waitqueue setup for vblank queries Chris Wilson
2016-01-06 11:09 ` [PATCH 3/3] drm: Peek at the current counter/timestamp " Chris Wilson
2016-01-06 13:20 ` ✗ failure: Fi.CI.BAT Patchwork
2017-03-15 20:40 [PATCH 1/3] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
2017-03-15 21:00 ` Ville Syrjälä
2017-03-22 15:06   ` Mario Kleiner
2017-03-22 20:02     ` Ville Syrjälä

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.