public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Ben Widawsky <ben@bwidawsk.net>Ben Widawsky <ben@bwidawsk.net>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/4 v7] drm/i915: wait render timeout ioctl
Date: Tue, 05 Jun 2012 22:09:48 +0100	[thread overview]
Message-ID: <1338930638_513573@CP5-2952> (raw)
In-Reply-To: <20120524201804.09bba7b8@bwidawsk.net>

On Thu, 24 May 2012 20:18:04 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> On Thu, 24 May 2012 15:03:10 -0700
> Ben Widawsky <ben@bwidawsk.net> wrote:
> 
> > This helps implement GL_ARB_sync but stops short of allowing full blown
> > sync objects. Finally we can use the new timed seqno waiting function
> > to allow userspace to wait on a buffer object with a timeout. This
> > implements that interface.
> > 
> > The IOCTL will take as input a buffer object handle, and a timeout in
> > nanoseconds (flags is currently optional but will likely be used for
> > permutations of flush operations). Users may specify 0 nanoseconds to
> > instantly check.
> > 
> > The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
> > non-zero timeout parameter the wait ioctl will wait for the given number
> > of nanoseconds on an object becoming unbusy. Since the wait itself does
> > so holding struct_mutex the object may become re-busied before this
> > completes. A similar but shorter race condition exists in the busy
> > ioctl.
> > 
> > v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
> > Flush the object from the gpu write domain (Chris + Daniel)
> > Fix leaked refcount in good case (Chris)
> > Naturally align ioctl struct (Chris)
> > 
> > v3: Drop lock after getting seqno to avoid ugly dance (Chris)
> > 
> > v4: check for 0 timeout after olr check to allow polling (Chris)
> > 
> > v5: Updated the comment. (Chris)
> > 
> > v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
> > Fix the commit message comment to be less ugly (Ben)
> > Add a warning to check the return timespec (Ben)
> > 
> > v7: Use DRM_AUTH for the ioctl. (Eugeni)

So what Ben just reminded me was that we hadn't considered enabling an
infinite non-blocking wait through this ioctl. That seems like a
gross oversight to me...
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2012-06-05 21:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-24 22:03 [PATCH 1/4 v5] drm/i915: timeout parameter for seqno wait Ben Widawsky
2012-05-24 22:03 ` [PATCH 2/4 v3] [RESEND] drm/i915: improve i915_wait_request_begin trace Ben Widawsky
2012-05-24 22:03 ` [PATCH 3/4 v7] drm/i915: wait render timeout ioctl Ben Widawsky
2012-05-25  3:18   ` Ben Widawsky
2012-06-05 21:09     ` Chris Wilson [this message]
2012-05-24 22:03 ` [PATCH 4/4] [RESEND] drm/i915: s/i915_wait_request/i915_wait_seqno/g Ben Widawsky
2012-05-25 12:20   ` Daniel Vetter

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=1338930638_513573@CP5-2952 \
    --to=chris@chris-wilson.co.uk \
    --cc=ben@bwidawsk.net \
    --cc=intel-gfx@lists.freedesktop.org \
    /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