From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 3/6] drm/i915: Remove the per-ring write list
Date: Fri, 13 Jul 2012 10:34:43 +0200 [thread overview]
Message-ID: <20120713083426.GA5721@phenom.ffwll.local> (raw)
In-Reply-To: <1342123681_2236@CP5-2952>
On Thu, Jul 12, 2012 at 09:07:52PM +0100, Chris Wilson wrote:
> On Thu, 12 Jul 2012 21:37:16 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Thu, Jul 12, 2012 at 04:13:36PM +0100, Chris Wilson wrote:
> > > obj->base.write_domain = 0;
> > > - list_del_init(&obj->gpu_write_list);
> > > + obj->pending_gpu_write = false;
> > > i915_gem_object_move_to_inactive(obj);
> >
> > Hm, this hunk makes me wonder whether we don't leak some bogus state
> > accross a gpu reset. Can't we just reuse the move_to_inactive helper here,
> > ensuring that we consistenly clear up any active state?
>
> Yes. I had planned to finish off with another patch to remove that pair
> of then redundant lines, but apparently forgot. I think it is better
> expressed as a second patch, at least from the point of view of how I
> was applying the transformations.
Actually I've been confused yesterday, we do call move_to_inactive in the
next line ;-)
I've looked again at your patch, and the changes to how we handle
obj->pending_pug_write look buggy. The above hunk is superflous, because
move_to_inactive will do that.
The hunk int i915_gem_execbuffer's is buggy, we can't clear
pending_gpu_write there - we use that to decide whether we need to stall
for the gpu when the cpu does a read-only accesss. We then stall
completely because we don't keep track of the last write seqno separately.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2012-07-13 8:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 15:13 Kill the flushing list Chris Wilson
2012-07-12 15:13 ` [PATCH 1/6] drm/i915: Allow late allocation of request for i915_add_request() Chris Wilson
2012-07-12 17:43 ` Daniel Vetter
2012-07-12 17:56 ` Chris Wilson
2012-07-12 18:02 ` [PATCH] " Chris Wilson
2012-07-12 15:13 ` [PATCH 2/6] drm/i915: Remove the defunct flushing list Chris Wilson
2012-07-13 9:12 ` Daniel Vetter
2012-07-12 15:13 ` [PATCH 3/6] drm/i915: Remove the per-ring write list Chris Wilson
2012-07-12 19:37 ` Daniel Vetter
2012-07-12 20:07 ` Chris Wilson
2012-07-13 8:34 ` Daniel Vetter [this message]
2012-07-13 8:49 ` Chris Wilson
2012-07-13 8:53 ` Chris Wilson
2012-07-13 9:05 ` Daniel Vetter
2012-07-12 15:13 ` [PATCH 4/6] drm/i915: Remove explicit flush from i915_gem_object_flush_fence() Chris Wilson
2012-07-12 15:13 ` [PATCH 5/6] drm/i915: Remove the explicit flush of the GPU write domain Chris Wilson
2012-07-12 15:13 ` [PATCH 6/6] drm/i915: Split i915_gem_flush_ring() into seperate invalidate/flush funcs Chris Wilson
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=20120713083426.GA5721@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--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;
as well as URLs for NNTP newsgroup(s).