dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Kleiner <mario.kleiner.de@gmail.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, dri-devel@lists.freedesktop.org
Cc: "Dave Airlie" <airlied@redhat.com>,
	"Michel Dänzer" <michel@daenzer.net>,
	"Laurent Pinchart" <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH 2/2] drm: Shortcircuit vblank queries
Date: Tue, 14 Apr 2015 20:43:12 +0200	[thread overview]
Message-ID: <552D5FC0.2060401@gmail.com> (raw)
In-Reply-To: <1428248421-29641-2-git-send-email-chris@chris-wilson.co.uk>

On 04/05/2015 05:40 PM, Chris Wilson wrote:
> 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.
>
> 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 ba80b51b4b00..be9c210bb22e 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1538,6 +1538,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.
>    *
> @@ -1587,6 +1598,21 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
>
>   	vblank = &dev->vblank[crtc];
>
> +	/* If the counter is currently enabled and accurate, short-circuit queries
> +	 * to return the cached timestamp of the last vblank.
> +	 */

Maybe somehow stress in the comment that this location in 
drm_wait_vblank is really the only place where it is ok'ish to call
drm_vblank_count_and_time() without wrapping it into a 
drm_vblank_get/put(), so nobody thinks this approach is ok anywhere else.

> +	if (dev->vblank_disable_immediate &&
> +	    drm_wait_vblank_is_query(vblwait) &&
> +	    vblank->enabled) {

You should also check for (drm_vblank_offdelay != 0) whenever checking 
for dev->vblank_disable_immediate. This is so one can override all the
vblank_disable_immediate related logic via the drm vblankoffdelay module 
parameter, both for debugging and as a safety switch for desparate users 
in case some driver+gpu combo screws up wrt. immediate disable and that 
makes it into distro kernels.

The other thing i'm not sure is if it wouldn't be a good idea to have 
some kind of write memory barrier in vblank_disable_and_save() after 
setting vblank->enabled = false; and some read memory barrier here 
before your check for vblank->enabled? I don't have a feeling for how 
much time can pass between one core executing the disable and the other 
core receiving the news that vblank->enabled is no longer true if those 
bits run on different cores?

I've run your patches through my standard tests on x86_64 and they don't 
seem to introduce errors or more skipped frames. Normally it would be so 
wrong to do this without drm_vblank_get/put(), but i think here 
potential errors introduced wouldn't be worse than what a userspace 
client would see due to preemption or other execution delays at the 
wrong moment, so it's probably ok. But i don't know if lack of memory 
barriers etc. could introduce large delays and trouble on other 
architectures?

> +		struct timeval now;
> +
> +		vblwait->reply.sequence =
> +			drm_vblank_count_and_time(dev, crtc, &now);
> +		vblwait->reply.tval_sec = now.tv_sec;
> +		vblwait->reply.tval_usec = now.tv_usec;

Have some DRM_DEBUG here, so one can follow the client doing the instant 
query through this path.

> +		return 0;
> +	}
> +
>   	ret = drm_vblank_get(dev, crtc);
>   	if (ret) {
>   		DRM_DEBUG("failed to acquire vblank counter, %d\n", ret);
>

With the above addressed i'd give you a Reviewed-and-tested-by, but it 
would be good if somebody else could look over it as well.

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

  reply	other threads:[~2015-04-14 18:43 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-17 15:44 [PATCH] drm: Return current vblank value for drmWaitVBlank queries Chris Wilson
2015-03-18  2:53 ` Michel Dänzer
2015-03-18  3:13   ` Michel Dänzer
2015-03-18  9:30   ` Chris Wilson
2015-03-18 14:52     ` Mario Kleiner
2015-03-19 14:33       ` Daniel Vetter
2015-03-19 15:04         ` Ville Syrjälä
2015-03-19 15:13           ` Chris Wilson
2015-03-19 15:36             ` [Intel-gfx] " Chris Wilson
2015-03-19 16:43           ` Mario Kleiner
2015-04-02 11:34 ` [PATCH] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
2015-04-03  2:20   ` Michel Dänzer
2015-04-03  9:06     ` Chris Wilson
2015-04-05 15:40   ` [PATCH 1/2] drm: Shortcircuit vblank queries Chris Wilson
2015-04-05 15:40     ` [PATCH 2/2] " Chris Wilson
2015-04-14 18:43       ` Mario Kleiner [this message]
2015-04-15  6:37         ` Daniel Vetter
2015-04-14  9:42     ` [PATCH 1/2] " Michel Dänzer
2015-04-14 14:21       ` Chris Wilson
2015-04-14 18:17         ` Mario Kleiner
2015-04-14 18:30           ` Chris Wilson
2015-04-15  3:50         ` Michel Dänzer
2015-04-14 18:22     ` Mario Kleiner
2015-04-14 18:36       ` Chris Wilson
2015-04-14 18:56         ` Mario Kleiner
2015-04-15  1:03   ` [PATCH] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Mario Kleiner
2015-05-04  5:25     ` Mario Kleiner
2015-05-04  9:02       ` [PATCH v2] " Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=552D5FC0.2060401@gmail.com \
    --to=mario.kleiner.de@gmail.com \
    --cc=airlied@redhat.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=michel@daenzer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox