[igt-dev] [PATCH i-g-t v1 1/1] gem_ctx_isolation.c - Gen11 enabling for context isolation test

[Chris Wilson]

Quoting Dale B Stimson via igt-dev (2019-02-15 21:31:53)
> This patch is a change to igt file tests/i915/gem_ctx_isolation.c to add
> Gen11 support.
> 
> This patch enables Gen11 support.
> 
> This patch accounts for whitelisted registers appropriately for the
> different Gen levels.
> 
> This patch accounts for the changed MMIO offsets of Gen11.
> 
> This patch redefines MAX_REG from 0x40000 to 0x200000 due to the
> larger total register space for Gen11 mmio offsets.  The resulting
> big sparse array allocations present a good candidate for future
> optimization of memory usage.
> 
> The current Gen11 SKU has two video engines (with indexes 0 and 2,
> for VCS0 and VCS2), with VCS1 not being used.
> 
> Current kernel and igt limitations only allow for VCS0 and VCS1.
> Those limitations are in the process of being removed.  See for
> example the RFC/PATCH series on igt-dev from Andy Shyti:
>     [igt-dev] [RFC PATCH v9 0/5] new engine discovery interface
> which depends on in-process kernel "media scalability" patches.
> 
> Lacking the above infrastructure at the moment:
> 
> The array of registers to be tested includes VCS2 and VCS3 registers.
> They are present as a provision for the future, but they will
> not actually be tested as those engines are not yet known to the
> underlying infrastructure.
> 
> When run on Gen11 this patch skips the sub-tests for the non-existent VCS1
> with these warnings:
>   Test requirement not met in function gem_require_engine, file ../lib/igt_gt.h:114:
>   Test requirement: gem_has_engine(gem_fd, class, instance)
> 
> Anticipated for the future:
> 
> Take advantage of the new infrastructure to dynamically determine which
> engines are present and test the same register(s) in each of them.

> Add support for CCS.
> 
> Reduce memory requirements by avoiding sparse register-space arrays.

Is that a real issue? Would you even care for doing anything other than
finding the range of interest in each engine-set? Or even just
subtracting off the engine->mmio_base.
 
