[Mesa-dev] [PATCH 3/4] i965: Issue performance warnings for program cache related stalls.
Daniel Vetter
daniel at ffwll.ch
Mon Sep 29 07:06:29 PDT 2014
On Fri, Sep 26, 2014 at 02:36:20PM -0700, Kenneth Graunke wrote:
> 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 <kenneth at whitecape.org>
> > >
> > > Reviewed-by: Kristian Høgsberg <krh at 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.
We coul add a flag to the timeout ioctl (which works like busy for
timeout=0) asking to just wait for read-only access. Shouldn't be a lot of
fuzz to pimp the corresponding igt testcase and wire it all up. Or not
that interesting?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the mesa-dev
mailing list