[igt-dev] [RFC v2 0/3] new engine discovery interface

[igt-dev] [RFC v2 0/3] new engine discovery interface

[Andi Shyti]

Hi,

this is a request for comments for the new engine discovery
interface developed by Tvrtko and Chris[*].

Thanks Chris and Tvrtko for your comments in the v1, here's the
changelog:

V1 --> V2
- added a demo test that simply queries the driver about the
  engines and executes a buffer (thanks Tvrtko)
- refactored the for_each_engine_ctx() macro so that what in the
  previous version was done by the "bind" function, now it's done
  in the first iteration. (Thanks Crhis)
- removed the "gem_has_ring_ctx()" because it was out of the
  scope.
- rename functions to more meaningful names

Andi

[*] git://people.freedesktop.org/~tursulin/drm-intel

Andi Shyti (3):
  include/drm-uapi: import i915_drm.h header file
  lib: implement new engine discovery interface
  tests: gem_gem_query_engines_demo: create test

 include/drm-uapi/i915_drm.h         | 239 +++++++++++++++++++++++++++-
 lib/igt_gt.c                        |  83 ++++++++++
 lib/igt_gt.h                        |   8 +
 tests/Makefile.sources              |   3 +
 tests/i915/gem_query_engines_demo.c |  56 +++++++
 tests/meson.build                   |   1 +
 6 files changed, 388 insertions(+), 2 deletions(-)
 create mode 100644 tests/i915/gem_query_engines_demo.c

-- 
2.19.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [RFC v2 1/3] include/drm-uapi: import i915_drm.h header file

[Andi Shyti]

This header file is imported in order to include the two new
ioctls DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM and
DRM_IOCTL_I915_QUERY. They are not based on a latest version of
the branch, but based on the

git://people.freedesktop.org/~tursulin/drm-intel

tree, "media" branch. In this RFC it's just to give a meaning to
the next patch.

Signed-off-by: Andi Shyti <andi.shyti@intel.com>
---
 include/drm-uapi/i915_drm.h | 239 +++++++++++++++++++++++++++++++++++-
 1 file changed, 237 insertions(+), 2 deletions(-)

diff --git a/include/drm-uapi/i915_drm.h b/include/drm-uapi/i915_drm.h
index 16e452aa..b14ca969 100644
--- a/include/drm-uapi/i915_drm.h
+++ b/include/drm-uapi/i915_drm.h
@@ -62,6 +62,26 @@ extern "C" {
 #define I915_ERROR_UEVENT		"ERROR"
 #define I915_RESET_UEVENT		"RESET"
 
+/*
+ * i915_user_extension: Base class for defining a chain of extensions
+ *
+ * Many interfaces need to grow over time. In most cases we can simply
+ * extend the struct and have userspace pass in more data. Another option,
+ * as demonstrated by Vulkan's approach to providing extensions for forward
+ * and backward compatibility, is to use a list of optional structs to
+ * provide those extra details.
+ *
+ * The key advantage to using an extension chain is that it allows us to
+ * redefine the interface more easily than an ever growing struct of
+ * increasing complexity, and for large parts of that interface to be
+ * entirely optional. The downside is more pointer chasing; chasing across
+ * the boundary with pointers encapsulated inside u64.
+ */
+struct i915_user_extension {
+	__u64 next_extension;
+	__u64 name;
+};
+
 /*
  * MOCS indexes used for GPU surfaces, defining the cacheability of the
  * surface data and the coherency for this data wrt. CPU vs. GPU accesses.
@@ -367,6 +387,7 @@ typedef struct _drm_i915_sarea {
 #define DRM_IOCTL_I915_GET_SPRITE_COLORKEY DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY, struct drm_intel_sprite_colorkey)
 #define DRM_IOCTL_I915_GEM_WAIT		DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_WAIT, struct drm_i915_gem_wait)
 #define DRM_IOCTL_I915_GEM_CONTEXT_CREATE	DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create)
+#define DRM_IOCTL_I915_GEM_CONTEXT_CREATE_v2	DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_CREATE, struct drm_i915_gem_context_create_v2)
 #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY	DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
 #define DRM_IOCTL_I915_REG_READ			DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
 #define DRM_IOCTL_I915_GET_RESET_STATS		DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
@@ -412,6 +433,14 @@ typedef struct drm_i915_irq_wait {
 	int irq_seq;
 } drm_i915_irq_wait_t;
 
+/*
+ * Different modes of per-process Graphics Translation Table,
+ * see I915_PARAM_HAS_ALIASING_PPGTT
+ */
+#define I915_GEM_PPGTT_NONE	0
+#define I915_GEM_PPGTT_ALIASING	1
+#define I915_GEM_PPGTT_FULL	2
+
 /* Ioctl to query kernel params:
  */
 #define I915_PARAM_IRQ_ACTIVE            1
@@ -529,6 +558,35 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_CS_TIMESTAMP_FREQUENCY 51
 
+/*
+ * Once upon a time we supposed that writes through the GGTT would be
+ * immediately in physical memory (once flushed out of the CPU path). However,
+ * on a few different processors and chipsets, this is not necessarily the case
+ * as the writes appear to be buffered internally. Thus a read of the backing
+ * storage (physical memory) via a different path (with different physical tags
+ * to the indirect write via the GGTT) will see stale values from before
+ * the GGTT write. Inside the kernel, we can for the most part keep track of
+ * the different read/write domains in use (e.g. set-domain), but the assumption
+ * of coherency is baked into the ABI, hence reporting its true state in this
+ * parameter.
+ *
+ * Reports true when writes via mmap_gtt are immediately visible following an
+ * lfence to flush the WCB.
+ *
+ * Reports false when writes via mmap_gtt are indeterminately delayed in an in
+ * internal buffer and are _not_ immediately visible to third parties accessing
+ * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC
+ * communications channel when reporting false is strongly disadvised.
+ */
+#define I915_PARAM_MMAP_GTT_COHERENT	52
+
+/*
+ * Query whether DRM_I915_GEM_EXECBUFFER2 supports coordination of parallel
+ * execution through use of explicit fence support.
+ * See I915_EXEC_FENCE_OUT and I915_EXEC_FENCE_SUBMIT.
+ */
+#define I915_PARAM_HAS_EXEC_SUBMIT_FENCE 53
+
 typedef struct drm_i915_getparam {
 	__s32 param;
 	/*
@@ -942,7 +1000,7 @@ struct drm_i915_gem_execbuffer2 {
 	 * struct drm_i915_gem_exec_fence *fences.
 	 */
 	__u64 cliprects_ptr;
-#define I915_EXEC_RING_MASK              (7<<0)
+#define I915_EXEC_RING_MASK              (0x3f)
 #define I915_EXEC_DEFAULT                (0<<0)
 #define I915_EXEC_RENDER                 (1<<0)
 #define I915_EXEC_BSD                    (2<<0)
@@ -1048,7 +1106,16 @@ struct drm_i915_gem_execbuffer2 {
  */
 #define I915_EXEC_FENCE_ARRAY   (1<<19)
 
-#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_ARRAY<<1))
+/*
+ * Setting I915_EXEC_FENCE_SUBMIT implies that lower_32_bits(rsvd2) represent
+ * a sync_file fd to wait upon (in a nonblocking manner) prior to executing
+ * the batch.
+ *
+ * Returns -EINVAL if the sync_file fd cannot be found.
+ */
+#define I915_EXEC_FENCE_SUBMIT		(1<<20)
+
+#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SUBMIT<<1))
 
 #define I915_EXEC_CONTEXT_ID_MASK	(0xffffffff)
 #define i915_execbuffer2_set_context_id(eb2, context) \
@@ -1387,6 +1454,16 @@ struct drm_i915_gem_context_create {
 	__u32 pad;
 };
 
+struct drm_i915_gem_context_create_v2 {
+	/*  output: id of new context*/
+	__u32 ctx_id;
+	__u32 flags;
+#define I915_GEM_CONTEXT_SHARE_GTT		0x1
+#define I915_GEM_CONTEXT_SINGLE_TIMELINE	0x2
+	__u32 share_ctx;
+	__u32 pad;
+};
+
 struct drm_i915_gem_context_destroy {
 	__u32 ctx_id;
 	__u32 pad;
@@ -1456,9 +1533,122 @@ struct drm_i915_gem_context_param {
 #define   I915_CONTEXT_MAX_USER_PRIORITY	1023 /* inclusive */
 #define   I915_CONTEXT_DEFAULT_PRIORITY		0
 #define   I915_CONTEXT_MIN_USER_PRIORITY	-1023 /* inclusive */
+
+/*
+ * I915_CONTEXT_PARAM_ENGINES:
+ *
+ * Bind this context to operate on this subset of available engines. Henceforth,
+ * the I915_EXEC_RING selector for DRM_IOCTL_I915_GEM_EXECBUFFER2 operates as
+ * an index into this array of engines; I915_EXEC_DEFAULT selecting engine[0]
+ * and upwards. The array created is offset by 1, such that by default
+ * I915_EXEC_DEFAULT is left empty, to be filled in as directed. Slots 1...N
+ * are then filled in using the specified (class, instance).
+ *
+ * Setting the number of engines bound to the context will revert back to
+ * default settings.
+ *
+ * See struct i915_context_param_engines.
+ *
+ * Extensions:
+ *   i915_context_engines_load_balance (I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE)
+ *   i915_context_engines_bond (I915_CONTEXT_ENGINES_EXT_BOND)
+ */
+#define I915_CONTEXT_PARAM_ENGINES	0x7
+
+/*
+ * When using the following param, value should be a pointer to
+ * drm_i915_gem_context_param_sseu.
+ */
+#define I915_CONTEXT_PARAM_SSEU		0x8
+
 	__u64 value;
 };
 
+/*
+ * i915_context_engines_load_balance:
+ *
+ * Enable load balancing across this set of engines.
+ *
+ * Into the I915_EXEC_DEFAULT slot, a virtual engine is created that when
+ * used will proxy the execbuffer request onto one of the set of engines
+ * in such a way as to distribute the load evenly across the set.
+ *
+ * The set of engines must be compatible (e.g. the same HW class) as they
+ * will share the same logical GPU context and ring.
+ *
+ * The context must be defined to use a single timeline for all engines.
+ */
+struct i915_context_engines_load_balance {
+	struct i915_user_extension base;
+
+	__u64 flags; /* all undefined flags must be zero */
+	__u64 engines_mask;
+
+	__u64 mbz[4]; /* reserved for future use; must be zero */
+};
+
+/*
+ * i915_context_engines_bond:
+ *
+ */
+struct i915_context_engines_bond {
+	struct i915_user_extension base;
+
+	__u16 master_class;
+	__u16 master_instance;
+	__u32 flags; /* all undefined flags must be zero */
+	__u64 sibling_mask;
+};
+
+struct i915_context_param_engines {
+	__u64 extensions;
+#define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0
+#define I915_CONTEXT_ENGINES_EXT_BOND 1
+
+	struct {
+		__u16 class; /* see enum drm_i915_gem_engine_class */
+		__u16 instance;
+	} class_instance[0];
+};
+
+struct drm_i915_gem_context_param_sseu {
+	/*
+	 * Engine class & instance to be configured or queried.
+	 */
+	__u16 class;
+	__u16 instance;
+
+	/*
+	 * Unused for now. Must be cleared to zero.
+	 */
+	__u32 rsvd1;
+
+	/*
+	 * Mask of slices to enable for the context. Valid values are a subset
+	 * of the bitmask value returned for I915_PARAM_SLICE_MASK.
+	 */
+	__u64 slice_mask;
+
+	/*
+	 * Mask of subslices to enable for the context. Valid values are a
+	 * subset of the bitmask value return by I915_PARAM_SUBSLICE_MASK.
+	 */
+	__u64 subslice_mask;
+
+	/*
+	 * Minimum/Maximum number of EUs to enable per subslice for the
+	 * context. min_eus_per_subslice must be inferior or equal to
+	 * max_eus_per_subslice.
+	 */
+	__u16 min_eus_per_subslice;
+	__u16 max_eus_per_subslice;
+
+	/*
+	 * Unused for now. Must be cleared to zero.
+	 */
+	__u32 rsvd2;
+};
+
 enum drm_i915_oa_format {
 	I915_OA_FORMAT_A13 = 1,	    /* HSW only */
 	I915_OA_FORMAT_A29,	    /* HSW only */
@@ -1620,6 +1810,7 @@ struct drm_i915_perf_oa_config {
 struct drm_i915_query_item {
 	__u64 query_id;
 #define DRM_I915_QUERY_TOPOLOGY_INFO    1
+#define DRM_I915_QUERY_ENGINE_INFO	2
 
 	/*
 	 * When set to zero by userspace, this is filled with the size of the
@@ -1717,6 +1908,50 @@ struct drm_i915_query_topology_info {
 	__u8 data[];
 };
 
+/**
+ * struct drm_i915_engine_info
+ *
+ * Describes one engine and it's capabilities as known to the driver.
+ */
+struct drm_i915_engine_info {
+	/** Engine class as in enum drm_i915_gem_engine_class. */
+	__u16 class;
+
+	/** Engine instance number. */
+	__u16 instance;
+
+	/** Reserved field. */
+	__u32 rsvd0;
+
+	/** Engine flags. */
+	__u64 flags;
+
+	/** Capabilities of this engine. */
+	__u64 capabilities;
+#define I915_VIDEO_CLASS_CAPABILITY_HEVC		(1 << 0)
+#define I915_VIDEO_AND_ENHANCE_CLASS_CAPABILITY_SFC	(1 << 1)
+
+	/** Reserved fields. */
+	__u64 rsvd1[4];
+};
+
+/**
+ * struct drm_i915_query_engine_info
+ *
+ * Engine info query enumerates all engines known to the driver by filling in
+ * an array of struct drm_i915_engine_info structures.
+ */
+struct drm_i915_query_engine_info {
+	/** Number of struct drm_i915_engine_info structs following. */
+	__u32 num_engines;
+
+	/** MBZ */
+	__u32 rsvd[3];
+
+	/** Marker for drm_i915_engine_info structures. */
+	struct drm_i915_engine_info engines[];
+};
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.19.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface

[Andi Shyti]

Kernel commits:

[1] ae8f4544dd8f ("drm/i915: Engine discovery query")
[2] 31e7d35667a0 ("drm/i915: Allow a context to define its set of engines")

from [*] repository, implement a new way uapi for engine
discovery that consist in first coupling context with engine [2]
and then query the engines through a specific structure [1].

In igt the classic way for discovering engines is done trhough
the for_each_physical_engine() macro, that would be replaced by
the new for_each_engine_ctx().

[*] git://people.freedesktop.org/~tursulin/drm-intel

Signed-off-by: Andi Shyti <andi.shyti@intel.com>
---
 lib/igt_gt.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/igt_gt.h |  8 +++++
 2 files changed, 91 insertions(+)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index a2061924..4a7b8671 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -650,3 +650,86 @@ bool gem_ring_has_physical_engine(int fd, unsigned ring)
 
 	return gem_has_ring(fd, ring);
 }
+
+static struct drm_i915_query_engine_info *__query_engines(int fd)
+{
+	struct drm_i915_query query;
+	struct drm_i915_query_item item;
+	struct drm_i915_query_engine_info *query_engines;
+	ssize_t size = sizeof(*query_engines) + 10 * sizeof(*query_engines->engines);
+	int err;
+
+	query_engines = malloc(size);
+	if (!query_engines)
+		return NULL;
+
+	memset(&query, 0, sizeof(query));
+	memset(&item, 0, sizeof(item));
+	memset(query_engines, 0, sizeof(*query_engines));
+
+	item.query_id = DRM_I915_QUERY_ENGINE_INFO;
+	item.length = size;
+	item.flags = 0;
+	item.data_ptr = to_user_pointer(query_engines);
+
+	query.items_ptr = to_user_pointer(&item);
+	query.num_items = 1;
+
+	err = igt_ioctl(fd, DRM_IOCTL_I915_QUERY, &query);
+	if (err) {
+		free(query_engines);
+		return NULL;
+	}
+
+	return query_engines;
+}
+
+static int __set_param(int fd, unsigned ctx_id,
+		struct drm_i915_query_engine_info *query_engine)
+{
+	int i, ret;
+	struct drm_i915_gem_context_param ctx_param;
+	struct i915_context_param_engines *ctx_engine;
+	size_t size = sizeof(struct i915_context_param_engines) +
+		      query_engine->num_engines *
+		      sizeof(*ctx_engine->class_instance);
+
+	ctx_engine = malloc(size);
+	if (!ctx_engine)
+		return errno;
+
+	ctx_engine->extensions = 0;
+	for (i = 0; i < query_engine->num_engines; i++) {
+		ctx_engine->class_instance[i].class = query_engine->engines[i].class;
+		ctx_engine->class_instance[i].instance = query_engine->engines[i].instance;
+	}
+
+	ctx_param.ctx_id = ctx_id;
+	ctx_param.size = size;
+	ctx_param.param = I915_CONTEXT_PARAM_ENGINES;
+	ctx_param.value = to_user_pointer(ctx_engine);
+
+	ret = igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &ctx_param);
+	free(ctx_engine);
+
+	return ret;
+}
+
+int get_engines(int fd, uint32_t ctx_id)
+{
+	struct drm_i915_query_engine_info *query_engine;
+	int n;
+
+	query_engine = __query_engines(fd);
+	if (!query_engine)
+		return -1;
+
+	n = __set_param(fd, ctx_id, query_engine);
+	if (n < 0)
+		return n;
+
+	n = query_engine->num_engines;
+	free(query_engine);
+
+	return n;
+}
diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index 54e95da9..7e299c31 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -86,8 +86,16 @@ extern const struct intel_execution_engine {
 	     e__++) \
 		for_if (gem_ring_has_physical_engine(fd__, flags__ = e__->exec_id | e__->flags))
 
+#define for_each_engine_ctx(fd, ctx, e) \
+		for (int __m, __e = 1; (__m = get_engines(fd, ctx)); ) \
+			if (__e > __m) \
+				break; \
+			else \
+				for(e = __e ; __e <= __m; e = ++__e)
+
 bool gem_ring_is_physical_engine(int fd, unsigned int ring);
 bool gem_ring_has_physical_engine(int fd, unsigned int ring);
+int get_engines(int fd, uint32_t ctx_id);
 
 bool gem_can_store_dword(int fd, unsigned int engine);
 
-- 
2.19.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface

[Tvrtko Ursulin]

On 21/11/2018 16:10, Andi Shyti wrote:
> Kernel commits:
> 
> [1] ae8f4544dd8f ("drm/i915: Engine discovery query")
> [2] 31e7d35667a0 ("drm/i915: Allow a context to define its set of engines")
> 
> from [*] repository, implement a new way uapi for engine
> discovery that consist in first coupling context with engine [2]
> and then query the engines through a specific structure [1].
> 
> In igt the classic way for discovering engines is done trhough

typo in through

> the for_each_physical_engine() macro, that would be replaced by
> the new for_each_engine_ctx().
> 
> [*] git://people.freedesktop.org/~tursulin/drm-intel
> 
> Signed-off-by: Andi Shyti <andi.shyti@intel.com>
> ---
>   lib/igt_gt.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>   lib/igt_gt.h |  8 +++++
>   2 files changed, 91 insertions(+)
> 
> diff --git a/lib/igt_gt.c b/lib/igt_gt.c
> index a2061924..4a7b8671 100644
> --- a/lib/igt_gt.c
> +++ b/lib/igt_gt.c
> @@ -650,3 +650,86 @@ bool gem_ring_has_physical_engine(int fd, unsigned ring)
>   
>   	return gem_has_ring(fd, ring);
>   }
> +
> +static struct drm_i915_query_engine_info *__query_engines(int fd)
> +{
> +	struct drm_i915_query query;
> +	struct drm_i915_query_item item;
> +	struct drm_i915_query_engine_info *query_engines;
> +	ssize_t size = sizeof(*query_engines) + 10 * sizeof(*query_engines->engines);

You'll have to change this in the final version to dynamically probe the 
amount of space needed.

If you send one DRM_IOCTL_I915_QUERY with the length set to zero it will 
return you the amount of space required to return everything.

> +	int err;
> +
> +	query_engines = malloc(size);
> +	if (!query_engines)
> +		return NULL;

We probably want to igt_assert on this since there is no point going 
further.

> +
> +	memset(&query, 0, sizeof(query));
> +	memset(&item, 0, sizeof(item));

For these two you can save some lines by adding a static initializer "= 
{ };" to the declaration, but do as you prefer.

> +	memset(query_engines, 0, sizeof(*query_engines));
> +
> +	item.query_id = DRM_I915_QUERY_ENGINE_INFO;
> +	item.length = size;
> +	item.flags = 0;

Can skip since it is already zero.

> +	item.data_ptr = to_user_pointer(query_engines);
> +
> +	query.items_ptr = to_user_pointer(&item);
> +	query.num_items = 1;
> +
> +	err = igt_ioctl(fd, DRM_IOCTL_I915_QUERY, &query);

I am not sure about this one, but am thinking that here we should 
probably use ioctl(3) directly. I don't think we need the auto-retry on 
EINTR and EAGAIN for this one.

> +	if (err) {

Should we perhaps igt_require ioctl works? So new IGT skips on old kernels.

> +		free(query_engines);
> +		return NUL > +	}
> +
> +	return query_engines;
> +}
> +
> +static int __set_param(int fd, unsigned ctx_id,

Use uint32_t for ctx_id for consistency.

> +		struct drm_i915_query_engine_info *query_engine)
> +{
> +	int i, ret;
> +	struct drm_i915_gem_context_param ctx_param;
> +	struct i915_context_param_engines *ctx_engine;
> +	size_t size = sizeof(struct i915_context_param_engines) +
> +		      query_engine->num_engines *
> +		      sizeof(*ctx_engine->class_instance);
> +
> +	ctx_engine = malloc(size);
> +	if (!ctx_engine)
> +		return errno;

Again probably better to just assert.

> +
> +	ctx_engine->extensions = 0;
> +	for (i = 0; i < query_engine->num_engines; i++) {
> +		ctx_engine->class_instance[i].class = query_engine->engines[i].class;
> +		ctx_engine->class_instance[i].instance = query_engine->engines[i].instance;
> +	}
> +
> +	ctx_param.ctx_id = ctx_id;
> +	ctx_param.size = size;
> +	ctx_param.param = I915_CONTEXT_PARAM_ENGINES;
> +	ctx_param.value = to_user_pointer(ctx_engine);
> +
> +	ret = igt_ioctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_SETPARAM, &ctx_param);

Same idea that we should perhaps skip here as with the query.

> +	free(ctx_engine);
> +
> +	return ret;
> +}
> +
> +int get_engines(int fd, uint32_t ctx_id)

setup_ctx_engines?

Does it need to be exported or it can be static?

> +{
> +	struct drm_i915_query_engine_info *query_engine;
> +	int n;
> +
> +	query_engine = __query_engines(fd);
> +	if (!query_engine)
> +		return -1;
> +
> +	n = __set_param(fd, ctx_id, query_engine);
> +	if (n < 0)
> +		return n;
> +
> +	n = query_engine->num_engines;
> +	free(query_engine);
> +
> +	return n;
> +}
> diff --git a/lib/igt_gt.h b/lib/igt_gt.h
> index 54e95da9..7e299c31 100644
> --- a/lib/igt_gt.h
> +++ b/lib/igt_gt.h
> @@ -86,8 +86,16 @@ extern const struct intel_execution_engine {
>   	     e__++) \
>   		for_if (gem_ring_has_physical_engine(fd__, flags__ = e__->exec_id | e__->flags))
>   
> +#define for_each_engine_ctx(fd, ctx, e) \

High level design question: Do we want 'e' to be an integer or a struct 
describing each engine?

> +		for (int __m, __e = 1; (__m = get_engines(fd, ctx)); ) \
> +			if (__e > __m) \
> +				break; \
> +			else \
> +				for(e = __e ; __e <= __m; e = ++__e)

I am struggling to figure this out, but it is probably just me. Can it 
cause some compiler warnings for misleading braces, indent or whatever 
the things are it could warn here?

Would something simpler not work?

#define for_each_engine_ctx(fd, ctx, e) \
    for (int __e = 0, __m = get_engines(fd, ctx);
	(e) = __e, __e < __m;
	__e++)

I am probably missing something elementary...


> +
>   bool gem_ring_is_physical_engine(int fd, unsigned int ring);
>   bool gem_ring_has_physical_engine(int fd, unsigned int ring);
> +int get_engines(int fd, uint32_t ctx_id);
>   
>   bool gem_can_store_dword(int fd, unsigned int engine);
>   
> 

Regards,

Tvrtko
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface

[Andi Shyti]

Hi Tvrtko,

> > +		for (int __m, __e = 1; (__m = get_engines(fd, ctx)); ) \
> > +			if (__e > __m) \
> > +				break; \
> > +			else \
> > +				for(e = __e ; __e <= __m; e = ++__e)
> 
> I am struggling to figure this out, but it is probably just me. Can it cause
> some compiler warnings for misleading braces, indent or whatever the things
> are it could warn here?
> 
> Would something simpler not work?
> 
> #define for_each_engine_ctx(fd, ctx, e) \
>    for (int __e = 0, __m = get_engines(fd, ctx);
> 	(e) = __e, __e < __m;
> 	__e++)
> 
> I am probably missing something elementary...

It doesn't complain, but I already simplified this macro.
I just used Chris's way just for the RFC (also because it ends up
calling calling get_engines() twice).

I agree with all your comments from this and the other RFC. I
will post directly the patch next, with few more improvements.

Important for me was not to go off track with this.

Thanks a lot, Tvrtko,
Andi
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface

[Andi Shyti]

Hi Tvrtko,

just few things that came to my mind while going through your
review.

> > +	query_engines = malloc(size);
> > +	if (!query_engines)
> > +		return NULL;
> 
> We probably want to igt_assert on this since there is no point going
> further.

isn't igt_assert used for the test outcome? What I mean is that
the test outcome would be to query and set the engines, but if we
fail in malloc we do not necessarily fail the test, but we have a
different kind of system failure.

(this is not important, just for me to understand better :) )

> > +int get_engines(int fd, uint32_t ctx_id)
> 
> setup_ctx_engines?
> 
> Does it need to be exported or it can be static?

How do we reach it from outside if we set it static? This
function is called in the for_each_engine_ctx macro that is used
outside from igt_gt.c

> > +#define for_each_engine_ctx(fd, ctx, e) \
> 
> High level design question: Do we want 'e' to be an integer or a struct
> describing each engine?

Do you mean that you would you prefer iterating with a
'i915_context_param_engines' or a 'intel_execution_engine' struct
instead of an 'e' integer? This way it would also be different
from how the current 'for_each_engine' works.

I could do it in a next patch, so that in this one we keep it as
close as possible to the current way of doing things.

Andi
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [RFC v2 2/3] lib: implement new engine discovery interface

[Tvrtko Ursulin]

On 26/11/2018 09:07, Andi Shyti wrote:
> Hi Tvrtko,
> 
> just few things that came to my mind while going through your
> review.
> 
>>> +	query_engines = malloc(size);
>>> +	if (!query_engines)
>>> +		return NULL;
>>
>> We probably want to igt_assert on this since there is no point going
>> further.
> 
> isn't igt_assert used for the test outcome? What I mean is that
> the test outcome would be to query and set the engines, but if we
> fail in malloc we do not necessarily fail the test, but we have a
> different kind of system failure.
> 
> (this is not important, just for me to understand better :) )

We use it for both since we haven't agreed on any mechanism to 
differentiate. I think it was mentioned a few times but I don't remember 
what were the different opinions.

>>> +int get_engines(int fd, uint32_t ctx_id)
>>
>> setup_ctx_engines?
>>
>> Does it need to be exported or it can be static?
> 
> How do we reach it from outside if we set it static? This
> function is called in the for_each_engine_ctx macro that is used
> outside from igt_gt.c

Of course! But then it needs a gem prefix and probably double underscore 
to signify it shouldn't be called directly.

>>> +#define for_each_engine_ctx(fd, ctx, e) \
>>
>> High level design question: Do we want 'e' to be an integer or a struct
>> describing each engine?
> 
> Do you mean that you would you prefer iterating with a
> 'i915_context_param_engines' or a 'intel_execution_engine' struct
> instead of an 'e' integer? This way it would also be different
> from how the current 'for_each_engine' works.
> 
> I could do it in a next patch, so that in this one we keep it as
> close as possible to the current way of doing things.

I forgot in current code struct intel_execution_engine is a hidden 
variable in the iterator, unlike the i915 version.

I think struct intel_execution_engine available during iteration is 
preferable (we often need easy access to engine name, class/instance and 
such), but I don't have an opinion on whether it should be explicit or 
still hidden variable. Staying with hidden makes the churn smaller. 
Maybe Chris has an opinion.