> Signed-off-by: Dale B Stimson <dale.b.stimson at intel.com>
> ---
>  tests/i915/gem_ctx_isolation.c | 57 +++++++++++++++++++++++++++-------
>  1 file changed, 45 insertions(+), 12 deletions(-)
> 
> diff --git a/tests/i915/gem_ctx_isolation.c b/tests/i915/gem_ctx_isolation.c
> index 839d49ad..4628e499 100644
> --- a/tests/i915/gem_ctx_isolation.c
> +++ b/tests/i915/gem_ctx_isolation.c
> @@ -24,7 +24,7 @@
>  #include "igt.h"
>  #include "igt_dummyload.h"
>  
> -#define MAX_REG 0x40000
> +#define MAX_REG 0x200000
>  #define NUM_REGS (MAX_REG / sizeof(uint32_t))
>  
>  #define PAGE_ALIGN(x) ALIGN(x, 4096)
> @@ -41,6 +41,8 @@ enum {
>         BCS0 = ENGINE(I915_ENGINE_CLASS_COPY, 0),
>         VCS0 = ENGINE(I915_ENGINE_CLASS_VIDEO, 0),
>         VCS1 = ENGINE(I915_ENGINE_CLASS_VIDEO, 1),
> +       VCS2 = ENGINE(I915_ENGINE_CLASS_VIDEO, 2),
> +       VCS3 = ENGINE(I915_ENGINE_CLASS_VIDEO, 3),
>         VECS0 = ENGINE(I915_ENGINE_CLASS_VIDEO_ENHANCE, 0),
>  };
>  
> @@ -52,10 +54,12 @@ enum {
>  #define GEN7 (ALL << 7)
>  #define GEN8 (ALL << 8)
>  #define GEN9 (ALL << 9)
> +#define GEN10 (ALL << 10)
> +#define GEN11 (ALL << 11)
>  
>  #define NOCTX 0
>  
> -#define LAST_KNOWN_GEN 10
> +#define LAST_KNOWN_GEN 11
>  
>  static const struct named_register {
>         const char *name;
> @@ -125,30 +129,59 @@ static const struct named_register {
>         { "PERF_CNT_1", NOCTX, RCS0, 0x91b8, 2 },
>         { "PERF_CNT_2", NOCTX, RCS0, 0x91c0, 2 },
>  
> +       /* Begin - registers privileged at one time or another */
> +
>         /* Privileged (enabled by w/a + FORCE_TO_NONPRIV) */
>         { "CTX_PREEMPT", NOCTX /* GEN_RANGE(9, 10) */, RCS0, 0x2248 },
> -       { "CS_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x2580 },
> -       { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS0, 0x7304 },
> -       { "L3SQREG1", GEN8, RCS0, 0xb010 },
> +
> +       /* FORCE_TO_NONPRIV for gen 9-10, present non-priv thereafter. */
> +       { "CS_CHICKEN1", GEN9, RCS0, 0x2580 },
> +
> +       /* FORCE_TO_NONPRIV for gen 9, present non-priv Gen 10-11. */
> +       { "HDC_CHICKEN1", GEN_RANGE(9, 11), RCS0, 0x7304 },

Or we could just list the registers twice in the force-to-nonpriv and
actually-nonpriv.

I'd rather do that, so that it's much easy to read the list of whitelist
registers against the kernel.

> +
> +       /* Removed in Gen11 */
> +       { "L3SQREG1", GEN_RANGE(8, 10), RCS0, 0xb010 },

Comment is identical to code, doesn't contain a why so superfuous.

> +       /* NOPRIV for Gen11 */
> +       { "HALF_SLICE_CHICKEN7", GEN_RANGE(11, 11), RCS0, 0xe194 },
> +
> +       /* NOPRIV for Gen11 */
> +       { "SAMPLER_MODE", GEN_RANGE(11, 11), RCS0, 0xE18C },

So no need to be part of the privileged section at all; if it is doesn't
exist as part of the test before gen11, we don't need to mention it. (As
not being part of earlier gen is explicit in the gen_range.)

> +       /* End - registers privileged at one time or another */

And pretty much redundant after the changes as it can be reduced to a
single visual block again.

>  
>         { "BCS_GPR", GEN9, BCS0, 0x22600, 32 },
>         { "BCS_SWCTRL", GEN8, BCS0, 0x22200 },
>  
> -       { "VCS0_GPR", GEN9, VCS0, 0x12600, 32 },
>         { "MFC_VDBOX1", NOCTX, VCS0, 0x12800, 64 },
> -
> -       { "VCS1_GPR", GEN9, VCS1, 0x1c600, 32 },
>         { "MFC_VDBOX2", NOCTX, VCS1, 0x1c800, 64 },
>  
> -       { "VECS_GPR", GEN9, VECS0, 0x1a600, 32 },
> +       { "VCS0_GPR", GEN_RANGE(9, 10), VCS0, 0x12600, 32 },
> +       { "VCS1_GPR", GEN_RANGE(9, 10), VCS1, 0x1c600, 32 },
> +       { "VECS_GPR", GEN_RANGE(9, 10), VECS0, 0x1a600, 32 },
> +
> +       { "VCS0_GPR", GEN11, VCS0, 0x1c0600, 32 },
> +       { "VCS1_GPR", GEN11, VCS1, 0x1c4600, 32 },
> +       { "VCS2_GPR", GEN11, VCS2, 0x1d0600, 32 },
> +       { "VCS3_GPR", GEN11, VCS3, 0x1d4600, 32 },
> +       { "VECS_GPR", GEN11, VECS0, 0x1c8600, 32 },

Would we not want to keep this as part of per-engine sets? That makes
more sense to me.

>         {}
>  }, ignore_registers[] = {
>         { "RCS timestamp", GEN6, ~0u, 0x2358 },
> -       { "VCS0 timestamp", GEN7, ~0u, 0x12358 },
> -       { "VCS1 timestamp", GEN7, ~0u, 0x1c358 },
>         { "BCS timestamp", GEN7, ~0u, 0x22358 },
> -       { "VECS timestamp", GEN8, ~0u, 0x1a358 },
> +
> +       { "VCS0 timestamp", GEN_RANGE(7, 10), ~0u, 0x12358 },
> +       { "VCS1 timestamp", GEN_RANGE(7, 10), ~0u, 0x1c358 },
> +       { "VECS timestamp", GEN_RANGE(8, 10), ~0u, 0x1a358 },
> +
> +       { "VCS0 timestamp", GEN11, ~0u, 0x1c0358 },
> +       { "VCS1 timestamp", GEN11, ~0u, 0x1c4358 },
> +       { "VCS2 timestamp", GEN11, ~0u, 0x1d0358 },
> +       { "VCS3 timestamp", GEN11, ~0u, 0x1d4358 },
> +       { "VECS timestamp", GEN11, ~0u, 0x1c8358 },

Part of me wants to add GEN11_xCSy_MMIO etc (and the other part wants
that from the query iface).

Otherwise looks ok, and I just want someone else with an actual icl to
confirm it does what it says on the tin.

I still think we should add a readback inside the test to confirm that
writes to these registers are actually sticking before confirming that
they are reset between ctx. That should have caught the issue with the
previous patch, so a useful piece of sanitychecking.
-Chris