* [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-18 22:51 ` Radhakrishna Sripada
0 siblings, 0 replies; 19+ messages in thread
From: Radhakrishna Sripada @ 2023-07-18 22:51 UTC (permalink / raw)
To: intel-gfx
Cc: Radhakrishna Sripada, stable, Ville Syrjälä,
Tvrtko Ursulin, Chris Wilson, Fei Yang
Dpt objects that are created from internal get evicted when there is
memory pressure and do not get restored when pinned during scanout. The
pinned page table entries look corrupted and programming the display
engine with the incorrect pte's result in DE throwing pipe faults.
Create DPT objects from shmem and mark the object as dirty when pinning so
that the object is restored when shrinker evicts an unpinned buffer object.
v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
Cc: <stable@vger.kernel.org> # v6.0+
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
---
drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c
index 7c5fddb203ba..fbfd8f959f17 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
i915_vma_get(vma);
}
+ dpt->obj->mm.dirty = true;
+
atomic_dec(&i915->gpu_error.pending_fb_pin);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
@@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
dpt_obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
- dpt_obj = i915_gem_object_create_internal(i915, size);
+ dpt_obj = i915_gem_object_create_shmem(i915, size);
}
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
--
2.34.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-18 22:51 ` Radhakrishna Sripada
0 siblings, 0 replies; 19+ messages in thread
From: Radhakrishna Sripada @ 2023-07-18 22:51 UTC (permalink / raw)
To: intel-gfx; +Cc: Chris Wilson, stable
Dpt objects that are created from internal get evicted when there is
memory pressure and do not get restored when pinned during scanout. The
pinned page table entries look corrupted and programming the display
engine with the incorrect pte's result in DE throwing pipe faults.
Create DPT objects from shmem and mark the object as dirty when pinning so
that the object is restored when shrinker evicts an unpinned buffer object.
v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
Cc: <stable@vger.kernel.org> # v6.0+
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
---
drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c
index 7c5fddb203ba..fbfd8f959f17 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
i915_vma_get(vma);
}
+ dpt->obj->mm.dirty = true;
+
atomic_dec(&i915->gpu_error.pending_fb_pin);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
@@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
dpt_obj = i915_gem_object_create_stolen(i915, size);
if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
- dpt_obj = i915_gem_object_create_internal(i915, size);
+ dpt_obj = i915_gem_object_create_shmem(i915, size);
}
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
--
2.34.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dpt: Use shmem for dpt objects (rev2)
2023-07-18 22:51 ` [Intel-gfx] " Radhakrishna Sripada
(?)
@ 2023-07-19 0:27 ` Patchwork
-1 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2023-07-19 0:27 UTC (permalink / raw)
To: Radhakrishna Sripada; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 7984 bytes --]
== Series Details ==
Series: drm/i915/dpt: Use shmem for dpt objects (rev2)
URL : https://patchwork.freedesktop.org/series/120885/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13394 -> Patchwork_120885v2
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/index.html
Participating hosts (44 -> 42)
------------------------------
Missing (2): fi-kbl-soraka fi-snb-2520m
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_120885v2:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@debugfs_test@read_all_entries:
- {bat-dg2-13}: [PASS][1] -> [ABORT][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-13/igt@debugfs_test@read_all_entries.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-dg2-13/igt@debugfs_test@read_all_entries.html
Known issues
------------
Here are the changes found in Patchwork_120885v2 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@debugfs_test@read_all_entries:
- bat-adlp-11: NOTRUN -> [ABORT][3] ([i915#4423] / [i915#6868])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-adlp-11/igt@debugfs_test@read_all_entries.html
* igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u: [PASS][4] -> [FAIL][5] ([i915#7940])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-8109u/igt@i915_pm_rpm@basic-rte.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-cfl-8109u/igt@i915_pm_rpm@basic-rte.html
- fi-kbl-7567u: [PASS][6] -> [FAIL][7] ([i915#7940])
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-7567u/igt@i915_pm_rpm@basic-rte.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-kbl-7567u/igt@i915_pm_rpm@basic-rte.html
* igt@i915_selftest@live@gt_mocs:
- bat-mtlp-8: [PASS][8] -> [DMESG-FAIL][9] ([i915#7059])
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html
- bat-mtlp-6: [PASS][10] -> [DMESG-FAIL][11] ([i915#7059])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html
* igt@i915_selftest@live@requests:
- bat-rpls-2: [PASS][12] -> [ABORT][13] ([i915#4983] / [i915#7913])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-rpls-2/igt@i915_selftest@live@requests.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rpls-2/igt@i915_selftest@live@requests.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- fi-bsw-n3050: NOTRUN -> [SKIP][14] ([fdo#109271])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-bsw-n3050/igt@kms_chamelium_hpd@common-hpd-after-suspend.html
* igt@kms_psr@primary_page_flip:
- bat-rplp-1: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rplp-1/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-rplp-1: NOTRUN -> [ABORT][16] ([i915#8260] / [i915#8668])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rplp-1/igt@kms_setmode@basic-clone-single-crtc.html
#### Possible fixes ####
* igt@i915_module_load@load:
- bat-adlp-11: [ABORT][17] ([i915#4423]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-adlp-11/igt@i915_module_load@load.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-adlp-11/igt@i915_module_load@load.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-x1275: [SKIP][19] ([fdo#109271]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-kbl-x1275/igt@i915_pm_rpm@basic-pci-d3-state.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-kbl-x1275/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@i915_pm_rpm@basic-rte:
- fi-cfl-guc: [FAIL][21] ([i915#7940]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-cfl-guc/igt@i915_pm_rpm@basic-rte.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-cfl-guc/igt@i915_pm_rpm@basic-rte.html
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [ABORT][23] ([i915#7911] / [i915#7913]) -> [PASS][24]
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/fi-bsw-n3050/igt@i915_selftest@live@execlists.html
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-WARN][25] ([i915#7699]) -> [PASS][26]
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-dg2-11/igt@i915_selftest@live@migrate.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-dg2-11/igt@i915_selftest@live@migrate.html
* igt@i915_selftest@live@requests:
- bat-mtlp-8: [DMESG-FAIL][27] ([i915#8497]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-mtlp-8/igt@i915_selftest@live@requests.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-mtlp-8/igt@i915_selftest@live@requests.html
* igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1:
- bat-rplp-1: [ABORT][29] ([i915#8442] / [i915#8668]) -> [PASS][30]
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#4423]: https://gitlab.freedesktop.org/drm/intel/issues/4423
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6868]: https://gitlab.freedesktop.org/drm/intel/issues/6868
[i915#7059]: https://gitlab.freedesktop.org/drm/intel/issues/7059
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7940]: https://gitlab.freedesktop.org/drm/intel/issues/7940
[i915#8260]: https://gitlab.freedesktop.org/drm/intel/issues/8260
[i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442
[i915#8497]: https://gitlab.freedesktop.org/drm/intel/issues/8497
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
Build changes
-------------
* Linux: CI_DRM_13394 -> Patchwork_120885v2
CI-20190529: 20190529
CI_DRM_13394: 4fab7ebb2e3675cb9fcd7a94a7b34caa0ea855cf @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7392: 1e7c1d677d7ba57f342486bc522ed1bb6c19bf5e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120885v2: 4fab7ebb2e3675cb9fcd7a94a7b34caa0ea855cf @ git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
335b74c7ffdc drm/i915/dpt: Use shmem for dpt objects
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/index.html
[-- Attachment #2: Type: text/html, Size: 9471 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dpt: Use shmem for dpt objects (rev2)
2023-07-18 22:51 ` [Intel-gfx] " Radhakrishna Sripada
(?)
(?)
@ 2023-07-19 2:50 ` Patchwork
2023-07-21 4:50 ` Sripada, Radhakrishna
-1 siblings, 1 reply; 19+ messages in thread
From: Patchwork @ 2023-07-19 2:50 UTC (permalink / raw)
To: Radhakrishna Sripada; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 54138 bytes --]
== Series Details ==
Series: drm/i915/dpt: Use shmem for dpt objects (rev2)
URL : https://patchwork.freedesktop.org/series/120885/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120885v2_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_120885v2_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_120885v2_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_120885v2_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-snb: [PASS][1] -> [ABORT][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-snb7/igt@gem_exec_whisper@basic-contexts-forked-all.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@gem_exec_whisper@basic-contexts-forked-all.html
* igt@kms_flip@blocking-wf_vblank@b-vga1:
- shard-snb: NOTRUN -> [ABORT][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@kms_flip@blocking-wf_vblank@b-vga1.html
New tests
---------
New tests have been introduced between CI_DRM_13394_full and Patchwork_120885v2_full:
### New IGT tests (106) ###
* igt@api_intel_bb@blit-noreloc-keep-cache:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0] s
* igt@api_intel_bb@blit-noreloc-purge-cache:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0] s
* igt@api_intel_bb@blit-reloc-keep-cache:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0] s
* igt@api_intel_bb@blit-reloc-purge-cache:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0] s
* igt@api_intel_bb@full-batch:
- Statuses : 7 pass(s)
- Exec time: [0.0] s
* igt@api_intel_bb@intel-bb-blit-none:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@api_intel_bb@intel-bb-blit-x:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@api_intel_bb@intel-bb-blit-y:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@api_intel_bb@offset-control:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@api_intel_bb@simple-bb:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@api_intel_bb@simple-bb-ctx:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@gem_ctx_param@invalid-get-engines:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@gem_ctx_param@invalid-get-no-zeromap:
- Statuses : 7 pass(s)
- Exec time: [0.0] s
* igt@gem_ctx_param@invalid-get-ringsize:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@gem_ctx_param@invalid-set-no-zeromap:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@gem_ctx_param@invalid-set-ringsize:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@gem_pread@bench:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0] s
* igt@i915_selftest@live@gem_migrate:
- Statuses : 8 pass(s)
- Exec time: [0.0] s
* igt@kms_async_flips@test-cursor@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_async_flips@test-cursor@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_async_flips@test-cursor@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_async_flips@test-cursor@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_concurrent@pipe-c@hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_cursor_crc@cursor-alpha-opaque@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_cursor_crc@cursor-alpha-opaque@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_dither@fb-8bpc-vs-panel-6bpc:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_dither@fb-8bpc-vs-panel-8bpc:
- Statuses : 3 skip(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-fb-recreate-interruptible@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-ts-check@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-ts-check@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-ts-check@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@plain-flip-ts-check@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@wf_vblank-ts-check-interruptible@a-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@wf_vblank-ts-check-interruptible@b-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_flip@wf_vblank-ts-check-interruptible@d-hdmi-a4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_mmap_write_crc@main@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_pipe_crc_basic@read-crc@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_pipe_crc_basic@read-crc@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_pipe_crc_basic@read-crc@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_pipe_crc_basic@read-crc@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-x@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-x@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-x@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-x@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-y@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-y@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-y@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_lowres@tiling-y@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-c-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-d-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-a-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-b-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-c-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-d-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-a-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-b-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-c-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-d-hdmi-a-4:
- Statuses : 1 skip(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-d-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_sequence@get-busy@hdmi-a-4-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_sequence@get-busy@hdmi-a-4-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_sequence@get-busy@hdmi-a-4-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_sequence@get-busy@hdmi-a-4-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_setmode@basic@pipe-a-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
* igt@kms_setmode@basic@pipe-b-hdmi-a-4:
- Statuses : 1 pass(s)
- Exec time: [0.0] s
Known issues
------------
Here are the changes found in Patchwork_120885v2_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@device_reset@cold-reset-bound:
- shard-mtlp: NOTRUN -> [SKIP][4] ([i915#7701])
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@device_reset@cold-reset-bound.html
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- shard-rkl: [PASS][5] -> [FAIL][6] ([i915#7742])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html
* igt@feature_discovery@display-2x:
- shard-mtlp: NOTRUN -> [SKIP][7] ([i915#1839])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@feature_discovery@display-2x.html
* igt@gem_ctx_persistence@idempotent:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +1 similar issue
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb6/igt@gem_ctx_persistence@idempotent.html
* igt@gem_exec_fair@basic-deadline:
- shard-rkl: [PASS][9] -> [FAIL][10] ([i915#2846])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-6/igt@gem_exec_fair@basic-deadline.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-6/igt@gem_exec_fair@basic-deadline.html
* igt@gem_exec_fair@basic-none-vip@rcs0:
- shard-rkl: NOTRUN -> [FAIL][11] ([i915#2842])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_exec_fair@basic-none-vip@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglu: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-8/igt@gem_exec_fair@basic-pace-share@rcs0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-9/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_fair@basic-pace@vecs0:
- shard-rkl: [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar issues
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@gem_exec_fair@basic-pace@vecs0.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-2/igt@gem_exec_fair@basic-pace@vecs0.html
* igt@gem_exec_params@secure-non-master:
- shard-rkl: NOTRUN -> [SKIP][16] ([fdo#112283])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_exec_params@secure-non-master.html
* igt@gem_exec_reloc@basic-gtt-read:
- shard-rkl: NOTRUN -> [SKIP][17] ([i915#3281]) +2 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_exec_reloc@basic-gtt-read.html
* igt@gem_exec_suspend@basic-s4-devices@smem:
- shard-tglu: [PASS][18] -> [ABORT][19] ([i915#7975] / [i915#8213])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-8/igt@gem_exec_suspend@basic-s4-devices@smem.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devices@smem.html
* igt@gem_exec_whisper@basic-contexts-forked-all:
- shard-mtlp: [PASS][20] -> [ABORT][21] ([i915#8131])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-1/igt@gem_exec_whisper@basic-contexts-forked-all.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@gem_exec_whisper@basic-contexts-forked-all.html
* igt@gem_lmem_swapping@basic:
- shard-rkl: NOTRUN -> [SKIP][22] ([i915#4613])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_lmem_swapping@basic.html
* igt@gem_lmem_swapping@heavy-verify-random:
- shard-apl: NOTRUN -> [SKIP][23] ([fdo#109271] / [i915#4613]) +1 similar issue
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@gem_lmem_swapping@heavy-verify-random.html
* igt@gem_lmem_swapping@smem-oom@lmem0:
- shard-dg2: [PASS][24] -> [DMESG-WARN][25] ([i915#4936] / [i915#5493])
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@gem_lmem_swapping@smem-oom@lmem0.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-3/igt@gem_lmem_swapping@smem-oom@lmem0.html
* igt@gem_mmap@bad-object:
- shard-mtlp: NOTRUN -> [SKIP][26] ([i915#4083])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gem_mmap@bad-object.html
* igt@gem_pwrite@basic-exhaustion:
- shard-apl: NOTRUN -> [WARN][27] ([i915#2658])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@gem_pwrite@basic-exhaustion.html
* igt@gem_pxp@reject-modify-context-protection-off-2:
- shard-mtlp: NOTRUN -> [SKIP][28] ([i915#4270])
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@gem_pxp@reject-modify-context-protection-off-2.html
* igt@gem_readwrite@new-obj:
- shard-mtlp: NOTRUN -> [SKIP][29] ([i915#3282])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gem_readwrite@new-obj.html
* igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs:
- shard-mtlp: NOTRUN -> [SKIP][30] ([i915#8428]) +1 similar issue
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs.html
* igt@gem_set_tiling_vs_pwrite:
- shard-rkl: NOTRUN -> [SKIP][31] ([i915#3282]) +3 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_set_tiling_vs_pwrite.html
* igt@gem_userptr_blits@coherency-sync:
- shard-rkl: NOTRUN -> [SKIP][32] ([fdo#110542])
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_userptr_blits@coherency-sync.html
* igt@gem_userptr_blits@relocations:
- shard-mtlp: NOTRUN -> [SKIP][33] ([i915#3281]) +2 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-1/igt@gem_userptr_blits@relocations.html
* igt@gen7_exec_parse@batch-without-end:
- shard-mtlp: NOTRUN -> [SKIP][34] ([fdo#109289])
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gen7_exec_parse@batch-without-end.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][35] -> [ABORT][36] ([i915#5566])
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk1/igt@gen9_exec_parse@allowed-single.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-glk9/igt@gen9_exec_parse@allowed-single.html
* igt@i915_pm_rpm@cursor:
- shard-tglu: [PASS][37] -> [FAIL][38] ([i915#7940]) +1 similar issue
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-2/igt@i915_pm_rpm@cursor.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-7/igt@i915_pm_rpm@cursor.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- shard-mtlp: NOTRUN -> [SKIP][39] ([i915#1397])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@i915_pm_rpm@modeset-non-lpsp-stress.html
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- shard-dg2: [PASS][40] -> [SKIP][41] ([i915#1397]) +1 similar issue
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-5/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-10/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html
* igt@i915_pm_rpm@pm-caching:
- shard-mtlp: NOTRUN -> [SKIP][42] ([i915#4077]) +2 similar issues
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@i915_pm_rpm@pm-caching.html
* igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
- shard-mtlp: NOTRUN -> [SKIP][43] ([i915#5190])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html
* igt@kms_addfb_basic@clobberred-modifier:
- shard-mtlp: NOTRUN -> [SKIP][44] ([i915#4212])
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_addfb_basic@clobberred-modifier.html
* igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-2:
- shard-glk: [PASS][45] -> [FAIL][46] ([i915#2521]) +1 similar issue
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk5/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-2.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-glk5/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-2.html
* igt@kms_async_flips@crc@pipe-a-hdmi-a-3:
- shard-dg2: NOTRUN -> [FAIL][47] ([i915#8247]) +3 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@kms_async_flips@crc@pipe-a-hdmi-a-3.html
* igt@kms_big_fb@4-tiled-8bpp-rotate-90:
- shard-rkl: NOTRUN -> [SKIP][48] ([i915#5286])
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_big_fb@4-tiled-8bpp-rotate-90.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
- shard-mtlp: [PASS][49] -> [FAIL][50] ([i915#5138])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-1/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-2/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html
* igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-mtlp: NOTRUN -> [FAIL][51] ([i915#3743])
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
- shard-mtlp: [PASS][52] -> [FAIL][53] ([i915#3743])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-7/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-5/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html
* igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-mtlp: NOTRUN -> [SKIP][54] ([fdo#111615])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_big_fb@y-tiled-64bpp-rotate-180.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-90:
- shard-rkl: NOTRUN -> [SKIP][55] ([fdo#110723]) +1 similar issue
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_big_fb@yf-tiled-64bpp-rotate-90.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs:
- shard-rkl: NOTRUN -> [SKIP][56] ([i915#3734] / [i915#5354] / [i915#6095]) +3 similar issues
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_ccs:
- shard-mtlp: NOTRUN -> [SKIP][57] ([i915#6095]) +6 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_ccs.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][58] ([fdo#109271] / [i915#3886]) +2 similar issues
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
- shard-rkl: NOTRUN -> [SKIP][59] ([i915#5354]) +5 similar issues
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-mtlp: NOTRUN -> [SKIP][60] ([i915#3886] / [i915#6095]) +1 similar issue
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_cdclk@mode-transition@pipe-d-hdmi-a-3:
- shard-dg2: NOTRUN -> [SKIP][61] ([i915#4087] / [i915#7213]) +3 similar issues
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-1/igt@kms_cdclk@mode-transition@pipe-d-hdmi-a-3.html
* igt@kms_chamelium_hpd@dp-hpd-enable-disable-mode:
- shard-rkl: NOTRUN -> [SKIP][62] ([i915#7828]) +1 similar issue
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_chamelium_hpd@dp-hpd-enable-disable-mode.html
* igt@kms_chamelium_hpd@vga-hpd-without-ddc:
- shard-mtlp: NOTRUN -> [SKIP][63] ([i915#7828])
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_chamelium_hpd@vga-hpd-without-ddc.html
* igt@kms_content_protection@atomic@pipe-a-dp-4:
- shard-dg2: NOTRUN -> [TIMEOUT][64] ([i915#7173])
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_content_protection@atomic@pipe-a-dp-4.html
* igt@kms_cursor_crc@cursor-rapid-movement-32x10:
- shard-mtlp: NOTRUN -> [SKIP][65] ([i915#8814])
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-1/igt@kms_cursor_crc@cursor-rapid-movement-32x10.html
* igt@kms_cursor_crc@cursor-rapid-movement-max-size:
- shard-rkl: NOTRUN -> [SKIP][66] ([i915#3555])
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_cursor_crc@cursor-rapid-movement-max-size.html
* igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
- shard-mtlp: NOTRUN -> [SKIP][67] ([i915#3546])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-1/igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic.html
* igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
- shard-mtlp: NOTRUN -> [SKIP][68] ([fdo#111767] / [i915#3546])
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_cursor_legacy@cursorb-vs-flipb-toggle.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][69] -> [FAIL][70] ([i915#2346]) +1 similar issue
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_display_modes@extended-mode-basic:
- shard-mtlp: NOTRUN -> [SKIP][71] ([i915#8827])
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_display_modes@extended-mode-basic.html
* igt@kms_flip@2x-dpms-vs-vblank-race:
- shard-rkl: NOTRUN -> [SKIP][72] ([fdo#111825])
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_flip@2x-dpms-vs-vblank-race.html
* igt@kms_flip@2x-flip-vs-wf_vblank-interruptible:
- shard-mtlp: NOTRUN -> [SKIP][73] ([i915#3637]) +1 similar issue
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_flip@2x-flip-vs-wf_vblank-interruptible.html
* igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2:
- shard-glk: [PASS][74] -> [FAIL][75] ([i915#79])
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk6/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2.html
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-glk3/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2.html
* igt@kms_flip@flip-vs-suspend@c-dp4:
- shard-dg2: NOTRUN -> [FAIL][76] ([fdo#103375])
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_flip@flip-vs-suspend@c-dp4.html
* igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-downscaling@pipe-a-valid-mode:
- shard-rkl: NOTRUN -> [SKIP][77] ([i915#2672])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-downscaling@pipe-a-valid-mode.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-default-mode:
- shard-mtlp: NOTRUN -> [SKIP][78] ([i915#2672])
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-default-mode.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-render:
- shard-rkl: NOTRUN -> [SKIP][79] ([fdo#111825] / [i915#1825]) +6 similar issues
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-render.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-plflip-blt:
- shard-mtlp: NOTRUN -> [SKIP][80] ([i915#1825]) +5 similar issues
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
- shard-dg2: [PASS][81] -> [FAIL][82] ([i915#6880])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt:
- shard-rkl: NOTRUN -> [SKIP][83] ([i915#3023]) +5 similar issues
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt.html
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-mtlp: NOTRUN -> [SKIP][84] ([i915#8708]) +1 similar issue
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
* igt@kms_hdr@static-toggle:
- shard-rkl: NOTRUN -> [SKIP][85] ([i915#3555] / [i915#8228])
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_hdr@static-toggle.html
* igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c:
- shard-rkl: NOTRUN -> [SKIP][86] ([fdo#109289])
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [DMESG-WARN][87] ([i915#8841]) +4 similar issues
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb1/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-1.html
* igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1:
- shard-apl: NOTRUN -> [FAIL][88] ([i915#4573]) +1 similar issue
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1.html
* igt@kms_plane_scaling@intel-max-src-size@pipe-a-hdmi-a-2:
- shard-rkl: NOTRUN -> [FAIL][89] ([i915#8292])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-1/igt@kms_plane_scaling@intel-max-src-size@pipe-a-hdmi-a-2.html
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1:
- shard-rkl: NOTRUN -> [SKIP][90] ([i915#5176]) +3 similar issues
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1.html
* igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-3:
- shard-dg2: NOTRUN -> [SKIP][91] ([i915#5176]) +3 similar issues
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-1/igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-3.html
* igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1:
- shard-mtlp: NOTRUN -> [SKIP][92] ([i915#5176]) +1 similar issue
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1.html
* igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
- shard-snb: NOTRUN -> [SKIP][93] ([fdo#109271]) +251 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1.html
* igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-b-hdmi-a-2:
- shard-rkl: NOTRUN -> [SKIP][94] ([i915#5235]) +3 similar issues
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-b-hdmi-a-2.html
* igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-hdmi-a-3:
- shard-dg2: NOTRUN -> [SKIP][95] ([i915#5235]) +15 similar issues
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-hdmi-a-3.html
* igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
- shard-rkl: NOTRUN -> [SKIP][96] ([fdo#111068] / [i915#658])
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html
* igt@kms_psr2_su@frontbuffer-xrgb8888:
- shard-apl: NOTRUN -> [SKIP][97] ([fdo#109271] / [i915#658])
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_psr2_su@frontbuffer-xrgb8888.html
* igt@kms_psr@primary_page_flip:
- shard-apl: NOTRUN -> [SKIP][98] ([fdo#109271]) +38 similar issues
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_psr@primary_page_flip.html
* igt@kms_rotation_crc@bad-pixel-format:
- shard-mtlp: NOTRUN -> [SKIP][99] ([i915#4235]) +1 similar issue
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_rotation_crc@bad-pixel-format.html
* igt@kms_tv_load_detect@load-detect:
- shard-mtlp: NOTRUN -> [SKIP][100] ([fdo#109309])
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_tv_load_detect@load-detect.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-apl: NOTRUN -> [SKIP][101] ([fdo#109271] / [i915#533])
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_vblank@pipe-d-wait-idle.html
* igt@kms_writeback@writeback-check-output:
- shard-rkl: NOTRUN -> [SKIP][102] ([i915#2437])
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_writeback@writeback-check-output.html
* igt@perf@enable-disable@0-rcs0:
- shard-dg2: [PASS][103] -> [FAIL][104] ([i915#8724])
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-1/igt@perf@enable-disable@0-rcs0.html
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@perf@enable-disable@0-rcs0.html
* igt@tools_test@sysfs_l3_parity:
- shard-rkl: NOTRUN -> [SKIP][105] ([fdo#109307])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@tools_test@sysfs_l3_parity.html
* igt@v3d/v3d_submit_csd@job-perfmon:
- shard-rkl: NOTRUN -> [SKIP][106] ([fdo#109315]) +2 similar issues
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@v3d/v3d_submit_csd@job-perfmon.html
* igt@v3d/v3d_submit_csd@multi-and-single-sync:
- shard-mtlp: NOTRUN -> [SKIP][107] ([i915#2575]) +2 similar issues
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@v3d/v3d_submit_csd@multi-and-single-sync.html
* igt@vc4/vc4_tiling@get-bad-flags:
- shard-rkl: NOTRUN -> [SKIP][108] ([i915#7711]) +1 similar issue
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@vc4/vc4_tiling@get-bad-flags.html
#### Possible fixes ####
* igt@gem_eio@kms:
- shard-dg2: [INCOMPLETE][109] ([i915#7892]) -> [PASS][110]
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-3/igt@gem_eio@kms.html
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@gem_eio@kms.html
* igt@gem_eio@reset-stress:
- {shard-dg1}: [FAIL][111] ([i915#5784]) -> [PASS][112]
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-14/igt@gem_eio@reset-stress.html
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-14/igt@gem_eio@reset-stress.html
* igt@gem_exec_whisper@basic-contexts-priority-all:
- shard-mtlp: [ABORT][113] ([i915#8131]) -> [PASS][114]
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-6/igt@gem_exec_whisper@basic-contexts-priority-all.html
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gem_exec_whisper@basic-contexts-priority-all.html
* igt@gem_lmem_swapping@smem-oom@lmem0:
- {shard-dg1}: [TIMEOUT][115] ([i915#5493]) -> [PASS][116]
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-15/igt@gem_lmem_swapping@smem-oom@lmem0.html
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-16/igt@gem_lmem_swapping@smem-oom@lmem0.html
* igt@i915_module_load@reload-with-fault-injection:
- shard-mtlp: [ABORT][117] ([i915#8489] / [i915#8668]) -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-3/igt@i915_module_load@reload-with-fault-injection.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@i915_module_load@reload-with-fault-injection.html
* igt@i915_pipe_stress@stress-xrgb8888-untiled:
- shard-mtlp: [FAIL][119] ([i915#8691]) -> [PASS][120]
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-6/igt@i915_pipe_stress@stress-xrgb8888-untiled.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@i915_pipe_stress@stress-xrgb8888-untiled.html
* igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- {shard-dg1}: [FAIL][121] ([i915#3591]) -> [PASS][122]
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-12/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html
* igt@i915_pm_rpm@dpms-lpsp:
- {shard-dg1}: [SKIP][123] ([i915#1397]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-12/igt@i915_pm_rpm@dpms-lpsp.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-19/igt@i915_pm_rpm@dpms-lpsp.html
* igt@i915_pm_rpm@dpms-non-lpsp:
- shard-rkl: [SKIP][125] ([i915#1397]) -> [PASS][126] +1 similar issue
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-7/igt@i915_pm_rpm@dpms-non-lpsp.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-1/igt@i915_pm_rpm@dpms-non-lpsp.html
* igt@i915_pm_rpm@gem-execbuf-stress@smem0:
- shard-tglu: [FAIL][127] ([i915#7940]) -> [PASS][128] +2 similar issues
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-7/igt@i915_pm_rpm@gem-execbuf-stress@smem0.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-10/igt@i915_pm_rpm@gem-execbuf-stress@smem0.html
* igt@i915_pm_rpm@modeset-non-lpsp:
- shard-dg2: [SKIP][129] ([i915#1397]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@i915_pm_rpm@modeset-non-lpsp.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@i915_pm_rpm@modeset-non-lpsp.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-mtlp: [FAIL][131] ([i915#3743]) -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-2/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-5/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-mtlp: [FAIL][133] ([i915#2346]) -> [PASS][134]
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-3/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-apl: [ABORT][135] ([i915#180]) -> [PASS][136]
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-apl7/igt@kms_fbcon_fbt@fbc-suspend.html
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_rotation_crc@primary-y-tiled-reflect-x-180:
- shard-rkl: [ABORT][137] ([i915#7461]) -> [PASS][138]
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-7/igt@kms_rotation_crc@primary-y-tiled-reflect-x-180.html
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_rotation_crc@primary-y-tiled-reflect-x-180.html
#### Warnings ####
* igt@i915_pm_rc6_residency@rc6-idle@vecs0:
- shard-tglu: [FAIL][139] ([i915#2681] / [i915#3591]) -> [WARN][140] ([i915#2681])
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-4/igt@i915_pm_rc6_residency@rc6-idle@vecs0.html
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-6/igt@i915_pm_rc6_residency@rc6-idle@vecs0.html
* igt@kms_content_protection@mei_interface:
- shard-dg2: [SKIP][141] ([i915#7118]) -> [SKIP][142] ([i915#7118] / [i915#7162])
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-1/igt@kms_content_protection@mei_interface.html
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_content_protection@mei_interface.html
* igt@kms_fbcon_fbt@psr:
- shard-rkl: [SKIP][143] ([fdo#110189] / [i915#3955]) -> [SKIP][144] ([i915#3955])
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@kms_fbcon_fbt@psr.html
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_fbcon_fbt@psr.html
* igt@kms_force_connector_basic@force-load-detect:
- shard-rkl: [SKIP][145] ([fdo#109285] / [i915#4098]) -> [SKIP][146] ([fdo#109285])
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@kms_force_connector_basic@force-load-detect.html
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-6/igt@kms_force_connector_basic@force-load-detect.html
* igt@sysfs_timeslice_duration@timeout@vecs0:
- shard-mtlp: [TIMEOUT][147] ([i915#6950]) -> [ABORT][148] ([i915#8521])
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-4/igt@sysfs_timeslice_duration@timeout@vecs0.html
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-6/igt@sysfs_timeslice_duration@timeout@vecs0.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109300]: https://bugs.freedesktop.org/show_bug.cgi?id=109300
[fdo#109307]: https://bugs.freedesktop.org/show_bug.cgi?id=109307
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#110542]: https://bugs.freedesktop.org/show_bug.cgi?id=110542
[fdo#110723]: https://bugs.freedesktop.org/show_bug.cgi?id=110723
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111767]: https://bugs.freedesktop.org/show_bug.cgi?id=111767
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#112283]: https://bugs.freedesktop.org/show_bug.cgi?id=112283
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1099]: https://gitlab.freedesktop.org/drm/intel/issues/1099
[i915#1397]: https://gitlab.freedesktop.org/drm/intel/issues/1397
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#1825]: https://gitlab.freedesktop.org/drm/intel/issues/1825
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2658]: https://gitlab.freedesktop.org/drm/intel/issues/2658
[i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
[i915#2681]: https://gitlab.freedesktop.org/drm/intel/issues/2681
[i915#2842]: https://gitlab.freedesktop.org/drm/intel/issues/2842
[i915#2846]: https://gitlab.freedesktop.org/drm/intel/issues/2846
[i915#3023]: https://gitlab.freedesktop.org/drm/intel/issues/3023
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3591]: https://gitlab.freedesktop.org/drm/intel/issues/3591
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3734]: https://gitlab.freedesktop.org/drm/intel/issues/3734
[i915#3743]: https://gitlab.freedesktop.org/drm/intel/issues/3743
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#3955]: https://gitlab.freedesktop.org/drm/intel/issues/3955
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078
[i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083
[i915#4087]: https://gitlab.freedesktop.org/drm/intel/issues/4087
[i915#4098]: https://gitlab.freedesktop.org/drm/intel/issues/4098
[i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212
[i915#4235]: https://gitlab.freedesktop.org/drm/intel/issues/4235
[i915#4270]: https://gitlab.freedesktop.org/drm/intel/issues/4270
[i915#4573]: https://gitlab.freedesktop.org/drm/intel/issues/4573
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4936]: https://gitlab.freedesktop.org/drm/intel/issues/4936
[i915#5138]: https://gitlab.freedesktop.org/drm/intel/issues/5138
[i915#5176]: https://gitlab.freedesktop.org/drm/intel/issues/5176
[i915#5190]: https://gitlab.freedesktop.org/drm/intel/issues/5190
[i915#5235]: https://gitlab.freedesktop.org/drm/intel/issues/5235
[i915#5286]: https://gitlab.freedesktop.org/drm/intel/issues/5286
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
[i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354
[i915#5493]: https://gitlab.freedesktop.org/drm/intel/issues/5493
[i915#5566]: https://gitlab.freedesktop.org/drm/intel/issues/5566
[i915#5784]: https://gitlab.freedesktop.org/drm/intel/issues/5784
[i915#6095]: https://gitlab.freedesktop.org/drm/intel/issues/6095
[i915#6121]: https://gitlab.freedesktop.org/drm/intel/issues/6121
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#6880]: https://gitlab.freedesktop.org/drm/intel/issues/6880
[i915#6950]: https://gitlab.freedesktop.org/drm/intel/issues/6950
[i915#7116]: https://gitlab.freedesktop.org/drm/intel/issues/7116
[i915#7118]: https://gitlab.freedesktop.org/drm/intel/issues/7118
[i915#7162]: https://gitlab.freedesktop.org/drm/intel/issues/7162
[i915#7173]: https://gitlab.freedesktop.org/drm/intel/issues/7173
[i915#7213]: https://gitlab.freedesktop.org/drm/intel/issues/7213
[i915#7461]: https://gitlab.freedesktop.org/drm/intel/issues/7461
[i915#7701]: https://gitlab.freedesktop.org/drm/intel/issues/7701
[i915#7711]: https://gitlab.freedesktop.org/drm/intel/issues/7711
[i915#7742]: https://gitlab.freedesktop.org/drm/intel/issues/7742
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7892]: https://gitlab.freedesktop.org/drm/intel/issues/7892
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#7940]: https://gitlab.freedesktop.org/drm/intel/issues/7940
[i915#7975]: https://gitlab.freedesktop.org/drm/intel/issues/7975
[i915#8131]: https://gitlab.freedesktop.org/drm/intel/issues/8131
[i915#8213]: https://gitlab.freedesktop.org/drm/intel/issues/8213
[i915#8228]: https://gitlab.freedesktop.org/drm/intel/issues/8228
[i915#8247]: https://gitlab.freedesktop.org/drm/intel/issues/8247
[i915#8292]: https://gitlab.freedesktop.org/drm/intel/issues/8292
[i915#8428]: https://gitlab.freedesktop.org/drm/intel/issues/8428
[i915#8489]: https://gitlab.freedesktop.org/drm/intel/issues/8489
[i915#8502]: https://gitlab.freedesktop.org/drm/intel/issues/8502
[i915#8521]: https://gitlab.freedesktop.org/drm/intel/issues/8521
[i915#8661]: https://gitlab.freedesktop.org/drm/intel/issues/8661
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8691]: https://gitlab.freedesktop.org/drm/intel/issues/8691
[i915#8708]: https://gitlab.freedesktop.org/drm/intel/issues/8708
[i915#8724]: https://gitlab.freedesktop.org/drm/intel/issues/8724
[i915#8814]: https://gitlab.freedesktop.org/drm/intel/issues/8814
[i915#8827]: https://gitlab.freedesktop.org/drm/intel/issues/8827
[i915#8841]: https://gitlab.freedesktop.org/drm/intel/issues/8841
[i915#8889]: https://gitlab.freedesktop.org/drm/intel/issues/8889
Build changes
-------------
* Linux: CI_DRM_13394 -> Patchwork_120885v2
CI-20190529: 20190529
CI_DRM_13394: 4fab7ebb2e3675cb9fcd7a94a7b34caa0ea855cf @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7392: 1e7c1d677d7ba57f342486bc522ed1bb6c19bf5e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120885v2: 4fab7ebb2e3675cb9fcd7a94a7b34caa0ea855cf @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/index.html
[-- Attachment #2: Type: text/html, Size: 62828 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-18 22:51 ` [Intel-gfx] " Radhakrishna Sripada
@ 2023-07-19 13:36 ` Tvrtko Ursulin
-1 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-19 13:36 UTC (permalink / raw)
To: Radhakrishna Sripada, intel-gfx
Cc: stable, Ville Syrjälä, Chris Wilson, Fei Yang
On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> Dpt objects that are created from internal get evicted when there is
> memory pressure and do not get restored when pinned during scanout. The
> pinned page table entries look corrupted and programming the display
> engine with the incorrect pte's result in DE throwing pipe faults.
>
> Create DPT objects from shmem and mark the object as dirty when pinning so
> that the object is restored when shrinker evicts an unpinned buffer object.
>
> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>
> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
> Cc: <stable@vger.kernel.org> # v6.0+
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c
> index 7c5fddb203ba..fbfd8f959f17 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
> i915_vma_get(vma);
> }
>
> + dpt->obj->mm.dirty = true;
> +
> atomic_dec(&i915->gpu_error.pending_fb_pin);
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>
> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> dpt_obj = i915_gem_object_create_stolen(i915, size);
> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
> - dpt_obj = i915_gem_object_create_internal(i915, size);
> + dpt_obj = i915_gem_object_create_shmem(i915, size);
> }
> if (IS_ERR(dpt_obj))
> return ERR_CAST(dpt_obj);
Okay I think I get it after some more looking at the DPT code paths.
Problem seems pretty clear - page tables are stored in dpt_obj and so
are lost when backing store is discarded.
Changing to shmem object indeed looks the easiest option.
Some related thoughts:
1)
I wonder if intel_dpt_suspend/resume remain needed after this patch.
Could you investigate please? On a glance their job was to restore the
PTEs which would be lost from internal objects backing storage. With
shmem objects that content should be preserved.
2)
I wonder if i915_vma_flush_writes should be used (as a companion of
i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
then I am also not sure if it does the right thing for the
i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
call __i915_gem_object_flush_map itself for that mapping flavour and not
do the ggtt flushing in that case.
In summary I think the fix is safe and correct but at least point 1) I
think needs looking into. It can be a follow up work too.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-19 13:36 ` Tvrtko Ursulin
0 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-19 13:36 UTC (permalink / raw)
To: Radhakrishna Sripada, intel-gfx; +Cc: Chris Wilson, stable
On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> Dpt objects that are created from internal get evicted when there is
> memory pressure and do not get restored when pinned during scanout. The
> pinned page table entries look corrupted and programming the display
> engine with the incorrect pte's result in DE throwing pipe faults.
>
> Create DPT objects from shmem and mark the object as dirty when pinning so
> that the object is restored when shrinker evicts an unpinned buffer object.
>
> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>
> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt")
> Cc: <stable@vger.kernel.org> # v6.0+
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
> Signed-off-by: Fei Yang <fei.yang@intel.com>
> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c b/drivers/gpu/drm/i915/display/intel_dpt.c
> index 7c5fddb203ba..fbfd8f959f17 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
> i915_vma_get(vma);
> }
>
> + dpt->obj->mm.dirty = true;
> +
> atomic_dec(&i915->gpu_error.pending_fb_pin);
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>
> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> dpt_obj = i915_gem_object_create_stolen(i915, size);
> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
> - dpt_obj = i915_gem_object_create_internal(i915, size);
> + dpt_obj = i915_gem_object_create_shmem(i915, size);
> }
> if (IS_ERR(dpt_obj))
> return ERR_CAST(dpt_obj);
Okay I think I get it after some more looking at the DPT code paths.
Problem seems pretty clear - page tables are stored in dpt_obj and so
are lost when backing store is discarded.
Changing to shmem object indeed looks the easiest option.
Some related thoughts:
1)
I wonder if intel_dpt_suspend/resume remain needed after this patch.
Could you investigate please? On a glance their job was to restore the
PTEs which would be lost from internal objects backing storage. With
shmem objects that content should be preserved.
2)
I wonder if i915_vma_flush_writes should be used (as a companion of
i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
then I am also not sure if it does the right thing for the
i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
call __i915_gem_object_flush_map itself for that mapping flavour and not
do the ggtt flushing in that case.
In summary I think the fix is safe and correct but at least point 1) I
think needs looking into. It can be a follow up work too.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-19 13:36 ` [Intel-gfx] " Tvrtko Ursulin
@ 2023-07-19 20:53 ` Yang, Fei
-1 siblings, 0 replies; 19+ messages in thread
From: Yang, Fei @ 2023-07-19 20:53 UTC (permalink / raw)
To: Tvrtko Ursulin, Sripada, Radhakrishna, intel-gfx
Cc: stable, Ville Syrjälä, Wilson, Chris P
> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>> Dpt objects that are created from internal get evicted when there is
>> memory pressure and do not get restored when pinned during scanout.
>> The pinned page table entries look corrupted and programming the
>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>
>> Create DPT objects from shmem and mark the object as dirty when
>> pinning so that the object is restored when shrinker evicts an unpinned buffer object.
>>
>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>
>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>> for dpt")
>> Cc: <stable@vger.kernel.org> # v6.0+
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>> ---
>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index 7c5fddb203ba..fbfd8f959f17 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
>> i915_vma_get(vma);
>> }
>>
>> + dpt->obj->mm.dirty = true;
>> +
>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>
>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>> }
>> if (IS_ERR(dpt_obj))
>> return ERR_CAST(dpt_obj);
>
> Okay I think I get it after some more looking at the DPT code paths.
> Problem seems pretty clear - page tables are stored in dpt_obj and so
> are lost when backing store is discarded.
>
> Changing to shmem object indeed looks the easiest option.
>
> Some related thoughts:
>
> 1)
> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> Could you investigate please? On a glance their job was to restore the
> PTEs which would be lost from internal objects backing storage. With
> shmem objects that content should be preserved.
intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
objects are mapped into, but also the framebuffer objects. I don't have
much knowledge on how the framebuffer objects are managed, but the suspend
resume path still look necessary to me, unless the content of these
framebuffer objects are also preserved.
> 2)
> I wonder if i915_vma_flush_writes should be used (as a companion of
> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
> then I am also not sure if it does the right thing for the
> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
> call __i915_gem_object_flush_map itself for that mapping flavour and
> not do the ggtt flushing in that case.
>
> In summary I think the fix is safe and correct but at least point 1) I
> think needs looking into. It can be a follow up work too.
>
> Regards,
>
> Tvrtko
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-19 20:53 ` Yang, Fei
0 siblings, 0 replies; 19+ messages in thread
From: Yang, Fei @ 2023-07-19 20:53 UTC (permalink / raw)
To: Tvrtko Ursulin, Sripada, Radhakrishna, intel-gfx; +Cc: Wilson, Chris P, stable
> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>> Dpt objects that are created from internal get evicted when there is
>> memory pressure and do not get restored when pinned during scanout.
>> The pinned page table entries look corrupted and programming the
>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>
>> Create DPT objects from shmem and mark the object as dirty when
>> pinning so that the object is restored when shrinker evicts an unpinned buffer object.
>>
>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>
>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>> for dpt")
>> Cc: <stable@vger.kernel.org> # v6.0+
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>> ---
>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>> index 7c5fddb203ba..fbfd8f959f17 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
>> i915_vma_get(vma);
>> }
>>
>> + dpt->obj->mm.dirty = true;
>> +
>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>
>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>> }
>> if (IS_ERR(dpt_obj))
>> return ERR_CAST(dpt_obj);
>
> Okay I think I get it after some more looking at the DPT code paths.
> Problem seems pretty clear - page tables are stored in dpt_obj and so
> are lost when backing store is discarded.
>
> Changing to shmem object indeed looks the easiest option.
>
> Some related thoughts:
>
> 1)
> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> Could you investigate please? On a glance their job was to restore the
> PTEs which would be lost from internal objects backing storage. With
> shmem objects that content should be preserved.
intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
objects are mapped into, but also the framebuffer objects. I don't have
much knowledge on how the framebuffer objects are managed, but the suspend
resume path still look necessary to me, unless the content of these
framebuffer objects are also preserved.
> 2)
> I wonder if i915_vma_flush_writes should be used (as a companion of
> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
> then I am also not sure if it does the right thing for the
> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
> call __i915_gem_object_flush_map itself for that mapping flavour and
> not do the ggtt flushing in that case.
>
> In summary I think the fix is safe and correct but at least point 1) I
> think needs looking into. It can be a follow up work too.
>
> Regards,
>
> Tvrtko
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-19 20:53 ` [Intel-gfx] " Yang, Fei
@ 2023-07-20 9:16 ` Tvrtko Ursulin
-1 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-20 9:16 UTC (permalink / raw)
To: Yang, Fei, Sripada, Radhakrishna, intel-gfx; +Cc: Wilson, Chris P, stable
On 19/07/2023 21:53, Yang, Fei wrote:
>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>>> Dpt objects that are created from internal get evicted when there is
>>> memory pressure and do not get restored when pinned during scanout.
>>> The pinned page table entries look corrupted and programming the
>>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>>
>>> Create DPT objects from shmem and mark the object as dirty when
>>> pinning so that the object is restored when shrinker evicts an unpinned buffer object.
>>>
>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>>
>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>>> for dpt")
>>> Cc: <stable@vger.kernel.org> # v6.0+
>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>>> index 7c5fddb203ba..fbfd8f959f17 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
>>> i915_vma_get(vma);
>>> }
>>>
>>> + dpt->obj->mm.dirty = true;
>>> +
>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>>
>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>>> }
>>> if (IS_ERR(dpt_obj))
>>> return ERR_CAST(dpt_obj);
>>
>> Okay I think I get it after some more looking at the DPT code paths.
>> Problem seems pretty clear - page tables are stored in dpt_obj and so
>> are lost when backing store is discarded.
>>
>> Changing to shmem object indeed looks the easiest option.
>>
>> Some related thoughts:
>>
>> 1)
>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
>> Could you investigate please? On a glance their job was to restore the
>> PTEs which would be lost from internal objects backing storage. With
>> shmem objects that content should be preserved.
>
> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> objects are mapped into, but also the framebuffer objects. I don't have
> much knowledge on how the framebuffer objects are managed, but the suspend
> resume path still look necessary to me, unless the content of these
> framebuffer objects are also preserved.
I don't think it has anything to do with fb content, but you are correct
it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
mapping for DPT FBs across system suspend/resume") reminds me backing
store for DPT PTEs can be either lmem, stolen or internal (now shmem).
Even though with this patch internal is out of the picture, stolen
remains and so the issue of losing the page table content remains.
Perhaps resume could be optimised to only restore PTEs when VM page
tables are backed by stolen which may win some suspend/resume speed on
some platforms.
Regards,
Tvrtko
>
>> 2)
>> I wonder if i915_vma_flush_writes should be used (as a companion of
>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
>> then I am also not sure if it does the right thing for the
>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
>> call __i915_gem_object_flush_map itself for that mapping flavour and
>> not do the ggtt flushing in that case.
>>
>> In summary I think the fix is safe and correct but at least point 1) I
>> think needs looking into. It can be a follow up work too.
>>
>> Regards,
>>
>> Tvrtko
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-20 9:16 ` Tvrtko Ursulin
0 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-20 9:16 UTC (permalink / raw)
To: Yang, Fei, Sripada, Radhakrishna, intel-gfx
Cc: stable, Ville Syrjälä, Wilson, Chris P
On 19/07/2023 21:53, Yang, Fei wrote:
>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>>> Dpt objects that are created from internal get evicted when there is
>>> memory pressure and do not get restored when pinned during scanout.
>>> The pinned page table entries look corrupted and programming the
>>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>>
>>> Create DPT objects from shmem and mark the object as dirty when
>>> pinning so that the object is restored when shrinker evicts an unpinned buffer object.
>>>
>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>>
>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>>> for dpt")
>>> Cc: <stable@vger.kernel.org> # v6.0+
>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>>> index 7c5fddb203ba..fbfd8f959f17 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct i915_address_space *vm)
>>> i915_vma_get(vma);
>>> }
>>>
>>> + dpt->obj->mm.dirty = true;
>>> +
>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>>
>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>>> }
>>> if (IS_ERR(dpt_obj))
>>> return ERR_CAST(dpt_obj);
>>
>> Okay I think I get it after some more looking at the DPT code paths.
>> Problem seems pretty clear - page tables are stored in dpt_obj and so
>> are lost when backing store is discarded.
>>
>> Changing to shmem object indeed looks the easiest option.
>>
>> Some related thoughts:
>>
>> 1)
>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
>> Could you investigate please? On a glance their job was to restore the
>> PTEs which would be lost from internal objects backing storage. With
>> shmem objects that content should be preserved.
>
> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> objects are mapped into, but also the framebuffer objects. I don't have
> much knowledge on how the framebuffer objects are managed, but the suspend
> resume path still look necessary to me, unless the content of these
> framebuffer objects are also preserved.
I don't think it has anything to do with fb content, but you are correct
it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
mapping for DPT FBs across system suspend/resume") reminds me backing
store for DPT PTEs can be either lmem, stolen or internal (now shmem).
Even though with this patch internal is out of the picture, stolen
remains and so the issue of losing the page table content remains.
Perhaps resume could be optimised to only restore PTEs when VM page
tables are backed by stolen which may win some suspend/resume speed on
some platforms.
Regards,
Tvrtko
>
>> 2)
>> I wonder if i915_vma_flush_writes should be used (as a companion of
>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
>> then I am also not sure if it does the right thing for the
>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
>> call __i915_gem_object_flush_map itself for that mapping flavour and
>> not do the ggtt flushing in that case.
>>
>> In summary I think the fix is safe and correct but at least point 1) I
>> think needs looking into. It can be a follow up work too.
>>
>> Regards,
>>
>> Tvrtko
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-20 9:16 ` Tvrtko Ursulin
@ 2023-07-20 17:02 ` Sripada, Radhakrishna
-1 siblings, 0 replies; 19+ messages in thread
From: Sripada, Radhakrishna @ 2023-07-20 17:02 UTC (permalink / raw)
To: Tvrtko Ursulin, Yang, Fei, intel-gfx
Cc: stable, Ville Syrjälä, Wilson, Chris P
Hi Tvrtko,
> -----Original Message-----
> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Sent: Thursday, July 20, 2023 2:17 AM
> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
> Chris P <chris.p.wilson@intel.com>
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 19/07/2023 21:53, Yang, Fei wrote:
> >> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>> Dpt objects that are created from internal get evicted when there is
> >>> memory pressure and do not get restored when pinned during scanout.
> >>> The pinned page table entries look corrupted and programming the
> >>> display engine with the incorrect pte's result in DE throwing pipe faults.
> >>>
> >>> Create DPT objects from shmem and mark the object as dirty when
> >>> pinning so that the object is restored when shrinker evicts an unpinned
> buffer object.
> >>>
> >>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>
> >>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>> for dpt")
> >>> Cc: <stable@vger.kernel.org> # v6.0+
> >>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
> >>> Signed-off-by: Fei Yang <fei.yang@intel.com>
> >>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> i915_address_space *vm)
> >>> i915_vma_get(vma);
> >>> }
> >>>
> >>> + dpt->obj->mm.dirty = true;
> >>> +
> >>> atomic_dec(&i915->gpu_error.pending_fb_pin);
> >>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >>>
> >>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>> dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
> >>> - dpt_obj = i915_gem_object_create_internal(i915, size);
> >>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>> }
> >>> if (IS_ERR(dpt_obj))
> >>> return ERR_CAST(dpt_obj);
> >>
> >> Okay I think I get it after some more looking at the DPT code paths.
> >> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >> are lost when backing store is discarded.
> >>
> >> Changing to shmem object indeed looks the easiest option.
> >>
> >> Some related thoughts:
> >>
> >> 1)
> >> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >> Could you investigate please? On a glance their job was to restore the
> >> PTEs which would be lost from internal objects backing storage. With
> >> shmem objects that content should be preserved.
> >
> > intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> > objects are mapped into, but also the framebuffer objects. I don't have
> > much knowledge on how the framebuffer objects are managed, but the
> suspend
> > resume path still look necessary to me, unless the content of these
> > framebuffer objects are also preserved.
>
> I don't think it has anything to do with fb content, but you are correct
> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
> mapping for DPT FBs across system suspend/resume") reminds me backing
> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
> Even though with this patch internal is out of the picture, stolen
> remains and so the issue of losing the page table content remains.
> Perhaps resume could be optimised to only restore PTEs when VM page
> tables are backed by stolen which may win some suspend/resume speed on
> some platforms.
I will have to look into how suspend resume will change with the current flow
as you said it can be looked in a later patch.
>
> Regards,
>
> Tvrtko
>
> >
> >> 2)
> >> I wonder if i915_vma_flush_writes should be used (as a companion of
> >> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
> >> then I am also not sure if it does the right thing for the
> >> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
> >> call __i915_gem_object_flush_map itself for that mapping flavour and
> >> not do the ggtt flushing in that case.
I am not sure if dpt_bind_vma will be called each time during pinning. IMO it gets called
Only when the fb object needs to be bind after and unbind(triggered during obj destroy).
Do you think if i915_vma_flush_writes should not be used if dpt objects are created from internal?
Or should we have a different flavor of i915_vm_pin_iomap that skips i915_vma_set_ggtt_write
so that we can drop i915_vma_flush_writes during unpinning and move i915_vma_set_ggtt_write
to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess __i915_gem_object_flush_map
called during vma bind and not object pinning. In either case I believe it is a larger cleanup
which requires more extensive validation and analysis.
> >>
> >> In summary I think the fix is safe and correct but at least point 1) I
> >> think needs looking into. It can be a follow up work too.
If you think this fix can work then I will look into the suspend/resume as a follow up and will appreciate
an r-b for this change. I believe 2) is a larger cleanup that may not be immediately required. I will have
to dig more into the ramifications of the changes proposed above.
Thoughts ?
--Radhakrishna(RK) Sripada
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-20 17:02 ` Sripada, Radhakrishna
0 siblings, 0 replies; 19+ messages in thread
From: Sripada, Radhakrishna @ 2023-07-20 17:02 UTC (permalink / raw)
To: Tvrtko Ursulin, Yang, Fei, intel-gfx; +Cc: Wilson, Chris P, stable
Hi Tvrtko,
> -----Original Message-----
> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Sent: Thursday, July 20, 2023 2:17 AM
> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
> Chris P <chris.p.wilson@intel.com>
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 19/07/2023 21:53, Yang, Fei wrote:
> >> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>> Dpt objects that are created from internal get evicted when there is
> >>> memory pressure and do not get restored when pinned during scanout.
> >>> The pinned page table entries look corrupted and programming the
> >>> display engine with the incorrect pte's result in DE throwing pipe faults.
> >>>
> >>> Create DPT objects from shmem and mark the object as dirty when
> >>> pinning so that the object is restored when shrinker evicts an unpinned
> buffer object.
> >>>
> >>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>
> >>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>> for dpt")
> >>> Cc: <stable@vger.kernel.org> # v6.0+
> >>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
> >>> Signed-off-by: Fei Yang <fei.yang@intel.com>
> >>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> >>> ---
> >>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> i915_address_space *vm)
> >>> i915_vma_get(vma);
> >>> }
> >>>
> >>> + dpt->obj->mm.dirty = true;
> >>> +
> >>> atomic_dec(&i915->gpu_error.pending_fb_pin);
> >>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >>>
> >>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>> dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
> >>> - dpt_obj = i915_gem_object_create_internal(i915, size);
> >>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>> }
> >>> if (IS_ERR(dpt_obj))
> >>> return ERR_CAST(dpt_obj);
> >>
> >> Okay I think I get it after some more looking at the DPT code paths.
> >> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >> are lost when backing store is discarded.
> >>
> >> Changing to shmem object indeed looks the easiest option.
> >>
> >> Some related thoughts:
> >>
> >> 1)
> >> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >> Could you investigate please? On a glance their job was to restore the
> >> PTEs which would be lost from internal objects backing storage. With
> >> shmem objects that content should be preserved.
> >
> > intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> > objects are mapped into, but also the framebuffer objects. I don't have
> > much knowledge on how the framebuffer objects are managed, but the
> suspend
> > resume path still look necessary to me, unless the content of these
> > framebuffer objects are also preserved.
>
> I don't think it has anything to do with fb content, but you are correct
> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
> mapping for DPT FBs across system suspend/resume") reminds me backing
> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
> Even though with this patch internal is out of the picture, stolen
> remains and so the issue of losing the page table content remains.
> Perhaps resume could be optimised to only restore PTEs when VM page
> tables are backed by stolen which may win some suspend/resume speed on
> some platforms.
I will have to look into how suspend resume will change with the current flow
as you said it can be looked in a later patch.
>
> Regards,
>
> Tvrtko
>
> >
> >> 2)
> >> I wonder if i915_vma_flush_writes should be used (as a companion of
> >> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
> >> then I am also not sure if it does the right thing for the
> >> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
> >> call __i915_gem_object_flush_map itself for that mapping flavour and
> >> not do the ggtt flushing in that case.
I am not sure if dpt_bind_vma will be called each time during pinning. IMO it gets called
Only when the fb object needs to be bind after and unbind(triggered during obj destroy).
Do you think if i915_vma_flush_writes should not be used if dpt objects are created from internal?
Or should we have a different flavor of i915_vm_pin_iomap that skips i915_vma_set_ggtt_write
so that we can drop i915_vma_flush_writes during unpinning and move i915_vma_set_ggtt_write
to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess __i915_gem_object_flush_map
called during vma bind and not object pinning. In either case I believe it is a larger cleanup
which requires more extensive validation and analysis.
> >>
> >> In summary I think the fix is safe and correct but at least point 1) I
> >> think needs looking into. It can be a follow up work too.
If you think this fix can work then I will look into the suspend/resume as a follow up and will appreciate
an r-b for this change. I believe 2) is a larger cleanup that may not be immediately required. I will have
to dig more into the ramifications of the changes proposed above.
Thoughts ?
--Radhakrishna(RK) Sripada
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dpt: Use shmem for dpt objects (rev2)
2023-07-19 2:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
@ 2023-07-21 4:50 ` Sripada, Radhakrishna
0 siblings, 0 replies; 19+ messages in thread
From: Sripada, Radhakrishna @ 2023-07-21 4:50 UTC (permalink / raw)
To: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 53605 bytes --]
The tests/platforms failed are not related to code changes made as the changes only apply to ADL-P DG2 and beyond.
The failures look like false positives.
--Radhakrishna(RK) Sripada
From: Patchwork <patchwork@emeril.freedesktop.org>
Sent: Tuesday, July 18, 2023 7:50 PM
To: Sripada, Radhakrishna <radhakrishna.sripada@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.IGT: failure for drm/i915/dpt: Use shmem for dpt objects (rev2)
Patch Details
Series: drm/i915/dpt: Use shmem for dpt objects (rev2)
URL: https://patchwork.freedesktop.org/series/120885/
State: failure
Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/index.html
CI Bug Log - changes from CI_DRM_13394_full -> Patchwork_120885v2_full
Summary
FAILURE
Serious unknown changes coming with Patchwork_120885v2_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_120885v2_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 10)
No changes in participating hosts
Possible new issues
Here are the unknown changes that may have been introduced in Patchwork_120885v2_full:
IGT changes
Possible regressions
• igt@gem_exec_whisper@basic-contexts-forked-all:
o shard-snb: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-snb7/igt@gem_exec_whisper@basic-contexts-forked-all.html> -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@gem_exec_whisper@basic-contexts-forked-all.html>
• igt@kms_flip@blocking-wf_vblank@b-vga1:
o shard-snb: NOTRUN -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@kms_flip@blocking-wf_vblank@b-vga1.html>
New tests
New tests have been introduced between CI_DRM_13394_full and Patchwork_120885v2_full:
New IGT tests (106)
• igt@api_intel_bb@blit-noreloc-keep-cache:
o Statuses : 7 pass(s) 1 skip(s)
o Exec time: [0.0] s
• igt@api_intel_bb@blit-noreloc-purge-cache:
o Statuses : 7 pass(s) 1 skip(s)
o Exec time: [0.0] s
• igt@api_intel_bb@blit-reloc-keep-cache:
o Statuses : 4 pass(s) 4 skip(s)
o Exec time: [0.0] s
• igt@api_intel_bb@blit-reloc-purge-cache:
o Statuses : 4 pass(s) 4 skip(s)
o Exec time: [0.0] s
• igt@api_intel_bb@full-batch:
o Statuses : 7 pass(s)
o Exec time: [0.0] s
• igt@api_intel_bb@intel-bb-blit-none:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@api_intel_bb@intel-bb-blit-x:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@api_intel_bb@intel-bb-blit-y:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@api_intel_bb@offset-control:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@api_intel_bb@simple-bb:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@api_intel_bb@simple-bb-ctx:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@gem_ctx_param@invalid-get-engines:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@gem_ctx_param@invalid-get-no-zeromap:
o Statuses : 7 pass(s)
o Exec time: [0.0] s
• igt@gem_ctx_param@invalid-get-ringsize:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@gem_ctx_param@invalid-set-no-zeromap:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@gem_ctx_param@invalid-set-ringsize:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@gem_pread@bench:
o Statuses : 4 pass(s) 4 skip(s)
o Exec time: [0.0] s
• igt@i915_selftest@live@gem_migrate:
o Statuses : 8 pass(s)
o Exec time: [0.0] s
• igt@kms_async_flips@test-cursor@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_async_flips@test-cursor@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_async_flips@test-cursor@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_async_flips@test-cursor@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_concurrent@pipe-c@hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_cursor_crc@cursor-alpha-opaque@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_cursor_crc@cursor-alpha-opaque@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_dither@fb-8bpc-vs-panel-6bpc:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_dither@fb-8bpc-vs-panel-8bpc:
o Statuses : 3 skip(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-fb-recreate-interruptible@a-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-fb-recreate-interruptible@b-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-fb-recreate-interruptible@c-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-fb-recreate-interruptible@d-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-ts-check@a-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-ts-check@b-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-ts-check@c-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@plain-flip-ts-check@d-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@a-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@b-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@c-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset@d-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@wf_vblank-ts-check-interruptible@a-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@wf_vblank-ts-check-interruptible@b-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@wf_vblank-ts-check-interruptible@c-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_flip@wf_vblank-ts-check-interruptible@d-hdmi-a4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-a:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-b:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-c:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@bad-vsync-end@hdmi-a-4-pipe-d:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-a:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-b:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-c:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_invalid_mode@int-max-clock@hdmi-a-4-pipe-d:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_mmap_write_crc@main@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_pipe_crc_basic@read-crc@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_pipe_crc_basic@read-crc@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_pipe_crc_basic@read-crc@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_pipe_crc_basic@read-crc@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-x@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-x@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-x@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-x@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-y@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-y@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-y@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_lowres@tiling-y@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-a-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-b-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-c-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-25@pipe-d-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-pixel-format-factor-0-5@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-a-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-b-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-c-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-5@pipe-d-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-a-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-b-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-c-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-d-hdmi-a-4:
o Statuses : 1 skip(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@plane-upscale-with-pixel-format-20x20@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-unity-scaling-downscale-factor-0-75@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-20x20-downscale-factor-0-75@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-c-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-d-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_sequence@get-busy@hdmi-a-4-pipe-a:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_sequence@get-busy@hdmi-a-4-pipe-b:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_sequence@get-busy@hdmi-a-4-pipe-c:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_sequence@get-busy@hdmi-a-4-pipe-d:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_setmode@basic@pipe-a-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
• igt@kms_setmode@basic@pipe-b-hdmi-a-4:
o Statuses : 1 pass(s)
o Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_120885v2_full that come from known issues:
IGT changes
Issues hit
• igt@device_reset@cold-reset-bound:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@device_reset@cold-reset-bound.html> (i915#7701<https://gitlab.freedesktop.org/drm/intel/issues/7701>)
• igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
o shard-rkl: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-2/igt@drm_fdinfo@most-busy-idle-check-all@rcs0.html> (i915#7742<https://gitlab.freedesktop.org/drm/intel/issues/7742>)
• igt@feature_discovery@display-2x:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@feature_discovery@display-2x.html> (i915#1839<https://gitlab.freedesktop.org/drm/intel/issues/1839>)
• igt@gem_ctx_persistence@idempotent:
o shard-snb: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb6/igt@gem_ctx_persistence@idempotent.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> / i915#1099<https://gitlab.freedesktop.org/drm/intel/issues/1099>) +1 similar issue
• igt@gem_exec_fair@basic-deadline:
o shard-rkl: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-6/igt@gem_exec_fair@basic-deadline.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-6/igt@gem_exec_fair@basic-deadline.html> (i915#2846<https://gitlab.freedesktop.org/drm/intel/issues/2846>)
• igt@gem_exec_fair@basic-none-vip@rcs0:
o shard-rkl: NOTRUN -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_exec_fair@basic-none-vip@rcs0.html> (i915#2842<https://gitlab.freedesktop.org/drm/intel/issues/2842>)
• igt@gem_exec_fair@basic-pace-share@rcs0:
o shard-tglu: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-8/igt@gem_exec_fair@basic-pace-share@rcs0.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-9/igt@gem_exec_fair@basic-pace-share@rcs0.html> (i915#2842<https://gitlab.freedesktop.org/drm/intel/issues/2842>)
• igt@gem_exec_fair@basic-pace@vecs0:
o shard-rkl: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@gem_exec_fair@basic-pace@vecs0.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-2/igt@gem_exec_fair@basic-pace@vecs0.html> (i915#2842<https://gitlab.freedesktop.org/drm/intel/issues/2842>) +2 similar issues
• igt@gem_exec_params@secure-non-master:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_exec_params@secure-non-master.html> (fdo#112283<https://bugs.freedesktop.org/show_bug.cgi?id=112283>)
• igt@gem_exec_reloc@basic-gtt-read:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_exec_reloc@basic-gtt-read.html> (i915#3281<https://gitlab.freedesktop.org/drm/intel/issues/3281>) +2 similar issues
• igt@gem_exec_suspend@basic-s4-devices@smem:
o shard-tglu: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-8/igt@gem_exec_suspend@basic-s4-devices@smem.html> -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devices@smem.html> (i915#7975<https://gitlab.freedesktop.org/drm/intel/issues/7975> / i915#8213<https://gitlab.freedesktop.org/drm/intel/issues/8213>)
• igt@gem_exec_whisper@basic-contexts-forked-all:
o shard-mtlp: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-1/igt@gem_exec_whisper@basic-contexts-forked-all.html> -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@gem_exec_whisper@basic-contexts-forked-all.html> (i915#8131<https://gitlab.freedesktop.org/drm/intel/issues/8131>)
• igt@gem_lmem_swapping@basic:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_lmem_swapping@basic.html> (i915#4613<https://gitlab.freedesktop.org/drm/intel/issues/4613>)
• igt@gem_lmem_swapping@heavy-verify-random:
o shard-apl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@gem_lmem_swapping@heavy-verify-random.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> / i915#4613<https://gitlab.freedesktop.org/drm/intel/issues/4613>) +1 similar issue
• igt@gem_lmem_swapping@smem-oom@lmem0:
o shard-dg2: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@gem_lmem_swapping@smem-oom@lmem0.html> -> DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-3/igt@gem_lmem_swapping@smem-oom@lmem0.html> (i915#4936<https://gitlab.freedesktop.org/drm/intel/issues/4936> / i915#5493<https://gitlab.freedesktop.org/drm/intel/issues/5493>)
• igt@gem_mmap@bad-object:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gem_mmap@bad-object.html> (i915#4083<https://gitlab.freedesktop.org/drm/intel/issues/4083>)
• igt@gem_pwrite@basic-exhaustion:
o shard-apl: NOTRUN -> WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@gem_pwrite@basic-exhaustion.html> (i915#2658<https://gitlab.freedesktop.org/drm/intel/issues/2658>)
• igt@gem_pxp@reject-modify-context-protection-off-2:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@gem_pxp@reject-modify-context-protection-off-2.html> (i915#4270<https://gitlab.freedesktop.org/drm/intel/issues/4270>)
• igt@gem_readwrite@new-obj:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gem_readwrite@new-obj.html> (i915#3282<https://gitlab.freedesktop.org/drm/intel/issues/3282>)
• igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@gem_render_copy@y-tiled-ccs-to-y-tiled-mc-ccs.html> (i915#8428<https://gitlab.freedesktop.org/drm/intel/issues/8428>) +1 similar issue
• igt@gem_set_tiling_vs_pwrite:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_set_tiling_vs_pwrite.html> (i915#3282<https://gitlab.freedesktop.org/drm/intel/issues/3282>) +3 similar issues
• igt@gem_userptr_blits@coherency-sync:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@gem_userptr_blits@coherency-sync.html> (fdo#110542<https://bugs.freedesktop.org/show_bug.cgi?id=110542>)
• igt@gem_userptr_blits@relocations:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-1/igt@gem_userptr_blits@relocations.html> (i915#3281<https://gitlab.freedesktop.org/drm/intel/issues/3281>) +2 similar issues
• igt@gen7_exec_parse@batch-without-end:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gen7_exec_parse@batch-without-end.html> (fdo#109289<https://bugs.freedesktop.org/show_bug.cgi?id=109289>)
• igt@gen9_exec_parse@allowed-single:
o shard-glk: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk1/igt@gen9_exec_parse@allowed-single.html> -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-glk9/igt@gen9_exec_parse@allowed-single.html> (i915#5566<https://gitlab.freedesktop.org/drm/intel/issues/5566>)
• igt@i915_pm_rpm@cursor:
o shard-tglu: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-2/igt@i915_pm_rpm@cursor.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-7/igt@i915_pm_rpm@cursor.html> (i915#7940<https://gitlab.freedesktop.org/drm/intel/issues/7940>) +1 similar issue
• igt@i915_pm_rpm@modeset-non-lpsp-stress:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@i915_pm_rpm@modeset-non-lpsp-stress.html> (i915#1397<https://gitlab.freedesktop.org/drm/intel/issues/1397>)
• igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
o shard-dg2: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-5/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html> -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-10/igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait.html> (i915#1397<https://gitlab.freedesktop.org/drm/intel/issues/1397>) +1 similar issue
• igt@i915_pm_rpm@pm-caching:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@i915_pm_rpm@pm-caching.html> (i915#4077<https://gitlab.freedesktop.org/drm/intel/issues/4077>) +2 similar issues
• igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html> (i915#5190<https://gitlab.freedesktop.org/drm/intel/issues/5190>)
• igt@kms_addfb_basic@clobberred-modifier:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_addfb_basic@clobberred-modifier.html> (i915#4212<https://gitlab.freedesktop.org/drm/intel/issues/4212>)
• igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-2:
o shard-glk: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk5/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-2.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-glk5/igt@kms_async_flips@alternate-sync-async-flip@pipe-a-hdmi-a-2.html> (i915#2521<https://gitlab.freedesktop.org/drm/intel/issues/2521>) +1 similar issue
• igt@kms_async_flips@crc@pipe-a-hdmi-a-3:
o shard-dg2: NOTRUN -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@kms_async_flips@crc@pipe-a-hdmi-a-3.html> (i915#8247<https://gitlab.freedesktop.org/drm/intel/issues/8247>) +3 similar issues
• igt@kms_big_fb@4-tiled-8bpp-rotate-90:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_big_fb@4-tiled-8bpp-rotate-90.html> (i915#5286<https://gitlab.freedesktop.org/drm/intel/issues/5286>)
• igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0:
o shard-mtlp: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-1/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-2/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0.html> (i915#5138<https://gitlab.freedesktop.org/drm/intel/issues/5138>)
• igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
o shard-mtlp: NOTRUN -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html> (i915#3743<https://gitlab.freedesktop.org/drm/intel/issues/3743>)
• igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip:
o shard-mtlp: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-7/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-5/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip.html> (i915#3743<https://gitlab.freedesktop.org/drm/intel/issues/3743>)
• igt@kms_big_fb@y-tiled-64bpp-rotate-180:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_big_fb@y-tiled-64bpp-rotate-180.html> (fdo#111615<https://bugs.freedesktop.org/show_bug.cgi?id=111615>)
• igt@kms_big_fb@yf-tiled-64bpp-rotate-90:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_big_fb@yf-tiled-64bpp-rotate-90.html> (fdo#110723<https://bugs.freedesktop.org/show_bug.cgi?id=110723>) +1 similar issue
• igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_ccs@pipe-a-missing-ccs-buffer-yf_tiled_ccs.html> (i915#3734<https://gitlab.freedesktop.org/drm/intel/issues/3734> / i915#5354<https://gitlab.freedesktop.org/drm/intel/issues/5354> / i915#6095<https://gitlab.freedesktop.org/drm/intel/issues/6095>) +3 similar issues
• igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_ccs:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_ccs.html> (i915#6095<https://gitlab.freedesktop.org/drm/intel/issues/6095>) +6 similar issues
• igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
o shard-apl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> / i915#3886<https://gitlab.freedesktop.org/drm/intel/issues/3886>) +2 similar issues
• igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_ccs@pipe-c-bad-aux-stride-y_tiled_gen12_rc_ccs_cc.html> (i915#5354<https://gitlab.freedesktop.org/drm/intel/issues/5354>) +5 similar issues
• igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html> (i915#3886<https://gitlab.freedesktop.org/drm/intel/issues/3886> / i915#6095<https://gitlab.freedesktop.org/drm/intel/issues/6095>) +1 similar issue
• igt@kms_cdclk@mode-transition@pipe-d-hdmi-a-3:
o shard-dg2: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-1/igt@kms_cdclk@mode-transition@pipe-d-hdmi-a-3.html> (i915#4087<https://gitlab.freedesktop.org/drm/intel/issues/4087> / i915#7213<https://gitlab.freedesktop.org/drm/intel/issues/7213>) +3 similar issues
• igt@kms_chamelium_hpd@dp-hpd-enable-disable-mode:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_chamelium_hpd@dp-hpd-enable-disable-mode.html> (i915#7828<https://gitlab.freedesktop.org/drm/intel/issues/7828>) +1 similar issue
• igt@kms_chamelium_hpd@vga-hpd-without-ddc:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_chamelium_hpd@vga-hpd-without-ddc.html> (i915#7828<https://gitlab.freedesktop.org/drm/intel/issues/7828>)
• igt@kms_content_protection@atomic@pipe-a-dp-4:
o shard-dg2: NOTRUN -> TIMEOUT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_content_protection@atomic@pipe-a-dp-4.html> (i915#7173<https://gitlab.freedesktop.org/drm/intel/issues/7173>)
• igt@kms_cursor_crc@cursor-rapid-movement-32x10:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-1/igt@kms_cursor_crc@cursor-rapid-movement-32x10.html> (i915#8814<https://gitlab.freedesktop.org/drm/intel/issues/8814>)
• igt@kms_cursor_crc@cursor-rapid-movement-max-size:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_cursor_crc@cursor-rapid-movement-max-size.html> (i915#3555<https://gitlab.freedesktop.org/drm/intel/issues/3555>)
• igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-1/igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic.html> (i915#3546<https://gitlab.freedesktop.org/drm/intel/issues/3546>)
• igt@kms_cursor_legacy@cursorb-vs-flipb-toggle:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_cursor_legacy@cursorb-vs-flipb-toggle.html> (fdo#111767<https://bugs.freedesktop.org/show_bug.cgi?id=111767> / i915#3546<https://gitlab.freedesktop.org/drm/intel/issues/3546>)
• igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
o shard-apl: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size.html> (i915#2346<https://gitlab.freedesktop.org/drm/intel/issues/2346>) +1 similar issue
• igt@kms_display_modes@extended-mode-basic:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_display_modes@extended-mode-basic.html> (i915#8827<https://gitlab.freedesktop.org/drm/intel/issues/8827>)
• igt@kms_flip@2x-dpms-vs-vblank-race:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_flip@2x-dpms-vs-vblank-race.html> (fdo#111825<https://bugs.freedesktop.org/show_bug.cgi?id=111825>)
• igt@kms_flip@2x-flip-vs-wf_vblank-interruptible:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_flip@2x-flip-vs-wf_vblank-interruptible.html> (i915#3637<https://gitlab.freedesktop.org/drm/intel/issues/3637>) +1 similar issue
• igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2:
o shard-glk: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-glk6/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-glk3/igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a2.html> (i915#79<https://gitlab.freedesktop.org/drm/intel/issues/79>)
• igt@kms_flip@flip-vs-suspend@c-dp4:
o shard-dg2: NOTRUN -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_flip@flip-vs-suspend@c-dp4.html> (fdo#103375<https://bugs.freedesktop.org/show_bug.cgi?id=103375>)
• igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-downscaling@pipe-a-valid-mode:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_flip_scaled_crc@flip-32bpp-yftile-to-32bpp-yftileccs-downscaling@pipe-a-valid-mode.html> (i915#2672<https://gitlab.freedesktop.org/drm/intel/issues/2672>)
• igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-default-mode:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs-downscaling@pipe-a-default-mode.html> (i915#2672<https://gitlab.freedesktop.org/drm/intel/issues/2672>)
• igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-render:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-shrfb-draw-render.html> (fdo#111825<https://bugs.freedesktop.org/show_bug.cgi?id=111825> / i915#1825<https://gitlab.freedesktop.org/drm/intel/issues/1825>) +6 similar issues
• igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-plflip-blt:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-shrfb-plflip-blt.html> (i915#1825<https://gitlab.freedesktop.org/drm/intel/issues/1825>) +5 similar issues
• igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render:
o shard-dg2: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-render.html> (i915#6880<https://gitlab.freedesktop.org/drm/intel/issues/6880>)
• igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-shrfb-draw-blt.html> (i915#3023<https://gitlab.freedesktop.org/drm/intel/issues/3023>) +5 similar issues
• igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_frontbuffer_tracking@psr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html> (i915#8708<https://gitlab.freedesktop.org/drm/intel/issues/8708>) +1 similar issue
• igt@kms_hdr@static-toggle:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_hdr@static-toggle.html> (i915#3555<https://gitlab.freedesktop.org/drm/intel/issues/3555> / i915#8228<https://gitlab.freedesktop.org/drm/intel/issues/8228>)
• igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_pipe_b_c_ivb@pipe-b-double-modeset-then-modeset-pipe-c.html> (fdo#109289<https://bugs.freedesktop.org/show_bug.cgi?id=109289>)
• igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-1:
o shard-snb: NOTRUN -> DMESG-WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb1/igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-1.html> (i915#8841<https://gitlab.freedesktop.org/drm/intel/issues/8841>) +4 similar issues
• igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1:
o shard-apl: NOTRUN -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1.html> (i915#4573<https://gitlab.freedesktop.org/drm/intel/issues/4573>) +1 similar issue
• igt@kms_plane_scaling@intel-max-src-size@pipe-a-hdmi-a-2:
o shard-rkl: NOTRUN -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-1/igt@kms_plane_scaling@intel-max-src-size@pipe-a-hdmi-a-2.html> (i915#8292<https://gitlab.freedesktop.org/drm/intel/issues/8292>)
• igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-1.html> (i915#5176<https://gitlab.freedesktop.org/drm/intel/issues/5176>) +3 similar issues
• igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-3:
o shard-dg2: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-1/igt@kms_plane_scaling@plane-downscale-with-rotation-factor-0-25@pipe-b-hdmi-a-3.html> (i915#5176<https://gitlab.freedesktop.org/drm/intel/issues/5176>) +3 similar issues
• igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_plane_scaling@plane-scaler-with-clipping-clamping-pixel-formats@pipe-b-edp-1.html> (i915#5176<https://gitlab.freedesktop.org/drm/intel/issues/5176>) +1 similar issue
• igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1:
o shard-snb: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-snb7/igt@kms_plane_scaling@plane-upscale-with-modifiers-factor-0-25@pipe-a-vga-1.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +251 similar issues
• igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-b-hdmi-a-2:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-1/igt@kms_plane_scaling@planes-downscale-factor-0-25-upscale-20x20@pipe-b-hdmi-a-2.html> (i915#5235<https://gitlab.freedesktop.org/drm/intel/issues/5235>) +3 similar issues
• igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-hdmi-a-3:
o shard-dg2: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-25@pipe-a-hdmi-a-3.html> (i915#5235<https://gitlab.freedesktop.org/drm/intel/issues/5235>) +15 similar issues
• igt@kms_psr2_sf@overlay-plane-update-continuous-sf:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_psr2_sf@overlay-plane-update-continuous-sf.html> (fdo#111068<https://bugs.freedesktop.org/show_bug.cgi?id=111068> / i915#658<https://gitlab.freedesktop.org/drm/intel/issues/658>)
• igt@kms_psr2_su@frontbuffer-xrgb8888:
o shard-apl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_psr2_su@frontbuffer-xrgb8888.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> / i915#658<https://gitlab.freedesktop.org/drm/intel/issues/658>)
• igt@kms_psr@primary_page_flip:
o shard-apl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_psr@primary_page_flip.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271>) +38 similar issues
• igt@kms_rotation_crc@bad-pixel-format:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@kms_rotation_crc@bad-pixel-format.html> (i915#4235<https://gitlab.freedesktop.org/drm/intel/issues/4235>) +1 similar issue
• igt@kms_tv_load_detect@load-detect:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_tv_load_detect@load-detect.html> (fdo#109309<https://bugs.freedesktop.org/show_bug.cgi?id=109309>)
• igt@kms_vblank@pipe-d-wait-idle:
o shard-apl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_vblank@pipe-d-wait-idle.html> (fdo#109271<https://bugs.freedesktop.org/show_bug.cgi?id=109271> / i915#533<https://gitlab.freedesktop.org/drm/intel/issues/533>)
• igt@kms_writeback@writeback-check-output:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_writeback@writeback-check-output.html> (i915#2437<https://gitlab.freedesktop.org/drm/intel/issues/2437>)
• igt@perf@enable-disable@0-rcs0:
o shard-dg2: PASS<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-1/igt@perf@enable-disable@0-rcs0.html> -> FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@perf@enable-disable@0-rcs0.html> (i915#8724<https://gitlab.freedesktop.org/drm/intel/issues/8724>)
• igt@tools_test@sysfs_l3_parity:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@tools_test@sysfs_l3_parity.html> (fdo#109307<https://bugs.freedesktop.org/show_bug.cgi?id=109307>)
• igt@v3d/v3d_submit_csd@job-perfmon:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@v3d/v3d_submit_csd@job-perfmon.html> (fdo#109315<https://bugs.freedesktop.org/show_bug.cgi?id=109315>) +2 similar issues
• igt@v3d/v3d_submit_csd@multi-and-single-sync:
o shard-mtlp: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@v3d/v3d_submit_csd@multi-and-single-sync.html> (i915#2575<https://gitlab.freedesktop.org/drm/intel/issues/2575>) +2 similar issues
• igt@vc4/vc4_tiling@get-bad-flags:
o shard-rkl: NOTRUN -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@vc4/vc4_tiling@get-bad-flags.html> (i915#7711<https://gitlab.freedesktop.org/drm/intel/issues/7711>) +1 similar issue
Possible fixes
• igt@gem_eio@kms:
o shard-dg2: INCOMPLETE<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-3/igt@gem_eio@kms.html> (i915#7892<https://gitlab.freedesktop.org/drm/intel/issues/7892>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@gem_eio@kms.html>
• igt@gem_eio@reset-stress:
o {shard-dg1}: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-14/igt@gem_eio@reset-stress.html> (i915#5784<https://gitlab.freedesktop.org/drm/intel/issues/5784>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-14/igt@gem_eio@reset-stress.html>
• igt@gem_exec_whisper@basic-contexts-priority-all:
o shard-mtlp: ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-6/igt@gem_exec_whisper@basic-contexts-priority-all.html> (i915#8131<https://gitlab.freedesktop.org/drm/intel/issues/8131>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@gem_exec_whisper@basic-contexts-priority-all.html>
• igt@gem_lmem_swapping@smem-oom@lmem0:
o {shard-dg1}: TIMEOUT<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-15/igt@gem_lmem_swapping@smem-oom@lmem0.html> (i915#5493<https://gitlab.freedesktop.org/drm/intel/issues/5493>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-16/igt@gem_lmem_swapping@smem-oom@lmem0.html>
• igt@i915_module_load@reload-with-fault-injection:
o shard-mtlp: ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-3/igt@i915_module_load@reload-with-fault-injection.html> (i915#8489<https://gitlab.freedesktop.org/drm/intel/issues/8489> / i915#8668<https://gitlab.freedesktop.org/drm/intel/issues/8668>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-7/igt@i915_module_load@reload-with-fault-injection.html>
• igt@i915_pipe_stress@stress-xrgb8888-untiled:
o shard-mtlp: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-6/igt@i915_pipe_stress@stress-xrgb8888-untiled.html> (i915#8691<https://gitlab.freedesktop.org/drm/intel/issues/8691>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@i915_pipe_stress@stress-xrgb8888-untiled.html>
• igt@i915_pm_rc6_residency@rc6-idle@rcs0:
o {shard-dg1}: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-16/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html> (i915#3591<https://gitlab.freedesktop.org/drm/intel/issues/3591>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-12/igt@i915_pm_rc6_residency@rc6-idle@rcs0.html>
• igt@i915_pm_rpm@dpms-lpsp:
o {shard-dg1}: SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg1-12/igt@i915_pm_rpm@dpms-lpsp.html> (i915#1397<https://gitlab.freedesktop.org/drm/intel/issues/1397>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg1-19/igt@i915_pm_rpm@dpms-lpsp.html>
• igt@i915_pm_rpm@dpms-non-lpsp:
o shard-rkl: SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-7/igt@i915_pm_rpm@dpms-non-lpsp.html> (i915#1397<https://gitlab.freedesktop.org/drm/intel/issues/1397>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-1/igt@i915_pm_rpm@dpms-non-lpsp.html> +1 similar issue
• igt@i915_pm_rpm@gem-execbuf-stress@smem0:
o shard-tglu: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-7/igt@i915_pm_rpm@gem-execbuf-stress@smem0.html> (i915#7940<https://gitlab.freedesktop.org/drm/intel/issues/7940>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-10/igt@i915_pm_rpm@gem-execbuf-stress@smem0.html> +2 similar issues
• igt@i915_pm_rpm@modeset-non-lpsp:
o shard-dg2: SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-10/igt@i915_pm_rpm@modeset-non-lpsp.html> (i915#1397<https://gitlab.freedesktop.org/drm/intel/issues/1397>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-8/igt@i915_pm_rpm@modeset-non-lpsp.html>
• igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
o shard-mtlp: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-2/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html> (i915#3743<https://gitlab.freedesktop.org/drm/intel/issues/3743>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-5/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html>
• igt@kms_cursor_legacy@flip-vs-cursor-toggle:
o shard-mtlp: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-3/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html> (i915#2346<https://gitlab.freedesktop.org/drm/intel/issues/2346>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-3/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html>
• igt@kms_fbcon_fbt@fbc-suspend:
o shard-apl: ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-apl7/igt@kms_fbcon_fbt@fbc-suspend.html> (i915#180<https://gitlab.freedesktop.org/drm/intel/issues/180>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-apl1/igt@kms_fbcon_fbt@fbc-suspend.html>
• igt@kms_rotation_crc@primary-y-tiled-reflect-x-180:
o shard-rkl: ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-7/igt@kms_rotation_crc@primary-y-tiled-reflect-x-180.html> (i915#7461<https://gitlab.freedesktop.org/drm/intel/issues/7461>) -> PASS<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_rotation_crc@primary-y-tiled-reflect-x-180.html>
Warnings
• igt@i915_pm_rc6_residency@rc6-idle@vecs0:
o shard-tglu: FAIL<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-tglu-4/igt@i915_pm_rc6_residency@rc6-idle@vecs0.html> (i915#2681<https://gitlab.freedesktop.org/drm/intel/issues/2681> / i915#3591<https://gitlab.freedesktop.org/drm/intel/issues/3591>) -> WARN<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-tglu-6/igt@i915_pm_rc6_residency@rc6-idle@vecs0.html> (i915#2681<https://gitlab.freedesktop.org/drm/intel/issues/2681>)
• igt@kms_content_protection@mei_interface:
o shard-dg2: SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-dg2-1/igt@kms_content_protection@mei_interface.html> (i915#7118<https://gitlab.freedesktop.org/drm/intel/issues/7118>) -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-dg2-11/igt@kms_content_protection@mei_interface.html> (i915#7118<https://gitlab.freedesktop.org/drm/intel/issues/7118> / i915#7162<https://gitlab.freedesktop.org/drm/intel/issues/7162>)
• igt@kms_fbcon_fbt@psr:
o shard-rkl: SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@kms_fbcon_fbt@psr.html> (fdo#110189<https://bugs.freedesktop.org/show_bug.cgi?id=110189> / i915#3955<https://gitlab.freedesktop.org/drm/intel/issues/3955>) -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-7/igt@kms_fbcon_fbt@psr.html> (i915#3955<https://gitlab.freedesktop.org/drm/intel/issues/3955>)
• igt@kms_force_connector_basic@force-load-detect:
o shard-rkl: SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-rkl-2/igt@kms_force_connector_basic@force-load-detect.html> (fdo#109285<https://bugs.freedesktop.org/show_bug.cgi?id=109285> / i915#4098<https://gitlab.freedesktop.org/drm/intel/issues/4098>) -> SKIP<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-rkl-6/igt@kms_force_connector_basic@force-load-detect.html> (fdo#109285<https://bugs.freedesktop.org/show_bug.cgi?id=109285>)
• igt@sysfs_timeslice_duration@timeout@vecs0:
o shard-mtlp: TIMEOUT<https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13394/shard-mtlp-4/igt@sysfs_timeslice_duration@timeout@vecs0.html> (i915#6950<https://gitlab.freedesktop.org/drm/intel/issues/6950>) -> ABORT<https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120885v2/shard-mtlp-6/igt@sysfs_timeslice_duration@timeout@vecs0.html> (i915#8521<https://gitlab.freedesktop.org/drm/intel/issues/8521>)
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
Build changes
• Linux: CI_DRM_13394 -> Patchwork_120885v2
CI-20190529: 20190529
CI_DRM_13394: 4fab7ebb2e3675cb9fcd7a94a7b34caa0ea855cf @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_7392: 1e7c1d677d7ba57f342486bc522ed1bb6c19bf5e @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_120885v2: 4fab7ebb2e3675cb9fcd7a94a7b34caa0ea855cf @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
[-- Attachment #2: Type: text/html, Size: 113404 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-20 17:02 ` [Intel-gfx] " Sripada, Radhakrishna
@ 2023-07-21 8:17 ` Tvrtko Ursulin
-1 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-21 8:17 UTC (permalink / raw)
To: Sripada, Radhakrishna, Yang, Fei, intel-gfx
Cc: stable, Ville Syrjälä, Wilson, Chris P
On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
> Hi Tvrtko,
>
>> -----Original Message-----
>> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Sent: Thursday, July 20, 2023 2:17 AM
>> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
>> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
>> Chris P <chris.p.wilson@intel.com>
>> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>>
>>
>> On 19/07/2023 21:53, Yang, Fei wrote:
>>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>>>>> Dpt objects that are created from internal get evicted when there is
>>>>> memory pressure and do not get restored when pinned during scanout.
>>>>> The pinned page table entries look corrupted and programming the
>>>>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>>>>
>>>>> Create DPT objects from shmem and mark the object as dirty when
>>>>> pinning so that the object is restored when shrinker evicts an unpinned
>> buffer object.
>>>>>
>>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>>>>
>>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>>>>> for dpt")
>>>>> Cc: <stable@vger.kernel.org> # v6.0+
>>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> index 7c5fddb203ba..fbfd8f959f17 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
>> i915_address_space *vm)
>>>>> i915_vma_get(vma);
>>>>> }
>>>>>
>>>>> + dpt->obj->mm.dirty = true;
>>>>> +
>>>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>>>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>>>>
>>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>>>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>>>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>>>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>>>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>>>>> }
>>>>> if (IS_ERR(dpt_obj))
>>>>> return ERR_CAST(dpt_obj);
>>>>
>>>> Okay I think I get it after some more looking at the DPT code paths.
>>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
>>>> are lost when backing store is discarded.
>>>>
>>>> Changing to shmem object indeed looks the easiest option.
>>>>
>>>> Some related thoughts:
>>>>
>>>> 1)
>>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
>>>> Could you investigate please? On a glance their job was to restore the
>>>> PTEs which would be lost from internal objects backing storage. With
>>>> shmem objects that content should be preserved.
>>>
>>> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
>>> objects are mapped into, but also the framebuffer objects. I don't have
>>> much knowledge on how the framebuffer objects are managed, but the
>> suspend
>>> resume path still look necessary to me, unless the content of these
>>> framebuffer objects are also preserved.
>>
>> I don't think it has anything to do with fb content, but you are correct
>> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
>> mapping for DPT FBs across system suspend/resume") reminds me backing
>> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
>> Even though with this patch internal is out of the picture, stolen
>> remains and so the issue of losing the page table content remains.
>> Perhaps resume could be optimised to only restore PTEs when VM page
>> tables are backed by stolen which may win some suspend/resume speed on
>> some platforms.
>
> I will have to look into how suspend resume will change with the current flow
> as you said it can be looked in a later patch.
Thanks!
>>>> 2)
>>>> I wonder if i915_vma_flush_writes should be used (as a companion of
>>>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
>>>> then I am also not sure if it does the right thing for the
>>>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
>>>> call __i915_gem_object_flush_map itself for that mapping flavour and
>>>> not do the ggtt flushing in that case.
> I am not sure if dpt_bind_vma will be called each time during pinning. IMO it gets called
> Only when the fb object needs to be bind after and unbind(triggered during obj destroy).
> Do you think if i915_vma_flush_writes should not be used if dpt objects are created from internal?
No, I *think* correct API usage is supposed to be: If one uses
i915_vma_pin_iomap() for CPU access, then one should call
i915_vma_flush_writes() after CPU writes are done - presumably as a
barrier to make sure writes are visible before proceeding.
If that is correct, the I noticed problem (or I am missing something),
that i915_vma_flush_writes only does something for the one of the three
ways i915_vma_pin_iomap() can set up the CPU visible mapping (the
ggtt->iomap path).
The i915_gem_object_lmem_io_map() path, relevant on dgfx, has no
flushing. Maybe it does need it due WC, or maybe flushing the
write-combine buffers would still be needed.
And the i915_gem_object_pin_map() path is also WC and in theory there is
the corresponding __i915_gem_object_flush_map().
Don't know, maybe I am indeed missing something.
But for instance if __i915_gem_object_flush_map() *was* called from
i915_vma_flush_writes(), and the latter *was* called after dpt_bind_vma
does its thing, then notice how obj->mm.dirty *would* be set by that
helper. Removing the need for this patch.
So perhaps i915_vma_flush_writes() should just dirty the object, *if*
the idea is to be called after CPU writes. And perhaps it should call
i915_gem_object_flush_map *if* the method of mmaping was other than
ggtt. But the information would have to be recorded first, probably same
as the i915_gem_object_pin_map() path records it in the bit 0 of the
vma->iomap pointer.
> Or should we have a different flavor of i915_vm_pin_iomap that skips i915_vma_set_ggtt_write
> so that we can drop i915_vma_flush_writes during unpinning and move i915_vma_set_ggtt_write
> to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess __i915_gem_object_flush_map
> called during vma bind and not object pinning. In either case I believe it is a larger cleanup
> which requires more extensive validation and analysis.
Yes definitely wasn't suggesting to do it in this patch.
>>>> In summary I think the fix is safe and correct but at least point 1) I
>>>> think needs looking into. It can be a follow up work too.
>
> If you think this fix can work then I will look into the suspend/resume as a follow up and will appreciate
> an r-b for this change. I believe 2) is a larger cleanup that may not be immediately required. I will have
> to dig more into the ramifications of the changes proposed above.
>
> Thoughts ?
Yeah it is fine. I assumed someone else would r-b but I can too.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-21 8:17 ` Tvrtko Ursulin
0 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-21 8:17 UTC (permalink / raw)
To: Sripada, Radhakrishna, Yang, Fei, intel-gfx; +Cc: Wilson, Chris P, stable
On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
> Hi Tvrtko,
>
>> -----Original Message-----
>> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Sent: Thursday, July 20, 2023 2:17 AM
>> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
>> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
>> Chris P <chris.p.wilson@intel.com>
>> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>>
>>
>> On 19/07/2023 21:53, Yang, Fei wrote:
>>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>>>>> Dpt objects that are created from internal get evicted when there is
>>>>> memory pressure and do not get restored when pinned during scanout.
>>>>> The pinned page table entries look corrupted and programming the
>>>>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>>>>
>>>>> Create DPT objects from shmem and mark the object as dirty when
>>>>> pinning so that the object is restored when shrinker evicts an unpinned
>> buffer object.
>>>>>
>>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>>>>
>>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>>>>> for dpt")
>>>>> Cc: <stable@vger.kernel.org> # v6.0+
>>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> index 7c5fddb203ba..fbfd8f959f17 100644
>>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
>> i915_address_space *vm)
>>>>> i915_vma_get(vma);
>>>>> }
>>>>>
>>>>> + dpt->obj->mm.dirty = true;
>>>>> +
>>>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>>>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>>>>
>>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>>>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>>>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>>>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>>>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>>>>> }
>>>>> if (IS_ERR(dpt_obj))
>>>>> return ERR_CAST(dpt_obj);
>>>>
>>>> Okay I think I get it after some more looking at the DPT code paths.
>>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
>>>> are lost when backing store is discarded.
>>>>
>>>> Changing to shmem object indeed looks the easiest option.
>>>>
>>>> Some related thoughts:
>>>>
>>>> 1)
>>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
>>>> Could you investigate please? On a glance their job was to restore the
>>>> PTEs which would be lost from internal objects backing storage. With
>>>> shmem objects that content should be preserved.
>>>
>>> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
>>> objects are mapped into, but also the framebuffer objects. I don't have
>>> much knowledge on how the framebuffer objects are managed, but the
>> suspend
>>> resume path still look necessary to me, unless the content of these
>>> framebuffer objects are also preserved.
>>
>> I don't think it has anything to do with fb content, but you are correct
>> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
>> mapping for DPT FBs across system suspend/resume") reminds me backing
>> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
>> Even though with this patch internal is out of the picture, stolen
>> remains and so the issue of losing the page table content remains.
>> Perhaps resume could be optimised to only restore PTEs when VM page
>> tables are backed by stolen which may win some suspend/resume speed on
>> some platforms.
>
> I will have to look into how suspend resume will change with the current flow
> as you said it can be looked in a later patch.
Thanks!
>>>> 2)
>>>> I wonder if i915_vma_flush_writes should be used (as a companion of
>>>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc. But
>>>> then I am also not sure if it does the right thing for the
>>>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it should
>>>> call __i915_gem_object_flush_map itself for that mapping flavour and
>>>> not do the ggtt flushing in that case.
> I am not sure if dpt_bind_vma will be called each time during pinning. IMO it gets called
> Only when the fb object needs to be bind after and unbind(triggered during obj destroy).
> Do you think if i915_vma_flush_writes should not be used if dpt objects are created from internal?
No, I *think* correct API usage is supposed to be: If one uses
i915_vma_pin_iomap() for CPU access, then one should call
i915_vma_flush_writes() after CPU writes are done - presumably as a
barrier to make sure writes are visible before proceeding.
If that is correct, the I noticed problem (or I am missing something),
that i915_vma_flush_writes only does something for the one of the three
ways i915_vma_pin_iomap() can set up the CPU visible mapping (the
ggtt->iomap path).
The i915_gem_object_lmem_io_map() path, relevant on dgfx, has no
flushing. Maybe it does need it due WC, or maybe flushing the
write-combine buffers would still be needed.
And the i915_gem_object_pin_map() path is also WC and in theory there is
the corresponding __i915_gem_object_flush_map().
Don't know, maybe I am indeed missing something.
But for instance if __i915_gem_object_flush_map() *was* called from
i915_vma_flush_writes(), and the latter *was* called after dpt_bind_vma
does its thing, then notice how obj->mm.dirty *would* be set by that
helper. Removing the need for this patch.
So perhaps i915_vma_flush_writes() should just dirty the object, *if*
the idea is to be called after CPU writes. And perhaps it should call
i915_gem_object_flush_map *if* the method of mmaping was other than
ggtt. But the information would have to be recorded first, probably same
as the i915_gem_object_pin_map() path records it in the bit 0 of the
vma->iomap pointer.
> Or should we have a different flavor of i915_vm_pin_iomap that skips i915_vma_set_ggtt_write
> so that we can drop i915_vma_flush_writes during unpinning and move i915_vma_set_ggtt_write
> to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess __i915_gem_object_flush_map
> called during vma bind and not object pinning. In either case I believe it is a larger cleanup
> which requires more extensive validation and analysis.
Yes definitely wasn't suggesting to do it in this patch.
>>>> In summary I think the fix is safe and correct but at least point 1) I
>>>> think needs looking into. It can be a follow up work too.
>
> If you think this fix can work then I will look into the suspend/resume as a follow up and will appreciate
> an r-b for this change. I believe 2) is a larger cleanup that may not be immediately required. I will have
> to dig more into the ramifications of the changes proposed above.
>
> Thoughts ?
Yeah it is fine. I assumed someone else would r-b but I can too.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-21 8:17 ` [Intel-gfx] " Tvrtko Ursulin
@ 2023-07-21 23:54 ` Sripada, Radhakrishna
-1 siblings, 0 replies; 19+ messages in thread
From: Sripada, Radhakrishna @ 2023-07-21 23:54 UTC (permalink / raw)
To: Tvrtko Ursulin, Yang, Fei, intel-gfx
Cc: stable, Ville Syrjälä, Wilson, Chris P
Hi Tvrtko,
> -----Original Message-----
> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Sent: Friday, July 21, 2023 1:17 AM
> To: Sripada, Radhakrishna <radhakrishna.sripada@intel.com>; Yang, Fei
> <fei.yang@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
> Chris P <chris.p.wilson@intel.com>
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
> > Hi Tvrtko,
> >
> >> -----Original Message-----
> >> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >> Sent: Thursday, July 20, 2023 2:17 AM
> >> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
> >> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>;
> Wilson,
> >> Chris P <chris.p.wilson@intel.com>
> >> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
> >>
> >>
> >> On 19/07/2023 21:53, Yang, Fei wrote:
> >>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>>>> Dpt objects that are created from internal get evicted when there is
> >>>>> memory pressure and do not get restored when pinned during scanout.
> >>>>> The pinned page table entries look corrupted and programming the
> >>>>> display engine with the incorrect pte's result in DE throwing pipe faults.
> >>>>>
> >>>>> Create DPT objects from shmem and mark the object as dirty when
> >>>>> pinning so that the object is restored when shrinker evicts an unpinned
> >> buffer object.
> >>>>>
> >>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>>>
> >>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>>>> for dpt")
> >>>>> Cc: <stable@vger.kernel.org> # v6.0+
> >>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
> >>>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
> >>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> >>>>> ---
> >>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> >> i915_address_space *vm)
> >>>>> i915_vma_get(vma);
> >>>>> }
> >>>>>
> >>>>> + dpt->obj->mm.dirty = true;
> >>>>> +
> >>>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
> >>>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >>>>>
> >>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
> >>>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
> >>>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>>>> }
> >>>>> if (IS_ERR(dpt_obj))
> >>>>> return ERR_CAST(dpt_obj);
> >>>>
> >>>> Okay I think I get it after some more looking at the DPT code paths.
> >>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >>>> are lost when backing store is discarded.
> >>>>
> >>>> Changing to shmem object indeed looks the easiest option.
> >>>>
> >>>> Some related thoughts:
> >>>>
> >>>> 1)
> >>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >>>> Could you investigate please? On a glance their job was to restore the
> >>>> PTEs which would be lost from internal objects backing storage. With
> >>>> shmem objects that content should be preserved.
> >>>
> >>> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> >>> objects are mapped into, but also the framebuffer objects. I don't have
> >>> much knowledge on how the framebuffer objects are managed, but the
> >> suspend
> >>> resume path still look necessary to me, unless the content of these
> >>> framebuffer objects are also preserved.
> >>
> >> I don't think it has anything to do with fb content, but you are correct
> >> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
> >> mapping for DPT FBs across system suspend/resume") reminds me backing
> >> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
> >> Even though with this patch internal is out of the picture, stolen
> >> remains and so the issue of losing the page table content remains.
> >> Perhaps resume could be optimised to only restore PTEs when VM page
> >> tables are backed by stolen which may win some suspend/resume speed on
> >> some platforms.
> >
> > I will have to look into how suspend resume will change with the current flow
> > as you said it can be looked in a later patch.
>
> Thanks!
>
> >>>> 2)
> >>>> I wonder if i915_vma_flush_writes should be used (as a companion of
> >>>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc.
> But
> >>>> then I am also not sure if it does the right thing for the
> >>>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it
> should
> >>>> call __i915_gem_object_flush_map itself for that mapping flavour and
> >>>> not do the ggtt flushing in that case.
> > I am not sure if dpt_bind_vma will be called each time during pinning. IMO it
> gets called
> > Only when the fb object needs to be bind after and unbind(triggered during obj
> destroy).
> > Do you think if i915_vma_flush_writes should not be used if dpt objects are
> created from internal?
>
> No, I *think* correct API usage is supposed to be: If one uses
> i915_vma_pin_iomap() for CPU access, then one should call
> i915_vma_flush_writes() after CPU writes are done - presumably as a
> barrier to make sure writes are visible before proceeding.
>
> If that is correct, the I noticed problem (or I am missing something),
> that i915_vma_flush_writes only does something for the one of the three
> ways i915_vma_pin_iomap() can set up the CPU visible mapping (the
> ggtt->iomap path).
>
> The i915_gem_object_lmem_io_map() path, relevant on dgfx, has no
> flushing. Maybe it does need it due WC, or maybe flushing the
> write-combine buffers would still be needed.
>
> And the i915_gem_object_pin_map() path is also WC and in theory there is
> the corresponding __i915_gem_object_flush_map().
>
> Don't know, maybe I am indeed missing something.
>
> But for instance if __i915_gem_object_flush_map() *was* called from
> i915_vma_flush_writes(), and the latter *was* called after dpt_bind_vma
> does its thing, then notice how obj->mm.dirty *would* be set by that
> helper. Removing the need for this patch.
>
> So perhaps i915_vma_flush_writes() should just dirty the object, *if*
> the idea is to be called after CPU writes. And perhaps it should call
> i915_gem_object_flush_map *if* the method of mmaping was other than
> ggtt. But the information would have to be recorded first, probably same
> as the i915_gem_object_pin_map() path records it in the bit 0 of the
> vma->iomap pointer.
So a question arises if marking the object as dirty/ doing i915_gem_object_flush_map
Needs to happen after vma bind or after pinning the dpt?
>
> > Or should we have a different flavor of i915_vm_pin_iomap that skips
> i915_vma_set_ggtt_write
> > so that we can drop i915_vma_flush_writes during unpinning and move
> i915_vma_set_ggtt_write
> > to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess
> __i915_gem_object_flush_map
> > called during vma bind and not object pinning. In either case I believe it is a
> larger cleanup
> > which requires more extensive validation and analysis.
>
> Yes definitely wasn't suggesting to do it in this patch.
>
> >>>> In summary I think the fix is safe and correct but at least point 1) I
> >>>> think needs looking into. It can be a follow up work too.
> >
> > If you think this fix can work then I will look into the suspend/resume as a
> follow up and will appreciate
> > an r-b for this change. I believe 2) is a larger cleanup that may not be
> immediately required. I will have
> > to dig more into the ramifications of the changes proposed above.
> >
> > Thoughts ?
>
> Yeah it is fine. I assumed someone else would r-b but I can too.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Thank you for the review, merged the patch.
--Radhakrishna Sripada
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-21 23:54 ` Sripada, Radhakrishna
0 siblings, 0 replies; 19+ messages in thread
From: Sripada, Radhakrishna @ 2023-07-21 23:54 UTC (permalink / raw)
To: Tvrtko Ursulin, Yang, Fei, intel-gfx; +Cc: Wilson, Chris P, stable
Hi Tvrtko,
> -----Original Message-----
> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Sent: Friday, July 21, 2023 1:17 AM
> To: Sripada, Radhakrishna <radhakrishna.sripada@intel.com>; Yang, Fei
> <fei.yang@intel.com>; intel-gfx@lists.freedesktop.org
> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
> Chris P <chris.p.wilson@intel.com>
> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>
>
> On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
> > Hi Tvrtko,
> >
> >> -----Original Message-----
> >> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >> Sent: Thursday, July 20, 2023 2:17 AM
> >> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
> >> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
> >> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>;
> Wilson,
> >> Chris P <chris.p.wilson@intel.com>
> >> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
> >>
> >>
> >> On 19/07/2023 21:53, Yang, Fei wrote:
> >>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
> >>>>> Dpt objects that are created from internal get evicted when there is
> >>>>> memory pressure and do not get restored when pinned during scanout.
> >>>>> The pinned page table entries look corrupted and programming the
> >>>>> display engine with the incorrect pte's result in DE throwing pipe faults.
> >>>>>
> >>>>> Create DPT objects from shmem and mark the object as dirty when
> >>>>> pinning so that the object is restored when shrinker evicts an unpinned
> >> buffer object.
> >>>>>
> >>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
> >>>>>
> >>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
> >>>>> for dpt")
> >>>>> Cc: <stable@vger.kernel.org> # v6.0+
> >>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> >>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
> >>>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
> >>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
> >>>>> ---
> >>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
> >>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> index 7c5fddb203ba..fbfd8f959f17 100644
> >>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
> >>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
> >> i915_address_space *vm)
> >>>>> i915_vma_get(vma);
> >>>>> }
> >>>>>
> >>>>> + dpt->obj->mm.dirty = true;
> >>>>> +
> >>>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
> >>>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >>>>>
> >>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
> >>>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
> >>>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
> >>>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
> >>>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
> >>>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
> >>>>> }
> >>>>> if (IS_ERR(dpt_obj))
> >>>>> return ERR_CAST(dpt_obj);
> >>>>
> >>>> Okay I think I get it after some more looking at the DPT code paths.
> >>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
> >>>> are lost when backing store is discarded.
> >>>>
> >>>> Changing to shmem object indeed looks the easiest option.
> >>>>
> >>>> Some related thoughts:
> >>>>
> >>>> 1)
> >>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
> >>>> Could you investigate please? On a glance their job was to restore the
> >>>> PTEs which would be lost from internal objects backing storage. With
> >>>> shmem objects that content should be preserved.
> >>>
> >>> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
> >>> objects are mapped into, but also the framebuffer objects. I don't have
> >>> much knowledge on how the framebuffer objects are managed, but the
> >> suspend
> >>> resume path still look necessary to me, unless the content of these
> >>> framebuffer objects are also preserved.
> >>
> >> I don't think it has anything to do with fb content, but you are correct
> >> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
> >> mapping for DPT FBs across system suspend/resume") reminds me backing
> >> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
> >> Even though with this patch internal is out of the picture, stolen
> >> remains and so the issue of losing the page table content remains.
> >> Perhaps resume could be optimised to only restore PTEs when VM page
> >> tables are backed by stolen which may win some suspend/resume speed on
> >> some platforms.
> >
> > I will have to look into how suspend resume will change with the current flow
> > as you said it can be looked in a later patch.
>
> Thanks!
>
> >>>> 2)
> >>>> I wonder if i915_vma_flush_writes should be used (as a companion of
> >>>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc.
> But
> >>>> then I am also not sure if it does the right thing for the
> >>>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it
> should
> >>>> call __i915_gem_object_flush_map itself for that mapping flavour and
> >>>> not do the ggtt flushing in that case.
> > I am not sure if dpt_bind_vma will be called each time during pinning. IMO it
> gets called
> > Only when the fb object needs to be bind after and unbind(triggered during obj
> destroy).
> > Do you think if i915_vma_flush_writes should not be used if dpt objects are
> created from internal?
>
> No, I *think* correct API usage is supposed to be: If one uses
> i915_vma_pin_iomap() for CPU access, then one should call
> i915_vma_flush_writes() after CPU writes are done - presumably as a
> barrier to make sure writes are visible before proceeding.
>
> If that is correct, the I noticed problem (or I am missing something),
> that i915_vma_flush_writes only does something for the one of the three
> ways i915_vma_pin_iomap() can set up the CPU visible mapping (the
> ggtt->iomap path).
>
> The i915_gem_object_lmem_io_map() path, relevant on dgfx, has no
> flushing. Maybe it does need it due WC, or maybe flushing the
> write-combine buffers would still be needed.
>
> And the i915_gem_object_pin_map() path is also WC and in theory there is
> the corresponding __i915_gem_object_flush_map().
>
> Don't know, maybe I am indeed missing something.
>
> But for instance if __i915_gem_object_flush_map() *was* called from
> i915_vma_flush_writes(), and the latter *was* called after dpt_bind_vma
> does its thing, then notice how obj->mm.dirty *would* be set by that
> helper. Removing the need for this patch.
>
> So perhaps i915_vma_flush_writes() should just dirty the object, *if*
> the idea is to be called after CPU writes. And perhaps it should call
> i915_gem_object_flush_map *if* the method of mmaping was other than
> ggtt. But the information would have to be recorded first, probably same
> as the i915_gem_object_pin_map() path records it in the bit 0 of the
> vma->iomap pointer.
So a question arises if marking the object as dirty/ doing i915_gem_object_flush_map
Needs to happen after vma bind or after pinning the dpt?
>
> > Or should we have a different flavor of i915_vm_pin_iomap that skips
> i915_vma_set_ggtt_write
> > so that we can drop i915_vma_flush_writes during unpinning and move
> i915_vma_set_ggtt_write
> > to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess
> __i915_gem_object_flush_map
> > called during vma bind and not object pinning. In either case I believe it is a
> larger cleanup
> > which requires more extensive validation and analysis.
>
> Yes definitely wasn't suggesting to do it in this patch.
>
> >>>> In summary I think the fix is safe and correct but at least point 1) I
> >>>> think needs looking into. It can be a follow up work too.
> >
> > If you think this fix can work then I will look into the suspend/resume as a
> follow up and will appreciate
> > an r-b for this change. I believe 2) is a larger cleanup that may not be
> immediately required. I will have
> > to dig more into the ramifications of the changes proposed above.
> >
> > Thoughts ?
>
> Yeah it is fine. I assumed someone else would r-b but I can too.
>
> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Thank you for the review, merged the patch.
--Radhakrishna Sripada
>
> Regards,
>
> Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
2023-07-21 23:54 ` [Intel-gfx] " Sripada, Radhakrishna
@ 2023-07-24 13:01 ` Tvrtko Ursulin
-1 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-24 13:01 UTC (permalink / raw)
To: Sripada, Radhakrishna, Yang, Fei, intel-gfx; +Cc: Wilson, Chris P, stable
On 22/07/2023 00:54, Sripada, Radhakrishna wrote:
> Hi Tvrtko,
>
>> -----Original Message-----
>> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Sent: Friday, July 21, 2023 1:17 AM
>> To: Sripada, Radhakrishna <radhakrishna.sripada@intel.com>; Yang, Fei
>> <fei.yang@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
>> Chris P <chris.p.wilson@intel.com>
>> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>>
>>
>> On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
>>> Hi Tvrtko,
>>>
>>>> -----Original Message-----
>>>> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>> Sent: Thursday, July 20, 2023 2:17 AM
>>>> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
>>>> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
>>>> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>;
>> Wilson,
>>>> Chris P <chris.p.wilson@intel.com>
>>>> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>>>>
>>>>
>>>> On 19/07/2023 21:53, Yang, Fei wrote:
>>>>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>>>>>>> Dpt objects that are created from internal get evicted when there is
>>>>>>> memory pressure and do not get restored when pinned during scanout.
>>>>>>> The pinned page table entries look corrupted and programming the
>>>>>>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>>>>>>
>>>>>>> Create DPT objects from shmem and mark the object as dirty when
>>>>>>> pinning so that the object is restored when shrinker evicts an unpinned
>>>> buffer object.
>>>>>>>
>>>>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>>>>>>
>>>>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>>>>>>> for dpt")
>>>>>>> Cc: <stable@vger.kernel.org> # v6.0+
>>>>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>>>>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>>>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> index 7c5fddb203ba..fbfd8f959f17 100644
>>>>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
>>>> i915_address_space *vm)
>>>>>>> i915_vma_get(vma);
>>>>>>> }
>>>>>>>
>>>>>>> + dpt->obj->mm.dirty = true;
>>>>>>> +
>>>>>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>>>>>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>>>>>>
>>>>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>>>>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>>>>>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>>>>>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>>>>>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>>>>>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>>>>>>> }
>>>>>>> if (IS_ERR(dpt_obj))
>>>>>>> return ERR_CAST(dpt_obj);
>>>>>>
>>>>>> Okay I think I get it after some more looking at the DPT code paths.
>>>>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
>>>>>> are lost when backing store is discarded.
>>>>>>
>>>>>> Changing to shmem object indeed looks the easiest option.
>>>>>>
>>>>>> Some related thoughts:
>>>>>>
>>>>>> 1)
>>>>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
>>>>>> Could you investigate please? On a glance their job was to restore the
>>>>>> PTEs which would be lost from internal objects backing storage. With
>>>>>> shmem objects that content should be preserved.
>>>>>
>>>>> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
>>>>> objects are mapped into, but also the framebuffer objects. I don't have
>>>>> much knowledge on how the framebuffer objects are managed, but the
>>>> suspend
>>>>> resume path still look necessary to me, unless the content of these
>>>>> framebuffer objects are also preserved.
>>>>
>>>> I don't think it has anything to do with fb content, but you are correct
>>>> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
>>>> mapping for DPT FBs across system suspend/resume") reminds me backing
>>>> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
>>>> Even though with this patch internal is out of the picture, stolen
>>>> remains and so the issue of losing the page table content remains.
>>>> Perhaps resume could be optimised to only restore PTEs when VM page
>>>> tables are backed by stolen which may win some suspend/resume speed on
>>>> some platforms.
>>>
>>> I will have to look into how suspend resume will change with the current flow
>>> as you said it can be looked in a later patch.
>>
>> Thanks!
>>
>>>>>> 2)
>>>>>> I wonder if i915_vma_flush_writes should be used (as a companion of
>>>>>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc.
>> But
>>>>>> then I am also not sure if it does the right thing for the
>>>>>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it
>> should
>>>>>> call __i915_gem_object_flush_map itself for that mapping flavour and
>>>>>> not do the ggtt flushing in that case.
>>> I am not sure if dpt_bind_vma will be called each time during pinning. IMO it
>> gets called
>>> Only when the fb object needs to be bind after and unbind(triggered during obj
>> destroy).
>>> Do you think if i915_vma_flush_writes should not be used if dpt objects are
>> created from internal?
>>
>> No, I *think* correct API usage is supposed to be: If one uses
>> i915_vma_pin_iomap() for CPU access, then one should call
>> i915_vma_flush_writes() after CPU writes are done - presumably as a
>> barrier to make sure writes are visible before proceeding.
>>
>> If that is correct, the I noticed problem (or I am missing something),
>> that i915_vma_flush_writes only does something for the one of the three
>> ways i915_vma_pin_iomap() can set up the CPU visible mapping (the
>> ggtt->iomap path).
>>
>> The i915_gem_object_lmem_io_map() path, relevant on dgfx, has no
>> flushing. Maybe it does need it due WC, or maybe flushing the
>> write-combine buffers would still be needed.
>>
>> And the i915_gem_object_pin_map() path is also WC and in theory there is
>> the corresponding __i915_gem_object_flush_map().
>>
>> Don't know, maybe I am indeed missing something.
>>
>> But for instance if __i915_gem_object_flush_map() *was* called from
>> i915_vma_flush_writes(), and the latter *was* called after dpt_bind_vma
>> does its thing, then notice how obj->mm.dirty *would* be set by that
>> helper. Removing the need for this patch.
>>
>> So perhaps i915_vma_flush_writes() should just dirty the object, *if*
>> the idea is to be called after CPU writes. And perhaps it should call
>> i915_gem_object_flush_map *if* the method of mmaping was other than
>> ggtt. But the information would have to be recorded first, probably same
>> as the i915_gem_object_pin_map() path records it in the bit 0 of the
>> vma->iomap pointer.
>
> So a question arises if marking the object as dirty/ doing i915_gem_object_flush_map
> Needs to happen after vma bind or after pinning the dpt?
New week and fresh perspective - it probably isn't the case that
i915_vma_flush_writes() should be used for flushing after any write and
so also setting obj->mm.dirty. I now think so because of the one-shot
nature of the i915_vma_unset_ggtt_write(). It wouldn't make sense for it
to be for persistently mapped objects since 2nd flush would be a no-op
per design.
So I think we might be simply relying on some implicit/natural
write-combine flushing with other paths in the driver too.
I've sent a small patch to hopefully clarify the flushing in the
i915_vma_pin_iomap + i915_vma_flush_writes pair, but other than that,
and the DPT suspend-resume open, I think lets leave it be for now.
Regards,
Tvrtko
>
>
>>
>>> Or should we have a different flavor of i915_vm_pin_iomap that skips
>> i915_vma_set_ggtt_write
>>> so that we can drop i915_vma_flush_writes during unpinning and move
>> i915_vma_set_ggtt_write
>>> to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess
>> __i915_gem_object_flush_map
>>> called during vma bind and not object pinning. In either case I believe it is a
>> larger cleanup
>>> which requires more extensive validation and analysis.
>>
>> Yes definitely wasn't suggesting to do it in this patch.
>>
>>>>>> In summary I think the fix is safe and correct but at least point 1) I
>>>>>> think needs looking into. It can be a follow up work too.
>>>
>>> If you think this fix can work then I will look into the suspend/resume as a
>> follow up and will appreciate
>>> an r-b for this change. I believe 2) is a larger cleanup that may not be
>> immediately required. I will have
>>> to dig more into the ramifications of the changes proposed above.
>>>
>>> Thoughts ?
>>
>> Yeah it is fine. I assumed someone else would r-b but I can too.
>>
>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Thank you for the review, merged the patch.
>
> --Radhakrishna Sripada
>>
>> Regards,
>>
>> Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
@ 2023-07-24 13:01 ` Tvrtko Ursulin
0 siblings, 0 replies; 19+ messages in thread
From: Tvrtko Ursulin @ 2023-07-24 13:01 UTC (permalink / raw)
To: Sripada, Radhakrishna, Yang, Fei, intel-gfx
Cc: stable, Ville Syrjälä, Wilson, Chris P
On 22/07/2023 00:54, Sripada, Radhakrishna wrote:
> Hi Tvrtko,
>
>> -----Original Message-----
>> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>> Sent: Friday, July 21, 2023 1:17 AM
>> To: Sripada, Radhakrishna <radhakrishna.sripada@intel.com>; Yang, Fei
>> <fei.yang@intel.com>; intel-gfx@lists.freedesktop.org
>> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>; Wilson,
>> Chris P <chris.p.wilson@intel.com>
>> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>>
>>
>> On 20/07/2023 18:02, Sripada, Radhakrishna wrote:
>>> Hi Tvrtko,
>>>
>>>> -----Original Message-----
>>>> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>> Sent: Thursday, July 20, 2023 2:17 AM
>>>> To: Yang, Fei <fei.yang@intel.com>; Sripada, Radhakrishna
>>>> <radhakrishna.sripada@intel.com>; intel-gfx@lists.freedesktop.org
>>>> Cc: stable@vger.kernel.org; Ville Syrjälä <ville.syrjala@linux.intel.com>;
>> Wilson,
>>>> Chris P <chris.p.wilson@intel.com>
>>>> Subject: Re: [PATCH v2] drm/i915/dpt: Use shmem for dpt objects
>>>>
>>>>
>>>> On 19/07/2023 21:53, Yang, Fei wrote:
>>>>>> On 18/07/2023 23:51, Radhakrishna Sripada wrote:
>>>>>>> Dpt objects that are created from internal get evicted when there is
>>>>>>> memory pressure and do not get restored when pinned during scanout.
>>>>>>> The pinned page table entries look corrupted and programming the
>>>>>>> display engine with the incorrect pte's result in DE throwing pipe faults.
>>>>>>>
>>>>>>> Create DPT objects from shmem and mark the object as dirty when
>>>>>>> pinning so that the object is restored when shrinker evicts an unpinned
>>>> buffer object.
>>>>>>>
>>>>>>> v2: Unconditionally mark the dpt objects dirty during pinning(Chris).
>>>>>>>
>>>>>>> Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation
>>>>>>> for dpt")
>>>>>>> Cc: <stable@vger.kernel.org> # v6.0+
>>>>>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
>>>>>>> Suggested-by: Chris Wilson <chris.p.wilson@intel.com>
>>>>>>> Signed-off-by: Fei Yang <fei.yang@intel.com>
>>>>>>> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/i915/display/intel_dpt.c | 4 +++-
>>>>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> index 7c5fddb203ba..fbfd8f959f17 100644
>>>>>>> --- a/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> +++ b/drivers/gpu/drm/i915/display/intel_dpt.c
>>>>>>> @@ -166,6 +166,8 @@ struct i915_vma *intel_dpt_pin(struct
>>>> i915_address_space *vm)
>>>>>>> i915_vma_get(vma);
>>>>>>> }
>>>>>>>
>>>>>>> + dpt->obj->mm.dirty = true;
>>>>>>> +
>>>>>>> atomic_dec(&i915->gpu_error.pending_fb_pin);
>>>>>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>>>>>>
>>>>>>> @@ -261,7 +263,7 @@ intel_dpt_create(struct intel_framebuffer *fb)
>>>>>>> dpt_obj = i915_gem_object_create_stolen(i915, size);
>>>>>>> if (IS_ERR(dpt_obj) && !HAS_LMEM(i915)) {
>>>>>>> drm_dbg_kms(&i915->drm, "Allocating dpt from smem\n");
>>>>>>> - dpt_obj = i915_gem_object_create_internal(i915, size);
>>>>>>> + dpt_obj = i915_gem_object_create_shmem(i915, size);
>>>>>>> }
>>>>>>> if (IS_ERR(dpt_obj))
>>>>>>> return ERR_CAST(dpt_obj);
>>>>>>
>>>>>> Okay I think I get it after some more looking at the DPT code paths.
>>>>>> Problem seems pretty clear - page tables are stored in dpt_obj and so
>>>>>> are lost when backing store is discarded.
>>>>>>
>>>>>> Changing to shmem object indeed looks the easiest option.
>>>>>>
>>>>>> Some related thoughts:
>>>>>>
>>>>>> 1)
>>>>>> I wonder if intel_dpt_suspend/resume remain needed after this patch.
>>>>>> Could you investigate please? On a glance their job was to restore the
>>>>>> PTEs which would be lost from internal objects backing storage. With
>>>>>> shmem objects that content should be preserved.
>>>>>
>>>>> intel_dpt_suspend is "suspending" the whole VM where, not only the dpt
>>>>> objects are mapped into, but also the framebuffer objects. I don't have
>>>>> much knowledge on how the framebuffer objects are managed, but the
>>>> suspend
>>>>> resume path still look necessary to me, unless the content of these
>>>>> framebuffer objects are also preserved.
>>>>
>>>> I don't think it has anything to do with fb content, but you are correct
>>>> it is still needed. Because 9755f055f512 ("drm/i915: Restore memory
>>>> mapping for DPT FBs across system suspend/resume") reminds me backing
>>>> store for DPT PTEs can be either lmem, stolen or internal (now shmem).
>>>> Even though with this patch internal is out of the picture, stolen
>>>> remains and so the issue of losing the page table content remains.
>>>> Perhaps resume could be optimised to only restore PTEs when VM page
>>>> tables are backed by stolen which may win some suspend/resume speed on
>>>> some platforms.
>>>
>>> I will have to look into how suspend resume will change with the current flow
>>> as you said it can be looked in a later patch.
>>
>> Thanks!
>>
>>>>>> 2)
>>>>>> I wonder if i915_vma_flush_writes should be used (as a companion of
>>>>>> i915_vma_pin_iomap) from DPT dpt_bind_vma, dpt_insert_entries, etc.
>> But
>>>>>> then I am also not sure if it does the right thing for the
>>>>>> i915_gem_object_pin_map path of i915_vma_pin_iomap. Perhaps it
>> should
>>>>>> call __i915_gem_object_flush_map itself for that mapping flavour and
>>>>>> not do the ggtt flushing in that case.
>>> I am not sure if dpt_bind_vma will be called each time during pinning. IMO it
>> gets called
>>> Only when the fb object needs to be bind after and unbind(triggered during obj
>> destroy).
>>> Do you think if i915_vma_flush_writes should not be used if dpt objects are
>> created from internal?
>>
>> No, I *think* correct API usage is supposed to be: If one uses
>> i915_vma_pin_iomap() for CPU access, then one should call
>> i915_vma_flush_writes() after CPU writes are done - presumably as a
>> barrier to make sure writes are visible before proceeding.
>>
>> If that is correct, the I noticed problem (or I am missing something),
>> that i915_vma_flush_writes only does something for the one of the three
>> ways i915_vma_pin_iomap() can set up the CPU visible mapping (the
>> ggtt->iomap path).
>>
>> The i915_gem_object_lmem_io_map() path, relevant on dgfx, has no
>> flushing. Maybe it does need it due WC, or maybe flushing the
>> write-combine buffers would still be needed.
>>
>> And the i915_gem_object_pin_map() path is also WC and in theory there is
>> the corresponding __i915_gem_object_flush_map().
>>
>> Don't know, maybe I am indeed missing something.
>>
>> But for instance if __i915_gem_object_flush_map() *was* called from
>> i915_vma_flush_writes(), and the latter *was* called after dpt_bind_vma
>> does its thing, then notice how obj->mm.dirty *would* be set by that
>> helper. Removing the need for this patch.
>>
>> So perhaps i915_vma_flush_writes() should just dirty the object, *if*
>> the idea is to be called after CPU writes. And perhaps it should call
>> i915_gem_object_flush_map *if* the method of mmaping was other than
>> ggtt. But the information would have to be recorded first, probably same
>> as the i915_gem_object_pin_map() path records it in the bit 0 of the
>> vma->iomap pointer.
>
> So a question arises if marking the object as dirty/ doing i915_gem_object_flush_map
> Needs to happen after vma bind or after pinning the dpt?
New week and fresh perspective - it probably isn't the case that
i915_vma_flush_writes() should be used for flushing after any write and
so also setting obj->mm.dirty. I now think so because of the one-shot
nature of the i915_vma_unset_ggtt_write(). It wouldn't make sense for it
to be for persistently mapped objects since 2nd flush would be a no-op
per design.
So I think we might be simply relying on some implicit/natural
write-combine flushing with other paths in the driver too.
I've sent a small patch to hopefully clarify the flushing in the
i915_vma_pin_iomap + i915_vma_flush_writes pair, but other than that,
and the DPT suspend-resume open, I think lets leave it be for now.
Regards,
Tvrtko
>
>
>>
>>> Or should we have a different flavor of i915_vm_pin_iomap that skips
>> i915_vma_set_ggtt_write
>>> so that we can drop i915_vma_flush_writes during unpinning and move
>> i915_vma_set_ggtt_write
>>> to dpt_insert_entires and do i915_vma_flush during clear range? Then I guess
>> __i915_gem_object_flush_map
>>> called during vma bind and not object pinning. In either case I believe it is a
>> larger cleanup
>>> which requires more extensive validation and analysis.
>>
>> Yes definitely wasn't suggesting to do it in this patch.
>>
>>>>>> In summary I think the fix is safe and correct but at least point 1) I
>>>>>> think needs looking into. It can be a follow up work too.
>>>
>>> If you think this fix can work then I will look into the suspend/resume as a
>> follow up and will appreciate
>>> an r-b for this change. I believe 2) is a larger cleanup that may not be
>> immediately required. I will have
>>> to dig more into the ramifications of the changes proposed above.
>>>
>>> Thoughts ?
>>
>> Yeah it is fine. I assumed someone else would r-b but I can too.
>>
>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Thank you for the review, merged the patch.
>
> --Radhakrishna Sripada
>>
>> Regards,
>>
>> Tvrtko
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2023-07-24 13:03 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-07-18 22:51 [PATCH v2] drm/i915/dpt: Use shmem for dpt objects Radhakrishna Sripada
2023-07-18 22:51 ` [Intel-gfx] " Radhakrishna Sripada
2023-07-19 0:27 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dpt: Use shmem for dpt objects (rev2) Patchwork
2023-07-19 2:50 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-07-21 4:50 ` Sripada, Radhakrishna
2023-07-19 13:36 ` [PATCH v2] drm/i915/dpt: Use shmem for dpt objects Tvrtko Ursulin
2023-07-19 13:36 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-19 20:53 ` Yang, Fei
2023-07-19 20:53 ` [Intel-gfx] " Yang, Fei
2023-07-20 9:16 ` Tvrtko Ursulin
2023-07-20 9:16 ` Tvrtko Ursulin
2023-07-20 17:02 ` Sripada, Radhakrishna
2023-07-20 17:02 ` [Intel-gfx] " Sripada, Radhakrishna
2023-07-21 8:17 ` Tvrtko Ursulin
2023-07-21 8:17 ` [Intel-gfx] " Tvrtko Ursulin
2023-07-21 23:54 ` Sripada, Radhakrishna
2023-07-21 23:54 ` [Intel-gfx] " Sripada, Radhakrishna
2023-07-24 13:01 ` Tvrtko Ursulin
2023-07-24 13:01 ` Tvrtko Ursulin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.