Regards,

Tvrtko
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] [RFC v2 3/3] tests: gem_gem_query_engines_demo: create test

[Andi Shyti]

The "gem_query_engines_demo" is a demo test used to show how to
use the new API in commit 65d2f30d ("lib: implement new engine
discovery interface").

The new API has uses two new ioctls to interrogate the driver
about the engines.

The test simply gets the engines and executes a buffer.

Signed-off-by: Andi Shyti <andi.shyti@intel.com>
---
 tests/Makefile.sources              |  3 ++
 tests/i915/gem_query_engines_demo.c | 56 +++++++++++++++++++++++++++++
 tests/meson.build                   |  1 +
 3 files changed, 60 insertions(+)
 create mode 100644 tests/i915/gem_query_engines_demo.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 5620c1d6..e91d15f2 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -494,6 +494,9 @@ i915_selftest_SOURCES = i915/selftest.c
 TESTS_progs += i915_suspend
 i915_suspend_SOURCES = i915/suspend.c
 
+TESTS_progs += gem_query_engines_demo
+discover_engines_SOURCES = i915/gem_query_engines_demo.c
+
 TESTS_progs_X = gem_concurrent_all
 gem_concurrent_all_SOURCES = i915/gem_concurrent_all.c
 
diff --git a/tests/i915/gem_query_engines_demo.c b/tests/i915/gem_query_engines_demo.c
new file mode 100644
index 00000000..dc6b031e
--- /dev/null
+++ b/tests/i915/gem_query_engines_demo.c
@@ -0,0 +1,56 @@
+#include "igt.h"
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+#include <fcntl.h>
+#include <inttypes.h>
+#include <errno.h>
+#include <sys/stat.h>
+#include <sys/ioctl.h>
+#include <sys/time.h>
+#include <time.h>
+#include "drm.h"
+
+static void execbuf_in_ctx(int fd, uint32_t engine, uint32_t ctx, uint32_t handle)
+{
+	struct drm_i915_gem_exec_object2 exec = {
+		.handle = handle,
+	};
+	struct drm_i915_gem_execbuffer2 execbuf = {
+		.buffers_ptr = to_user_pointer(&exec),
+		.buffer_count = 1,
+		.flags = engine,
+		.rsvd1 = ctx & I915_EXEC_CONTEXT_ID_MASK,
+	};
+
+	gem_execbuf(fd, &execbuf);
+}
+
+igt_main
+{
+	int fd;
+	uint32_t ctx_id, e;
+	uint32_t handle;
+	uint32_t bbend = MI_BATCH_BUFFER_END;
+
+	igt_fixture {
+		fd = drm_open_driver(DRIVER_INTEL);
+		ctx_id = gem_context_create(fd);
+
+		handle = gem_create(fd, 4096);
+		gem_write(fd, handle, 0, &bbend, sizeof(bbend));
+	}
+
+	igt_subtest("basic") {
+		for_each_engine_ctx(fd, ctx_id, e)
+			execbuf_in_ctx(fd, e, ctx_id, handle);
+	}
+
+	igt_fixture {
+		gem_close(fd, handle);
+		gem_context_destroy(fd, ctx_id);
+		close(fd);
+	}
+}
diff --git a/tests/meson.build b/tests/meson.build
index 52f91a22..0c091cf3 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -217,6 +217,7 @@ gem_progs = [
 	'gem_wait',
 	'gem_workarounds',
 	'gem_write_read_ring_switch',
+	'gem_query_engines_demo',
 ]
 
 gen3_progs = [
-- 
2.19.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [RFC v2 3/3] tests: gem_gem_query_engines_demo: create test

[Tvrtko Ursulin]

On 21/11/2018 16:10, Andi Shyti wrote:
> The "gem_query_engines_demo" is a demo test used to show how to
> use the new API in commit 65d2f30d ("lib: implement new engine
> discovery interface").
> 
> The new API has uses two new ioctls to interrogate the driver
> about the engines.
> 
> The test simply gets the engines and executes a buffer.
> 
> Signed-off-by: Andi Shyti <andi.shyti@intel.com>
> ---
>   tests/Makefile.sources              |  3 ++
>   tests/i915/gem_query_engines_demo.c | 56 +++++++++++++++++++++++++++++
>   tests/meson.build                   |  1 +
>   3 files changed, 60 insertions(+)
>   create mode 100644 tests/i915/gem_query_engines_demo.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 5620c1d6..e91d15f2 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -494,6 +494,9 @@ i915_selftest_SOURCES = i915/selftest.c
>   TESTS_progs += i915_suspend
>   i915_suspend_SOURCES = i915/suspend.c
>   
> +TESTS_progs += gem_query_engines_demo
> +discover_engines_SOURCES = i915/gem_query_engines_demo.c
> +
>   TESTS_progs_X = gem_concurrent_all
>   gem_concurrent_all_SOURCES = i915/gem_concurrent_all.c
>   
> diff --git a/tests/i915/gem_query_engines_demo.c b/tests/i915/gem_query_engines_demo.c
> new file mode 100644
> index 00000000..dc6b031e
> --- /dev/null
> +++ b/tests/i915/gem_query_engines_demo.c
> @@ -0,0 +1,56 @@
> +#include "igt.h"
> +#include <unistd.h>
> +#include <stdlib.h>
> +#include <stdint.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <fcntl.h>
> +#include <inttypes.h>
> +#include <errno.h>
> +#include <sys/stat.h>
> +#include <sys/ioctl.h>
> +#include <sys/time.h>
> +#include <time.h>
> +#include "drm.h"

Feels like to many includes, evidence of copy & paste? :) And license 
header needs to be added.

> +
> +static void execbuf_in_ctx(int fd, uint32_t engine, uint32_t ctx, uint32_t handle)

I think plain unsigned int for engine.

> +{
> +	struct drm_i915_gem_exec_object2 exec = {
> +		.handle = handle,
> +	};
> +	struct drm_i915_gem_execbuffer2 execbuf = {
> +		.buffers_ptr = to_user_pointer(&exec),
> +		.buffer_count = 1,
> +		.flags = engine,
> +		.rsvd1 = ctx & I915_EXEC_CONTEXT_ID_MASK,
> +	};

Maybe add igt_assert(!(engine & I915_EXEC_RING_MASK)).

> +
> +	gem_execbuf(fd, &execbuf);
> +}
> +
> +igt_main
> +{
> +	int fd;
> +	uint32_t ctx_id, e;
> +	uint32_t handle;
> +	uint32_t bbend = MI_BATCH_BUFFER_END;
> +
> +	igt_fixture {
> +		fd = drm_open_driver(DRIVER_INTEL);
> +		ctx_id = gem_context_create(fd);
> +
> +		handle = gem_create(fd, 4096);
> +		gem_write(fd, handle, 0, &bbend, sizeof(bbend));
> +	}
> +
> +	igt_subtest("basic") {
> +		for_each_engine_ctx(fd, ctx_id, e)
> +			execbuf_in_ctx(fd, e, ctx_id, handle);
> +	}
> +
> +	igt_fixture {
> +		gem_close(fd, handle);
> +		gem_context_destroy(fd, ctx_id);
> +		close(fd);
> +	}
> +}
> diff --git a/tests/meson.build b/tests/meson.build
> index 52f91a22..0c091cf3 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -217,6 +217,7 @@ gem_progs = [
>   	'gem_wait',
>   	'gem_workarounds',
>   	'gem_write_read_ring_switch',
> +	'gem_query_engines_demo',
>   ]
>   
>   gen3_progs = [
> 

I'd be tempted to move this whole new test into gem_exec_basic. Either 
to replace the current loop or add new noop based subtests. I suspect 
Chris will have a stronger opinion on which option of the two.

Regards,

Tvrtko
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for new engine discovery interface (rev2)

[Patchwork]

== Series Details ==

Series: new engine discovery interface (rev2)
URL   : https://patchwork.freedesktop.org/series/52699/
State : success

== Summary ==

= CI Bug Log - changes from IGT_4724 -> IGTPW_2084 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/52699/revisions/2/mbox/

== Known issues ==

  Here are the changes found in IGTPW_2084 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
      fi-byt-clapper:     PASS -> FAIL (fdo#107362, fdo#103191)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
      fi-blb-e6850:       PASS -> INCOMPLETE (fdo#107718)

    
    ==== Possible fixes ====

    igt@i915_selftest@live_coherency:
      fi-gdg-551:         DMESG-FAIL (fdo#107164) -> PASS

    
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
  fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
  fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718


== Participating hosts (51 -> 43) ==

  Missing    (8): fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u3 fi-icl-y 


== Build changes ==

    * IGT: IGT_4724 -> IGTPW_2084

  CI_DRM_5180: 95de9a943571204eda4dc3156c3d984ba07c78e4 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2084: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2084/
  IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@gem_query_engines_demo@basic

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2084/issues.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for new engine discovery interface (rev2)

[Patchwork]

== Series Details ==

Series: new engine discovery interface (rev2)
URL   : https://patchwork.freedesktop.org/series/52699/
State : success

== Summary ==

= CI Bug Log - changes from IGT_4724_full -> IGTPW_2084_full =

== Summary - WARNING ==

  Minor unknown changes coming with IGTPW_2084_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_2084_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/52699/revisions/2/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in IGTPW_2084_full:

  === IGT changes ===

    ==== Warnings ====

    igt@pm_rc6_residency@rc6-accuracy:
      shard-snb:          PASS -> SKIP

    
== Known issues ==

  Here are the changes found in IGTPW_2084_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_exec_params@invalid-fence-in:
      shard-apl:          PASS -> INCOMPLETE (fdo#103927)

    igt@gem_softpin@noreloc-s3:
      shard-kbl:          PASS -> INCOMPLETE (fdo#103665) +1

    igt@kms_available_modes_crc@available_mode_test_crc:
      shard-apl:          PASS -> FAIL (fdo#106641)

    igt@kms_busy@extended-modeset-hang-newfb-render-b:
      shard-kbl:          NOTRUN -> DMESG-WARN (fdo#107956)

    igt@kms_busy@extended-pageflip-hang-newfb-render-c:
      shard-glk:          NOTRUN -> DMESG-WARN (fdo#107956)

    igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
      shard-snb:          NOTRUN -> DMESG-WARN (fdo#107956)

    igt@kms_color@pipe-b-degamma:
      shard-apl:          PASS -> FAIL (fdo#104782)

    igt@kms_cursor_crc@cursor-256x85-sliding:
      shard-kbl:          PASS -> FAIL (fdo#103232)
      shard-glk:          PASS -> FAIL (fdo#103232) +1

    igt@kms_cursor_crc@cursor-64x21-onscreen:
      shard-glk:          NOTRUN -> FAIL (fdo#103232) +1

    igt@kms_cursor_crc@cursor-64x64-dpms:
      shard-apl:          PASS -> FAIL (fdo#103232) +4

    igt@kms_cursor_crc@cursor-64x64-suspend:
      shard-apl:          PASS -> FAIL (fdo#103191, fdo#103232)

    igt@kms_draw_crc@draw-method-rgb565-blt-ytiled:
      shard-glk:          PASS -> FAIL (fdo#103184)

    igt@kms_flip@flip-vs-expired-vblank:
      shard-glk:          PASS -> FAIL (fdo#105363)

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
      shard-glk:          NOTRUN -> FAIL (fdo#103167)

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-move:
      shard-kbl:          PASS -> FAIL (fdo#103167)

    igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-cpu:
      shard-glk:          PASS -> FAIL (fdo#103167) +4

    igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-mmap-gtt:
      shard-glk:          PASS -> DMESG-FAIL (fdo#105763, fdo#103167, fdo#106538)

    igt@kms_plane@plane-position-covered-pipe-a-planes:
      shard-glk:          PASS -> FAIL (fdo#103166) +3

    igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
      shard-apl:          PASS -> FAIL (fdo#103166) +1

    igt@kms_setmode@basic:
      shard-apl:          PASS -> FAIL (fdo#99912)
      shard-kbl:          PASS -> FAIL (fdo#99912)

    igt@kms_sysfs_edid_timing:
      shard-kbl:          NOTRUN -> FAIL (fdo#100047)

    igt@perf_pmu@rc6-runtime-pm:
      shard-glk:          NOTRUN -> FAIL (fdo#105010)
      shard-apl:          PASS -> FAIL (fdo#105010)
      shard-kbl:          PASS -> FAIL (fdo#105010)

    
    ==== Possible fixes ====

    igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
      shard-glk:          FAIL (fdo#108145) -> PASS
      shard-kbl:          FAIL (fdo#108145, fdo#107725) -> PASS

    igt@kms_cursor_crc@cursor-128x128-random:
      shard-apl:          FAIL (fdo#103232) -> PASS +2

    igt@kms_cursor_crc@cursor-128x42-sliding:
      shard-glk:          FAIL (fdo#103232) -> PASS +2

    igt@kms_cursor_crc@cursor-256x256-suspend:
      shard-kbl:          DMESG-WARN -> PASS

    igt@kms_draw_crc@draw-method-rgb565-pwrite-xtiled:
      shard-glk:          FAIL (fdo#103184) -> PASS

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-cpu:
      shard-glk:          FAIL (fdo#103167) -> PASS

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-pwrite:
      shard-apl:          FAIL (fdo#103167) -> PASS +2

    igt@kms_plane@pixel-format-pipe-a-planes:
      shard-kbl:          FAIL (fdo#103166) -> PASS

    igt@kms_plane@pixel-format-pipe-b-planes:
      shard-glk:          FAIL (fdo#103166) -> PASS +1

    igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
      shard-glk:          INCOMPLETE (fdo#103359, k.org#198133) -> PASS

    igt@kms_plane@plane-position-covered-pipe-c-planes:
      shard-apl:          FAIL (fdo#103166) -> PASS +4

    
  fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104782 https://bugs.freedesktop.org/show_bug.cgi?id=104782
  fdo#105010 https://bugs.freedesktop.org/show_bug.cgi?id=105010
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
  fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
  fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641
  fdo#107725 https://bugs.freedesktop.org/show_bug.cgi?id=107725
  fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956
  fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
  k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133


== Participating hosts (7 -> 5) ==

  Missing    (2): shard-skl shard-iclb 


== Build changes ==

    * IGT: IGT_4724 -> IGTPW_2084

  CI_DRM_5180: 95de9a943571204eda4dc3156c3d984ba07c78e4 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_2084: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2084/
  IGT_4724: 29ae0925abe1d3a0202059538559468ad947d42d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_2084/shards.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev