[Intel-gfx] [PATCH v3 1/6] drm/i915/gen8: Add infrastructure to initialize WA batch buffers

[Chris Wilson]

On Fri, Jun 05, 2015 at 11:34:01AM +0100, Arun Siluvery wrote:
> Some of the WA are to be applied during context save but before restore and
> some at the end of context save/restore but before executing the instructions
> in the ring, WA batch buffers are created for this purpose and these WA cannot
> be applied using normal means. Each context has two registers to load the
> offsets of these batch buffers. If they are non-zero, HW understands that it
> need to execute these batches.
> 
> v1: In this version two separate ring_buffer objects were used to load WA
> instructions for indirect and per context batch buffers and they were part
> of every context.
> 
> v2: Chris suggested to include additional page in context and use it to load
> these WA instead of creating separate objects. This will simplify lot of things
> as we need not explicity pin/unpin them. Thomas Daniel further pointed that GuC
> is planning to use a similar setup to share data between GuC and driver and
> WA batch buffers can probably share that page. However after discussions with
> Dave who is implementing GuC changes, he suggested to use an independent page
> for the reasons - GuC area might grow and these WA are initialized only once and
> are not changed afterwards so we can share them share across all contexts.
> This version uses this approach.
> (Thanks to Chris, Dave and Thomas for their inputs)

Having moved to a shared wa_ctx for all lrc, I think it makes sense to
then do the allocation during ring_init itself, next to the scratch/hws
status pages. The advantage is that we don't then need to add more
special cases to the default ctx on RCS, and its permanence is far more
prominent. It will also be more consistent with calling it ring->wa_ctx.

Since you have it already plumbed into ring init/fini, why is it partly
done during default ctx init? Maybe all that is required a little bit of
code and changelog explanation.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre