[igt-dev] [PATCH i-g-t 0/4] Add copy basic test to exercise blt commands

[igt-dev] [PATCH i-g-t 0/4] Add copy basic test to exercise blt commands

[sai.gowtham.ch]

From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>

Add copy basic test which exercies mem-se and mem-copy commands, this
patch series involves in following changes:

1. Add copy basic test to exercise blt commands.
2. check if blt commands are supported by the platforms.
3. Add copy commands to blt_cmd_type.
4. Add copy commands MEM_SET_CMD and MEM_COPY_CMD in the lib.

Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>

Sai Gowtham Ch (4):
  intel/xe_copy_basic: Add copy basic test to exercise blt commands
  lib/intel_blt: check if blt commands are supported by the platforms
  lib/intel_cmds_info: Add copy commands to blt_cmd_type
  lib/intel_reg: Add copy commands in the lib

 lib/intel_blt.c             |  32 ++++
 lib/intel_blt.h             |   2 +
 lib/intel_cmds_info.h       |   2 +
 lib/intel_reg.h             |   4 +
 tests/intel/xe_copy_basic.c | 284 ++++++++++++++++++++++++++++++++++++
 tests/meson.build           |   1 +
 6 files changed, 325 insertions(+)
 create mode 100644 tests/intel/xe_copy_basic.c

-- 
2.39.1

[igt-dev] [PATCH i-g-t 1/4] intel/xe_copy_basic: Add copy basic test to exercise blt commands

[sai.gowtham.ch]

From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>

Add copy basic test to exercise copy commands like mem-copy and mem-set.

Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
---
 tests/intel/xe_copy_basic.c | 284 ++++++++++++++++++++++++++++++++++++
 tests/meson.build           |   1 +
 2 files changed, 285 insertions(+)
 create mode 100644 tests/intel/xe_copy_basic.c

