From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 05/13] drm/i915: Insert a flush between batches if the breadcrumb was dropped
Date: Sat, 14 Jul 2012 11:24:33 +0100 [thread overview]
Message-ID: <1342261485_7208@CP5-2952> (raw)
In-Reply-To: <20120713154620.GG5721@phenom.ffwll.local>
On Fri, 13 Jul 2012 17:46:20 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Jul 13, 2012 at 02:14:08PM +0100, Chris Wilson wrote:
> > If we drop the breadcrumb request after a batch due to a signal for
> > example we aim to fix it up at the next opportunity. In this case we
> > emit a second batchbuffer with no waits upon the first and so no
> > opportunity to insert the missing request, so we need to emit the
> > missing flush for coherency. (Note that that invalidating the render
> > cache is the same as flushing it, so there should have been no
> > observable corruption.)
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>
> Imo still too meager commit message ;-) As I've said in the previous mail,
> I'd like some mention of the two commits that made this disaster possible
> (put the blame on me where it is due). And I think some more in-detail
> walk-thru of how things blow up would be great. And the Bugzilla link for
> the QA bugreport.
Sure, in the patch I thought I was sending I had an extra paragraph:
As a side effect this will also paper over issues such as
https://bugs.freedesktop.org/show_bug.cgi?id=52040
whereby we clear the write_domain on objects on the defunct
gpu_write_list.
References: https://bugs.freedesktop.org/show_bug.cgi?id=52040
> Also, I still don't understand why this patch here isn't enough to fix up
> the fallout. So if you can enlighten me where/why stuff blows up even with
> this I'd highly appreciate. Not just because not understanding bugs makes
> me queasy, but also to have a clear picture of what I'd need to send to
> Dave it this -next cycle misses 3.6.
The remaining fallout is that we still end up using the flushing-list,
as revealed by *adding* a WARN.
To end up in that situation we must retire an object with a write-domain
still set. But how can this be possible if we always clear the
write_list prior to the request/retirment?
I thought I had it, being sneaky with the use of INSTRUCTION write
domain for pipe-control. However, looks like I'm going to have to
reproduce with some more debugging.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-07-14 10:24 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 13:14 Remove defunct flushing list (v2) Chris Wilson
2012-07-13 13:14 ` [PATCH 01/13] drm/i915: Flush the context object from the CPU caches upon creation Chris Wilson
2012-07-13 15:28 ` Ben Widawsky
2012-07-13 15:54 ` Daniel Vetter
2012-07-14 9:38 ` Chris Wilson
2012-07-14 11:58 ` Daniel Vetter
2012-07-14 12:48 ` Chris Wilson
2012-07-14 12:59 ` Daniel Vetter
2012-07-13 13:14 ` [PATCH 02/13] drm/i915: fix invalid reference handling of the default ctx obj Chris Wilson
2012-07-13 15:25 ` Ben Widawsky
2012-07-13 15:37 ` Daniel Vetter
2012-07-14 9:55 ` Chris Wilson
2012-07-14 11:53 ` Daniel Vetter
2012-07-13 13:14 ` [PATCH 03/13] drm/i915: Allow late allocation of request for i915_add_request() Chris Wilson
2012-07-13 13:14 ` [PATCH 04/13] drm/i915: Replace the pending_gpu_write flag with an explicit seqno Chris Wilson
2012-07-13 15:41 ` Daniel Vetter
2012-07-14 9:53 ` Chris Wilson
2012-07-13 13:14 ` [PATCH 05/13] drm/i915: Insert a flush between batches if the breadcrumb was dropped Chris Wilson
2012-07-13 15:46 ` Daniel Vetter
2012-07-14 10:24 ` Chris Wilson [this message]
2012-07-14 13:39 ` Daniel Vetter
2012-07-13 13:14 ` [PATCH 06/13] drm/i915: Remove the defunct flushing list Chris Wilson
2012-07-13 13:14 ` [PATCH 07/13] drm/i915: Remove the per-ring write list Chris Wilson
2012-07-13 13:14 ` [PATCH 08/13] drm/i915: Remove explicit flush from i915_gem_object_flush_fence() Chris Wilson
2012-07-13 13:14 ` [PATCH 09/13] drm/i915: Remove the explicit flush of the GPU write domain Chris Wilson
2012-07-13 13:14 ` [PATCH 10/13] drm/i915: Replace the complex flushing logic with simple invalidate/flush all Chris Wilson
2012-07-13 13:14 ` [PATCH 11/13] drm/i915: Clear the pending_gpu_fenced_access flag at the start of execbuffer Chris Wilson
2012-07-13 13:14 ` [PATCH 12/13] drm/i915: Split i915_gem_flush_ring() into seperate invalidate/flush funcs Chris Wilson
2012-07-13 13:14 ` [PATCH 13/13] drm/i915: Move the write seqno handling to move_to_active 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=1342261485_7208@CP5-2952 \
--to=chris@chris-wilson.co.uk \
--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.