Skip to contentSkip to conversation

new engine discovery interface

RFC Superseded Andi Shyti 4 participants 11 messages Nov 21, 2018 – Nov 26, 2018

Subsystems (2)

v2 of 24 Superseded Latest is v24 →

lore
Share & tools
lore

Andi Shyti

author
#0 lore raw

v2 cover new engine discovery interface

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
Signature · 6 lines
2.19.1

_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
author
#1 lore raw

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

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.

---
 include/drm-uapi/i915_drm.h | 239 +++++++++++++++++++++++++++++++++++-
 1 file changed, 237 insertions(+), 2 deletions(-)
include/drm-uapi/i915_drm.h +237 -2
index 16e452aa..b14ca969 100644
@@ -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
Signature · 6 lines
2.19.1

_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
author
#2 lore raw

RFC v2 2/3 lib: implement new engine discovery interface

In reply to 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

---
 lib/igt_gt.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/igt_gt.h |  8 +++++
 2 files changed, 91 insertions(+)
lib/igt_gt.c +83 -0
index a2061924..4a7b8671 100644
@@ -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;
+}
lib/igt_gt.h +8 -0
index 54e95da9..7e299c31 100644
@@ -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);
 
Signature · 6 lines
2.19.1

_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
#3 lore raw

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

Quoted 10 lines · 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

typo in through

Quoted 16 lines

the for_each_physical_engine() macro, that would be replaced by the new for_each_engine_ctx().

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

---
  lib/igt_gt.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++++
  lib/igt_gt.h |  8 +++++
  2 files changed, 91 insertions(+)
lib/igt_gt.c +0 -0
index a2061924..4a7b8671 100644

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 659

Quoted 10 lines
lib/igt_gt.c +7 -0
@@ -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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 664

Quoted 5 lines
lib/igt_gt.c +5 -0
+	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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 667

Quoted 3 lines
lib/igt_gt.c +3 -0
+
+	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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 672

Quoted 5 lines
lib/igt_gt.c +5 -0
+	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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 678

Quoted 6 lines
lib/igt_gt.c +6 -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);

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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 679

Quoted 1 line
lib/igt_gt.c +1 -0
+	if (err) {

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

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 687

Quoted 7 lines
lib/igt_gt.c +7 -0
+		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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 699

Quoted 12 lines
lib/igt_gt.c +12 -0
+		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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 712

Quoted 13 lines
lib/igt_gt.c +13 -0
+
+	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.

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 718

Quoted 6 lines
lib/igt_gt.c +6 -0
+	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?

Quoted 22 lines
lib/igt_gt.c +17 -0
+{
+	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;
+}
lib/igt_gt.h +0 -0
index 54e95da9..7e299c31 100644

lib/igt_gt.h extern const struct intel_execution_engine { · line 89

Quoted 4 lines
lib/igt_gt.h +1 -0
@@ -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?

lib/igt_gt.h extern const struct intel_execution_engine { · line 94

Quoted 5 lines
lib/igt_gt.h +5 -0
+		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...

lib/igt_gt.h extern const struct intel_execution_engine { · line 101

Quoted 8 lines
lib/igt_gt.h +2 -0
+
  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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev

author
#4 lore raw

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

Hi Tvrtko,

Quoted 10 lines

lib/igt_gt.h extern const struct intel_execution_engine { · line 94

Quoted 5 lines
lib/igt_gt.h +5 -0
+		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?

Quoted 8 lines

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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev

#5 lore raw

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

In reply to Tvrtko Ursulin

Hi Tvrtko,

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

Quoted 6 lines

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 664

Quoted 3 lines
lib/igt_gt.c +3 -0
+	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 :) )

Quoted 5 lines
Quoted 1 line

+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

Quoted 4 lines
Quoted 1 line

+#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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev

#6 lore raw

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

Quoted 12 lines · Andi Shyti

Hi Tvrtko,

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

Quoted 6 lines

lib/igt_gt.c bool gem_ring_has_physical_engine(int fd, unsigned ring) · line 664

Quoted 3 lines
lib/igt_gt.c +3 -0
+	query_engines = malloc(size);
+	if (!query_engines)
+		return NULL;

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

Quoted 6 lines

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.

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

+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.

Quoted 5 lines
Quoted 4 lines
Quoted 1 line

+#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?

Quoted 7 lines

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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev

author
#7 lore raw

RFC v2 3/3 tests: gem_gem_query_engines_demo: create test

In reply to 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.

---
 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
tests/Makefile.sources +3 -0
index 5620c1d6..e91d15f2 100644
@@ -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
 
tests/i915/gem_query_engines_demo.c new file +56 -0

56 lines not on this page · raw message

tests/meson.build +1 -0
index 52f91a22..0c091cf3 100644
@@ -217,6 +217,7 @@ gem_progs = [
 	'gem_wait',
 	'gem_workarounds',
 	'gem_write_read_ring_switch',
+	'gem_query_engines_demo',
 ]
 
 gen3_progs = [
Signature · 6 lines
2.19.1

_______________________________________________
igt-dev mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev
#8 lore raw

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

Quoted 41 lines · 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.

---
  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

tests/Makefile.sources +3 -0
index 5620c1d6..e91d15f2 100644
@@ -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
 
tests/i915/gem_query_engines_demo.c new file +4 -0
new file mode 100644
index 00000000..dc6b031e
@@ -0,0 +1,56 @@
+#include "igt.h"
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdint.h>

tests/i915/gem_query_engines_demo.c line 14

Quoted 10 lines
tests/i915/gem_query_engines_demo.c new file +10 -0
+#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.

tests/i915/gem_query_engines_demo.c line 16

Quoted 2 lines
tests/i915/gem_query_engines_demo.c new file +2 -0
+
+static void execbuf_in_ctx(int fd, uint32_t engine, uint32_t ctx, uint32_t handle)

I think plain unsigned int for engine.

tests/i915/gem_query_engines_demo.c line 26

Quoted 10 lines
tests/i915/gem_query_engines_demo.c new file +10 -0
+{
+	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)).

Quoted 36 lines
tests/i915/gem_query_engines_demo.c new file +30 -0
+
+	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);
+	}
+}
tests/meson.build +0 -0
index 52f91a22..0c091cf3 100644

tests/meson.build gem_progs = [ · line 223

Quoted 7 lines
tests/meson.build +1 -0
@@ -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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev

#9 lore raw

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

In reply to Andi Shyti
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev

#10 lore raw

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

In reply to Andi Shyti
== Series Details ==

== 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
[email protected]
https://lists.freedesktop.org/mailman/listinfo/igt-dev