All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Widawsky <ben@bwidawsk.net>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
	Ben Widawsky <benjamin.widawsky@intel.com>
Subject: Re: [PATCH 1/8] drm/i915: Synchronize pread/pwrite with wait_rendering
Date: Tue, 3 Sep 2013 16:53:06 -0700	[thread overview]
Message-ID: <20130903235306.GA2860@bwidawsk.net> (raw)
In-Reply-To: <20130903160819.GK5767@phenom.ffwll.local>

On Tue, Sep 03, 2013 at 06:08:19PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 04:12:36PM +0200, Daniel Vetter wrote:
> > On Mon, Sep 02, 2013 at 02:14:12PM +0100, Chris Wilson wrote:
> > > On Mon, Sep 02, 2013 at 08:32:24AM +0200, Daniel Vetter wrote:
> > > > On Fri, Aug 30, 2013 at 08:39:46PM -0700, Ben Widawsky wrote:
> > > > > On Sat, Aug 31, 2013 at 12:50:30AM +0100, Chris Wilson wrote:
> > > > > > On Fri, Aug 30, 2013 at 04:43:54PM -0700, Ben Widawsky wrote:
> > > > > > > lifted from Daniel:
> > > > > > > pread/pwrite isn't about the object's domain at all, but purely about
> > > > > > > synchronizing for outstanding rendering. Replacing the call to
> > > > > > > set_to_gtt_domain with a wait_rendering would imo improve code
> > > > > > > readability. Furthermore we could pimp pread to only block for
> > > > > > > outstanding writes and not for reads.
> > > > > > > 
> > > > > > > Since you're not the first one to trip over this: Can I volunteer you
> > > > > > > for a follow-up patch to fix this?
> > > > > > > 
> > > > > > > Recommended-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > > > > Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> > > > > > 
> > > > > > This should fail i-g-t...
> > > > > > -Chris
> > > > > > 
> > > > > 
> > > > > Daniel, how have I failed your plan?
> > > > 
> > > > It should work ... Since the enclosing if-block checks for !cpu domain
> > > > (for either reads or writes) that implies that going into the gtt domain
> > > > is a noop (or better should be) wrt clflushing and we only wait for
> > > > outstanding gpu rendering. wait_rendering is an interface that's been
> > > > added afterwards. Unfortunately I've failed to explain this trickery in
> > > > either a comment or the commit message. Bad me ;-)
> > > 
> > > The issue is that in the patch pwrite is not waiting for any outstanding
> > > GPU reads.
> > 
> > Oh right, silly me didn't spot the s/true/false/ switch Ben sneaked in.
> > This /should/ have been caught by the gem_concurrent_blt subtests that
> > exercise pwrites ...
> > 
> > Ben can you please check that this indeed blew up on igt? Should fail on
> > any platform, no special caching mode required.
> 
> Actually it won't blow up since you always set readonly = false. But it'll
> kill the neat read-read optimization ...
> -Daniel

Doh! Sorry about this. Fixed locally.

-- 
Ben Widawsky, Intel Open Source Technology Center

  reply	other threads:[~2013-09-03 23:53 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-30 23:43 [PATCH 0/8] [RESEND] VMA patches Ben Widawsky
2013-08-30 23:43 ` [PATCH 1/8] drm/i915: Synchronize pread/pwrite with wait_rendering Ben Widawsky
2013-08-30 23:50   ` Chris Wilson
2013-08-31  3:39     ` Ben Widawsky
2013-09-02  6:32       ` Daniel Vetter
2013-09-02 13:14         ` Chris Wilson
2013-09-02 14:12           ` Daniel Vetter
2013-09-03 16:08             ` Daniel Vetter
2013-09-03 23:53               ` Ben Widawsky [this message]
2013-08-30 23:43 ` [PATCH 2/8] drm/i915: Extract vm specific part of eviction Ben Widawsky
2013-08-30 23:52   ` Chris Wilson
2013-08-31  3:39     ` Ben Widawsky
2013-08-30 23:43 ` [PATCH 3/8] drm/i915: evict VM instead of everything Ben Widawsky
2013-08-31  0:04   ` Chris Wilson
2013-08-30 23:43 ` [PATCH 4/8] drm/i915: trace vm eviction " Ben Widawsky
2013-08-31  0:06   ` Chris Wilson
2013-08-31  3:40     ` Ben Widawsky
2013-08-30 23:43 ` [PATCH 5/8] drm/i915: Convert active API to VMA Ben Widawsky
2013-08-31  0:08   ` Chris Wilson
2013-08-30 23:43 ` [PATCH 6/8] drm/i915: Add bind/unbind object functions to VM Ben Widawsky
2013-08-31  0:12   ` Chris Wilson
2013-08-31  3:40     ` Ben Widawsky
2013-09-03 14:48       ` Chris Wilson
2013-09-02 12:46   ` Ville Syrjälä
2013-09-04  0:20     ` Ben Widawsky
2013-09-04  7:31       ` Ville Syrjälä
2013-08-30 23:44 ` [PATCH 7/8] drm/i915: Use the new vm [un]bind functions Ben Widawsky
2013-08-30 23:44 ` [PATCH 8/8] drm/i915: eliminate vm->insert_entries() Ben Widawsky
  -- strict thread matches above, loose matches on Subject: below --
2013-09-11 21:57 [PATCH 1/8] drm/i915: Synchronize pread/pwrite with wait_rendering Ben Widawsky

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=20130903235306.GA2860@bwidawsk.net \
    --to=ben@bwidawsk.net \
    --cc=benjamin.widawsky@intel.com \
    --cc=daniel@ffwll.ch \
    --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 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.