All of 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: 30+ 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-03-18 17:57 ` shuang.he
2015-04-02 11:34 ` [PATCH] drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Chris Wilson
2015-04-02 19:01   ` shuang.he
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 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.