public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects
Date: Wed, 20 Jul 2016 10:32:44 +0300	[thread overview]
Message-ID: <1468999964.4964.0.camel@linux.intel.com> (raw)
In-Reply-To: <20160719142730.GK17604@nuc-i3427.alporthouse.com>

On ti, 2016-07-19 at 15:27 +0100, Chris Wilson wrote:
> On Tue, Jul 19, 2016 at 05:12:22PM +0300, Joonas Lahtinen wrote:
> > 
> > On ti, 2016-07-19 at 11:51 +0100, Chris Wilson wrote:
> > > 
> > > +	resv = i915_gem_object_get_dmabuf_resv(obj);
> > > +	if (resv) {
> > > +		long err;
> > We already have ret in the function scope.
> ret is int, we need a long. At least I can attest to our test coverage!
> 
> > 
> > > 
> > > @@ -3402,13 +3414,13 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
> > >  	struct i915_vma *vma;
> > >  	int ret;
> > >  
> > > -	if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
> > > -		return 0;
> > > -
> > >  	ret = i915_gem_object_wait_rendering(obj, !write);
> > >  	if (ret)
> > >  		return ret;
> > >  
> > > +	if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
> > > +		return 0;
> > > +
> > Not sure I follow this change, wait rendering would only be issued if
> > DOMAIN_CPU was in place, this function was about moving to gtt_domain
> > so should really be NOP if in GTT domain already, no? Maybe calling
> > site should do an explicit wait_rendering if needed.
> No, this is where we do the wait rendering. The API says
> set-to-gtt-domain implies that it is out of the GPU domain (no
> rendering) and out of the CPU domain. (Similarly for set-to-cpu-domain.)
> The relaxation I've applied here is to try and catch third parties that
> have not updated our domain tracking for their access.
> 
> Moving the wait_rendering to the parent is a fair amount of burden.
> 
> > 
> > > 
> > >  		vma->pin_count = 0;
> > > -		ret = i915_vma_unbind(vma);
> > Maybe add a comment/TODO/FIXME: about the potential WARN.
> __i915_vma_unbind_no_wait() is itself an automatic FIXME - it only
> exists to cover up a WARN. (I wish we had this series in place first so
> that such a hack wasn't applied.)

OK then,

Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>

> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-07-20  7:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 10:51 [PATCH 1/8] drm/i915: Move GEM request routines to i915_gem_request.c Chris Wilson
2016-07-19 10:51 ` [PATCH 2/8] drm/i915: Retire oldest completed request before allocating next Chris Wilson
2016-07-19 10:51 ` [PATCH 3/8] drm/i915: Mark all current requests as complete before resetting them Chris Wilson
2016-07-19 10:51 ` [PATCH 4/8] drm/i915: Derive GEM requests from dma-fence Chris Wilson
2016-07-19 10:51 ` [PATCH 5/8] drm/i915: Disable waitboosting for fence_wait() Chris Wilson
2016-07-19 10:51 ` [PATCH 6/8] drm/i915: Disable waitboosting for mmioflips/semaphores Chris Wilson
2016-07-19 10:51 ` [PATCH 7/8] drm/i915: Mark imported dma-buf objects as being coherent Chris Wilson
2016-07-19 13:27   ` Joonas Lahtinen
2016-07-19 10:51 ` [PATCH 8/8] drm/i915: Wait on external rendering for GEM objects Chris Wilson
2016-07-19 14:12   ` Joonas Lahtinen
2016-07-19 14:27     ` Chris Wilson
2016-07-20  7:32       ` Joonas Lahtinen [this message]
2016-07-19 11:29 ` ✗ Ro.CI.BAT: failure for series starting with [1/8] drm/i915: Move GEM request routines to i915_gem_request.c Patchwork

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=1468999964.4964.0.camel@linux.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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