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
next prev parent 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.