[Intel-gfx] [PATCH] drm/i915/icl: Forcibly evict stale csb entries
Chris Wilson
chris at chris-wilson.co.uk
Wed Dec 5 13:58:53 UTC 2018
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 at chris-wilson.co.uk>
-Chris
More information about the Intel-gfx
mailing list