On Friday, September 26, 2014 04:41:14 PM Chris Wilson wrote:
> On Fri, Sep 26, 2014 at 08:36:39AM -0700, Kristian Høgsberg wrote:
> > On Fri, Aug 29, 2014 at 11:10:49PM -0700, Kenneth Graunke wrote:
> > > We don't really want extra buffer copying or stalls when mapping,
> > > so it'd be nice to know when it's happening.
> > > 
> > > Signed-off-by: Kenneth Graunke <kenn...@whitecape.org>
> > 
> > Reviewed-by: Kristian Høgsberg <k...@bitplanet.net>
> 
> This warns if the the program cache is currently being read by the GPU
> (expected) but a read-read (as used here) does not incur a stall.
> -Chris

Good catch!  Since we're doing a read-only mapping, and all of our relocations 
to this buffer have 0 for the write domains, GEM knows that nobody is altering 
it, so there shouldn't be a stall.  Even though i915_gem_set_domain_ioctl calls 
i915_gem_object_wait_rendering__nonblocking, it shouldn't actually wait.

Thanks for spotting this.  I'll drop this hunk.

I suppose this is a problem with my stall-warning code in general... 
drm_intel_bo_busy() == true does not necessarily imply that there will be a 
stall when mapping it.  I hadn't considered that.

It sounds like patch 4 (using unsynchronized mappings) is still useful though, 
as drm_intel_bo_subdata/pwrite doesn't know that it's safe to let the CPU write 
the buffer even while the GPU is reading it.

--Ken

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to