diff --git a/tests/intel/xe_copy_basic.c b/tests/intel/xe_copy_basic.c
new file mode 100644
index 000000000..a9c00ec5a
--- /dev/null
+++ b/tests/intel/xe_copy_basic.c
@@ -0,0 +1,284 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ *
+ * Authors:
+ *	Sai Gowtham Ch <sai.gowtham.ch@intel.com>
+ */
+
+#include "igt.h"
+#include "lib/igt_syncobj.h"
+#include "intel_blt.h"
+#include "lib/intel_cmds_info.h"
+#include "lib/intel_mocs.h"
+#include "lib/intel_reg.h"
+#include "xe/xe_ioctl.h"
+#include "xe/xe_query.h"
+#include "xe/xe_util.h"
+
+/**
+ * TEST: Test to validate copy commands on xe
+ * Category: Software building block
+ * Sub-category: Copy
+ * Functionality: blitter
+ * Test category: functionality test
+ */
+
+#define MEM_COPY_MOCS_SHIFT                     25
+
+static int objcmp(int fd, uint32_t src, uint32_t dst,
+		uint32_t src_size, uint32_t dst_size)
+{
+	uint32_t *buf_src, *buf_dst;
+	int ret = 0;
+
+	buf_src = xe_bo_map(fd, src, src_size);
+	buf_dst = xe_bo_map(fd, dst, dst_size);
+
+	ret = memcmp(buf_src, buf_dst, src_size);
+
+	munmap(buf_src, src_size);
+	munmap(buf_dst, dst_size);
+
+	return ret;
+}
+
+/**
+ * SUBTEST: mem-copy
+ * Description: Test validates MEM_COPY command, it takes various
+ *		parameters needed for the filling batch buffer for MEM_COPY command.
+ * Run type: FULL
+ */
+static void
+igt_mem_copy(int fd, uint32_t src, uint32_t dst, uint32_t size,
+		uint32_t col_size, uint32_t vm, uint32_t exec_queue,
+		uint64_t ahnd)
+{
+	struct drm_xe_sync sync = {
+		.flags = DRM_XE_SYNC_SYNCOBJ | DRM_XE_SYNC_SIGNAL,
+	};
+	struct drm_xe_exec exec = {
+		.num_batch_buffer = 1,
+		.num_syncs = 1,
+		.syncs = to_user_pointer(&sync),
+	};
+
+	uint32_t bb_handle, syncobj;
+	struct {
+		uint32_t batch[12];
+		uint32_t data;
+	} *data;
+
+	uint64_t bb_offset, src_offset, dst_offset;
+	uint64_t alignment;
+	uint8_t src_mocs = intel_get_uc_mocs(fd);
+	uint64_t bb_size = xe_get_default_alignment(fd);
+	uint8_t dst_mocs = src_mocs;
+	int i;
+
+	alignment = xe_get_default_alignment(fd);
+
+	bb_handle = xe_bo_create_flags(fd, 0, bb_size, visible_vram_if_possible(fd, 0));
+	data = xe_bo_map(fd, bb_handle, bb_size);
+
+	src_offset = get_offset(ahnd, src, size, alignment);
+	dst_offset = get_offset(ahnd, dst, size, alignment);
+	bb_offset = get_offset(ahnd, bb_handle, bb_size, alignment);
+
+	i = 0;
+	data->batch[i++] = MEM_COPY_CMD;
+	data->batch[i++] = size - 1;
+	data->batch[i++] = col_size - 1;
+	data->batch[i++] = 0;
+	data->batch[i++] = 0;
+	data->batch[i++] = src_offset;
+	data->batch[i++] = src_offset << 32;
+	data->batch[i++] = dst_offset;
+	data->batch[i++] = dst_offset << 32;
+	data->batch[i++] = src_mocs << MEM_COPY_MOCS_SHIFT | dst_mocs;
+	data->batch[i++] = MI_BATCH_BUFFER_END;
+	data->batch[i++] = MI_NOOP;
+
+	syncobj = syncobj_create(fd, 0);
+	sync.handle = syncobj;
+
+	xe_vm_bind_sync(fd, vm, bb_handle, 0, bb_offset, bb_size);
+
+	exec.exec_queue_id = exec_queue;
+	exec.address = bb_offset;
+	sync.handle = syncobj;
+	igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_XE_EXEC, &exec), 0);
+
+	gem_close(fd, bb_handle);
+	put_ahnd(ahnd);
+	munmap(data, bb_size);
+	syncobj_destroy(fd, syncobj);
+}
+
+/**
+ * SUBTEST: mem-set
+ * Description: Test validates MEM_SET command.
+ * RUN type: FULL
+ */
+static void igt_mem_set(int fd, uint32_t dst, size_t size, uint32_t height,
+			uint32_t fill_data, uint32_t vm, uint32_t exec_queue, uint64_t ahnd)
+{
+	struct drm_xe_sync sync = {
+		.flags = DRM_XE_SYNC_SYNCOBJ | DRM_XE_SYNC_SIGNAL,
+	};
+	struct drm_xe_exec exec = {
+		.num_batch_buffer = 1,
+		.num_syncs = 1,
+		.syncs = to_user_pointer(&sync),
+	};
+	struct {
+		uint32_t batch[12];
+		uint32_t data;
+	} *data;
+
+	uint32_t syncobj;
+	uint64_t dst_offset;
+	uint8_t dst_mocs = intel_get_uc_mocs(fd);
+	int b;
+	uint32_t dword0;
+
+	data = xe_bo_map(fd, dst, size);
+	dst_offset = intel_allocator_alloc_with_strategy(ahnd, dst, size, 0,
+							 ALLOC_STRATEGY_LOW_TO_HIGH);
+
+	dword0 = MEM_SET_CMD;
+	b = 0;
+	data->batch[b++] = dword0;
+	data->batch[b++] = size - 1;
+	data->batch[b++] = height;
+	data->batch[b++] = 0;
+	data->batch[b++] = dst_offset;
+	data->batch[b++] = dst_offset << 32;
+	data->batch[b++] = (fill_data << 24) | dst_mocs;
+	data->batch[b++] = MI_BATCH_BUFFER_END;
+	data->batch[b++] = MI_NOOP;
+
+	igt_assert(b <= ARRAY_SIZE(data->batch));
+
+	syncobj = syncobj_create(fd, 0);
+	sync.handle = syncobj;
+
+	xe_vm_bind_sync(fd, vm, dst, 0, dst_offset, size);
+
+	exec.exec_queue_id = exec_queue;
+	exec.address = dst_offset;
+	sync.handle = syncobj;
+	igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_XE_EXEC, &exec), 0);
+
+	munmap(data, size);
+	put_ahnd(ahnd);
+	syncobj_destroy(fd, syncobj);
+}
+
+static void copy_test(int fd, uint32_t size, enum blt_cmd_type cmd,
+		      struct drm_xe_engine_class_instance *hwe, uint32_t region)
+{
+	uint32_t src_size, dst_size;
+	uint32_t src, dst, vm, exec_queue;
+	char c = 'a';
+	uint32_t bo_size = ALIGN(size + xe_cs_prefetch_size(fd), xe_get_default_alignment(fd));
+	uint32_t temp_buffer[bo_size];
+	uint64_t ahnd;
+
+	src = xe_bo_create_flags(fd, 0, bo_size, region);
+	dst = xe_bo_create_flags(fd, 0, bo_size, region);
+	vm = xe_vm_create(fd, 0, 0);
+
+	exec_queue = xe_exec_queue_create(fd, vm, hwe, 0);
+	ahnd = intel_allocator_open(fd, 0, INTEL_ALLOCATOR_RELOC);
+
+	/* Fill a pattern in the buffer */
+	for (int i = 0; i < bo_size; i++) {
+		temp_buffer[i] = c++ % 16;
+		temp_buffer[i] |= (c++ % 16) << 8;
+		temp_buffer[i] |= (c++ % 16) << 16;
+		temp_buffer[i] |= (c++ % 16) << 24;
+	}
+
+	src_size = bo_size;
+	dst_size = bo_size;
+
+	if (cmd == MEM_COPY) {
+		igt_mem_copy(fd,
+			     src,/*src_handle*/
+			     dst,/*dst_handle*/
+			     bo_size,/*row_size*/
+			     1,/*col_size*/
+			     vm,
+			     exec_queue,
+			     ahnd);
+		igt_assert_eq(objcmp(fd, src, dst, src_size, dst_size), 0);
+	} else if (cmd == MEM_SET) {
+		igt_mem_set(fd,
+			    dst, /*dst_handle*/
+			    bo_size,/*width*/
+			    1,/*height*/
+			    0,/*fill_data*/
+			    vm,
+			    exec_queue,
+			    ahnd);
+		src_size = 1;
+	}
+
+	gem_close(fd, src);
+	gem_close(fd, dst);
+
+	xe_exec_queue_destroy(fd, exec_queue);
+	xe_vm_destroy(fd, vm);
+}
+
+igt_main
+{
+	struct drm_xe_engine_class_instance *hwe;
+	int fd;
+	struct igt_collection *set, *regions;
+	uint32_t region;
+	uint64_t size[] = {0xFD, 0x369, 0x369, 0x3FFF, 0xFFFF, 0x1FFFF, 0x3FFFF};
+
+	igt_fixture {
+		fd = drm_open_driver(DRIVER_XE);
+		xe_device_get(fd);
+		set = xe_get_memory_region_set(fd,
+					       XE_MEM_REGION_CLASS_SYSMEM,
+					       XE_MEM_REGION_CLASS_VRAM);
+	}
+	igt_subtest_with_dynamic_f("mem-copy") {
+		igt_require(blt_has_mem_copy(fd));
+		for_each_variation_r(regions, 1, set) {
+			region = igt_collection_get_value(regions, 0);
+			xe_for_each_hw_engine(fd, hwe) {
+				for (int i = 0; i < ARRAY_SIZE(size); i++) {
+					igt_dynamic_f("size-0x%lx", size[i]) {
+						copy_test(fd, size[i],
+							  MEM_COPY, hwe,
+							  region);
+					}
+				}
+			}
+		}
+	}
+
+	igt_subtest_with_dynamic_f("mem-set") {
+		igt_require(blt_has_mem_set(fd));
+		for_each_variation_r(regions, 1, set) {
+			region = igt_collection_get_value(regions, 0);
+			xe_for_each_hw_engine(fd, hwe) {
+				for (int i = 0; i < ARRAY_SIZE(size); i++) {
+					igt_dynamic_f("size-0x%lx", size[i]) {
+						copy_test(fd, size[i],
+							  MEM_SET, hwe, region);
+					}
+				}
+			}
+		}
+	}
+
+	igt_fixture {
+		drm_close_driver(fd);
+	}
+}
diff --git a/tests/meson.build b/tests/meson.build
index aa8e3434c..418b7aa53 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -273,6 +273,7 @@ intel_xe_progs = [
 	'xe_ccs',
 	'xe_create',
 	'xe_compute',
+	'xe_copy_basic',
 	'xe_dma_buf_sync',
 	'xe_debugfs',
 	'xe_evict',
-- 
2.39.1

Re: [igt-dev] [PATCH i-g-t 1/4] intel/xe_copy_basic: Add copy basic test to exercise blt commands

[Karolina Stolarek]

On 4.09.2023 13:04, sai.gowtham.ch@intel.com wrote:
> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> 
> Add copy basic test to exercise copy commands like mem-copy and mem-set.
> 
> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> ---
>   tests/intel/xe_copy_basic.c | 284 ++++++++++++++++++++++++++++++++++++
>   tests/meson.build           |   1 +
>   2 files changed, 285 insertions(+)
>   create mode 100644 tests/intel/xe_copy_basic.c
> 
> diff --git a/tests/intel/xe_copy_basic.c b/tests/intel/xe_copy_basic.c
> new file mode 100644
> index 000000000..a9c00ec5a
> --- /dev/null
> +++ b/tests/intel/xe_copy_basic.c
> @@ -0,0 +1,284 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2023 Intel Corporation
> + *
> + * Authors:
> + *	Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> + */
> +
> +#include "igt.h"
> +#include "lib/igt_syncobj.h"
> +#include "intel_blt.h"
> +#include "lib/intel_cmds_info.h"
> +#include "lib/intel_mocs.h"
> +#include "lib/intel_reg.h"
> +#include "xe/xe_ioctl.h"
> +#include "xe/xe_query.h"
> +#include "xe/xe_util.h"
> +
> +/**
> + * TEST: Test to validate copy commands on xe
> + * Category: Software building block
> + * Sub-category: Copy
> + * Functionality: blitter
> + * Test category: functionality test
> + */
> +
> +#define MEM_COPY_MOCS_SHIFT                     25
> +
> +static int objcmp(int fd, uint32_t src, uint32_t dst,
> +		uint32_t src_size, uint32_t dst_size)

Please fix the alignment in this line

> +{
> +	uint32_t *buf_src, *buf_dst;
> +	int ret = 0;
> +
> +	buf_src = xe_bo_map(fd, src, src_size);
> +	buf_dst = xe_bo_map(fd, dst, dst_size);
> +
> +	ret = memcmp(buf_src, buf_dst, src_size);
> +
> +	munmap(buf_src, src_size);
> +	munmap(buf_dst, dst_size);
> +
> +	return ret;
> +}
> +
> +/**
> + * SUBTEST: mem-copy
> + * Description: Test validates MEM_COPY command, it takes various
> + *		parameters needed for the filling batch buffer for MEM_COPY command.
> + * Run type: FULL
> + */
> +static void
> +igt_mem_copy(int fd, uint32_t src, uint32_t dst, uint32_t size,
> +		uint32_t col_size, uint32_t vm, uint32_t exec_queue,
> +		uint64_t ahnd)

Here as well. It looks fine in my email client, but it's off in the 
code, and checkpatch script also caught it.

The test looks good in general[1], but I'd re-order and merge some of 
the patches so they compile one by one:

squash lib/intel_cmds_info + lib/intel_blt --> intel_reg change --> 
xe_basic_copy test

To reiterate, I'm fine with either extracting the commands to intel_blt 
library or leaving the test as it is. It's all dependent on if we want 
to test MEM_SET and MEM_COPY on i915 or not.

All the best,
Karolina

---------------------------------------------
[1] - I didn't test it, so I hope that you did, not just on the platform 
that supports mem_set

> +{
> +	struct drm_xe_sync sync = {
> +		.flags = DRM_XE_SYNC_SYNCOBJ | DRM_XE_SYNC_SIGNAL,
> +	};
> +	struct drm_xe_exec exec = {
> +		.num_batch_buffer = 1,
> +		.num_syncs = 1,
> +		.syncs = to_user_pointer(&sync),
> +	};
> +
> +	uint32_t bb_handle, syncobj;
> +	struct {
> +		uint32_t batch[12];
> +		uint32_t data;
> +	} *data;
> +
> +	uint64_t bb_offset, src_offset, dst_offset;
> +	uint64_t alignment;
> +	uint8_t src_mocs = intel_get_uc_mocs(fd);
> +	uint64_t bb_size = xe_get_default_alignment(fd);
> +	uint8_t dst_mocs = src_mocs;
> +	int i;
> +
> +	alignment = xe_get_default_alignment(fd);
> +
> +	bb_handle = xe_bo_create_flags(fd, 0, bb_size, visible_vram_if_possible(fd, 0));
> +	data = xe_bo_map(fd, bb_handle, bb_size);
> +
> +	src_offset = get_offset(ahnd, src, size, alignment);
> +	dst_offset = get_offset(ahnd, dst, size, alignment);
> +	bb_offset = get_offset(ahnd, bb_handle, bb_size, alignment);
> +
> +	i = 0;
> +	data->batch[i++] = MEM_COPY_CMD;
> +	data->batch[i++] = size - 1;
> +	data->batch[i++] = col_size - 1;
> +	data->batch[i++] = 0;
> +	data->batch[i++] = 0;
> +	data->batch[i++] = src_offset;
> +	data->batch[i++] = src_offset << 32;
> +	data->batch[i++] = dst_offset;
> +	data->batch[i++] = dst_offset << 32;
> +	data->batch[i++] = src_mocs << MEM_COPY_MOCS_SHIFT | dst_mocs;
> +	data->batch[i++] = MI_BATCH_BUFFER_END;
> +	data->batch[i++] = MI_NOOP;
> +
> +	syncobj = syncobj_create(fd, 0);
> +	sync.handle = syncobj;
> +
> +	xe_vm_bind_sync(fd, vm, bb_handle, 0, bb_offset, bb_size);
> +
> +	exec.exec_queue_id = exec_queue;
> +	exec.address = bb_offset;
> +	sync.handle = syncobj;
> +	igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_XE_EXEC, &exec), 0);
> +
> +	gem_close(fd, bb_handle);
> +	put_ahnd(ahnd);
> +	munmap(data, bb_size);
> +	syncobj_destroy(fd, syncobj);
> +}
> +
> +/**
> + * SUBTEST: mem-set
> + * Description: Test validates MEM_SET command.
> + * RUN type: FULL
> + */
> +static void igt_mem_set(int fd, uint32_t dst, size_t size, uint32_t height,
> +			uint32_t fill_data, uint32_t vm, uint32_t exec_queue, uint64_t ahnd)
> +{
> +	struct drm_xe_sync sync = {
> +		.flags = DRM_XE_SYNC_SYNCOBJ | DRM_XE_SYNC_SIGNAL,
> +	};
> +	struct drm_xe_exec exec = {
> +		.num_batch_buffer = 1,
> +		.num_syncs = 1,
> +		.syncs = to_user_pointer(&sync),
> +	};
> +	struct {
> +		uint32_t batch[12];
> +		uint32_t data;
> +	} *data;
> +
> +	uint32_t syncobj;
> +	uint64_t dst_offset;
> +	uint8_t dst_mocs = intel_get_uc_mocs(fd);
> +	int b;
> +	uint32_t dword0;
> +
> +	data = xe_bo_map(fd, dst, size);
> +	dst_offset = intel_allocator_alloc_with_strategy(ahnd, dst, size, 0,
> +							 ALLOC_STRATEGY_LOW_TO_HIGH);
> +
> +	dword0 = MEM_SET_CMD;
> +	b = 0;
> +	data->batch[b++] = dword0;
> +	data->batch[b++] = size - 1;
> +	data->batch[b++] = height;
> +	data->batch[b++] = 0;
> +	data->batch[b++] = dst_offset;
> +	data->batch[b++] = dst_offset << 32;
> +	data->batch[b++] = (fill_data << 24) | dst_mocs;
> +	data->batch[b++] = MI_BATCH_BUFFER_END;
> +	data->batch[b++] = MI_NOOP;
> +
> +	igt_assert(b <= ARRAY_SIZE(data->batch));
> +
> +	syncobj = syncobj_create(fd, 0);
> +	sync.handle = syncobj;
> +
> +	xe_vm_bind_sync(fd, vm, dst, 0, dst_offset, size);
> +
> +	exec.exec_queue_id = exec_queue;
> +	exec.address = dst_offset;
> +	sync.handle = syncobj;
> +	igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_XE_EXEC, &exec), 0);
> +
> +	munmap(data, size);
> +	put_ahnd(ahnd);
> +	syncobj_destroy(fd, syncobj);
> +}
> +
> +static void copy_test(int fd, uint32_t size, enum blt_cmd_type cmd,
> +		      struct drm_xe_engine_class_instance *hwe, uint32_t region)
> +{
> +	uint32_t src_size, dst_size;
> +	uint32_t src, dst, vm, exec_queue;
> +	char c = 'a';
> +	uint32_t bo_size = ALIGN(size + xe_cs_prefetch_size(fd), xe_get_default_alignment(fd));
> +	uint32_t temp_buffer[bo_size];
> +	uint64_t ahnd;
> +
> +	src = xe_bo_create_flags(fd, 0, bo_size, region);
> +	dst = xe_bo_create_flags(fd, 0, bo_size, region);
> +	vm = xe_vm_create(fd, 0, 0);
> +
> +	exec_queue = xe_exec_queue_create(fd, vm, hwe, 0);
> +	ahnd = intel_allocator_open(fd, 0, INTEL_ALLOCATOR_RELOC);
> +
> +	/* Fill a pattern in the buffer */
> +	for (int i = 0; i < bo_size; i++) {
> +		temp_buffer[i] = c++ % 16;
> +		temp_buffer[i] |= (c++ % 16) << 8;
> +		temp_buffer[i] |= (c++ % 16) << 16;
> +		temp_buffer[i] |= (c++ % 16) << 24;
> +	}
> +
> +	src_size = bo_size;
> +	dst_size = bo_size;
> +
> +	if (cmd == MEM_COPY) {
> +		igt_mem_copy(fd,
> +			     src,/*src_handle*/
> +			     dst,/*dst_handle*/
> +			     bo_size,/*row_size*/
> +			     1,/*col_size*/
> +			     vm,
> +			     exec_queue,
> +			     ahnd);
> +		igt_assert_eq(objcmp(fd, src, dst, src_size, dst_size), 0);
> +	} else if (cmd == MEM_SET) {
> +		igt_mem_set(fd,
> +			    dst, /*dst_handle*/
> +			    bo_size,/*width*/
> +			    1,/*height*/
> +			    0,/*fill_data*/
> +			    vm,
> +			    exec_queue,
> +			    ahnd);
> +		src_size = 1;
> +	}
> +
> +	gem_close(fd, src);
> +	gem_close(fd, dst);
> +
> +	xe_exec_queue_destroy(fd, exec_queue);
> +	xe_vm_destroy(fd, vm);
> +}
> +
> +igt_main
> +{
> +	struct drm_xe_engine_class_instance *hwe;
> +	int fd;
> +	struct igt_collection *set, *regions;
> +	uint32_t region;
> +	uint64_t size[] = {0xFD, 0x369, 0x369, 0x3FFF, 0xFFFF, 0x1FFFF, 0x3FFFF};
> +
> +	igt_fixture {
> +		fd = drm_open_driver(DRIVER_XE);
> +		xe_device_get(fd);
> +		set = xe_get_memory_region_set(fd,
> +					       XE_MEM_REGION_CLASS_SYSMEM,
> +					       XE_MEM_REGION_CLASS_VRAM);
> +	}
> +	igt_subtest_with_dynamic_f("mem-copy") {
> +		igt_require(blt_has_mem_copy(fd));
> +		for_each_variation_r(regions, 1, set) {
> +			region = igt_collection_get_value(regions, 0);
> +			xe_for_each_hw_engine(fd, hwe) {
> +				for (int i = 0; i < ARRAY_SIZE(size); i++) {
> +					igt_dynamic_f("size-0x%lx", size[i]) {
> +						copy_test(fd, size[i],
> +							  MEM_COPY, hwe,
> +							  region);
> +					}
> +				}
> +			}
> +		}
> +	}
> +
> +	igt_subtest_with_dynamic_f("mem-set") {
> +		igt_require(blt_has_mem_set(fd));
> +		for_each_variation_r(regions, 1, set) {
> +			region = igt_collection_get_value(regions, 0);
> +			xe_for_each_hw_engine(fd, hwe) {
> +				for (int i = 0; i < ARRAY_SIZE(size); i++) {
> +					igt_dynamic_f("size-0x%lx", size[i]) {
> +						copy_test(fd, size[i],
> +							  MEM_SET, hwe, region);
> +					}
> +				}
> +			}
> +		}
> +	}
> +
> +	igt_fixture {
> +		drm_close_driver(fd);
> +	}
> +}
> diff --git a/tests/meson.build b/tests/meson.build
> index aa8e3434c..418b7aa53 100644
> --- a/tests/meson.build
> +++ b/tests/meson.build
> @@ -273,6 +273,7 @@ intel_xe_progs = [
>   	'xe_ccs',
>   	'xe_create',
>   	'xe_compute',
> +	'xe_copy_basic',
>   	'xe_dma_buf_sync',
>   	'xe_debugfs',
>   	'xe_evict',

Re: [igt-dev] [PATCH i-g-t 1/4] intel/xe_copy_basic: Add copy basic test to exercise blt commands

[Ch, Sai Gowtham]

>-----Original Message-----
>From: Stolarek, Karolina <karolina.stolarek@intel.com>
>Sent: Monday, September 11, 2023 6:45 PM
>To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>; igt-
>dev@lists.freedesktop.org
>Subject: Re: [PATCH i-g-t 1/4] intel/xe_copy_basic: Add copy basic test to
>exercise blt commands
>
>On 4.09.2023 13:04, sai.gowtham.ch@intel.com wrote:
>> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>
>> Add copy basic test to exercise copy commands like mem-copy and mem-set.
>>
>> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>> ---
>>   tests/intel/xe_copy_basic.c | 284
>++++++++++++++++++++++++++++++++++++
>>   tests/meson.build           |   1 +
>>   2 files changed, 285 insertions(+)
>>   create mode 100644 tests/intel/xe_copy_basic.c
>>
>> diff --git a/tests/intel/xe_copy_basic.c b/tests/intel/xe_copy_basic.c
>> new file mode 100644 index 000000000..a9c00ec5a
>> --- /dev/null
>> +++ b/tests/intel/xe_copy_basic.c
>> @@ -0,0 +1,284 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright © 2023 Intel Corporation
>> + *
>> + * Authors:
>> + *	Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>> + */
>> +
>> +#include "igt.h"
>> +#include "lib/igt_syncobj.h"
>> +#include "intel_blt.h"
>> +#include "lib/intel_cmds_info.h"
>> +#include "lib/intel_mocs.h"
>> +#include "lib/intel_reg.h"
>> +#include "xe/xe_ioctl.h"
>> +#include "xe/xe_query.h"
>> +#include "xe/xe_util.h"
>> +
>> +/**
>> + * TEST: Test to validate copy commands on xe
>> + * Category: Software building block
>> + * Sub-category: Copy
>> + * Functionality: blitter
>> + * Test category: functionality test
>> + */
>> +
>> +#define MEM_COPY_MOCS_SHIFT                     25
>> +
>> +static int objcmp(int fd, uint32_t src, uint32_t dst,
>> +		uint32_t src_size, uint32_t dst_size)
>
>Please fix the alignment in this line
>
>> +{
>> +	uint32_t *buf_src, *buf_dst;
>> +	int ret = 0;
>> +
>> +	buf_src = xe_bo_map(fd, src, src_size);
>> +	buf_dst = xe_bo_map(fd, dst, dst_size);
>> +
>> +	ret = memcmp(buf_src, buf_dst, src_size);
>> +
>> +	munmap(buf_src, src_size);
>> +	munmap(buf_dst, dst_size);
>> +
>> +	return ret;
>> +}
>> +
>> +/**
>> + * SUBTEST: mem-copy
>> + * Description: Test validates MEM_COPY command, it takes various
>> + *		parameters needed for the filling batch buffer for MEM_COPY
>command.
>> + * Run type: FULL
>> + */
>> +static void
>> +igt_mem_copy(int fd, uint32_t src, uint32_t dst, uint32_t size,
>> +		uint32_t col_size, uint32_t vm, uint32_t exec_queue,
>> +		uint64_t ahnd)
>
>Here as well. It looks fine in my email client, but it's off in the code, and
>checkpatch script also caught it.
Strange !! Checkpatch script didn't catch this for me, Let me check that. 
>
>The test looks good in general[1], but I'd re-order and merge some of the
>patches so they compile one by one:
>
>squash lib/intel_cmds_info + lib/intel_blt --> intel_reg change -->
>xe_basic_copy test
Sure Will do that In my next patch. 
>
>To reiterate, I'm fine with either extracting the commands to intel_blt library
>or leaving the test as it is. It's all dependent on if we want to test MEM_SET
>and MEM_COPY on i915 or not.
Understood.

--------
Gowtham
>
>All the best,
>Karolina
>
>---------------------------------------------
>[1] - I didn't test it, so I hope that you did, not just on the platform that
>supports mem_set
>
>> +{
>> +	struct drm_xe_sync sync = {
>> +		.flags = DRM_XE_SYNC_SYNCOBJ | DRM_XE_SYNC_SIGNAL,
>> +	};
>> +	struct drm_xe_exec exec = {
>> +		.num_batch_buffer = 1,
>> +		.num_syncs = 1,
>> +		.syncs = to_user_pointer(&sync),
>> +	};
>> +
>> +	uint32_t bb_handle, syncobj;
>> +	struct {
>> +		uint32_t batch[12];
>> +		uint32_t data;
>> +	} *data;
>> +
>> +	uint64_t bb_offset, src_offset, dst_offset;
>> +	uint64_t alignment;
>> +	uint8_t src_mocs = intel_get_uc_mocs(fd);
>> +	uint64_t bb_size = xe_get_default_alignment(fd);
>> +	uint8_t dst_mocs = src_mocs;
>> +	int i;
>> +
>> +	alignment = xe_get_default_alignment(fd);
>> +
>> +	bb_handle = xe_bo_create_flags(fd, 0, bb_size,
>visible_vram_if_possible(fd, 0));
>> +	data = xe_bo_map(fd, bb_handle, bb_size);
>> +
>> +	src_offset = get_offset(ahnd, src, size, alignment);
>> +	dst_offset = get_offset(ahnd, dst, size, alignment);
>> +	bb_offset = get_offset(ahnd, bb_handle, bb_size, alignment);
>> +
>> +	i = 0;
>> +	data->batch[i++] = MEM_COPY_CMD;
>> +	data->batch[i++] = size - 1;
>> +	data->batch[i++] = col_size - 1;
>> +	data->batch[i++] = 0;
>> +	data->batch[i++] = 0;
>> +	data->batch[i++] = src_offset;
>> +	data->batch[i++] = src_offset << 32;
>> +	data->batch[i++] = dst_offset;
>> +	data->batch[i++] = dst_offset << 32;
>> +	data->batch[i++] = src_mocs << MEM_COPY_MOCS_SHIFT | dst_mocs;
>> +	data->batch[i++] = MI_BATCH_BUFFER_END;
>> +	data->batch[i++] = MI_NOOP;
>> +
>> +	syncobj = syncobj_create(fd, 0);
>> +	sync.handle = syncobj;
>> +
>> +	xe_vm_bind_sync(fd, vm, bb_handle, 0, bb_offset, bb_size);
>> +
>> +	exec.exec_queue_id = exec_queue;
>> +	exec.address = bb_offset;
>> +	sync.handle = syncobj;
>> +	igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_XE_EXEC, &exec), 0);
>> +
>> +	gem_close(fd, bb_handle);
>> +	put_ahnd(ahnd);
>> +	munmap(data, bb_size);
>> +	syncobj_destroy(fd, syncobj);
>> +}
>> +
>> +/**
>> + * SUBTEST: mem-set
>> + * Description: Test validates MEM_SET command.
>> + * RUN type: FULL
>> + */
>> +static void igt_mem_set(int fd, uint32_t dst, size_t size, uint32_t height,
>> +			uint32_t fill_data, uint32_t vm, uint32_t exec_queue,
>uint64_t
>> +ahnd) {
>> +	struct drm_xe_sync sync = {
>> +		.flags = DRM_XE_SYNC_SYNCOBJ | DRM_XE_SYNC_SIGNAL,
>> +	};
>> +	struct drm_xe_exec exec = {
>> +		.num_batch_buffer = 1,
>> +		.num_syncs = 1,
>> +		.syncs = to_user_pointer(&sync),
>> +	};
>> +	struct {
>> +		uint32_t batch[12];
>> +		uint32_t data;
>> +	} *data;
>> +
>> +	uint32_t syncobj;
>> +	uint64_t dst_offset;
>> +	uint8_t dst_mocs = intel_get_uc_mocs(fd);
>> +	int b;
>> +	uint32_t dword0;
>> +
>> +	data = xe_bo_map(fd, dst, size);
>> +	dst_offset = intel_allocator_alloc_with_strategy(ahnd, dst, size, 0,
>> +
>ALLOC_STRATEGY_LOW_TO_HIGH);
>> +
>> +	dword0 = MEM_SET_CMD;
>> +	b = 0;
>> +	data->batch[b++] = dword0;
>> +	data->batch[b++] = size - 1;
>> +	data->batch[b++] = height;
>> +	data->batch[b++] = 0;
>> +	data->batch[b++] = dst_offset;
>> +	data->batch[b++] = dst_offset << 32;
>> +	data->batch[b++] = (fill_data << 24) | dst_mocs;
>> +	data->batch[b++] = MI_BATCH_BUFFER_END;
>> +	data->batch[b++] = MI_NOOP;
>> +
>> +	igt_assert(b <= ARRAY_SIZE(data->batch));
>> +
>> +	syncobj = syncobj_create(fd, 0);
>> +	sync.handle = syncobj;
>> +
>> +	xe_vm_bind_sync(fd, vm, dst, 0, dst_offset, size);
>> +
>> +	exec.exec_queue_id = exec_queue;
>> +	exec.address = dst_offset;
>> +	sync.handle = syncobj;
>> +	igt_assert_eq(igt_ioctl(fd, DRM_IOCTL_XE_EXEC, &exec), 0);
>> +
>> +	munmap(data, size);
>> +	put_ahnd(ahnd);
>> +	syncobj_destroy(fd, syncobj);
>> +}
>> +
>> +static void copy_test(int fd, uint32_t size, enum blt_cmd_type cmd,
>> +		      struct drm_xe_engine_class_instance *hwe, uint32_t
>region) {
>> +	uint32_t src_size, dst_size;
>> +	uint32_t src, dst, vm, exec_queue;
>> +	char c = 'a';
>> +	uint32_t bo_size = ALIGN(size + xe_cs_prefetch_size(fd),
>xe_get_default_alignment(fd));
>> +	uint32_t temp_buffer[bo_size];
>> +	uint64_t ahnd;
>> +
>> +	src = xe_bo_create_flags(fd, 0, bo_size, region);
>> +	dst = xe_bo_create_flags(fd, 0, bo_size, region);
>> +	vm = xe_vm_create(fd, 0, 0);
>> +
>> +	exec_queue = xe_exec_queue_create(fd, vm, hwe, 0);
>> +	ahnd = intel_allocator_open(fd, 0, INTEL_ALLOCATOR_RELOC);
>> +
>> +	/* Fill a pattern in the buffer */
>> +	for (int i = 0; i < bo_size; i++) {
>> +		temp_buffer[i] = c++ % 16;
>> +		temp_buffer[i] |= (c++ % 16) << 8;
>> +		temp_buffer[i] |= (c++ % 16) << 16;
>> +		temp_buffer[i] |= (c++ % 16) << 24;
>> +	}
>> +
>> +	src_size = bo_size;
>> +	dst_size = bo_size;
>> +
>> +	if (cmd == MEM_COPY) {
>> +		igt_mem_copy(fd,
>> +			     src,/*src_handle*/
>> +			     dst,/*dst_handle*/
>> +			     bo_size,/*row_size*/
>> +			     1,/*col_size*/
>> +			     vm,
>> +			     exec_queue,
>> +			     ahnd);
>> +		igt_assert_eq(objcmp(fd, src, dst, src_size, dst_size), 0);
>> +	} else if (cmd == MEM_SET) {
>> +		igt_mem_set(fd,
>> +			    dst, /*dst_handle*/
>> +			    bo_size,/*width*/
>> +			    1,/*height*/
>> +			    0,/*fill_data*/
>> +			    vm,
>> +			    exec_queue,
>> +			    ahnd);
>> +		src_size = 1;
>> +	}
>> +
>> +	gem_close(fd, src);
>> +	gem_close(fd, dst);
>> +
>> +	xe_exec_queue_destroy(fd, exec_queue);
>> +	xe_vm_destroy(fd, vm);
>> +}
>> +
>> +igt_main
>> +{
>> +	struct drm_xe_engine_class_instance *hwe;
>> +	int fd;
>> +	struct igt_collection *set, *regions;
>> +	uint32_t region;
>> +	uint64_t size[] = {0xFD, 0x369, 0x369, 0x3FFF, 0xFFFF, 0x1FFFF,
>> +0x3FFFF};
>> +
>> +	igt_fixture {
>> +		fd = drm_open_driver(DRIVER_XE);
>> +		xe_device_get(fd);
>> +		set = xe_get_memory_region_set(fd,
>> +
>XE_MEM_REGION_CLASS_SYSMEM,
>> +					       XE_MEM_REGION_CLASS_VRAM);
>> +	}
>> +	igt_subtest_with_dynamic_f("mem-copy") {
>> +		igt_require(blt_has_mem_copy(fd));
>> +		for_each_variation_r(regions, 1, set) {
>> +			region = igt_collection_get_value(regions, 0);
>> +			xe_for_each_hw_engine(fd, hwe) {
>> +				for (int i = 0; i < ARRAY_SIZE(size); i++) {
>> +					igt_dynamic_f("size-0x%lx", size[i]) {
>> +						copy_test(fd, size[i],
>> +							  MEM_COPY, hwe,
>> +							  region);
>> +					}
>> +				}
>> +			}
>> +		}
>> +	}
>> +
>> +	igt_subtest_with_dynamic_f("mem-set") {
>> +		igt_require(blt_has_mem_set(fd));
>> +		for_each_variation_r(regions, 1, set) {
>> +			region = igt_collection_get_value(regions, 0);
>> +			xe_for_each_hw_engine(fd, hwe) {
>> +				for (int i = 0; i < ARRAY_SIZE(size); i++) {
>> +					igt_dynamic_f("size-0x%lx", size[i]) {
>> +						copy_test(fd, size[i],
>> +							  MEM_SET, hwe,
>region);
>> +					}
>> +				}
>> +			}
>> +		}
>> +	}
>> +
>> +	igt_fixture {
>> +		drm_close_driver(fd);
>> +	}
>> +}
>> diff --git a/tests/meson.build b/tests/meson.build index
>> aa8e3434c..418b7aa53 100644
>> --- a/tests/meson.build
>> +++ b/tests/meson.build
>> @@ -273,6 +273,7 @@ intel_xe_progs = [
>>   	'xe_ccs',
>>   	'xe_create',
>>   	'xe_compute',
>> +	'xe_copy_basic',
>>   	'xe_dma_buf_sync',
>>   	'xe_debugfs',
>>   	'xe_evict',

[igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[sai.gowtham.ch]

From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>

Check if mem-copy/mem-set commands are supported by fd device.

Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
---
 lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
 lib/intel_blt.h |  2 ++
 2 files changed, 34 insertions(+)

diff --git a/lib/intel_blt.c b/lib/intel_blt.c
index 429511920..b55fa9b52 100644
--- a/lib/intel_blt.c
+++ b/lib/intel_blt.c
@@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
 	return blt_supports_command(cmds_info, XY_BLOCK_COPY);
 }
 
+/**
+ * blt_has_mem_copy
+ * @fd: drm fd
+ *
+ * Check if mem copy is supported by @fd device
+ *
+ * Returns:
+ * true if it does, false otherwise.
+ */
+bool blt_has_mem_copy(int fd)
+{
+	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
+
+	return blt_supports_command(cmds_info, MEM_COPY);
+}
+
+/**
+ * blt_has_mem_set
+ * @fd: drm fd
+ *
+ * Check if mem set is supported by @fd device
+ *
+ * Returns:
+ * true if it does, false otherwise.
+ */
+bool blt_has_mem_set(int fd)
+{
+	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
+
+	return blt_supports_command(cmds_info, MEM_SET);
+}
+
 /**
  * blt_has_fast_copy
  * @fd: drm fd
diff --git a/lib/intel_blt.h b/lib/intel_blt.h
index b8b3d724d..d9c8883c7 100644
--- a/lib/intel_blt.h
+++ b/lib/intel_blt.h
@@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct intel_cmds_info *cmds_info,
 			  uint32_t prop);
 
 bool blt_has_block_copy(int fd);
+bool blt_has_mem_copy(int fd);
+bool blt_has_mem_set(int fd);
 bool blt_has_fast_copy(int fd);
 bool blt_has_xy_src_copy(int fd);
 bool blt_has_xy_color(int fd);
-- 
2.39.1

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Zbigniew Kempczyński]

On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com wrote:
> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> 
> Check if mem-copy/mem-set commands are supported by fd device.
> 
> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> ---
>  lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
>  lib/intel_blt.h |  2 ++
>  2 files changed, 34 insertions(+)
> 
> diff --git a/lib/intel_blt.c b/lib/intel_blt.c
> index 429511920..b55fa9b52 100644
> --- a/lib/intel_blt.c
> +++ b/lib/intel_blt.c
> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
>  	return blt_supports_command(cmds_info, XY_BLOCK_COPY);
>  }
>  
> +/**
> + * blt_has_mem_copy
> + * @fd: drm fd
> + *
> + * Check if mem copy is supported by @fd device
> + *
> + * Returns:
> + * true if it does, false otherwise.
> + */
> +bool blt_has_mem_copy(int fd)
> +{
> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> +
> +	return blt_supports_command(cmds_info, MEM_COPY);
> +}
> +
> +/**
> + * blt_has_mem_set
> + * @fd: drm fd
> + *
> + * Check if mem set is supported by @fd device
> + *
> + * Returns:
> + * true if it does, false otherwise.
> + */
> +bool blt_has_mem_set(int fd)
> +{
> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> +
> +	return blt_supports_command(cmds_info, MEM_SET);
> +}
> +

It is not true if you'll use those functions in i915 igts.
mem-set and mem-copy commands you've introduced in 1/4 patch
should be part of intel_blt.[ch] library.

BTW first patch 1/4 won't compile in step-by-step mode because
it uses code from following patches.

--
Zbigniew


>  /**
>   * blt_has_fast_copy
>   * @fd: drm fd
> diff --git a/lib/intel_blt.h b/lib/intel_blt.h
> index b8b3d724d..d9c8883c7 100644
> --- a/lib/intel_blt.h
> +++ b/lib/intel_blt.h
> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct intel_cmds_info *cmds_info,
>  			  uint32_t prop);
>  
>  bool blt_has_block_copy(int fd);
> +bool blt_has_mem_copy(int fd);
> +bool blt_has_mem_set(int fd);
>  bool blt_has_fast_copy(int fd);
>  bool blt_has_xy_src_copy(int fd);
>  bool blt_has_xy_color(int fd);
> -- 
> 2.39.1
> 

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Ch, Sai Gowtham]

>-----Original Message-----
>From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
>Sent: Monday, September 4, 2023 6:10 PM
>To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
>Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
><karolina.stolarek@intel.com>
>Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are
>supported by the platforms
>
>On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com wrote:
>> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>
>> Check if mem-copy/mem-set commands are supported by fd device.
>>
>> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>> ---
>>  lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
>> lib/intel_blt.h |  2 ++
>>  2 files changed, 34 insertions(+)
>>
>> diff --git a/lib/intel_blt.c b/lib/intel_blt.c index
>> 429511920..b55fa9b52 100644
>> --- a/lib/intel_blt.c
>> +++ b/lib/intel_blt.c
>> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
>>  	return blt_supports_command(cmds_info, XY_BLOCK_COPY);  }
>>
>> +/**
>> + * blt_has_mem_copy
>> + * @fd: drm fd
>> + *
>> + * Check if mem copy is supported by @fd device
>> + *
>> + * Returns:
>> + * true if it does, false otherwise.
>> + */
>> +bool blt_has_mem_copy(int fd)
>> +{
>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>> +
>> +	return blt_supports_command(cmds_info, MEM_COPY); }
>> +
>> +/**
>> + * blt_has_mem_set
>> + * @fd: drm fd
>> + *
>> + * Check if mem set is supported by @fd device
>> + *
>> + * Returns:
>> + * true if it does, false otherwise.
>> + */
>> +bool blt_has_mem_set(int fd)
>> +{
>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>> +
>> +	return blt_supports_command(cmds_info, MEM_SET); }
>> +
>
>It is not true if you'll use those functions in i915 igts.
Do you mean path for i915 needs to be enabled ? 
>mem-set and mem-copy commands you've introduced in 1/4 patch should be
>part of intel_blt.[ch] library.
Do you mean MEM_SET and MEM_COPY  in 3/4 patch ? Can you elaborate ? 
>
>BTW first patch 1/4 won't compile in step-by-step mode because it uses code
>from following patches.
I'll correct that in my next patch series.
----
Ch Sai Gowtham 
>
>--
>Zbigniew
>
>
>>  /**
>>   * blt_has_fast_copy
>>   * @fd: drm fd
>> diff --git a/lib/intel_blt.h b/lib/intel_blt.h index
>> b8b3d724d..d9c8883c7 100644
>> --- a/lib/intel_blt.h
>> +++ b/lib/intel_blt.h
>> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct
>intel_cmds_info *cmds_info,
>>  			  uint32_t prop);
>>
>>  bool blt_has_block_copy(int fd);
>> +bool blt_has_mem_copy(int fd);
>> +bool blt_has_mem_set(int fd);
>>  bool blt_has_fast_copy(int fd);
>>  bool blt_has_xy_src_copy(int fd);
>>  bool blt_has_xy_color(int fd);
>> --
>> 2.39.1
>>

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Zbigniew Kempczyński]

On Tue, Sep 05, 2023 at 06:11:54AM +0200, Ch, Sai Gowtham wrote:
> 
> 
> >-----Original Message-----
> >From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
> >Sent: Monday, September 4, 2023 6:10 PM
> >To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
> >Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
> ><karolina.stolarek@intel.com>
> >Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are
> >supported by the platforms
> >
> >On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com wrote:
> >> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> >>
> >> Check if mem-copy/mem-set commands are supported by fd device.
> >>
> >> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> >> ---
> >>  lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
> >> lib/intel_blt.h |  2 ++
> >>  2 files changed, 34 insertions(+)
> >>
> >> diff --git a/lib/intel_blt.c b/lib/intel_blt.c index
> >> 429511920..b55fa9b52 100644
> >> --- a/lib/intel_blt.c
> >> +++ b/lib/intel_blt.c
> >> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
> >>  	return blt_supports_command(cmds_info, XY_BLOCK_COPY);  }
> >>
> >> +/**
> >> + * blt_has_mem_copy
> >> + * @fd: drm fd
> >> + *
> >> + * Check if mem copy is supported by @fd device
> >> + *
> >> + * Returns:
> >> + * true if it does, false otherwise.
> >> + */
> >> +bool blt_has_mem_copy(int fd)
> >> +{
> >> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> >> +
> >> +	return blt_supports_command(cmds_info, MEM_COPY); }
> >> +
> >> +/**
> >> + * blt_has_mem_set
> >> + * @fd: drm fd
> >> + *
> >> + * Check if mem set is supported by @fd device
> >> + *
> >> + * Returns:
> >> + * true if it does, false otherwise.
> >> + */
> >> +bool blt_has_mem_set(int fd)
> >> +{
> >> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> >> +
> >> +	return blt_supports_command(cmds_info, MEM_SET); }
> >> +
> >
> >It is not true if you'll use those functions in i915 igts.
> Do you mean path for i915 needs to be enabled ? 

Yes, if I'm not wrong PVC will be supported on i915 as either.
So if blt_has_mem_set() will return true for it it should have
the implementation in the blitter library. Generally you got
almost everything you need (mem_set/copy code is already written
so what you need is to extract this and support two ways of
entering it (for i915 and for xe).

> >mem-set and mem-copy commands you've introduced in 1/4 patch should be
> >part of intel_blt.[ch] library.
> Do you mean MEM_SET and MEM_COPY  in 3/4 patch ? Can you elaborate ? 

Related to above comment. You need to have batch commands + prepare
execution. Batch commands + execution for Xe you already have in the
test. I would migrate this to intel_blt.c and add i915 execution path.

Then in the test just call the mem_set or mem_copy depending what you
want to test to.

--
Zbigniew

> >
> >BTW first patch 1/4 won't compile in step-by-step mode because it uses code
> >from following patches.
> I'll correct that in my next patch series.
> ----
> Ch Sai Gowtham 
> >
> >--
> >Zbigniew
> >
> >
> >>  /**
> >>   * blt_has_fast_copy
> >>   * @fd: drm fd
> >> diff --git a/lib/intel_blt.h b/lib/intel_blt.h index
> >> b8b3d724d..d9c8883c7 100644
> >> --- a/lib/intel_blt.h
> >> +++ b/lib/intel_blt.h
> >> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct
> >intel_cmds_info *cmds_info,
> >>  			  uint32_t prop);
> >>
> >>  bool blt_has_block_copy(int fd);
> >> +bool blt_has_mem_copy(int fd);
> >> +bool blt_has_mem_set(int fd);
> >>  bool blt_has_fast_copy(int fd);
> >>  bool blt_has_xy_src_copy(int fd);
> >>  bool blt_has_xy_color(int fd);
> >> --
> >> 2.39.1
> >>

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Ch, Sai Gowtham]

>-----Original Message-----
>From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
>Sent: Thursday, September 7, 2023 3:06 PM
>To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
>Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
><karolina.stolarek@intel.com>
>Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are
>supported by the platforms
>
>On Tue, Sep 05, 2023 at 06:11:54AM +0200, Ch, Sai Gowtham wrote:
>>
>>
>> >-----Original Message-----
>> >From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
>> >Sent: Monday, September 4, 2023 6:10 PM
>> >To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
>> >Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
>> ><karolina.stolarek@intel.com>
>> >Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt
>> >commands are supported by the platforms
>> >
>> >On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com
>wrote:
>> >> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>> >>
>> >> Check if mem-copy/mem-set commands are supported by fd device.
>> >>
>> >> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>> >> ---
>> >>  lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
>> >> lib/intel_blt.h |  2 ++
>> >>  2 files changed, 34 insertions(+)
>> >>
>> >> diff --git a/lib/intel_blt.c b/lib/intel_blt.c index
>> >> 429511920..b55fa9b52 100644
>> >> --- a/lib/intel_blt.c
>> >> +++ b/lib/intel_blt.c
>> >> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
>> >>  	return blt_supports_command(cmds_info, XY_BLOCK_COPY);  }
>> >>
>> >> +/**
>> >> + * blt_has_mem_copy
>> >> + * @fd: drm fd
>> >> + *
>> >> + * Check if mem copy is supported by @fd device
>> >> + *
>> >> + * Returns:
>> >> + * true if it does, false otherwise.
>> >> + */
>> >> +bool blt_has_mem_copy(int fd)
>> >> +{
>> >> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>> >> +
>> >> +	return blt_supports_command(cmds_info, MEM_COPY); }
>> >> +
>> >> +/**
>> >> + * blt_has_mem_set
>> >> + * @fd: drm fd
>> >> + *
>> >> + * Check if mem set is supported by @fd device
>> >> + *
>> >> + * Returns:
>> >> + * true if it does, false otherwise.
>> >> + */
>> >> +bool blt_has_mem_set(int fd)
>> >> +{
>> >> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>> >> +
>> >> +	return blt_supports_command(cmds_info, MEM_SET); }
>> >> +
>> >
>> >It is not true if you'll use those functions in i915 igts.
>> Do you mean path for i915 needs to be enabled ?
>
>Yes, if I'm not wrong PVC will be supported on i915 as either.
>So if blt_has_mem_set() will return true for it it should have the implementation
>in the blitter library. Generally you got almost everything you need
>(mem_set/copy code is already written so what you need is to extract this and
>support two ways of entering it (for i915 and for xe).

Sure will make this work for both i915 and xe. 
>
>> >mem-set and mem-copy commands you've introduced in 1/4 patch should
>> >be part of intel_blt.[ch] library.
>> Do you mean MEM_SET and MEM_COPY  in 3/4 patch ? Can you elaborate ?
>
>Related to above comment. You need to have batch commands + prepare
>execution. Batch commands + execution for Xe you already have in the test. I
>would migrate this to intel_blt.c and add i915 execution path.
>
do you mean something similar to "emit_blt_fast_copy" for fast_copy, mem_copy/set has to be migrated to 
Intel_blt.c ?  

----
Ch Sai Gowtham
>Then in the test just call the mem_set or mem_copy depending what you want
>to test to.
>
>--
>Zbigniew
>
>> >
>> >BTW first patch 1/4 won't compile in step-by-step mode because it
>> >uses code from following patches.
>> I'll correct that in my next patch series.
>> ----
>> Ch Sai Gowtham
>> >
>> >--
>> >Zbigniew
>> >
>> >
>> >>  /**
>> >>   * blt_has_fast_copy
>> >>   * @fd: drm fd
>> >> diff --git a/lib/intel_blt.h b/lib/intel_blt.h index
>> >> b8b3d724d..d9c8883c7 100644
>> >> --- a/lib/intel_blt.h
>> >> +++ b/lib/intel_blt.h
>> >> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct
>> >intel_cmds_info *cmds_info,
>> >>  			  uint32_t prop);
>> >>
>> >>  bool blt_has_block_copy(int fd);
>> >> +bool blt_has_mem_copy(int fd);
>> >> +bool blt_has_mem_set(int fd);
>> >>  bool blt_has_fast_copy(int fd);
>> >>  bool blt_has_xy_src_copy(int fd);
>> >>  bool blt_has_xy_color(int fd);
>> >> --
>> >> 2.39.1
>> >>

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Karolina Stolarek]

On 7.09.2023 15:36, Ch, Sai Gowtham wrote:
> 
> 
>> -----Original Message-----
>> From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
>> Sent: Thursday, September 7, 2023 3:06 PM
>> To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
>> Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
>> <karolina.stolarek@intel.com>
>> Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are
>> supported by the platforms
>>
>> On Tue, Sep 05, 2023 at 06:11:54AM +0200, Ch, Sai Gowtham wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
>>>> Sent: Monday, September 4, 2023 6:10 PM
>>>> To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
>>>> Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
>>>> <karolina.stolarek@intel.com>
>>>> Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt
>>>> commands are supported by the platforms
>>>>
>>>> On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com
>> wrote:
>>>>> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>>>>
>>>>> Check if mem-copy/mem-set commands are supported by fd device.
>>>>>
>>>>> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>>>> ---
>>>>>   lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
>>>>> lib/intel_blt.h |  2 ++
>>>>>   2 files changed, 34 insertions(+)
>>>>>
>>>>> diff --git a/lib/intel_blt.c b/lib/intel_blt.c index
>>>>> 429511920..b55fa9b52 100644
>>>>> --- a/lib/intel_blt.c
>>>>> +++ b/lib/intel_blt.c
>>>>> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
>>>>>   	return blt_supports_command(cmds_info, XY_BLOCK_COPY);  }
>>>>>
>>>>> +/**
>>>>> + * blt_has_mem_copy
>>>>> + * @fd: drm fd
>>>>> + *
>>>>> + * Check if mem copy is supported by @fd device
>>>>> + *
>>>>> + * Returns:
>>>>> + * true if it does, false otherwise.
>>>>> + */
>>>>> +bool blt_has_mem_copy(int fd)
>>>>> +{
>>>>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>>>>> +
>>>>> +	return blt_supports_command(cmds_info, MEM_COPY); }
>>>>> +
>>>>> +/**
>>>>> + * blt_has_mem_set
>>>>> + * @fd: drm fd
>>>>> + *
>>>>> + * Check if mem set is supported by @fd device
>>>>> + *
>>>>> + * Returns:
>>>>> + * true if it does, false otherwise.
>>>>> + */
>>>>> +bool blt_has_mem_set(int fd)
>>>>> +{
>>>>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>>>>> +
>>>>> +	return blt_supports_command(cmds_info, MEM_SET); }
>>>>> +
>>>>
>>>> It is not true if you'll use those functions in i915 igts.
>>> Do you mean path for i915 needs to be enabled ?
>>
>> Yes, if I'm not wrong PVC will be supported on i915 as either.
>> So if blt_has_mem_set() will return true for it it should have the implementation
>> in the blitter library. Generally you got almost everything you need
>> (mem_set/copy code is already written so what you need is to extract this and
>> support two ways of entering it (for i915 and for xe).
> 
> Sure will make this work for both i915 and xe.
>>
>>>> mem-set and mem-copy commands you've introduced in 1/4 patch should
>>>> be part of intel_blt.[ch] library.
>>> Do you mean MEM_SET and MEM_COPY  in 3/4 patch ? Can you elaborate ?
>>
>> Related to above comment. You need to have batch commands + prepare
>> execution. Batch commands + execution for Xe you already have in the test. I
>> would migrate this to intel_blt.c and add i915 execution path.
>>
> do you mean something similar to "emit_blt_fast_copy" for fast_copy, mem_copy/set has to be migrated to
> Intel_blt.c ?

I'll jump on this.

That would be something similar, yes, but the interface would be 
different. You can't reuse blt_copy_data struct, and you'll need to 
define extra structs to describe source, destination and the command 
itself. Also, I'm not sure if we'd get much value from pipelined 
mem_copy/set (i.e. many copies issued in one BB), we could have just a 
single copy/set instead of emitting it.

That could stir a debate, but, in my opinion, it should be fine to first 
finish writing the test as it is, and then extract the implemented 
functions to intel_blt. Writing an additional path for i915 will take 
time. Sai, could you check if this is also a priority? If yes, then I'm 
all for implementing it as a part of the series. If not, well, I would 
reconsider doing it.

All the best,
Karolina

> 
> ----
> Ch Sai Gowtham
>> Then in the test just call the mem_set or mem_copy depending what you want
>> to test to.
>>
>> --
>> Zbigniew
>>
>>>>
>>>> BTW first patch 1/4 won't compile in step-by-step mode because it
>>>> uses code from following patches.
>>> I'll correct that in my next patch series.
>>> ----
>>> Ch Sai Gowtham
>>>>
>>>> --
>>>> Zbigniew
>>>>
>>>>
>>>>>   /**
>>>>>    * blt_has_fast_copy
>>>>>    * @fd: drm fd
>>>>> diff --git a/lib/intel_blt.h b/lib/intel_blt.h index
>>>>> b8b3d724d..d9c8883c7 100644
>>>>> --- a/lib/intel_blt.h
>>>>> +++ b/lib/intel_blt.h
>>>>> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct
>>>> intel_cmds_info *cmds_info,
>>>>>   			  uint32_t prop);
>>>>>
>>>>>   bool blt_has_block_copy(int fd);
>>>>> +bool blt_has_mem_copy(int fd);
>>>>> +bool blt_has_mem_set(int fd);
>>>>>   bool blt_has_fast_copy(int fd);
>>>>>   bool blt_has_xy_src_copy(int fd);
>>>>>   bool blt_has_xy_color(int fd);
>>>>> --
>>>>> 2.39.1
>>>>>

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Zbigniew Kempczyński]

On Thu, Sep 07, 2023 at 03:36:41PM +0200, Ch, Sai Gowtham wrote:
> 
> 
> >-----Original Message-----
> >From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
> >Sent: Thursday, September 7, 2023 3:06 PM
> >To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
> >Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
> ><karolina.stolarek@intel.com>
> >Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are
> >supported by the platforms
> >
> >On Tue, Sep 05, 2023 at 06:11:54AM +0200, Ch, Sai Gowtham wrote:
> >>
> >>
> >> >-----Original Message-----
> >> >From: Kempczynski, Zbigniew <zbigniew.kempczynski@intel.com>
> >> >Sent: Monday, September 4, 2023 6:10 PM
> >> >To: Ch, Sai Gowtham <sai.gowtham.ch@intel.com>
> >> >Cc: igt-dev@lists.freedesktop.org; Stolarek, Karolina
> >> ><karolina.stolarek@intel.com>
> >> >Subject: Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt
> >> >commands are supported by the platforms
> >> >
> >> >On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com
> >wrote:
> >> >> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> >> >>
> >> >> Check if mem-copy/mem-set commands are supported by fd device.
> >> >>
> >> >> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> >> >> ---
> >> >>  lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
> >> >> lib/intel_blt.h |  2 ++
> >> >>  2 files changed, 34 insertions(+)
> >> >>
> >> >> diff --git a/lib/intel_blt.c b/lib/intel_blt.c index
> >> >> 429511920..b55fa9b52 100644
> >> >> --- a/lib/intel_blt.c
> >> >> +++ b/lib/intel_blt.c
> >> >> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
> >> >>  	return blt_supports_command(cmds_info, XY_BLOCK_COPY);  }
> >> >>
> >> >> +/**
> >> >> + * blt_has_mem_copy
> >> >> + * @fd: drm fd
> >> >> + *
> >> >> + * Check if mem copy is supported by @fd device
> >> >> + *
> >> >> + * Returns:
> >> >> + * true if it does, false otherwise.
> >> >> + */
> >> >> +bool blt_has_mem_copy(int fd)
> >> >> +{
> >> >> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> >> >> +
> >> >> +	return blt_supports_command(cmds_info, MEM_COPY); }
> >> >> +
> >> >> +/**
> >> >> + * blt_has_mem_set
> >> >> + * @fd: drm fd
> >> >> + *
> >> >> + * Check if mem set is supported by @fd device
> >> >> + *
> >> >> + * Returns:
> >> >> + * true if it does, false otherwise.
> >> >> + */
> >> >> +bool blt_has_mem_set(int fd)
> >> >> +{
> >> >> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> >> >> +
> >> >> +	return blt_supports_command(cmds_info, MEM_SET); }
> >> >> +
> >> >
> >> >It is not true if you'll use those functions in i915 igts.
> >> Do you mean path for i915 needs to be enabled ?
> >
> >Yes, if I'm not wrong PVC will be supported on i915 as either.
> >So if blt_has_mem_set() will return true for it it should have the implementation
> >in the blitter library. Generally you got almost everything you need
> >(mem_set/copy code is already written so what you need is to extract this and
> >support two ways of entering it (for i915 and for xe).
> 
> Sure will make this work for both i915 and xe. 
> >
> >> >mem-set and mem-copy commands you've introduced in 1/4 patch should
> >> >be part of intel_blt.[ch] library.
> >> Do you mean MEM_SET and MEM_COPY  in 3/4 patch ? Can you elaborate ?
> >
> >Related to above comment. You need to have batch commands + prepare
> >execution. Batch commands + execution for Xe you already have in the test. I
> >would migrate this to intel_blt.c and add i915 execution path.
> >
> do you mean something similar to "emit_blt_fast_copy" for fast_copy, mem_copy/set has to be migrated to 
> Intel_blt.c ?  

Yes, emit_blt_mem_set/copy as batch generator. Apart of this
blt_mem_set/copy which do execution on i915 or xe driver.

--
Zbigniew

> 
> ----
> Ch Sai Gowtham
> >Then in the test just call the mem_set or mem_copy depending what you want
> >to test to.
> >
> >--
> >Zbigniew
> >
> >> >
> >> >BTW first patch 1/4 won't compile in step-by-step mode because it
> >> >uses code from following patches.
> >> I'll correct that in my next patch series.
> >> ----
> >> Ch Sai Gowtham
> >> >
> >> >--
> >> >Zbigniew
> >> >
> >> >
> >> >>  /**
> >> >>   * blt_has_fast_copy
> >> >>   * @fd: drm fd
> >> >> diff --git a/lib/intel_blt.h b/lib/intel_blt.h index
> >> >> b8b3d724d..d9c8883c7 100644
> >> >> --- a/lib/intel_blt.h
> >> >> +++ b/lib/intel_blt.h
> >> >> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct
> >> >intel_cmds_info *cmds_info,
> >> >>  			  uint32_t prop);
> >> >>
> >> >>  bool blt_has_block_copy(int fd);
> >> >> +bool blt_has_mem_copy(int fd);
> >> >> +bool blt_has_mem_set(int fd);
> >> >>  bool blt_has_fast_copy(int fd);
> >> >>  bool blt_has_xy_src_copy(int fd);
> >> >>  bool blt_has_xy_color(int fd);
> >> >> --
> >> >> 2.39.1
> >> >>

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Karolina Stolarek]

On 4.09.2023 14:39, Zbigniew Kempczyński wrote:
> On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com wrote:
>> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>
>> Check if mem-copy/mem-set commands are supported by fd device.
>>
>> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>> ---
>>   lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
>>   lib/intel_blt.h |  2 ++
>>   2 files changed, 34 insertions(+)
>>
>> diff --git a/lib/intel_blt.c b/lib/intel_blt.c
>> index 429511920..b55fa9b52 100644
>> --- a/lib/intel_blt.c
>> +++ b/lib/intel_blt.c
>> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
>>   	return blt_supports_command(cmds_info, XY_BLOCK_COPY);
>>   }
>>   
>> +/**
>> + * blt_has_mem_copy
>> + * @fd: drm fd
>> + *
>> + * Check if mem copy is supported by @fd device
>> + *
>> + * Returns:
>> + * true if it does, false otherwise.
>> + */
>> +bool blt_has_mem_copy(int fd)
>> +{
>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>> +
>> +	return blt_supports_command(cmds_info, MEM_COPY);
>> +}
>> +
>> +/**
>> + * blt_has_mem_set
>> + * @fd: drm fd
>> + *
>> + * Check if mem set is supported by @fd device
>> + *
>> + * Returns:
>> + * true if it does, false otherwise.
>> + */
>> +bool blt_has_mem_set(int fd)
>> +{
>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>> +
>> +	return blt_supports_command(cmds_info, MEM_SET);
>> +}
>> +
> 
> It is not true if you'll use those functions in i915 igts.
> mem-set and mem-copy commands you've introduced in 1/4 patch
> should be part of intel_blt.[ch] library.

Following this logic, we'd need to provide XY_SRC_COPY_BLT in intel_blt 
library as well. We don't -- mostly because intel_blt lacks support for 
relocations.

blt_has_<command> are lightweight checks that only say if you can issue 
a specific command to a platform, and they don't depend on a driver. 
They don't guarantee that a specific blitter function is implemented in 
intel_blt.

This confusion shows that we should've keep intel_cmds_info and 
intel_blt libraries separated from the beginning. Yes, they are closely 
related, but it's intel_blt quering intel_cmds_info about hardware 
capabilities, not implemented features.

Many thanks,
Karolina

> 
> BTW first patch 1/4 won't compile in step-by-step mode because
> it uses code from following patches.
> 
> --
> Zbigniew
> 
> 
>>   /**
>>    * blt_has_fast_copy
>>    * @fd: drm fd
>> diff --git a/lib/intel_blt.h b/lib/intel_blt.h
>> index b8b3d724d..d9c8883c7 100644
>> --- a/lib/intel_blt.h
>> +++ b/lib/intel_blt.h
>> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct intel_cmds_info *cmds_info,
>>   			  uint32_t prop);
>>   
>>   bool blt_has_block_copy(int fd);
>> +bool blt_has_mem_copy(int fd);
>> +bool blt_has_mem_set(int fd);
>>   bool blt_has_fast_copy(int fd);
>>   bool blt_has_xy_src_copy(int fd);
>>   bool blt_has_xy_color(int fd);
>> -- 
>> 2.39.1
>>

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Zbigniew Kempczyński]

On Mon, Sep 11, 2023 at 01:09:31PM +0200, Karolina Stolarek wrote:
> On 4.09.2023 14:39, Zbigniew Kempczyński wrote:
> > On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com wrote:
> > > From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> > > 
> > > Check if mem-copy/mem-set commands are supported by fd device.
> > > 
> > > Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
> > > ---
> > >   lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
> > >   lib/intel_blt.h |  2 ++
> > >   2 files changed, 34 insertions(+)
> > > 
> > > diff --git a/lib/intel_blt.c b/lib/intel_blt.c
> > > index 429511920..b55fa9b52 100644
> > > --- a/lib/intel_blt.c
> > > +++ b/lib/intel_blt.c
> > > @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
> > >   	return blt_supports_command(cmds_info, XY_BLOCK_COPY);
> > >   }
> > > +/**
> > > + * blt_has_mem_copy
> > > + * @fd: drm fd
> > > + *
> > > + * Check if mem copy is supported by @fd device
> > > + *
> > > + * Returns:
> > > + * true if it does, false otherwise.
> > > + */
> > > +bool blt_has_mem_copy(int fd)
> > > +{
> > > +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> > > +
> > > +	return blt_supports_command(cmds_info, MEM_COPY);
> > > +}
> > > +
> > > +/**
> > > + * blt_has_mem_set
> > > + * @fd: drm fd
> > > + *
> > > + * Check if mem set is supported by @fd device
> > > + *
> > > + * Returns:
> > > + * true if it does, false otherwise.
> > > + */
> > > +bool blt_has_mem_set(int fd)
> > > +{
> > > +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
> > > +
> > > +	return blt_supports_command(cmds_info, MEM_SET);
> > > +}
> > > +
> > 
> > It is not true if you'll use those functions in i915 igts.
> > mem-set and mem-copy commands you've introduced in 1/4 patch
> > should be part of intel_blt.[ch] library.
> 
> Following this logic, we'd need to provide XY_SRC_COPY_BLT in intel_blt
> library as well. We don't -- mostly because intel_blt lacks support for
> relocations.

Yes, I hoped we will add this implementation. Adding relocations isn't
problem here but I would stick to softpinning/vm_bind at the moment.
Perfect would be if we claim that some command is supported we provide
an implementation of such blit command for i915/xe.

> 
> blt_has_<command> are lightweight checks that only say if you can issue a
> specific command to a platform, and they don't depend on a driver. They
> don't guarantee that a specific blitter function is implemented in
> intel_blt.
> 
> This confusion shows that we should've keep intel_cmds_info and intel_blt
> libraries separated from the beginning. Yes, they are closely related, but
> it's intel_blt quering intel_cmds_info about hardware capabilities, not
> implemented features.

Converging intel_blt to have implementation of supported hw blits should
be our target - that's why I'm asking for mem_set/copy. Adding
xy-src-copy and test it inside gem|xe_exercise_blt will close this gap.

--
Zbigniew

> 
> Many thanks,
> Karolina
> 
> > 
> > BTW first patch 1/4 won't compile in step-by-step mode because
> > it uses code from following patches.
> > 
> > --
> > Zbigniew
> > 
> > 
> > >   /**
> > >    * blt_has_fast_copy
> > >    * @fd: drm fd
> > > diff --git a/lib/intel_blt.h b/lib/intel_blt.h
> > > index b8b3d724d..d9c8883c7 100644
> > > --- a/lib/intel_blt.h
> > > +++ b/lib/intel_blt.h
> > > @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct intel_cmds_info *cmds_info,
> > >   			  uint32_t prop);
> > >   bool blt_has_block_copy(int fd);
> > > +bool blt_has_mem_copy(int fd);
> > > +bool blt_has_mem_set(int fd);
> > >   bool blt_has_fast_copy(int fd);
> > >   bool blt_has_xy_src_copy(int fd);
> > >   bool blt_has_xy_color(int fd);
> > > -- 
> > > 2.39.1
> > > 

Re: [igt-dev] [PATCH i-g-t 2/4] lib/intel_blt: check if blt commands are supported by the platforms

[Karolina Stolarek]

On 13.09.2023 09:39, Zbigniew Kempczyński wrote:
> On Mon, Sep 11, 2023 at 01:09:31PM +0200, Karolina Stolarek wrote:
>> On 4.09.2023 14:39, Zbigniew Kempczyński wrote:
>>> On Mon, Sep 04, 2023 at 04:34:56PM +0530, sai.gowtham.ch@intel.com wrote:
>>>> From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>>>
>>>> Check if mem-copy/mem-set commands are supported by fd device.
>>>>
>>>> Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
>>>> ---
>>>>    lib/intel_blt.c | 32 ++++++++++++++++++++++++++++++++
>>>>    lib/intel_blt.h |  2 ++
>>>>    2 files changed, 34 insertions(+)
>>>>
>>>> diff --git a/lib/intel_blt.c b/lib/intel_blt.c
>>>> index 429511920..b55fa9b52 100644
>>>> --- a/lib/intel_blt.c
>>>> +++ b/lib/intel_blt.c
>>>> @@ -289,6 +289,38 @@ bool blt_has_block_copy(int fd)
>>>>    	return blt_supports_command(cmds_info, XY_BLOCK_COPY);
>>>>    }
>>>> +/**
>>>> + * blt_has_mem_copy
>>>> + * @fd: drm fd
>>>> + *
>>>> + * Check if mem copy is supported by @fd device
>>>> + *
>>>> + * Returns:
>>>> + * true if it does, false otherwise.
>>>> + */
>>>> +bool blt_has_mem_copy(int fd)
>>>> +{
>>>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>>>> +
>>>> +	return blt_supports_command(cmds_info, MEM_COPY);
>>>> +}
>>>> +
>>>> +/**
>>>> + * blt_has_mem_set
>>>> + * @fd: drm fd
>>>> + *
>>>> + * Check if mem set is supported by @fd device
>>>> + *
>>>> + * Returns:
>>>> + * true if it does, false otherwise.
>>>> + */
>>>> +bool blt_has_mem_set(int fd)
>>>> +{
>>>> +	const struct intel_cmds_info *cmds_info = GET_CMDS_INFO(fd);
>>>> +
>>>> +	return blt_supports_command(cmds_info, MEM_SET);
>>>> +}
>>>> +
>>>
>>> It is not true if you'll use those functions in i915 igts.
>>> mem-set and mem-copy commands you've introduced in 1/4 patch
>>> should be part of intel_blt.[ch] library.
>>
>> Following this logic, we'd need to provide XY_SRC_COPY_BLT in intel_blt
>> library as well. We don't -- mostly because intel_blt lacks support for
>> relocations.
> 
> Yes, I hoped we will add this implementation. Adding relocations isn't
> problem here but I would stick to softpinning/vm_bind at the moment.

I was asked about adding support for relocations to intel_blt at least 
once, and I experienced it as a problem myself when working on 
gem_blits. So, it would be good to see them introduced there.

The tests that use blit commands are expected to work across 
generations. The blit library won't be widely adopted unless we provide 
support for relocations.

> Perfect would be if we claim that some command is supported we provide
> an implementation of such blit command for i915/xe.

OK, that's new to me, especially given the fact that we allow folks to 
query about supported commands even if they build them on their own. 
This library can exist on its own and doesn't have to be tied to 
intel_blt. I mean, it is now due to the review comments I got during the 
review.

But I agree, the ultimate goal would be to get everyone to use 
intel_blt, but it's not ready for it, yet.

All the best,
Karolina

> 
>>
>> blt_has_<command> are lightweight checks that only say if you can issue a
>> specific command to a platform, and they don't depend on a driver. They
>> don't guarantee that a specific blitter function is implemented in
>> intel_blt.
>>
>> This confusion shows that we should've keep intel_cmds_info and intel_blt
>> libraries separated from the beginning. Yes, they are closely related, but
>> it's intel_blt quering intel_cmds_info about hardware capabilities, not
>> implemented features.
> 
> Converging intel_blt to have implementation of supported hw blits should
> be our target - that's why I'm asking for mem_set/copy. Adding
> xy-src-copy and test it inside gem|xe_exercise_blt will close this gap.
> 
> --
> Zbigniew
> 
>>
>> Many thanks,
>> Karolina
>>
>>>
>>> BTW first patch 1/4 won't compile in step-by-step mode because
>>> it uses code from following patches.
>>>
>>> --
>>> Zbigniew
>>>
>>>
>>>>    /**
>>>>     * blt_has_fast_copy
>>>>     * @fd: drm fd
>>>> diff --git a/lib/intel_blt.h b/lib/intel_blt.h
>>>> index b8b3d724d..d9c8883c7 100644
>>>> --- a/lib/intel_blt.h
>>>> +++ b/lib/intel_blt.h
>>>> @@ -175,6 +175,8 @@ bool blt_cmd_has_property(const struct intel_cmds_info *cmds_info,
>>>>    			  uint32_t prop);
>>>>    bool blt_has_block_copy(int fd);
>>>> +bool blt_has_mem_copy(int fd);
>>>> +bool blt_has_mem_set(int fd);
>>>>    bool blt_has_fast_copy(int fd);
>>>>    bool blt_has_xy_src_copy(int fd);
>>>>    bool blt_has_xy_color(int fd);
>>>> -- 
>>>> 2.39.1
>>>>

[igt-dev] [PATCH i-g-t 3/4] lib/intel_cmds_info: Add copy commands to blt_cmd_type

[sai.gowtham.ch]

From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>

Add copy commands to blt_cmd_type which is used latter,
to check it they are supported by fd.

Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
---
 lib/intel_cmds_info.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/intel_cmds_info.h b/lib/intel_cmds_info.h
index 91d0f15ec..ec8312d56 100644
--- a/lib/intel_cmds_info.h
+++ b/lib/intel_cmds_info.h
@@ -20,6 +20,8 @@ enum blt_tiling_type {
 
 enum blt_cmd_type {
 	SRC_COPY,
+	MEM_SET,
+	MEM_COPY,
 	XY_SRC_COPY,
 	XY_FAST_COPY,
 	XY_BLOCK_COPY,
-- 
2.39.1

[igt-dev] [PATCH i-g-t 4/4] lib/intel_reg: Add copy commands in the lib

[sai.gowtham.ch]

From: Sai Gowtham Ch <sai.gowtham.ch@intel.com>

Add memory copy and set commands to the lib.

Signed-off-by: Sai Gowtham Ch <sai.gowtham.ch@intel.com>
---
 lib/intel_reg.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/intel_reg.h b/lib/intel_reg.h
index 3bf3676dc..322aec9fd 100644
--- a/lib/intel_reg.h
+++ b/lib/intel_reg.h
@@ -2564,6 +2564,10 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 #define XY_FAST_COLOR_BLT		((0x2<<29)|(0x44<<22)|0xe)
 
+/* RAW memory commands */
+#define MEM_COPY_CMD                    ((0x2 << 29)|(0x5a << 22)|0x8)
+#define MEM_SET_CMD                     ((0x2 << 29)|(0x5b << 22)|0x5)
+
 #define XY_FAST_COPY_BLT				((2<<29)|(0x42<<22)|0x8)
 /* dword 0 */
 #define   XY_FAST_COPY_SRC_TILING_LINEAR		(0 << 20)
-- 
2.39.1

[igt-dev] ✗ GitLab.Pipeline: warning for Add copy basic test to exercise blt commands (rev2)

[Patchwork]

== Series Details ==

Series: Add copy basic test to exercise blt commands (rev2)
URL   : https://patchwork.freedesktop.org/series/122615/
State : warning

== Summary ==

Pipeline status: FAILED.

see https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/pipelines/977330 for the overview.

build-containers:build-debian has failed (https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/48486597):
  time="2023-09-04T12:45:37Z" level=fatal msg="Error determining repository tags: Get https://registry.freedesktop.org/v2/gfx-ci/igt-ci-tags/build-debian-minimal/tags/list?last=commit-781e70b5d4038a4d241d8758d9ca089d374e9361&n=100: dial tcp 147.75.198.156:443: i/o timeout" 
  Building!
  STEP 1: FROM debian:buster
  Getting image source signatures
  Copying blob sha256:d6b7393fb4f375905c31c483d81ce2a2905f88aba8cb198874da2b54035bc41d
  Copying config sha256:de08540e8ff0e470ff7956df4bed403725a5f45c186e9bf495da5344ff8fbe84
  Writing manifest to image destination
  Storing signatures
  STEP 2: RUN apt-get update
  error running container: error creating container for [/bin/sh -c apt-get update]: time="2023-09-04T12:45:42Z" level=warning msg="signal: killed"
  time="2023-09-04T12:45:42Z" level=error msg="container_linux.go:346: starting container process caused \"process_linux.go:297: applying cgroup configuration for process caused \\\"mountpoint for cgroup not found\\\"\"\n"
  container_linux.go:346: starting container process caused "process_linux.go:297: applying cgroup configuration for process caused \"mountpoint for cgroup not found\""
  : exit status 1
  Error: error building at STEP "RUN apt-get update": error while running runtime: exit status 1
  section_end:1693831543:step_script
  section_start:1693831543:cleanup_file_variables
  Cleaning up project directory and file based variables
  section_end:1693831543:cleanup_file_variables
  ERROR: Job failed: exit code 1
  

build-containers:build-debian-armhf has failed (https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/48486598):
  time="2023-09-04T12:45:25Z" level=fatal msg="Error determining repository tags: Get https://registry.freedesktop.org/v2/gfx-ci/igt-ci-tags/build-debian-armhf/tags/list?last=commit-096cfce286be2570ee14f0fe6c3969afdcf5e54e&n=100: dial tcp 147.75.198.156:443: i/o timeout" 
  Building!
  STEP 1: FROM debian:buster
  Getting image source signatures
  Copying blob sha256:d6b7393fb4f375905c31c483d81ce2a2905f88aba8cb198874da2b54035bc41d
  Copying config sha256:de08540e8ff0e470ff7956df4bed403725a5f45c186e9bf495da5344ff8fbe84
  Writing manifest to image destination
  Storing signatures
  STEP 2: RUN apt-get update
  error running container: error creating container for [/bin/sh -c apt-get update]: time="2023-09-04T12:45:29Z" level=warning msg="signal: killed"
  time="2023-09-04T12:45:29Z" level=error msg="container_linux.go:346: starting container process caused \"process_linux.go:297: applying cgroup configuration for process caused \\\"mountpoint for cgroup not found\\\"\"\n"
  container_linux.go:346: starting container process caused "process_linux.go:297: applying cgroup configuration for process caused \"mountpoint for cgroup not found\""
  : exit status 1
  Error: error building at STEP "RUN apt-get update": error while running runtime: exit status 1
  section_end:1693831530:step_script
  section_start:1693831530:cleanup_file_variables
  Cleaning up project directory and file based variables
  section_end:1693831530:cleanup_file_variables
  ERROR: Job failed: exit code 1
  

build-containers:build-debian-mips has failed (https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/48486600):
  Reinitialized existing Git repository in /builds/gfx-ci/igt-ci-tags/.git/
  Checking out fd09cd4e as detached HEAD (ref is intel/IGTPW_9710)...
  
  Skipping Git submodules setup
  section_end:1693831505:get_sources
  section_start:1693831505:step_script
  Executing "step_script" stage of the job script
  Using docker image sha256:594aa868d31ee3304dee8cae8a3433c89a6fcfcf6c7d420c04cce22f60147176 for registry.freedesktop.org/wayland/ci-templates/buildah:2019-08-13.0 with digest registry.freedesktop.org/wayland/ci-templates/buildah@sha256:7dbcf22cd2c1c7d49db0dc7b4ab207c3d6a4a09bd81cc3b71a688d3727d8749f ...
  $ /host/bin/curl -s -L --cacert /host/ca-certificates.crt --retry 4 -f --retry-delay 60 https://gitlab.freedesktop.org/freedesktop/helm-gitlab-infra/-/raw/main/runner-gating/runner-gating.sh | sh
  Checking if the user of the pipeline is allowed...
  Checking if the job's project is part of a well-known group...
  Thank you for contributing to freedesktop.org
  $ podman login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
  Error: error authenticating creds for "registry.freedesktop.org": pinging docker registry returned: Get https://registry.freedesktop.org/v2/: dial tcp 147.75.198.156:443: i/o timeout
  section_end:1693831536:step_script
  section_start:1693831536:cleanup_file_variables
  Cleaning up project directory and file based variables
  section_end:1693831536:cleanup_file_variables
  ERROR: Job failed: exit code 1
  

build-containers:build-fedora has failed (https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/jobs/48486601):
  time="2023-09-04T12:45:44Z" level=fatal msg="Error determining repository tags: Get https://registry.freedesktop.org/v2/gfx-ci/igt-ci-tags/build-fedora/tags/list?last=commit-223e782226f598acc33a9943caaeb4c9b220d470&n=100: dial tcp 147.75.198.156:443: i/o timeout" 
  Building!
  STEP 1: FROM fedora:31
  Getting image source signatures
  Copying blob sha256:854946d575a439a894349addd141568875d7c1e673d3286b08250f3dde002e6a
  Copying config sha256:7e94ed77b448a8d2ff08b92d3ca743e4e862c744892d6886c73487581eb5863a
  Writing manifest to image destination
  Storing signatures
  STEP 2: RUN dnf install -y 	gcc flex bison libatomic meson ninja-build xdotool 	'pkgconfig(libdrm)' 	'pkgconfig(pciaccess)' 	'pkgconfig(libkmod)' 	'pkgconfig(libprocps)' 	'pkgconfig(libunwind)' 	'pkgconfig(libdw)' 	'pkgconfig(pixman-1)' 	'pkgconfig(valgrind)' 	'pkgconfig(cairo)' 	'pkgconfig(libudev)' 	'pkgconfig(glib-2.0)' 	'pkgconfig(gsl)' 	'pkgconfig(alsa)' 	'pkgconfig(xmlrpc)' 	'pkgconfig(xmlrpc_util)' 	'pkgconfig(xmlrpc_client)' 	'pkgconfig(json-c)' 	'pkgconfig(gtk-doc)' 	'pkgconfig(xv)' 	'pkgconfig(xrandr)' 	python3-docutils
  error running container: error creating container for [/bin/sh -c dnf install -y 	gcc flex bison libatomic meson ninja-build xdotool 	'pkgconfig(libdrm)' 	'pkgconfig(pciaccess)' 	'pkgconfig(libkmod)' 	'pkgconfig(libprocps)' 	'pkgconfig(libunwind)' 	'pkgconfig(libdw)' 	'pkgconfig(pixman-1)' 	'pkgconfig(valgrind)' 	'pkgconfig(cairo)' 	'pkgconfig(libudev)' 	'pkgconfig(glib-2.0)' 	'pkgconfig(gsl)' 	'pkgconfig(alsa)' 	'pkgconfig(xmlrpc)' 	'pkgconfig(xmlrpc_util)' 	'pkgconfig(xmlrpc_client)' 	'pkgconfig(json-c)' 	'pkgconfig(gtk-doc)' 	'pkgconfig(xv)' 	'pkgconfig(xrandr)' 	python3-docutils]: time="2023-09-04T12:45:50Z" level=warning msg="signal: killed"
  time="2023-09-04T12:45:50Z" level=error msg="container_linux.go:346: starting container process caused \"process_linux.go:297: applying cgroup configuration for process caused \\\"mountpoint for cgroup not found\\\"\"\n"
  container_linux.go:346: starting container process caused "process_linux.go:297: applying cgroup configuration for process caused \"mountpoint for cgroup not found\""
  : exit status 1
  Error: error building at STEP "RUN dnf install -y 	gcc flex bison libatomic meson ninja-build xdotool 	'pkgconfig(libdrm)' 	'pkgconfig(pciaccess)' 	'pkgconfig(libkmod)' 	'pkgconfig(libprocps)' 	'pkgconfig(libunwind)' 	'pkgconfig(libdw)' 	'pkgconfig(pixman-1)' 	'pkgconfig(valgrind)' 	'pkgconfig(cairo)' 	'pkgconfig(libudev)' 	'pkgconfig(glib-2.0)' 	'pkgconfig(gsl)' 	'pkgconfig(alsa)' 	'pkgconfig(xmlrpc)' 	'pkgconfig(xmlrpc_util)' 	'pkgconfig(xmlrpc_client)' 	'pkgconfig(json-c)' 	'pkgconfig(gtk-doc)' 	'pkgconfig(xv)' 	'pkgconfig(xrandr)' 	python3-docutils": error while running runtime: exit status 1
  section_end:1693831551:step_script
  section_start:1693831551:cleanup_file_variables
  Cleaning up project directory and file based variables
  section_end:1693831551:cleanup_file_variables
  ERROR: Job failed: exit code 1

== Logs ==

For more details see: https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags/-/pipelines/977330

[igt-dev] ✗ Fi.CI.BAT: failure for Add copy basic test to exercise blt commands (rev2)

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 8361 bytes --]

== Series Details ==

Series: Add copy basic test to exercise blt commands (rev2)
URL   : https://patchwork.freedesktop.org/series/122615/
State : failure

== Summary ==

CI Bug Log - changes from IGT_7467 -> IGTPW_9710
====================================================

Summary
-------

  **FAILURE**

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

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/index.html

Participating hosts (39 -> 39)
------------------------------

  Additional (1): fi-kbl-soraka 
  Missing    (1): fi-snb-2520m 

Possible new issues
-------------------

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

### IGT changes ###

#### Possible regressions ####

  * igt@gem_exec_suspend@basic-s0@smem:
    - bat-jsl-3:          [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/bat-jsl-3/igt@gem_exec_suspend@basic-s0@smem.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-jsl-3/igt@gem_exec_suspend@basic-s0@smem.html

  
Known issues
------------

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

### IGT changes ###

#### Issues hit ####

  * igt@core_hotunplug@unbind-rebind:
    - fi-apl-guc:         [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/fi-apl-guc/igt@core_hotunplug@unbind-rebind.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-apl-guc/igt@core_hotunplug@unbind-rebind.html

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-kbl-soraka/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@basic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-kbl-soraka/igt@gem_lmem_swapping@basic.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - bat-adlp-11:        NOTRUN -> [ABORT][7] ([i915#7977] / [i915#8469] / [i915#8668])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-adlp-11/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@i915_selftest@live@gt_pm:
    - fi-kbl-soraka:      NOTRUN -> [DMESG-FAIL][8] ([i915#1886] / [i915#7913])
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html

  * igt@i915_selftest@live@migrate:
    - bat-mtlp-6:         [PASS][9] -> [DMESG-FAIL][10] ([i915#7699])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/bat-mtlp-6/igt@i915_selftest@live@migrate.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-mtlp-6/igt@i915_selftest@live@migrate.html

  * igt@i915_suspend@basic-s3-without-i915:
    - bat-jsl-3:          [PASS][11] -> [FAIL][12] ([fdo#103375])
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/bat-jsl-3/igt@i915_suspend@basic-s3-without-i915.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-jsl-3/igt@i915_suspend@basic-s3-without-i915.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
    - fi-hsw-4770:        NOTRUN -> [SKIP][13] ([fdo#109271]) +13 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-hsw-4770/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-kbl-soraka:      NOTRUN -> [SKIP][14] ([fdo#109271]) +8 similar issues
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-kbl-soraka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence:
    - bat-dg2-11:         NOTRUN -> [SKIP][15] ([i915#1845])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-dg2-11/igt@kms_pipe_crc_basic@read-crc-frame-sequence.html

  * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1:
    - fi-hsw-4770:        NOTRUN -> [DMESG-WARN][16] ([i915#8841]) +6 similar issues
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-hsw-4770/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-vga-1.html

  * igt@kms_psr@primary_page_flip:
    - bat-rplp-1:         NOTRUN -> [SKIP][17] ([i915#1072]) +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-rplp-1/igt@kms_psr@primary_page_flip.html

  * igt@kms_psr@sprite_plane_onoff:
    - fi-hsw-4770:        NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#1072]) +3 similar issues
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
    - bat-rplp-1:         NOTRUN -> [ABORT][19] ([i915#8442] / [i915#8668] / [i915#8712])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-rplp-1/igt@kms_psr@sprite_plane_onoff.html

  
#### Possible fixes ####

  * igt@gem_exec_suspend@basic-s0@smem:
    - bat-dg2-9:          [INCOMPLETE][20] ([i915#6311]) -> [PASS][21]
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/bat-dg2-9/igt@gem_exec_suspend@basic-s0@smem.html
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-dg2-9/igt@gem_exec_suspend@basic-s0@smem.html

  * igt@kms_frontbuffer_tracking@basic:
    - fi-bsw-nick:        [FAIL][22] -> [PASS][23]
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/fi-bsw-nick/igt@kms_frontbuffer_tracking@basic.html
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/fi-bsw-nick/igt@kms_frontbuffer_tracking@basic.html

  * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
    - bat-rplp-1:         [ABORT][24] ([i915#8442] / [i915#8668]) -> [PASS][25]
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1.html
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1.html

  
#### Warnings ####

  * igt@i915_pm_backlight@basic-brightness:
    - bat-adlp-11:        [ABORT][26] ([i915#8668]) -> [SKIP][27] ([i915#3546] / [i915#7561])
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_7467/bat-adlp-11/igt@i915_pm_backlight@basic-brightness.html
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/bat-adlp-11/igt@i915_pm_backlight@basic-brightness.html

  
  [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311
  [i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
  [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
  [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
  [i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
  [i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442
  [i915#8469]: https://gitlab.freedesktop.org/drm/intel/issues/8469
  [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
  [i915#8712]: https://gitlab.freedesktop.org/drm/intel/issues/8712
  [i915#8841]: https://gitlab.freedesktop.org/drm/intel/issues/8841


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_7467 -> IGTPW_9710

  CI-20190529: 20190529
  CI_DRM_13593: 70c5bfd28eab769b048876075fc3561c3f04a54a @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_9710: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/index.html
  IGT_7467: 7467


Testlist changes
----------------

+igt@xe_copy_basic@mem-copy
+igt@xe_copy_basic@mem-set

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/index.html

[-- Attachment #2: Type: text/html, Size: 10024 bytes --]

[igt-dev] ✓ CI.xeBAT: success for Add copy basic test to exercise blt commands (rev2)

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

== Series Details ==

Series: Add copy basic test to exercise blt commands (rev2)
URL   : https://patchwork.freedesktop.org/series/122615/
State : success

== Summary ==

CI Bug Log - changes from XEIGT_7467_BAT -> XEIGTPW_9710_BAT
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  

Participating hosts (4 -> 4)
------------------------------

  No changes in participating hosts

Known issues
------------

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

### IGT changes ###

  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [Intel XE#524]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/524


Build changes
-------------

  * IGT: IGT_7467 -> IGTPW_9710

  IGTPW_9710: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_9710/index.html
  IGT_7467: 7467
  xe-354-7ec520d3a63b6e95174329108cd44359a70907ba: 7ec520d3a63b6e95174329108cd44359a70907ba

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_9710/index.html

[-- Attachment #2: Type: text/html, Size: 1620 bytes --]