From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/icl: Forcibly evict stale csb entries
Date: Fri, 07 Dec 2018 14:37:33 +0200 [thread overview]
Message-ID: <87k1kltsvm.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <154401833327.27857.16327743594313953545@skylake-alporthouse-com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Mika Kuoppala (2018-12-05 13:46:12)
>> static void nop_submission_tasklet(unsigned long data)
>> @@ -1015,6 +1025,19 @@ static void process_csb(struct intel_engine_cs *engine)
>> } while (head != tail);
>>
>> execlists->csb_head = head;
>> +
>> + /*
>> + * Gen11 has proven to fail wrt global observation point between
>> + * entry and tail update, failing on the ordering and thus
>> + * we see an old entry in the context status buffer.
>> + *
>> + * Forcibly evict out entries for the next gpu csb update,
>> + * to increase the odds that we get a fresh entries with non
>> + * working hardware. The cost for doing so comes out mostly with
>> + * the wash as hardware, working or not, will need to do the
>> + * invalidation before.
>> + */
>> + invalidate_csb_entries(&buf[0], &buf[GEN8_CSB_ENTRIES - 1]);
>
> If it works, this is a stroke of genius.
>
> If we hypothesize that the GPU did write the CSB entries before the head
> pointer and inserted a Global Observation point beforehand, then we
> theorize that they merely forgot the cc protocol, the writes to system memory is
> correctly, but unordered into the cpu cache.
>
> By using the clflush to evict our used cacheline, on the next pass we
> will pull in that CSB entry cacheline back in from memory (ordered by
> the rmb used for the ringbuffer) and so, if the HW engineer's
> insistence that they did remember their wmb, the CSB entries will be
> coherent with the head pointer.
>
> So we remove one piece of the puzzle at what should be negligible cost,
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Thank you for review and kind words, pushed.
-Mika
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-12-07 12:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-05 13:46 [PATCH] drm/i915/icl: Forcibly evict stale csb entries Mika Kuoppala
2018-12-05 13:58 ` Chris Wilson
2018-12-07 12:37 ` Mika Kuoppala [this message]
2018-12-05 15:36 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-12-05 20:25 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-12-05 21:20 ` ✓ Fi.CI.BAT: success for drm/i915/icl: Forcibly evict stale csb entries (rev2) 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=87k1kltsvm.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@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 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.