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