Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
@ 2018-06-20 15:14 Tomasz Lis
  2018-06-20 16:59 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Tomasz Lis @ 2018-06-20 15:14 UTC (permalink / raw)
  To: igt-dev; +Cc: bartosz.dunajski

This adds a new test binary, containing tests for the Data Port Coherency
option. The tests check whether the option value is stored properly on the
kernel side, but also whether is is correctly set to proper GPU register.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>

Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
---
 tests/Makefile.sources          |   1 +
 tests/gem_ctx_cache_coherency.c | 324 ++++++++++++++++++++++++++++++++++++++++
 tests/meson.build               |   1 +
 3 files changed, 326 insertions(+)
 create mode 100644 tests/gem_ctx_cache_coherency.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ad62611..181ba9d 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -56,6 +56,7 @@ TESTS_progs = \
 	gem_cs_tlb \
 	gem_ctx_bad_destroy \
 	gem_ctx_bad_exec \
+	gem_ctx_cache_coherency \
 	gem_ctx_create \
 	gem_ctx_exec \
 	gem_ctx_isolation \
diff --git a/tests/gem_ctx_cache_coherency.c b/tests/gem_ctx_cache_coherency.c
new file mode 100644
index 0000000..715f212
--- /dev/null
+++ b/tests/gem_ctx_cache_coherency.c
@@ -0,0 +1,324 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+/** @file gem_ctx_cache_coherency.c
+ *
+ * Check that the Data port coherency settings are working.
+ */
+
+#include "igt.h"
+#include "igt_gt.h"
+#include "igt_sysfs.h"
+
+enum {
+	NONE,
+	RESET,
+	RC6,
+	SUSPEND,
+	HIBERNATE,
+	MAX_COHERENCY_TEST_MODES
+};
+
+static const char * const test_modes[] = {
+	[NONE] = "settings",
+	[RESET] = "reset",
+	[RC6] = "rc6",
+	[SUSPEND] = "suspend",
+	[HIBERNATE] = "hibernate"
+};
+
+/** Make the test be performed on non-default context (created by the test) */
+#define COHERENCY_NON_DEFAULT_CTX	(1<<0)
+/** Check for test value separation between contexts */
+#define COHERENCY_CTX_SEPARATION	(1<<1)
+/** Value of all flags set */
+#define ALL_COHERENCY_FLAGS		(COHERENCY_NON_DEFAULT_CTX | \
+					COHERENCY_CTX_SEPARATION)
+
+/* IOCTL definitions */
+#define I915_CONTEXT_PARAM_COHERENCY	0x7
+
+/* Hardware registers */
+#define HDC_CHICKEN0		(0x7300)
+#define CNL_HDC_CHICKEN0	(0xE5F0)
+#define ICL_HDC_CHICKEN0	(0xE5F4)
+/** Coherency bit within chicken0 register */
+#define HDC_FORCE_NON_COHERENT	(1<<4)
+
+static uint32_t get_context_coherency_store_register(int fd, uint32_t engine)
+{
+	const int gen = intel_gen(intel_get_drm_devid(fd));
+	if (gen >= 11)
+		return ICL_HDC_CHICKEN0;
+	if (gen >= 10)
+		return CNL_HDC_CHICKEN0;
+	return HDC_CHICKEN0;
+}
+
+#define MI_STORE_REGISTER_MEM_64_BIT_ADDR	((0x24 << 23) | 2)
+
+static int create_read_batch(struct drm_i915_gem_relocation_entry *reloc,
+			     uint32_t *batch,
+			     uint32_t dst_handle,
+			     uint32_t size,
+			     uint32_t reg_base)
+{
+	unsigned int offset = 0;
+
+	for (uint32_t index = 0; index < size; index++, offset += 4) {
+		batch[offset]   = MI_STORE_REGISTER_MEM_64_BIT_ADDR;
+		batch[offset+1] = reg_base + (index * sizeof(uint32_t));
+		batch[offset+2] = index * sizeof(uint32_t);	/* reloc */
+		batch[offset+3] = 0;
+
+		reloc[index].offset = (offset + 2) * sizeof(uint32_t);
+		reloc[index].delta = index * sizeof(uint32_t);
+		reloc[index].target_handle = dst_handle;
+		reloc[index].write_domain = I915_GEM_DOMAIN_RENDER;
+		reloc[index].read_domains = I915_GEM_DOMAIN_RENDER;
+	}
+
+	batch[offset++] = MI_BATCH_BUFFER_END;
+	batch[offset++] = 0;
+
+	return offset * sizeof(uint32_t);
+}
+
+static void do_read_registers(int fd,
+			      uint32_t ctx_id,
+			      uint32_t dst_handle,
+			      uint32_t reg_base,
+			      uint32_t size,
+			      uint32_t engine_id)
+{
+	struct drm_i915_gem_execbuffer2 execbuf;
+	struct drm_i915_gem_exec_object2 obj[2];
+	struct drm_i915_gem_relocation_entry reloc[size];
+	uint32_t batch[size * 4 + 4];
+	uint32_t handle = gem_create(fd, 4096);
+
+	memset(reloc, 0, sizeof(reloc));
+	memset(obj, 0, sizeof(obj));
+	memset(&execbuf, 0, sizeof(execbuf));
+
+	obj[0].handle = dst_handle;
+
+	obj[1].handle = handle;
+	obj[1].relocation_count = size;
+	obj[1].relocs_ptr = to_user_pointer(reloc);
+
+	execbuf.buffers_ptr = to_user_pointer(obj);
+	execbuf.buffer_count = 2;
+	execbuf.batch_len =
+		create_read_batch(reloc, batch, dst_handle, size, reg_base);
+	i915_execbuffer2_set_context_id(execbuf, ctx_id);
+	execbuf.flags = I915_EXEC_SECURE | engine_id;
+
+	gem_write(fd, handle, 0, batch, execbuf.batch_len);
+	gem_execbuf(fd, &execbuf);
+	gem_close(fd, handle);
+}
+
+/**
+ * __gem_context_set_coherency:
+ * @fd: open i915 drm file descriptor
+ * @ctx_id: i915 context id
+ * @enable: desired context coherency state
+ *
+ * This function modifies Data port coherency property of the context.
+ *
+ * Returns: An integer equal to zero for success and negative for failure
+ */
+static int __gem_context_set_coherency(int fd, uint32_t ctx_id, int enable)
+{
+	struct drm_i915_gem_context_param p;
+
+	memset(&p, 0, sizeof(p));
+	p.ctx_id = ctx_id;
+	p.size = 0;
+	p.param = I915_CONTEXT_PARAM_COHERENCY;
+	p.value = enable;
+
+	return __gem_context_set_param(fd, &p);
+}
+
+/**
+ * gem_context_set_coherency:
+ * @fd: open i915 drm file descriptor
+ * @ctx_id: i915 context id
+ * @enable: desired context coherency state
+ *
+ * Like __gem_context_set_coherency(), except we assert on failure.
+ */
+static void gem_context_set_coherency(int fd, uint32_t ctx_id, int enable)
+{
+	igt_assert(__gem_context_set_coherency(fd, ctx_id, enable) == 0);
+}
+
+static int gem_context_get_coherency(int fd, uint32_t ctx_id)
+{
+	struct drm_i915_gem_context_param p;
+	memset(&p, 0, sizeof(p));
+	p.ctx_id = ctx_id;
+	p.size = 0;
+	p.param = I915_CONTEXT_PARAM_COHERENCY;
+
+	igt_assert(__gem_context_get_param(fd, &p) == 0);
+
+	return p.value;
+}
+
+static void check_chicken_register_coherency_flag(int fd,
+				    unsigned engine,
+				    uint32_t ctx_id)
+{
+	const uint32_t reg_base = get_context_coherency_store_register(fd, engine);
+	uint32_t dst_handle = gem_create(fd, 4096);
+	uint32_t *read_regs;
+	int fg_coherency;
+
+	fg_coherency = gem_context_get_coherency(fd, ctx_id);
+
+	do_read_registers(fd,
+			  ctx_id,
+			  dst_handle,
+			  reg_base,
+			  1,
+			  engine);
+
+	read_regs = gem_mmap__cpu(fd, dst_handle, 0, 4096, PROT_READ);
+
+	gem_set_domain(fd, dst_handle, I915_GEM_DOMAIN_CPU, 0);
+	/* Coherency is enabled when non-hoherent bit is disabled */
+	igt_assert(((read_regs[0] & HDC_FORCE_NON_COHERENT) != 0) != fg_coherency);
+
+	munmap(read_regs, 4096);
+	gem_close(fd, dst_handle);
+}
+
+static uint32_t rc6_residency(int dir)
+{
+	return igt_sysfs_get_u32(dir, "power/rc6_residency_ms");
+}
+
+static void rc6_wait(int fd)
+{
+	int sysfs;
+	uint32_t residency;
+
+	sysfs = igt_sysfs_open(fd, NULL);
+	igt_assert_lte(0, sysfs);
+
+	residency = rc6_residency(sysfs);
+	igt_require(igt_wait(rc6_residency(sysfs) != residency, 10000, 2));
+
+	close(sysfs);
+}
+
+static void run_test(int fd, unsigned engine, unsigned flags, unsigned mode)
+{
+	uint32_t ctx_id = 0;
+	uint32_t ctx_clean_id;
+	uint32_t ctx_dirty_id;
+
+	gem_require_ring(fd, engine);
+	/* Only run RESET tests when GPU Reset functionality is available.
+	 */
+	if (mode == RESET)
+		igt_require(gem_gpu_reset_enabled(fd));
+
+	if (flags & COHERENCY_NON_DEFAULT_CTX)
+		ctx_id = gem_context_create(fd);
+
+	gem_context_set_coherency(fd, ctx_id, 1);
+
+	if (flags & COHERENCY_CTX_SEPARATION) {
+		ctx_dirty_id = gem_context_create(fd);
+		//gem_context_set_coherency(fd, ctx_dirty_id, 0); // this is default, no need to set
+		igt_assert(gem_context_get_coherency(fd, ctx_dirty_id) == 0);
+		check_chicken_register_coherency_flag(fd, engine, ctx_dirty_id);
+	}
+
+	igt_assert(gem_context_get_coherency(fd, ctx_id) == 1);
+	check_chicken_register_coherency_flag(fd, engine, ctx_id);
+
+	/* Check if the values are preserved across power mode changes - one change per run */
+	switch (mode) {
+	case NONE:	break;
+	case RESET:	igt_force_gpu_reset(fd);	break;
+	case SUSPEND:	igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
+						      SUSPEND_TEST_NONE); break;
+	case HIBERNATE:	igt_system_suspend_autoresume(SUSPEND_STATE_DISK,
+						      SUSPEND_TEST_NONE); break;
+	case RC6:	rc6_wait(fd);			break;
+	}
+
+	igt_assert(gem_context_get_coherency(fd, ctx_id) == 1);
+	check_chicken_register_coherency_flag(fd, engine, ctx_id);
+
+	if (flags & COHERENCY_CTX_SEPARATION) {
+		ctx_clean_id = gem_context_create(fd);
+		check_chicken_register_coherency_flag(fd, engine, ctx_dirty_id);
+		check_chicken_register_coherency_flag(fd, engine, ctx_clean_id);
+		gem_context_destroy(fd, ctx_dirty_id);
+		gem_context_destroy(fd, ctx_clean_id);
+	}
+
+	if (ctx_id)
+		gem_context_destroy(fd, ctx_id);
+}
+
+igt_main
+{
+	const struct intel_execution_engine *e;
+	int fd = -1;
+
+	igt_fixture {
+		fd = drm_open_driver(DRIVER_INTEL);
+		igt_require_gem(fd);
+	}
+
+	for (e = intel_execution_engines; e->name; e++) {
+		/* Check only the render engine, which is also used for compute
+		 */
+		if (e->exec_id != I915_EXEC_RENDER)
+			continue;
+
+		for (unsigned mode = NONE; mode < MAX_COHERENCY_TEST_MODES; mode++) {
+			for (unsigned flags = 0; flags < ALL_COHERENCY_FLAGS + 1; flags++) {
+
+				igt_subtest_f("coherency-%s%s%s-%s",
+					      test_modes[mode],
+					      flags & COHERENCY_NON_DEFAULT_CTX ? "-ctx": "",
+					      flags & COHERENCY_CTX_SEPARATION ? "-sep": "",
+					      e->name) {
+					run_test(fd, e->exec_id | e->flags, flags, mode);
+				}
+			}
+		}
+	}
+
+	igt_fixture
+		close(fd);
+}
diff --git a/tests/meson.build b/tests/meson.build
index cedb4ff..b7094ce 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -33,6 +33,7 @@ test_progs = [
 	'gem_cs_tlb',
 	'gem_ctx_bad_destroy',
 	'gem_ctx_bad_exec',
+	'gem_ctx_cache_coherency',
 	'gem_ctx_create',
 	'gem_ctx_exec',
 	'gem_ctx_isolation',
-- 
2.7.4

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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [igt-dev] ✓ Fi.CI.BAT: success for Data Port Cache Coherency tests.
  2018-06-20 15:14 [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests Tomasz Lis
@ 2018-06-20 16:59 ` Patchwork
  2018-06-20 23:13 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
  2018-06-21  5:53 ` [igt-dev] [PATCH i-g-t v1] " Joonas Lahtinen
  2 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2018-06-20 16:59 UTC (permalink / raw)
  To: Tomasz Lis; +Cc: igt-dev

== Series Details ==

Series: Data Port Cache Coherency tests.
URL   : https://patchwork.freedesktop.org/series/45098/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4348 -> IGTPW_1492 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/45098/revisions/1/mbox/

== Known issues ==

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

  === IGT changes ===

    ==== Possible fixes ====

    igt@drv_module_reload@basic-reload:
      fi-glk-j4005:       DMESG-WARN (fdo#106248, fdo#106725) -> PASS

    
  fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248
  fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725


== Participating hosts (44 -> 38) ==

  Additional (1): fi-hsw-peppy 
  Missing    (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 


== Build changes ==

    * IGT: IGT_4526 -> IGTPW_1492

  CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1492: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1492/
  IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools



== Testlist changes ==

+igt@gem_ctx_cache_coherency@coherency-hibernate-ctx-render
+igt@gem_ctx_cache_coherency@coherency-hibernate-ctx-sep-render
+igt@gem_ctx_cache_coherency@coherency-hibernate-render
+igt@gem_ctx_cache_coherency@coherency-hibernate-sep-render
+igt@gem_ctx_cache_coherency@coherency-rc6-ctx-render
+igt@gem_ctx_cache_coherency@coherency-rc6-ctx-sep-render
+igt@gem_ctx_cache_coherency@coherency-rc6-render
+igt@gem_ctx_cache_coherency@coherency-rc6-sep-render
+igt@gem_ctx_cache_coherency@coherency-reset-ctx-render
+igt@gem_ctx_cache_coherency@coherency-reset-ctx-sep-render
+igt@gem_ctx_cache_coherency@coherency-reset-render
+igt@gem_ctx_cache_coherency@coherency-reset-sep-render
+igt@gem_ctx_cache_coherency@coherency-settings-ctx-render
+igt@gem_ctx_cache_coherency@coherency-settings-ctx-sep-render
+igt@gem_ctx_cache_coherency@coherency-settings-render
+igt@gem_ctx_cache_coherency@coherency-settings-sep-render
+igt@gem_ctx_cache_coherency@coherency-suspend-ctx-render
+igt@gem_ctx_cache_coherency@coherency-suspend-ctx-sep-render
+igt@gem_ctx_cache_coherency@coherency-suspend-render
+igt@gem_ctx_cache_coherency@coherency-suspend-sep-render

== Logs ==

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [igt-dev] ✗ Fi.CI.IGT: failure for Data Port Cache Coherency tests.
  2018-06-20 15:14 [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests Tomasz Lis
  2018-06-20 16:59 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
@ 2018-06-20 23:13 ` Patchwork
  2018-06-21  5:53 ` [igt-dev] [PATCH i-g-t v1] " Joonas Lahtinen
  2 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2018-06-20 23:13 UTC (permalink / raw)
  To: Tomasz Lis; +Cc: igt-dev

== Series Details ==

Series: Data Port Cache Coherency tests.
URL   : https://patchwork.freedesktop.org/series/45098/
State : failure

== Summary ==

= CI Bug Log - changes from IGT_4526_full -> IGTPW_1492_full =

== Summary - FAILURE ==

  Serious unknown changes coming with IGTPW_1492_full absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_1492_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/45098/revisions/1/mbox/

== Possible new issues ==

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

  === IGT changes ===

    ==== Possible regressions ====

    {igt@gem_ctx_cache_coherency@coherency-rc6-ctx-sep-render}:
      shard-apl:          NOTRUN -> FAIL +15

    {igt@gem_ctx_cache_coherency@coherency-reset-ctx-sep-render}:
      shard-glk:          NOTRUN -> FAIL +15

    {igt@gem_ctx_cache_coherency@coherency-settings-ctx-sep-render}:
      shard-kbl:          NOTRUN -> FAIL +15

    {igt@gem_ctx_cache_coherency@coherency-settings-render}:
      shard-snb:          NOTRUN -> FAIL +15

    {igt@gem_ctx_cache_coherency@coherency-suspend-render}:
      shard-hsw:          NOTRUN -> FAIL +15

    igt@pm_rpm@cursor:
      shard-kbl:          PASS -> DMESG-WARN

    
    ==== Warnings ====

    igt@gem_shrink@reclaim:
      shard-kbl:          PASS -> SKIP
      shard-glk:          PASS -> SKIP
      shard-apl:          PASS -> SKIP

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

    
== Known issues ==

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

  === IGT changes ===

    ==== Issues hit ====

    igt@drv_selftest@live_gtt:
      shard-apl:          PASS -> FAIL (fdo#105347)

    igt@gem_exec_schedule@pi-ringfull-vebox:
      shard-kbl:          NOTRUN -> FAIL (fdo#103158)

    igt@gem_wait@basic-busy-all:
      shard-snb:          PASS -> INCOMPLETE (fdo#105411)

    igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing:
      shard-glk:          PASS -> FAIL (fdo#105703)

    igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
      shard-glk:          PASS -> FAIL (fdo#106509)

    igt@kms_flip@flip-vs-expired-vblank-interruptible:
      shard-apl:          PASS -> FAIL (fdo#102887, fdo#105363)

    igt@kms_flip@plain-flip-ts-check-interruptible:
      shard-glk:          PASS -> FAIL (fdo#100368)

    igt@kms_flip_tiling@flip-y-tiled:
      shard-glk:          PASS -> FAIL (fdo#104724, fdo#103822)

    igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-cpu:
      shard-glk:          PASS -> FAIL (fdo#104724, fdo#103167)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      shard-kbl:          PASS -> INCOMPLETE (fdo#103665)

    igt@kms_plane_multiple@atomic-pipe-a-tiling-x:
      shard-snb:          PASS -> FAIL (fdo#104724, fdo#103166)

    igt@kms_rotation_crc@sprite-rotation-90:
      shard-kbl:          PASS -> FAIL (fdo#104724, fdo#103925)

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

    igt@perf@polling:
      shard-hsw:          PASS -> FAIL (fdo#102252)

    igt@testdisplay:
      shard-glk:          PASS -> INCOMPLETE (fdo#103359, k.org#198133)

    
    ==== Possible fixes ====

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

    igt@kms_flip@plain-flip-ts-check:
      shard-glk:          FAIL (fdo#100368) -> PASS

    igt@kms_flip_tiling@flip-to-y-tiled:
      shard-glk:          FAIL (fdo#104724, fdo#103822) -> PASS

    igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt:
      shard-snb:          INCOMPLETE (fdo#105411) -> PASS

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

    igt@pm_rpm@system-suspend-execbuf:
      shard-kbl:          INCOMPLETE (fdo#103665) -> PASS

    
    ==== Warnings ====

    igt@drv_selftest@live_gtt:
      shard-glk:          FAIL (fdo#105347) -> INCOMPLETE (fdo#103359, k.org#198133)

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

  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
  fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665
  fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822
  fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411
  fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509
  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 (5 -> 5) ==

  No changes in participating hosts


== Build changes ==

    * IGT: IGT_4526 -> IGTPW_1492
    * Linux: CI_DRM_4347 -> CI_DRM_4348

  CI_DRM_4347: 5b7806eb03ba0ce0c1bfe75b2e303506c076965d @ git://anongit.freedesktop.org/gfx-ci/linux
  CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_1492: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1492/
  IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
  2018-06-20 15:14 [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests Tomasz Lis
  2018-06-20 16:59 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
  2018-06-20 23:13 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
@ 2018-06-21  5:53 ` Joonas Lahtinen
  2018-06-21 11:54   ` Lis, Tomasz
  2 siblings, 1 reply; 9+ messages in thread
From: Joonas Lahtinen @ 2018-06-21  5:53 UTC (permalink / raw)
  To: Tomasz Lis, igt-dev; +Cc: bartosz.dunajski

Quoting Tomasz Lis (2018-06-20 18:14:38)
> This adds a new test binary, containing tests for the Data Port Coherency
> option. The tests check whether the option value is stored properly on the
> kernel side, but also whether is is correctly set to proper GPU register.

I'm fairly sure there already was review feedback that simply checking
the register state is not a good IGT test.

IGT tests make sure that whatever uAPI the kernel has, the promised effects
of that uAPI do not get broken. And the promise for cache coherency uAPI
for surely isn't that some register value gets written, it's that the
cache coherency is traded with some performance. The chicken bits or the
whole implementation of the feature might be turned upside down, but as
long as the userspace is still working, userspace should not care.

So the chicken bit setting should be scrapped, and actual cache
coherency observed. It might be a worthy kernel selftest that register
writes stick and remain over sleep states as a generic thing, but not
here.

If you don't address the feedback given, but hammer the mailing list
without addressing it, don't expect further feedback.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
  2018-06-21  5:53 ` [igt-dev] [PATCH i-g-t v1] " Joonas Lahtinen
@ 2018-06-21 11:54   ` Lis, Tomasz
  2018-07-16 12:48     ` Joonas Lahtinen
  0 siblings, 1 reply; 9+ messages in thread
From: Lis, Tomasz @ 2018-06-21 11:54 UTC (permalink / raw)
  To: Joonas Lahtinen, igt-dev; +Cc: bartosz.dunajski


On 2018-06-21 07:53, Joonas Lahtinen wrote:
> Quoting Tomasz Lis (2018-06-20 18:14:38)
>> This adds a new test binary, containing tests for the Data Port Coherency
>> option. The tests check whether the option value is stored properly on the
>> kernel side, but also whether is is correctly set to proper GPU register.
> I'm fairly sure there already was review feedback that simply checking
> the register state is not a good IGT test.
>
> IGT tests make sure that whatever uAPI the kernel has, the promised effects
> of that uAPI do not get broken. And the promise for cache coherency uAPI
> for surely isn't that some register value gets written, it's that the
> cache coherency is traded with some performance. The chicken bits or the
> whole implementation of the feature might be turned upside down, but as
> long as the userspace is still working, userspace should not care.
>
> So the chicken bit setting should be scrapped, and actual cache
> coherency observed. It might be a worthy kernel selftest that register
> writes stick and remain over sleep states as a generic thing, but not
> here.
>
> If you don't address the feedback given, but hammer the mailing list
> without addressing it, don't expect further feedback.
>
> Regards, Joonas
Thank you for your feedback, both now and in the previous round.

Developing a test which checks whether the hardware is really doing what 
is should is possible, but also it is quite problematic.
On the UMD side, there are Khronos OCL 2.1 tests which verify coherency; 
but they have graphics pipeline fully configured, and it is a lot easier 
to verify it on the user level.

We could write a test which does the following:
- Allocates a very big buffer
- Executes a shader which fills the whole buffer over and over, with 
increasing numbers
- Does it long enough for the IGT to notice changes in the buffer while 
the shader is being executed
- If there were increasing changes in buffer content - test passes

But there are issues with this approach:
- We need a lot of memory to do the test; the faster the GPU is, the 
more we need
- We need to write a shader, in assembly, for each platform
- A new shader will need to be written to test future platforms
- We need to configure the graphics pipeline within IGT test, which is 
not trivial
- The test results may be unreliable because even if coherency is 
disabled, there is no guarantee that the memory will not be updated
- Actually the buffer probably will be updated while the shader is 
executing without coherency, but details may depend on platform, 
pipeline settings and buffer size
- The test results may be unreliable due to timing, so it will likely 
produce sporadics
- The test would require a separate pre-silicon part
- Test execution time would be considerable

After reading the answers in previous review, I agree that to achieve 
the IGTs goal testing hardware should be included. But I don't think 
it's a good idea here.

But maybe there is an easier way to test the functionality which I 
didn't noticed? Or maybe some of my arguments are invalid?

We do have gem_gpgpu_fill test which does execute a simple shader. The 
shader needs to be written for each gen to re-enable the test, but it 
works.

-Tomasz

Adding the last mail in previous review, for reference:

Quoting Lis, Tomasz (2018-03-20 18:27:44)
 >
 >
 > On 2018-03-20 16:36, Chris Wilson wrote:
 > > Quoting Chris Wilson (2018-03-20 15:30:59)
 > >> Quoting Tomasz Lis (2018-03-20 15:12:32)
 > >>> From: "Lis, Tomasz" <tomasz.lis@intel.com>
 > >>>
 > >>> This adds a new test binary, containing tests for the Data Port
 > >>> Coherency option. The tests check whether the option is correctly
 > >>> set to proper GPU register.
 > >> But where's the test that it *does* anything? I.e. what's the
 > >> expected change in user visible behaviour? (What does the flag
 > >> really mean, now and for years to come?)
 >
 > With a test that "does anything" (which I understand as - submitting 
large workload and checking the coherency while the workload is 
executing) we would be testing the hardware, not the kernel.
 > I prepared a test binary designed to test the kernel change I 
proposed. This is what I consider good practices.
 > Do we have another approach when developing IGT?

What we try to avoid is "visible userspace breakage". So when some added 
kernel feature introduces a behavioral change for userspace, the 
accompanying tests should make sure that change is observed with the 
feature bit flipped. That's pretty much the only way we can make sure 
the written userspace applications using the feature will keep working 
when going forward.

Writing to MMIO address X so that the bits Y and Z stick will only 
guarantee that there is some hardware register in there. It is not very 
valuable of a test because making sure the feature keeps working will 
implicitly test the same thing.

Hopefully this answers the question.

Regards, Joonas

 >
 > > To be clear; this test illustrates that it is a context register
 > > being tweaked and not an execbuf property.
 > > -Chris
 > I agree the hardware flag is within hardware context. Both the kernel
 > patch and the IGT test are accessing that bit, so they both illustrate
 > it is a context register.
 > But both patches also implement UMD interface to that flag via execbuf
 > flag. What do you mean when you write this is "not an execbuf property"?
 >
 >

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
  2018-06-21 11:54   ` Lis, Tomasz
@ 2018-07-16 12:48     ` Joonas Lahtinen
  2018-07-17 13:47       ` Lis, Tomasz
  0 siblings, 1 reply; 9+ messages in thread
From: Joonas Lahtinen @ 2018-07-16 12:48 UTC (permalink / raw)
  To: Lis, Tomasz, igt-dev; +Cc: bartosz.dunajski

Quoting Lis, Tomasz (2018-06-21 14:54:47)
> 
> On 2018-06-21 07:53, Joonas Lahtinen wrote:
> > Quoting Tomasz Lis (2018-06-20 18:14:38)
> >> This adds a new test binary, containing tests for the Data Port Coherency
> >> option. The tests check whether the option value is stored properly on the
> >> kernel side, but also whether is is correctly set to proper GPU register.
> > I'm fairly sure there already was review feedback that simply checking
> > the register state is not a good IGT test.
> >
> > IGT tests make sure that whatever uAPI the kernel has, the promised effects
> > of that uAPI do not get broken. And the promise for cache coherency uAPI
> > for surely isn't that some register value gets written, it's that the
> > cache coherency is traded with some performance. The chicken bits or the
> > whole implementation of the feature might be turned upside down, but as
> > long as the userspace is still working, userspace should not care.
> >
> > So the chicken bit setting should be scrapped, and actual cache
> > coherency observed. It might be a worthy kernel selftest that register
> > writes stick and remain over sleep states as a generic thing, but not
> > here.
> >
> > If you don't address the feedback given, but hammer the mailing list
> > without addressing it, don't expect further feedback.
> >
> > Regards, Joonas
> Thank you for your feedback, both now and in the previous round.
> 
> Developing a test which checks whether the hardware is really doing what 
> is should is possible, but also it is quite problematic.
> On the UMD side, there are Khronos OCL 2.1 tests which verify coherency; 
> but they have graphics pipeline fully configured, and it is a lot easier 
> to verify it on the user level.
> 
> We could write a test which does the following:
> - Allocates a very big buffer
> - Executes a shader which fills the whole buffer over and over, with 
> increasing numbers
> - Does it long enough for the IGT to notice changes in the buffer while 
> the shader is being executed
> - If there were increasing changes in buffer content - test passes
> 
> But there are issues with this approach:
> - We need a lot of memory to do the test; the faster the GPU is, the 
> more we need
> - We need to write a shader, in assembly, for each platform
> - A new shader will need to be written to test future platforms
> - We need to configure the graphics pipeline within IGT test, which is 
> not trivial
> - The test results may be unreliable because even if coherency is 
> disabled, there is no guarantee that the memory will not be updated
> - Actually the buffer probably will be updated while the shader is 
> executing without coherency, but details may depend on platform, 
> pipeline settings and buffer size
> - The test results may be unreliable due to timing, so it will likely 
> produce sporadics
> - The test would require a separate pre-silicon part
> - Test execution time would be considerable
> 
> After reading the answers in previous review, I agree that to achieve 
> the IGTs goal testing hardware should be included. But I don't think 
> it's a good idea here.

Without testing what is actually the promised effect for userspace, we
just can't succeed maintaining the feature. There surely are use-cases
where it's noticed if the feature is not working, and those would be
the prime candidates for extracting the testing logic. We should
definitely be able to accumulate execution time if we run a little bit
of the test in each CI run.

Just looking at register values is simply not going to make it, the
registers could be just sitting there, not effecting the HW operation on
a future gen.

Hopefully this clarifies enough the expected kind of test.

Regards, Joonas

> 
> But maybe there is an easier way to test the functionality which I 
> didn't noticed? Or maybe some of my arguments are invalid?
> 
> We do have gem_gpgpu_fill test which does execute a simple shader. The 
> shader needs to be written for each gen to re-enable the test, but it 
> works.
> 
> -Tomasz
> 
> Adding the last mail in previous review, for reference:
> 
> Quoting Lis, Tomasz (2018-03-20 18:27:44)
>  >
>  >
>  > On 2018-03-20 16:36, Chris Wilson wrote:
>  > > Quoting Chris Wilson (2018-03-20 15:30:59)
>  > >> Quoting Tomasz Lis (2018-03-20 15:12:32)
>  > >>> From: "Lis, Tomasz" <tomasz.lis@intel.com>
>  > >>>
>  > >>> This adds a new test binary, containing tests for the Data Port
>  > >>> Coherency option. The tests check whether the option is correctly
>  > >>> set to proper GPU register.
>  > >> But where's the test that it *does* anything? I.e. what's the
>  > >> expected change in user visible behaviour? (What does the flag
>  > >> really mean, now and for years to come?)
>  >
>  > With a test that "does anything" (which I understand as - submitting 
> large workload and checking the coherency while the workload is 
> executing) we would be testing the hardware, not the kernel.
>  > I prepared a test binary designed to test the kernel change I 
> proposed. This is what I consider good practices.
>  > Do we have another approach when developing IGT?
> 
> What we try to avoid is "visible userspace breakage". So when some added 
> kernel feature introduces a behavioral change for userspace, the 
> accompanying tests should make sure that change is observed with the 
> feature bit flipped. That's pretty much the only way we can make sure 
> the written userspace applications using the feature will keep working 
> when going forward.
> 
> Writing to MMIO address X so that the bits Y and Z stick will only 
> guarantee that there is some hardware register in there. It is not very 
> valuable of a test because making sure the feature keeps working will 
> implicitly test the same thing.
> 
> Hopefully this answers the question.
> 
> Regards, Joonas
> 
>  >
>  > > To be clear; this test illustrates that it is a context register
>  > > being tweaked and not an execbuf property.
>  > > -Chris
>  > I agree the hardware flag is within hardware context. Both the kernel
>  > patch and the IGT test are accessing that bit, so they both illustrate
>  > it is a context register.
>  > But both patches also implement UMD interface to that flag via execbuf
>  > flag. What do you mean when you write this is "not an execbuf property"?
>  >
>  >
> 
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
  2018-07-16 12:48     ` Joonas Lahtinen
@ 2018-07-17 13:47       ` Lis, Tomasz
  2018-07-18 13:22         ` Tvrtko Ursulin
  0 siblings, 1 reply; 9+ messages in thread
From: Lis, Tomasz @ 2018-07-17 13:47 UTC (permalink / raw)
  To: Joonas Lahtinen, igt-dev; +Cc: bartosz.dunajski



On 2018-07-16 14:48, Joonas Lahtinen wrote:
> Quoting Lis, Tomasz (2018-06-21 14:54:47)
>> On 2018-06-21 07:53, Joonas Lahtinen wrote:
>>> Quoting Tomasz Lis (2018-06-20 18:14:38)
>>>> This adds a new test binary, containing tests for the Data Port Coherency
>>>> option. The tests check whether the option value is stored properly on the
>>>> kernel side, but also whether is is correctly set to proper GPU register.
>>> I'm fairly sure there already was review feedback that simply checking
>>> the register state is not a good IGT test.
>>>
>>> IGT tests make sure that whatever uAPI the kernel has, the promised effects
>>> of that uAPI do not get broken. And the promise for cache coherency uAPI
>>> for surely isn't that some register value gets written, it's that the
>>> cache coherency is traded with some performance. The chicken bits or the
>>> whole implementation of the feature might be turned upside down, but as
>>> long as the userspace is still working, userspace should not care.
>>>
>>> So the chicken bit setting should be scrapped, and actual cache
>>> coherency observed. It might be a worthy kernel selftest that register
>>> writes stick and remain over sleep states as a generic thing, but not
>>> here.
>>>
>>> If you don't address the feedback given, but hammer the mailing list
>>> without addressing it, don't expect further feedback.
>>>
>>> Regards, Joonas
>> Thank you for your feedback, both now and in the previous round.
>>
>> Developing a test which checks whether the hardware is really doing what
>> is should is possible, but also it is quite problematic.
>> On the UMD side, there are Khronos OCL 2.1 tests which verify coherency;
>> but they have graphics pipeline fully configured, and it is a lot easier
>> to verify it on the user level.
>>
>> We could write a test which does the following:
>> - Allocates a very big buffer
>> - Executes a shader which fills the whole buffer over and over, with
>> increasing numbers
>> - Does it long enough for the IGT to notice changes in the buffer while
>> the shader is being executed
>> - If there were increasing changes in buffer content - test passes
>>
>> But there are issues with this approach:
>> - We need a lot of memory to do the test; the faster the GPU is, the
>> more we need
>> - We need to write a shader, in assembly, for each platform
>> - A new shader will need to be written to test future platforms
>> - We need to configure the graphics pipeline within IGT test, which is
>> not trivial
>> - The test results may be unreliable because even if coherency is
>> disabled, there is no guarantee that the memory will not be updated
>> - Actually the buffer probably will be updated while the shader is
>> executing without coherency, but details may depend on platform,
>> pipeline settings and buffer size
>> - The test results may be unreliable due to timing, so it will likely
>> produce sporadics
>> - The test would require a separate pre-silicon part
>> - Test execution time would be considerable
>>
>> After reading the answers in previous review, I agree that to achieve
>> the IGTs goal testing hardware should be included. But I don't think
>> it's a good idea here.
> Without testing what is actually the promised effect for userspace, we
> just can't succeed maintaining the feature. There surely are use-cases
> where it's noticed if the feature is not working, and those would be
> the prime candidates for extracting the testing logic. We should
> definitely be able to accumulate execution time if we run a little bit
> of the test in each CI run.
>
> Just looking at register values is simply not going to make it, the
> registers could be just sitting there, not effecting the HW operation on
> a future gen.
>
> Hopefully this clarifies enough the expected kind of test.
>
> Regards, Joonas
Note that it still won't be possible to test future gens, because the 
test will have to be re-developed for each gen.
But I did used that argument already. I don't have any more arguments.

Since I wasn't able to convince you, I will start estimating effort 
required to develop the test within I-G-T which verifies coherency using 
a shared buffer.
-Tomasz
>> But maybe there is an easier way to test the functionality which I
>> didn't noticed? Or maybe some of my arguments are invalid?
>>
>> We do have gem_gpgpu_fill test which does execute a simple shader. The
>> shader needs to be written for each gen to re-enable the test, but it
>> works.
>>
>> -Tomasz
>>
>> Adding the last mail in previous review, for reference:
>>
>> Quoting Lis, Tomasz (2018-03-20 18:27:44)
>>   >
>>   >
>>   > On 2018-03-20 16:36, Chris Wilson wrote:
>>   > > Quoting Chris Wilson (2018-03-20 15:30:59)
>>   > >> Quoting Tomasz Lis (2018-03-20 15:12:32)
>>   > >>> From: "Lis, Tomasz" <tomasz.lis@intel.com>
>>   > >>>
>>   > >>> This adds a new test binary, containing tests for the Data Port
>>   > >>> Coherency option. The tests check whether the option is correctly
>>   > >>> set to proper GPU register.
>>   > >> But where's the test that it *does* anything? I.e. what's the
>>   > >> expected change in user visible behaviour? (What does the flag
>>   > >> really mean, now and for years to come?)
>>   >
>>   > With a test that "does anything" (which I understand as - submitting
>> large workload and checking the coherency while the workload is
>> executing) we would be testing the hardware, not the kernel.
>>   > I prepared a test binary designed to test the kernel change I
>> proposed. This is what I consider good practices.
>>   > Do we have another approach when developing IGT?
>>
>> What we try to avoid is "visible userspace breakage". So when some added
>> kernel feature introduces a behavioral change for userspace, the
>> accompanying tests should make sure that change is observed with the
>> feature bit flipped. That's pretty much the only way we can make sure
>> the written userspace applications using the feature will keep working
>> when going forward.
>>
>> Writing to MMIO address X so that the bits Y and Z stick will only
>> guarantee that there is some hardware register in there. It is not very
>> valuable of a test because making sure the feature keeps working will
>> implicitly test the same thing.
>>
>> Hopefully this answers the question.
>>
>> Regards, Joonas
>>
>>   >
>>   > > To be clear; this test illustrates that it is a context register
>>   > > being tweaked and not an execbuf property.
>>   > > -Chris
>>   > I agree the hardware flag is within hardware context. Both the kernel
>>   > patch and the IGT test are accessing that bit, so they both illustrate
>>   > it is a context register.
>>   > But both patches also implement UMD interface to that flag via execbuf
>>   > flag. What do you mean when you write this is "not an execbuf property"?
>>   >
>>   >
>>

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
  2018-07-17 13:47       ` Lis, Tomasz
@ 2018-07-18 13:22         ` Tvrtko Ursulin
  2018-07-19 17:34           ` Lis, Tomasz
  0 siblings, 1 reply; 9+ messages in thread
From: Tvrtko Ursulin @ 2018-07-18 13:22 UTC (permalink / raw)
  To: Lis, Tomasz, Joonas Lahtinen, igt-dev; +Cc: bartosz.dunajski


On 17/07/2018 14:47, Lis, Tomasz wrote:
> 
> 
> On 2018-07-16 14:48, Joonas Lahtinen wrote:
>> Quoting Lis, Tomasz (2018-06-21 14:54:47)
>>> On 2018-06-21 07:53, Joonas Lahtinen wrote:
>>>> Quoting Tomasz Lis (2018-06-20 18:14:38)
>>>>> This adds a new test binary, containing tests for the Data Port 
>>>>> Coherency
>>>>> option. The tests check whether the option value is stored properly 
>>>>> on the
>>>>> kernel side, but also whether is is correctly set to proper GPU 
>>>>> register.
>>>> I'm fairly sure there already was review feedback that simply checking
>>>> the register state is not a good IGT test.
>>>>
>>>> IGT tests make sure that whatever uAPI the kernel has, the promised 
>>>> effects
>>>> of that uAPI do not get broken. And the promise for cache coherency 
>>>> uAPI
>>>> for surely isn't that some register value gets written, it's that the
>>>> cache coherency is traded with some performance. The chicken bits or 
>>>> the
>>>> whole implementation of the feature might be turned upside down, but as
>>>> long as the userspace is still working, userspace should not care.
>>>>
>>>> So the chicken bit setting should be scrapped, and actual cache
>>>> coherency observed. It might be a worthy kernel selftest that register
>>>> writes stick and remain over sleep states as a generic thing, but not
>>>> here.
>>>>
>>>> If you don't address the feedback given, but hammer the mailing list
>>>> without addressing it, don't expect further feedback.
>>>>
>>>> Regards, Joonas
>>> Thank you for your feedback, both now and in the previous round.
>>>
>>> Developing a test which checks whether the hardware is really doing what
>>> is should is possible, but also it is quite problematic.
>>> On the UMD side, there are Khronos OCL 2.1 tests which verify coherency;
>>> but they have graphics pipeline fully configured, and it is a lot easier
>>> to verify it on the user level.
>>>
>>> We could write a test which does the following:
>>> - Allocates a very big buffer
>>> - Executes a shader which fills the whole buffer over and over, with
>>> increasing numbers
>>> - Does it long enough for the IGT to notice changes in the buffer while
>>> the shader is being executed
>>> - If there were increasing changes in buffer content - test passes
>>>
>>> But there are issues with this approach:
>>> - We need a lot of memory to do the test; the faster the GPU is, the
>>> more we need
>>> - We need to write a shader, in assembly, for each platform
>>> - A new shader will need to be written to test future platforms
>>> - We need to configure the graphics pipeline within IGT test, which is
>>> not trivial
>>> - The test results may be unreliable because even if coherency is
>>> disabled, there is no guarantee that the memory will not be updated
>>> - Actually the buffer probably will be updated while the shader is
>>> executing without coherency, but details may depend on platform,
>>> pipeline settings and buffer size
>>> - The test results may be unreliable due to timing, so it will likely
>>> produce sporadics
>>> - The test would require a separate pre-silicon part
>>> - Test execution time would be considerable
>>>
>>> After reading the answers in previous review, I agree that to achieve
>>> the IGTs goal testing hardware should be included. But I don't think
>>> it's a good idea here.
>> Without testing what is actually the promised effect for userspace, we
>> just can't succeed maintaining the feature. There surely are use-cases
>> where it's noticed if the feature is not working, and those would be
>> the prime candidates for extracting the testing logic. We should
>> definitely be able to accumulate execution time if we run a little bit
>> of the test in each CI run.
>>
>> Just looking at register values is simply not going to make it, the
>> registers could be just sitting there, not effecting the HW operation on
>> a future gen.
>>
>> Hopefully this clarifies enough the expected kind of test.
>>
>> Regards, Joonas
> Note that it still won't be possible to test future gens, because the 
> test will have to be re-developed for each gen.
> But I did used that argument already. I don't have any more arguments.
> 
> Since I wasn't able to convince you, I will start estimating effort 
> required to develop the test within I-G-T which verifies coherency using 
> a shared buffer.

Sounds like the dilemma is whether we should be testing the driver or 
hardware. We can of course test both, or even test the driver indirectly 
via testing the hardware.

It sounds reasonable to attempt to test the hardware (that it is really 
coherent when enabled, or vice versa). It is simpler in a way since then 
you don't need to embed knowledge on what the register and bit are per 
Gen. But yeah, to test coherency I do understand you also need some gen 
dependant code. Existing rendercopy copy wouldn't work for this?

But I don't understand the low-level workings of the feature well enough 
to know why it is so difficult to trigger non-coherency from a test.

We do have stress tests which hammer on something and rely only on 
occasional failures to flag up problems, so not being to trigger the 
problem in 100% of runs per-se is not a showstopper.

If it is indeed very difficult, would it be easier to start with trying 
to detect two levels of performance between non-coherent and coherent 
modes? That way we would know setting the bit has some effect at least 
and is not completely ignored by the hardware.

Regards,

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests.
  2018-07-18 13:22         ` Tvrtko Ursulin
@ 2018-07-19 17:34           ` Lis, Tomasz
  0 siblings, 0 replies; 9+ messages in thread
From: Lis, Tomasz @ 2018-07-19 17:34 UTC (permalink / raw)
  To: Tvrtko Ursulin, Joonas Lahtinen, igt-dev; +Cc: bartosz.dunajski



On 2018-07-18 15:22, Tvrtko Ursulin wrote:
>
> On 17/07/2018 14:47, Lis, Tomasz wrote:
>>
>>
>> On 2018-07-16 14:48, Joonas Lahtinen wrote:
>>> Quoting Lis, Tomasz (2018-06-21 14:54:47)
>>>> On 2018-06-21 07:53, Joonas Lahtinen wrote:
>>>>> Quoting Tomasz Lis (2018-06-20 18:14:38)
>>>>>> This adds a new test binary, containing tests for the Data Port 
>>>>>> Coherency
>>>>>> option. The tests check whether the option value is stored 
>>>>>> properly on the
>>>>>> kernel side, but also whether is is correctly set to proper GPU 
>>>>>> register.
>>>>> I'm fairly sure there already was review feedback that simply 
>>>>> checking
>>>>> the register state is not a good IGT test.
>>>>>
>>>>> IGT tests make sure that whatever uAPI the kernel has, the 
>>>>> promised effects
>>>>> of that uAPI do not get broken. And the promise for cache 
>>>>> coherency uAPI
>>>>> for surely isn't that some register value gets written, it's that the
>>>>> cache coherency is traded with some performance. The chicken bits 
>>>>> or the
>>>>> whole implementation of the feature might be turned upside down, 
>>>>> but as
>>>>> long as the userspace is still working, userspace should not care.
>>>>>
>>>>> So the chicken bit setting should be scrapped, and actual cache
>>>>> coherency observed. It might be a worthy kernel selftest that 
>>>>> register
>>>>> writes stick and remain over sleep states as a generic thing, but not
>>>>> here.
>>>>>
>>>>> If you don't address the feedback given, but hammer the mailing list
>>>>> without addressing it, don't expect further feedback.
>>>>>
>>>>> Regards, Joonas
>>>> Thank you for your feedback, both now and in the previous round.
>>>>
>>>> Developing a test which checks whether the hardware is really doing 
>>>> what
>>>> is should is possible, but also it is quite problematic.
>>>> On the UMD side, there are Khronos OCL 2.1 tests which verify 
>>>> coherency;
>>>> but they have graphics pipeline fully configured, and it is a lot 
>>>> easier
>>>> to verify it on the user level.
>>>>
>>>> We could write a test which does the following:
>>>> - Allocates a very big buffer
>>>> - Executes a shader which fills the whole buffer over and over, with
>>>> increasing numbers
>>>> - Does it long enough for the IGT to notice changes in the buffer 
>>>> while
>>>> the shader is being executed
>>>> - If there were increasing changes in buffer content - test passes
>>>>
>>>> But there are issues with this approach:
>>>> - We need a lot of memory to do the test; the faster the GPU is, the
>>>> more we need
>>>> - We need to write a shader, in assembly, for each platform
>>>> - A new shader will need to be written to test future platforms
>>>> - We need to configure the graphics pipeline within IGT test, which is
>>>> not trivial
>>>> - The test results may be unreliable because even if coherency is
>>>> disabled, there is no guarantee that the memory will not be updated
>>>> - Actually the buffer probably will be updated while the shader is
>>>> executing without coherency, but details may depend on platform,
>>>> pipeline settings and buffer size
>>>> - The test results may be unreliable due to timing, so it will likely
>>>> produce sporadics
>>>> - The test would require a separate pre-silicon part
>>>> - Test execution time would be considerable
>>>>
>>>> After reading the answers in previous review, I agree that to achieve
>>>> the IGTs goal testing hardware should be included. But I don't think
>>>> it's a good idea here.
>>> Without testing what is actually the promised effect for userspace, we
>>> just can't succeed maintaining the feature. There surely are use-cases
>>> where it's noticed if the feature is not working, and those would be
>>> the prime candidates for extracting the testing logic. We should
>>> definitely be able to accumulate execution time if we run a little bit
>>> of the test in each CI run.
>>>
>>> Just looking at register values is simply not going to make it, the
>>> registers could be just sitting there, not effecting the HW 
>>> operation on
>>> a future gen.
>>>
>>> Hopefully this clarifies enough the expected kind of test.
>>>
>>> Regards, Joonas
>> Note that it still won't be possible to test future gens, because the 
>> test will have to be re-developed for each gen.
>> But I did used that argument already. I don't have any more arguments.
>>
>> Since I wasn't able to convince you, I will start estimating effort 
>> required to develop the test within I-G-T which verifies coherency 
>> using a shared buffer.
>
> Sounds like the dilemma is whether we should be testing the driver or 
> hardware. We can of course test both, or even test the driver 
> indirectly via testing the hardware.
>
> It sounds reasonable to attempt to test the hardware (that it is 
> really coherent when enabled, or vice versa). It is simpler in a way 
> since then you don't need to embed knowledge on what the register and 
> bit are per Gen. But yeah, to test coherency I do understand you also 
> need some gen dependant code. Existing rendercopy copy wouldn't work 
> for this?
>
> But I don't understand the low-level workings of the feature well 
> enough to know why it is so difficult to trigger non-coherency from a 
> test.
>
> We do have stress tests which hammer on something and rely only on 
> occasional failures to flag up problems, so not being to trigger the 
> problem in 100% of runs per-se is not a showstopper.
>
> If it is indeed very difficult, would it be easier to start with 
> trying to detect two levels of performance between non-coherent and 
> coherent modes? That way we would know setting the bit has some effect 
> at least and is not completely ignored by the hardware.
>
Here is possible inspiration for the test - comments from Khronos OCL 
tests for the feature:

test_fine_grain_sync_buffers.cpp:
// Goals: demonstrate use of SVM's atomics to do fine grain 
synchronization between the device and host.
// Concept: a device kernel is used to search an input image for regions 
that match a target pattern.
// The device immediately notifies the host when it finds a target (via 
an atomic operation that works across host and devices).
// The host is then able to spawn a task that further analyzes the 
target while the device continues searching for more targets.

test_fine_grain_memory_consistency.cpp:
// This tests for memory consistency across devices and the host.
// Each device and the host simultaneously insert values into a single 
hash table.
// Each bin in the hash table is a linked list.  Each bin is protected 
against simultaneous
// update using a lock free technique.  The correctness of the list is 
verfied on the host.
// This test requires the new OpenCL 2.0 atomic operations that 
implement the new seq_cst memory ordering.

-Tomasz
> Regards,
>
> Tvrtko

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2018-07-19 17:35 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-20 15:14 [igt-dev] [PATCH i-g-t v1] Data Port Cache Coherency tests Tomasz Lis
2018-06-20 16:59 ` [igt-dev] ✓ Fi.CI.BAT: success for " Patchwork
2018-06-20 23:13 ` [igt-dev] ✗ Fi.CI.IGT: failure " Patchwork
2018-06-21  5:53 ` [igt-dev] [PATCH i-g-t v1] " Joonas Lahtinen
2018-06-21 11:54   ` Lis, Tomasz
2018-07-16 12:48     ` Joonas Lahtinen
2018-07-17 13:47       ` Lis, Tomasz
2018-07-18 13:22         ` Tvrtko Ursulin
2018-07-19 17:34           ` Lis, Tomasz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox