* [PATCH] drm/xe: Do not preempt fence signaling CS instructions
@ 2026-01-15 0:45 Matthew Brost
2026-01-15 0:52 ` ✓ CI.KUnit: success for " Patchwork
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Matthew Brost @ 2026-01-15 0:45 UTC (permalink / raw)
To: intel-xe; +Cc: Daniele Ceraolo Spurio, Carlos Santa
If a batch buffer is complete, it makes little sense to preempt the
fence signaling instructions in the ring, as the largest portion of the
work (the batch buffer) is already done and fence signaling consists of
only a few instructions. If these instructions are preempted, the GuC
would need to perform a context switch just to signal the fence, which
is costly and delays fence signaling. Avoid this scenario by disabling
preemption immediately after the BB start instruction and re-enabling it
after executing the fence signaling instructions.
Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Carlos Santa <carlos.santa@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
---
drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c
index a1fd99f2d539..cd645ee400b9 100644
--- a/drivers/gpu/drm/xe/xe_ring_ops.c
+++ b/drivers/gpu/drm/xe/xe_ring_ops.c
@@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc
i = emit_bb_start(batch_addr, ppgtt_flag, dw, i);
+ /* Don't preempt fence signaling */
+ dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
if (job->user_fence.used) {
i = emit_flush_dw(dw, i);
i = emit_store_imm_ppgtt_posted(job->user_fence.addr,
@@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc,
i = emit_bb_start(batch_addr, ppgtt_flag, dw, i);
+ /* Don't preempt fence signaling */
+ dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
if (job->user_fence.used) {
i = emit_flush_dw(dw, i);
i = emit_store_imm_ppgtt_posted(job->user_fence.addr,
@@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job,
i = emit_bb_start(batch_addr, ppgtt_flag, dw, i);
+ /* Don't preempt fence signaling */
+ dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE;
+
i = emit_render_cache_flush(job, dw, i);
if (job->user_fence.used)
--
2.34.1
^ permalink raw reply related [flat|nested] 25+ messages in thread* ✓ CI.KUnit: success for drm/xe: Do not preempt fence signaling CS instructions 2026-01-15 0:45 [PATCH] drm/xe: Do not preempt fence signaling CS instructions Matthew Brost @ 2026-01-15 0:52 ` Patchwork 2026-01-15 1:35 ` ✓ Xe.CI.BAT: " Patchwork ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Patchwork @ 2026-01-15 0:52 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe == Series Details == Series: drm/xe: Do not preempt fence signaling CS instructions URL : https://patchwork.freedesktop.org/series/160113/ State : success == Summary == + trap cleanup EXIT + /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/xe/.kunitconfig [00:50:24] Configuring KUnit Kernel ... Generating .config ... Populating config with: $ make ARCH=um O=.kunit olddefconfig [00:50:28] Building KUnit Kernel ... Populating config with: $ make ARCH=um O=.kunit olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=25 [00:51:08] Starting KUnit Kernel (1/1)... [00:51:08] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [00:51:08] ================== guc_buf (11 subtests) =================== [00:51:08] [PASSED] test_smallest [00:51:08] [PASSED] test_largest [00:51:08] [PASSED] test_granular [00:51:08] [PASSED] test_unique [00:51:08] [PASSED] test_overlap [00:51:08] [PASSED] test_reusable [00:51:08] [PASSED] test_too_big [00:51:08] [PASSED] test_flush [00:51:08] [PASSED] test_lookup [00:51:08] [PASSED] test_data [00:51:08] [PASSED] test_class [00:51:08] ===================== [PASSED] guc_buf ===================== [00:51:08] =================== guc_dbm (7 subtests) =================== [00:51:08] [PASSED] test_empty [00:51:08] [PASSED] test_default [00:51:08] ======================== test_size ======================== [00:51:08] [PASSED] 4 [00:51:08] [PASSED] 8 [00:51:08] [PASSED] 32 [00:51:08] [PASSED] 256 [00:51:08] ==================== [PASSED] test_size ==================== [00:51:08] ======================= test_reuse ======================== [00:51:08] [PASSED] 4 [00:51:08] [PASSED] 8 [00:51:08] [PASSED] 32 [00:51:08] [PASSED] 256 [00:51:08] =================== [PASSED] test_reuse ==================== [00:51:08] =================== test_range_overlap ==================== [00:51:08] [PASSED] 4 [00:51:08] [PASSED] 8 [00:51:08] [PASSED] 32 [00:51:08] [PASSED] 256 [00:51:08] =============== [PASSED] test_range_overlap ================ [00:51:08] =================== test_range_compact ==================== [00:51:08] [PASSED] 4 [00:51:08] [PASSED] 8 [00:51:08] [PASSED] 32 [00:51:08] [PASSED] 256 [00:51:08] =============== [PASSED] test_range_compact ================ [00:51:08] ==================== test_range_spare ===================== [00:51:08] [PASSED] 4 [00:51:08] [PASSED] 8 [00:51:08] [PASSED] 32 [00:51:08] [PASSED] 256 [00:51:08] ================ [PASSED] test_range_spare ================= [00:51:08] ===================== [PASSED] guc_dbm ===================== [00:51:08] =================== guc_idm (6 subtests) =================== [00:51:08] [PASSED] bad_init [00:51:08] [PASSED] no_init [00:51:08] [PASSED] init_fini [00:51:08] [PASSED] check_used [00:51:08] [PASSED] check_quota [00:51:08] [PASSED] check_all [00:51:08] ===================== [PASSED] guc_idm ===================== [00:51:08] ================== no_relay (3 subtests) =================== [00:51:08] [PASSED] xe_drops_guc2pf_if_not_ready [00:51:08] [PASSED] xe_drops_guc2vf_if_not_ready [00:51:08] [PASSED] xe_rejects_send_if_not_ready [00:51:08] ==================== [PASSED] no_relay ===================== [00:51:08] ================== pf_relay (14 subtests) ================== [00:51:08] [PASSED] pf_rejects_guc2pf_too_short [00:51:08] [PASSED] pf_rejects_guc2pf_too_long [00:51:08] [PASSED] pf_rejects_guc2pf_no_payload [00:51:08] [PASSED] pf_fails_no_payload [00:51:08] [PASSED] pf_fails_bad_origin [00:51:08] [PASSED] pf_fails_bad_type [00:51:08] [PASSED] pf_txn_reports_error [00:51:08] [PASSED] pf_txn_sends_pf2guc [00:51:08] [PASSED] pf_sends_pf2guc [00:51:08] [SKIPPED] pf_loopback_nop [00:51:08] [SKIPPED] pf_loopback_echo [00:51:08] [SKIPPED] pf_loopback_fail [00:51:08] [SKIPPED] pf_loopback_busy [00:51:08] [SKIPPED] pf_loopback_retry [00:51:08] ==================== [PASSED] pf_relay ===================== [00:51:08] ================== vf_relay (3 subtests) =================== [00:51:08] [PASSED] vf_rejects_guc2vf_too_short [00:51:08] [PASSED] vf_rejects_guc2vf_too_long [00:51:08] [PASSED] vf_rejects_guc2vf_no_payload [00:51:08] ==================== [PASSED] vf_relay ===================== [00:51:08] ================ pf_gt_config (6 subtests) ================= [00:51:08] [PASSED] fair_contexts_1vf [00:51:08] [PASSED] fair_doorbells_1vf [00:51:08] [PASSED] fair_ggtt_1vf [00:51:08] ====================== fair_contexts ====================== [00:51:08] [PASSED] 1 VF [00:51:08] [PASSED] 2 VFs [00:51:08] [PASSED] 3 VFs [00:51:08] [PASSED] 4 VFs [00:51:08] [PASSED] 5 VFs [00:51:08] [PASSED] 6 VFs [00:51:08] [PASSED] 7 VFs [00:51:08] [PASSED] 8 VFs [00:51:08] [PASSED] 9 VFs [00:51:08] [PASSED] 10 VFs [00:51:08] [PASSED] 11 VFs [00:51:08] [PASSED] 12 VFs [00:51:08] [PASSED] 13 VFs [00:51:08] [PASSED] 14 VFs [00:51:08] [PASSED] 15 VFs [00:51:08] [PASSED] 16 VFs [00:51:08] [PASSED] 17 VFs [00:51:08] [PASSED] 18 VFs [00:51:08] [PASSED] 19 VFs [00:51:08] [PASSED] 20 VFs [00:51:08] [PASSED] 21 VFs [00:51:08] [PASSED] 22 VFs [00:51:08] [PASSED] 23 VFs [00:51:08] [PASSED] 24 VFs [00:51:08] [PASSED] 25 VFs [00:51:08] [PASSED] 26 VFs [00:51:08] [PASSED] 27 VFs [00:51:08] [PASSED] 28 VFs [00:51:08] [PASSED] 29 VFs [00:51:08] [PASSED] 30 VFs [00:51:08] [PASSED] 31 VFs [00:51:08] [PASSED] 32 VFs [00:51:08] [PASSED] 33 VFs [00:51:08] [PASSED] 34 VFs [00:51:08] [PASSED] 35 VFs [00:51:08] [PASSED] 36 VFs [00:51:08] [PASSED] 37 VFs [00:51:08] [PASSED] 38 VFs [00:51:08] [PASSED] 39 VFs [00:51:08] [PASSED] 40 VFs [00:51:08] [PASSED] 41 VFs [00:51:08] [PASSED] 42 VFs [00:51:08] [PASSED] 43 VFs [00:51:08] [PASSED] 44 VFs [00:51:08] [PASSED] 45 VFs [00:51:08] [PASSED] 46 VFs [00:51:08] [PASSED] 47 VFs [00:51:08] [PASSED] 48 VFs [00:51:08] [PASSED] 49 VFs [00:51:08] [PASSED] 50 VFs [00:51:08] [PASSED] 51 VFs [00:51:08] [PASSED] 52 VFs [00:51:08] [PASSED] 53 VFs [00:51:08] [PASSED] 54 VFs [00:51:08] [PASSED] 55 VFs [00:51:08] [PASSED] 56 VFs [00:51:08] [PASSED] 57 VFs [00:51:08] [PASSED] 58 VFs [00:51:08] [PASSED] 59 VFs [00:51:08] [PASSED] 60 VFs [00:51:08] [PASSED] 61 VFs [00:51:08] [PASSED] 62 VFs [00:51:08] [PASSED] 63 VFs [00:51:08] ================== [PASSED] fair_contexts ================== [00:51:08] ===================== fair_doorbells ====================== [00:51:08] [PASSED] 1 VF [00:51:08] [PASSED] 2 VFs [00:51:08] [PASSED] 3 VFs [00:51:08] [PASSED] 4 VFs [00:51:08] [PASSED] 5 VFs [00:51:08] [PASSED] 6 VFs [00:51:08] [PASSED] 7 VFs [00:51:08] [PASSED] 8 VFs [00:51:08] [PASSED] 9 VFs [00:51:08] [PASSED] 10 VFs [00:51:08] [PASSED] 11 VFs [00:51:08] [PASSED] 12 VFs [00:51:08] [PASSED] 13 VFs [00:51:08] [PASSED] 14 VFs [00:51:08] [PASSED] 15 VFs [00:51:08] [PASSED] 16 VFs [00:51:08] [PASSED] 17 VFs [00:51:08] [PASSED] 18 VFs [00:51:08] [PASSED] 19 VFs [00:51:08] [PASSED] 20 VFs [00:51:08] [PASSED] 21 VFs [00:51:08] [PASSED] 22 VFs [00:51:08] [PASSED] 23 VFs [00:51:08] [PASSED] 24 VFs [00:51:08] [PASSED] 25 VFs [00:51:08] [PASSED] 26 VFs [00:51:08] [PASSED] 27 VFs [00:51:08] [PASSED] 28 VFs [00:51:08] [PASSED] 29 VFs [00:51:08] [PASSED] 30 VFs [00:51:08] [PASSED] 31 VFs [00:51:08] [PASSED] 32 VFs [00:51:08] [PASSED] 33 VFs [00:51:08] [PASSED] 34 VFs [00:51:08] [PASSED] 35 VFs [00:51:08] [PASSED] 36 VFs [00:51:08] [PASSED] 37 VFs [00:51:08] [PASSED] 38 VFs [00:51:08] [PASSED] 39 VFs [00:51:08] [PASSED] 40 VFs [00:51:08] [PASSED] 41 VFs [00:51:08] [PASSED] 42 VFs [00:51:08] [PASSED] 43 VFs [00:51:08] [PASSED] 44 VFs [00:51:08] [PASSED] 45 VFs [00:51:08] [PASSED] 46 VFs [00:51:08] [PASSED] 47 VFs [00:51:08] [PASSED] 48 VFs [00:51:08] [PASSED] 49 VFs [00:51:08] [PASSED] 50 VFs [00:51:08] [PASSED] 51 VFs [00:51:08] [PASSED] 52 VFs [00:51:08] [PASSED] 53 VFs [00:51:08] [PASSED] 54 VFs [00:51:08] [PASSED] 55 VFs [00:51:08] [PASSED] 56 VFs [00:51:08] [PASSED] 57 VFs [00:51:08] [PASSED] 58 VFs [00:51:08] [PASSED] 59 VFs [00:51:08] [PASSED] 60 VFs [00:51:08] [PASSED] 61 VFs [00:51:08] [PASSED] 62 VFs [00:51:08] [PASSED] 63 VFs [00:51:08] ================= [PASSED] fair_doorbells ================== [00:51:08] ======================== fair_ggtt ======================== [00:51:08] [PASSED] 1 VF [00:51:08] [PASSED] 2 VFs [00:51:08] [PASSED] 3 VFs [00:51:08] [PASSED] 4 VFs [00:51:08] [PASSED] 5 VFs [00:51:08] [PASSED] 6 VFs [00:51:08] [PASSED] 7 VFs [00:51:08] [PASSED] 8 VFs [00:51:08] [PASSED] 9 VFs [00:51:08] [PASSED] 10 VFs [00:51:08] [PASSED] 11 VFs [00:51:08] [PASSED] 12 VFs [00:51:08] [PASSED] 13 VFs [00:51:08] [PASSED] 14 VFs [00:51:08] [PASSED] 15 VFs [00:51:08] [PASSED] 16 VFs [00:51:08] [PASSED] 17 VFs [00:51:08] [PASSED] 18 VFs [00:51:08] [PASSED] 19 VFs [00:51:08] [PASSED] 20 VFs [00:51:08] [PASSED] 21 VFs [00:51:08] [PASSED] 22 VFs [00:51:08] [PASSED] 23 VFs [00:51:08] [PASSED] 24 VFs [00:51:08] [PASSED] 25 VFs [00:51:08] [PASSED] 26 VFs [00:51:08] [PASSED] 27 VFs [00:51:08] [PASSED] 28 VFs [00:51:08] [PASSED] 29 VFs [00:51:08] [PASSED] 30 VFs [00:51:08] [PASSED] 31 VFs [00:51:08] [PASSED] 32 VFs [00:51:08] [PASSED] 33 VFs [00:51:08] [PASSED] 34 VFs [00:51:08] [PASSED] 35 VFs [00:51:08] [PASSED] 36 VFs [00:51:08] [PASSED] 37 VFs [00:51:08] [PASSED] 38 VFs [00:51:08] [PASSED] 39 VFs [00:51:08] [PASSED] 40 VFs [00:51:08] [PASSED] 41 VFs [00:51:08] [PASSED] 42 VFs [00:51:08] [PASSED] 43 VFs [00:51:08] [PASSED] 44 VFs [00:51:08] [PASSED] 45 VFs [00:51:08] [PASSED] 46 VFs [00:51:08] [PASSED] 47 VFs [00:51:08] [PASSED] 48 VFs [00:51:08] [PASSED] 49 VFs [00:51:08] [PASSED] 50 VFs [00:51:08] [PASSED] 51 VFs [00:51:08] [PASSED] 52 VFs [00:51:08] [PASSED] 53 VFs [00:51:08] [PASSED] 54 VFs [00:51:08] [PASSED] 55 VFs [00:51:08] [PASSED] 56 VFs [00:51:08] [PASSED] 57 VFs [00:51:08] [PASSED] 58 VFs [00:51:08] [PASSED] 59 VFs [00:51:08] [PASSED] 60 VFs [00:51:08] [PASSED] 61 VFs [00:51:08] [PASSED] 62 VFs [00:51:08] [PASSED] 63 VFs [00:51:08] ==================== [PASSED] fair_ggtt ==================== [00:51:08] ================== [PASSED] pf_gt_config =================== [00:51:08] ===================== lmtt (1 subtest) ===================== [00:51:08] ======================== test_ops ========================= [00:51:08] [PASSED] 2-level [00:51:08] [PASSED] multi-level [00:51:08] ==================== [PASSED] test_ops ===================== [00:51:08] ====================== [PASSED] lmtt ======================= [00:51:08] ================= pf_service (11 subtests) ================= [00:51:08] [PASSED] pf_negotiate_any [00:51:08] [PASSED] pf_negotiate_base_match [00:51:08] [PASSED] pf_negotiate_base_newer [00:51:08] [PASSED] pf_negotiate_base_next [00:51:08] [SKIPPED] pf_negotiate_base_older [00:51:08] [PASSED] pf_negotiate_base_prev [00:51:08] [PASSED] pf_negotiate_latest_match [00:51:08] [PASSED] pf_negotiate_latest_newer [00:51:08] [PASSED] pf_negotiate_latest_next [00:51:08] [SKIPPED] pf_negotiate_latest_older [00:51:08] [SKIPPED] pf_negotiate_latest_prev [00:51:08] =================== [PASSED] pf_service ==================== [00:51:08] ================= xe_guc_g2g (2 subtests) ================== [00:51:08] ============== xe_live_guc_g2g_kunit_default ============== [00:51:08] ========= [SKIPPED] xe_live_guc_g2g_kunit_default ========== [00:51:08] ============== xe_live_guc_g2g_kunit_allmem =============== [00:51:08] ========== [SKIPPED] xe_live_guc_g2g_kunit_allmem ========== [00:51:08] =================== [SKIPPED] xe_guc_g2g =================== [00:51:08] =================== xe_mocs (2 subtests) =================== [00:51:08] ================ xe_live_mocs_kernel_kunit ================ [00:51:08] =========== [SKIPPED] xe_live_mocs_kernel_kunit ============ [00:51:08] ================ xe_live_mocs_reset_kunit ================= [00:51:08] ============ [SKIPPED] xe_live_mocs_reset_kunit ============ [00:51:08] ==================== [SKIPPED] xe_mocs ===================== [00:51:08] ================= xe_migrate (2 subtests) ================== [00:51:08] ================= xe_migrate_sanity_kunit ================= [00:51:08] ============ [SKIPPED] xe_migrate_sanity_kunit ============= [00:51:08] ================== xe_validate_ccs_kunit ================== [00:51:08] ============= [SKIPPED] xe_validate_ccs_kunit ============== [00:51:08] =================== [SKIPPED] xe_migrate =================== [00:51:08] ================== xe_dma_buf (1 subtest) ================== [00:51:08] ==================== xe_dma_buf_kunit ===================== [00:51:08] ================ [SKIPPED] xe_dma_buf_kunit ================ [00:51:08] =================== [SKIPPED] xe_dma_buf =================== [00:51:08] ================= xe_bo_shrink (1 subtest) ================= [00:51:08] =================== xe_bo_shrink_kunit ==================== [00:51:08] =============== [SKIPPED] xe_bo_shrink_kunit =============== [00:51:08] ================== [SKIPPED] xe_bo_shrink ================== [00:51:08] ==================== xe_bo (2 subtests) ==================== [00:51:08] ================== xe_ccs_migrate_kunit =================== [00:51:08] ============== [SKIPPED] xe_ccs_migrate_kunit ============== [00:51:08] ==================== xe_bo_evict_kunit ==================== [00:51:08] =============== [SKIPPED] xe_bo_evict_kunit ================ [00:51:08] ===================== [SKIPPED] xe_bo ====================== [00:51:08] ==================== args (13 subtests) ==================== [00:51:08] [PASSED] count_args_test [00:51:08] [PASSED] call_args_example [00:51:08] [PASSED] call_args_test [00:51:08] [PASSED] drop_first_arg_example [00:51:08] [PASSED] drop_first_arg_test [00:51:08] [PASSED] first_arg_example [00:51:08] [PASSED] first_arg_test [00:51:08] [PASSED] last_arg_example [00:51:08] [PASSED] last_arg_test [00:51:08] [PASSED] pick_arg_example [00:51:08] [PASSED] if_args_example [00:51:08] [PASSED] if_args_test [00:51:08] [PASSED] sep_comma_example [00:51:08] ====================== [PASSED] args ======================= [00:51:08] =================== xe_pci (3 subtests) ==================== [00:51:08] ==================== check_graphics_ip ==================== [00:51:08] [PASSED] 12.00 Xe_LP [00:51:08] [PASSED] 12.10 Xe_LP+ [00:51:08] [PASSED] 12.55 Xe_HPG [00:51:08] [PASSED] 12.60 Xe_HPC [00:51:08] [PASSED] 12.70 Xe_LPG [00:51:08] [PASSED] 12.71 Xe_LPG [00:51:08] [PASSED] 12.74 Xe_LPG+ [00:51:08] [PASSED] 20.01 Xe2_HPG [00:51:08] [PASSED] 20.02 Xe2_HPG [00:51:08] [PASSED] 20.04 Xe2_LPG [00:51:08] [PASSED] 30.00 Xe3_LPG [00:51:08] [PASSED] 30.01 Xe3_LPG [00:51:08] [PASSED] 30.03 Xe3_LPG [00:51:08] [PASSED] 30.04 Xe3_LPG [00:51:08] [PASSED] 30.05 Xe3_LPG [00:51:08] [PASSED] 35.11 Xe3p_XPC [00:51:08] ================ [PASSED] check_graphics_ip ================ [00:51:08] ===================== check_media_ip ====================== [00:51:08] [PASSED] 12.00 Xe_M [00:51:08] [PASSED] 12.55 Xe_HPM [00:51:08] [PASSED] 13.00 Xe_LPM+ [00:51:08] [PASSED] 13.01 Xe2_HPM [00:51:08] [PASSED] 20.00 Xe2_LPM [00:51:08] [PASSED] 30.00 Xe3_LPM [00:51:08] [PASSED] 30.02 Xe3_LPM [00:51:08] [PASSED] 35.00 Xe3p_LPM [00:51:08] [PASSED] 35.03 Xe3p_HPM [00:51:08] ================= [PASSED] check_media_ip ================== [00:51:08] =================== check_platform_desc =================== [00:51:08] [PASSED] 0x9A60 (TIGERLAKE) [00:51:08] [PASSED] 0x9A68 (TIGERLAKE) [00:51:08] [PASSED] 0x9A70 (TIGERLAKE) [00:51:08] [PASSED] 0x9A40 (TIGERLAKE) [00:51:08] [PASSED] 0x9A49 (TIGERLAKE) [00:51:08] [PASSED] 0x9A59 (TIGERLAKE) [00:51:08] [PASSED] 0x9A78 (TIGERLAKE) [00:51:08] [PASSED] 0x9AC0 (TIGERLAKE) [00:51:08] [PASSED] 0x9AC9 (TIGERLAKE) [00:51:08] [PASSED] 0x9AD9 (TIGERLAKE) [00:51:08] [PASSED] 0x9AF8 (TIGERLAKE) [00:51:08] [PASSED] 0x4C80 (ROCKETLAKE) [00:51:08] [PASSED] 0x4C8A (ROCKETLAKE) [00:51:08] [PASSED] 0x4C8B (ROCKETLAKE) [00:51:08] [PASSED] 0x4C8C (ROCKETLAKE) [00:51:08] [PASSED] 0x4C90 (ROCKETLAKE) [00:51:08] [PASSED] 0x4C9A (ROCKETLAKE) [00:51:08] [PASSED] 0x4680 (ALDERLAKE_S) [00:51:08] [PASSED] 0x4682 (ALDERLAKE_S) [00:51:08] [PASSED] 0x4688 (ALDERLAKE_S) [00:51:08] [PASSED] 0x468A (ALDERLAKE_S) [00:51:08] [PASSED] 0x468B (ALDERLAKE_S) [00:51:08] [PASSED] 0x4690 (ALDERLAKE_S) [00:51:08] [PASSED] 0x4692 (ALDERLAKE_S) [00:51:08] [PASSED] 0x4693 (ALDERLAKE_S) [00:51:08] [PASSED] 0x46A0 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46A1 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46A2 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46A3 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46A6 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46A8 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46AA (ALDERLAKE_P) [00:51:08] [PASSED] 0x462A (ALDERLAKE_P) [00:51:08] [PASSED] 0x4626 (ALDERLAKE_P) [00:51:08] [PASSED] 0x4628 (ALDERLAKE_P) stty: 'standard input': Inappropriate ioctl for device [00:51:08] [PASSED] 0x46B0 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46B1 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46B2 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46B3 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46C0 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46C1 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46C2 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46C3 (ALDERLAKE_P) [00:51:08] [PASSED] 0x46D0 (ALDERLAKE_N) [00:51:08] [PASSED] 0x46D1 (ALDERLAKE_N) [00:51:08] [PASSED] 0x46D2 (ALDERLAKE_N) [00:51:08] [PASSED] 0x46D3 (ALDERLAKE_N) [00:51:08] [PASSED] 0x46D4 (ALDERLAKE_N) [00:51:08] [PASSED] 0xA721 (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7A1 (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7A9 (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7AC (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7AD (ALDERLAKE_P) [00:51:08] [PASSED] 0xA720 (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7A0 (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7A8 (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7AA (ALDERLAKE_P) [00:51:08] [PASSED] 0xA7AB (ALDERLAKE_P) [00:51:08] [PASSED] 0xA780 (ALDERLAKE_S) [00:51:08] [PASSED] 0xA781 (ALDERLAKE_S) [00:51:08] [PASSED] 0xA782 (ALDERLAKE_S) [00:51:08] [PASSED] 0xA783 (ALDERLAKE_S) [00:51:08] [PASSED] 0xA788 (ALDERLAKE_S) [00:51:08] [PASSED] 0xA789 (ALDERLAKE_S) [00:51:08] [PASSED] 0xA78A (ALDERLAKE_S) [00:51:08] [PASSED] 0xA78B (ALDERLAKE_S) [00:51:08] [PASSED] 0x4905 (DG1) [00:51:08] [PASSED] 0x4906 (DG1) [00:51:08] [PASSED] 0x4907 (DG1) [00:51:08] [PASSED] 0x4908 (DG1) [00:51:08] [PASSED] 0x4909 (DG1) [00:51:08] [PASSED] 0x56C0 (DG2) [00:51:08] [PASSED] 0x56C2 (DG2) [00:51:08] [PASSED] 0x56C1 (DG2) [00:51:08] [PASSED] 0x7D51 (METEORLAKE) [00:51:08] [PASSED] 0x7DD1 (METEORLAKE) [00:51:08] [PASSED] 0x7D41 (METEORLAKE) [00:51:08] [PASSED] 0x7D67 (METEORLAKE) [00:51:08] [PASSED] 0xB640 (METEORLAKE) [00:51:08] [PASSED] 0x56A0 (DG2) [00:51:08] [PASSED] 0x56A1 (DG2) [00:51:08] [PASSED] 0x56A2 (DG2) [00:51:08] [PASSED] 0x56BE (DG2) [00:51:08] [PASSED] 0x56BF (DG2) [00:51:08] [PASSED] 0x5690 (DG2) [00:51:08] [PASSED] 0x5691 (DG2) [00:51:08] [PASSED] 0x5692 (DG2) [00:51:08] [PASSED] 0x56A5 (DG2) [00:51:08] [PASSED] 0x56A6 (DG2) [00:51:08] [PASSED] 0x56B0 (DG2) [00:51:08] [PASSED] 0x56B1 (DG2) [00:51:08] [PASSED] 0x56BA (DG2) [00:51:08] [PASSED] 0x56BB (DG2) [00:51:08] [PASSED] 0x56BC (DG2) [00:51:08] [PASSED] 0x56BD (DG2) [00:51:08] [PASSED] 0x5693 (DG2) [00:51:08] [PASSED] 0x5694 (DG2) [00:51:08] [PASSED] 0x5695 (DG2) [00:51:08] [PASSED] 0x56A3 (DG2) [00:51:08] [PASSED] 0x56A4 (DG2) [00:51:08] [PASSED] 0x56B2 (DG2) [00:51:08] [PASSED] 0x56B3 (DG2) [00:51:08] [PASSED] 0x5696 (DG2) [00:51:08] [PASSED] 0x5697 (DG2) [00:51:08] [PASSED] 0xB69 (PVC) [00:51:08] [PASSED] 0xB6E (PVC) [00:51:08] [PASSED] 0xBD4 (PVC) [00:51:08] [PASSED] 0xBD5 (PVC) [00:51:08] [PASSED] 0xBD6 (PVC) [00:51:08] [PASSED] 0xBD7 (PVC) [00:51:08] [PASSED] 0xBD8 (PVC) [00:51:08] [PASSED] 0xBD9 (PVC) [00:51:08] [PASSED] 0xBDA (PVC) [00:51:08] [PASSED] 0xBDB (PVC) [00:51:08] [PASSED] 0xBE0 (PVC) [00:51:08] [PASSED] 0xBE1 (PVC) [00:51:08] [PASSED] 0xBE5 (PVC) [00:51:08] [PASSED] 0x7D40 (METEORLAKE) [00:51:08] [PASSED] 0x7D45 (METEORLAKE) [00:51:08] [PASSED] 0x7D55 (METEORLAKE) [00:51:08] [PASSED] 0x7D60 (METEORLAKE) [00:51:08] [PASSED] 0x7DD5 (METEORLAKE) [00:51:08] [PASSED] 0x6420 (LUNARLAKE) [00:51:08] [PASSED] 0x64A0 (LUNARLAKE) [00:51:08] [PASSED] 0x64B0 (LUNARLAKE) [00:51:08] [PASSED] 0xE202 (BATTLEMAGE) [00:51:08] [PASSED] 0xE209 (BATTLEMAGE) [00:51:08] [PASSED] 0xE20B (BATTLEMAGE) [00:51:08] [PASSED] 0xE20C (BATTLEMAGE) [00:51:08] [PASSED] 0xE20D (BATTLEMAGE) [00:51:08] [PASSED] 0xE210 (BATTLEMAGE) [00:51:08] [PASSED] 0xE211 (BATTLEMAGE) [00:51:08] [PASSED] 0xE212 (BATTLEMAGE) [00:51:08] [PASSED] 0xE216 (BATTLEMAGE) [00:51:08] [PASSED] 0xE220 (BATTLEMAGE) [00:51:08] [PASSED] 0xE221 (BATTLEMAGE) [00:51:08] [PASSED] 0xE222 (BATTLEMAGE) [00:51:08] [PASSED] 0xE223 (BATTLEMAGE) [00:51:08] [PASSED] 0xB080 (PANTHERLAKE) [00:51:08] [PASSED] 0xB081 (PANTHERLAKE) [00:51:08] [PASSED] 0xB082 (PANTHERLAKE) [00:51:08] [PASSED] 0xB083 (PANTHERLAKE) [00:51:08] [PASSED] 0xB084 (PANTHERLAKE) [00:51:08] [PASSED] 0xB085 (PANTHERLAKE) [00:51:08] [PASSED] 0xB086 (PANTHERLAKE) [00:51:08] [PASSED] 0xB087 (PANTHERLAKE) [00:51:08] [PASSED] 0xB08F (PANTHERLAKE) [00:51:08] [PASSED] 0xB090 (PANTHERLAKE) [00:51:08] [PASSED] 0xB0A0 (PANTHERLAKE) [00:51:08] [PASSED] 0xB0B0 (PANTHERLAKE) [00:51:08] [PASSED] 0xFD80 (PANTHERLAKE) [00:51:08] [PASSED] 0xFD81 (PANTHERLAKE) [00:51:08] [PASSED] 0xD740 (NOVALAKE_S) [00:51:08] [PASSED] 0xD741 (NOVALAKE_S) [00:51:08] [PASSED] 0xD742 (NOVALAKE_S) [00:51:08] [PASSED] 0xD743 (NOVALAKE_S) [00:51:08] [PASSED] 0xD744 (NOVALAKE_S) [00:51:08] [PASSED] 0xD745 (NOVALAKE_S) [00:51:08] [PASSED] 0x674C (CRESCENTISLAND) [00:51:08] =============== [PASSED] check_platform_desc =============== [00:51:08] ===================== [PASSED] xe_pci ====================== [00:51:08] =================== xe_rtp (2 subtests) ==================== [00:51:08] =============== xe_rtp_process_to_sr_tests ================ [00:51:08] [PASSED] coalesce-same-reg [00:51:08] [PASSED] no-match-no-add [00:51:08] [PASSED] match-or [00:51:08] [PASSED] match-or-xfail [00:51:08] [PASSED] no-match-no-add-multiple-rules [00:51:08] [PASSED] two-regs-two-entries [00:51:08] [PASSED] clr-one-set-other [00:51:08] [PASSED] set-field [00:51:08] [PASSED] conflict-duplicate [00:51:08] [PASSED] conflict-not-disjoint [00:51:08] [PASSED] conflict-reg-type [00:51:08] =========== [PASSED] xe_rtp_process_to_sr_tests ============ [00:51:08] ================== xe_rtp_process_tests =================== [00:51:08] [PASSED] active1 [00:51:08] [PASSED] active2 [00:51:08] [PASSED] active-inactive [00:51:08] [PASSED] inactive-active [00:51:08] [PASSED] inactive-1st_or_active-inactive [00:51:08] [PASSED] inactive-2nd_or_active-inactive [00:51:08] [PASSED] inactive-last_or_active-inactive [00:51:08] [PASSED] inactive-no_or_active-inactive [00:51:08] ============== [PASSED] xe_rtp_process_tests =============== [00:51:08] ===================== [PASSED] xe_rtp ====================== [00:51:08] ==================== xe_wa (1 subtest) ===================== [00:51:08] ======================== xe_wa_gt ========================= [00:51:08] [PASSED] TIGERLAKE B0 [00:51:08] [PASSED] DG1 A0 [00:51:08] [PASSED] DG1 B0 [00:51:08] [PASSED] ALDERLAKE_S A0 [00:51:08] [PASSED] ALDERLAKE_S B0 [00:51:08] [PASSED] ALDERLAKE_S C0 [00:51:08] [PASSED] ALDERLAKE_S D0 [00:51:08] [PASSED] ALDERLAKE_P A0 [00:51:08] [PASSED] ALDERLAKE_P B0 [00:51:08] [PASSED] ALDERLAKE_P C0 [00:51:08] [PASSED] ALDERLAKE_S RPLS D0 [00:51:08] [PASSED] ALDERLAKE_P RPLU E0 [00:51:08] [PASSED] DG2 G10 C0 [00:51:08] [PASSED] DG2 G11 B1 [00:51:08] [PASSED] DG2 G12 A1 [00:51:08] [PASSED] METEORLAKE 12.70(Xe_LPG) A0 13.00(Xe_LPM+) A0 [00:51:08] [PASSED] METEORLAKE 12.71(Xe_LPG) A0 13.00(Xe_LPM+) A0 [00:51:08] [PASSED] METEORLAKE 12.74(Xe_LPG+) A0 13.00(Xe_LPM+) A0 [00:51:08] [PASSED] LUNARLAKE 20.04(Xe2_LPG) A0 20.00(Xe2_LPM) A0 [00:51:08] [PASSED] LUNARLAKE 20.04(Xe2_LPG) B0 20.00(Xe2_LPM) A0 [00:51:08] [PASSED] BATTLEMAGE 20.01(Xe2_HPG) A0 13.01(Xe2_HPM) A1 [00:51:08] [PASSED] PANTHERLAKE 30.00(Xe3_LPG) A0 30.00(Xe3_LPM) A0 [00:51:08] ==================== [PASSED] xe_wa_gt ===================== [00:51:08] ====================== [PASSED] xe_wa ====================== [00:51:08] ============================================================ [00:51:08] Testing complete. Ran 512 tests: passed: 494, skipped: 18 [00:51:08] Elapsed time: 44.012s total, 4.326s configuring, 39.168s building, 0.485s running + /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/tests/.kunitconfig [00:51:08] Configuring KUnit Kernel ... Regenerating .config ... Populating config with: $ make ARCH=um O=.kunit olddefconfig [00:51:10] Building KUnit Kernel ... Populating config with: $ make ARCH=um O=.kunit olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=25 [00:51:40] Starting KUnit Kernel (1/1)... [00:51:40] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [00:51:41] ============ drm_test_pick_cmdline (2 subtests) ============ [00:51:41] [PASSED] drm_test_pick_cmdline_res_1920_1080_60 [00:51:41] =============== drm_test_pick_cmdline_named =============== [00:51:41] [PASSED] NTSC [00:51:41] [PASSED] NTSC-J [00:51:41] [PASSED] PAL [00:51:41] [PASSED] PAL-M [00:51:41] =========== [PASSED] drm_test_pick_cmdline_named =========== [00:51:41] ============== [PASSED] drm_test_pick_cmdline ============== [00:51:41] == drm_test_atomic_get_connector_for_encoder (1 subtest) === [00:51:41] [PASSED] drm_test_drm_atomic_get_connector_for_encoder [00:51:41] ==== [PASSED] drm_test_atomic_get_connector_for_encoder ==== [00:51:41] =========== drm_validate_clone_mode (2 subtests) =========== [00:51:41] ============== drm_test_check_in_clone_mode =============== [00:51:41] [PASSED] in_clone_mode [00:51:41] [PASSED] not_in_clone_mode [00:51:41] ========== [PASSED] drm_test_check_in_clone_mode =========== [00:51:41] =============== drm_test_check_valid_clones =============== [00:51:41] [PASSED] not_in_clone_mode [00:51:41] [PASSED] valid_clone [00:51:41] [PASSED] invalid_clone [00:51:41] =========== [PASSED] drm_test_check_valid_clones =========== [00:51:41] ============= [PASSED] drm_validate_clone_mode ============= [00:51:41] ============= drm_validate_modeset (1 subtest) ============= [00:51:41] [PASSED] drm_test_check_connector_changed_modeset [00:51:41] ============== [PASSED] drm_validate_modeset =============== [00:51:41] ====== drm_test_bridge_get_current_state (2 subtests) ====== [00:51:41] [PASSED] drm_test_drm_bridge_get_current_state_atomic [00:51:41] [PASSED] drm_test_drm_bridge_get_current_state_legacy [00:51:41] ======== [PASSED] drm_test_bridge_get_current_state ======== [00:51:41] ====== drm_test_bridge_helper_reset_crtc (3 subtests) ====== [00:51:41] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic [00:51:41] [PASSED] drm_test_drm_bridge_helper_reset_crtc_atomic_disabled [00:51:41] [PASSED] drm_test_drm_bridge_helper_reset_crtc_legacy [00:51:41] ======== [PASSED] drm_test_bridge_helper_reset_crtc ======== [00:51:41] ============== drm_bridge_alloc (2 subtests) =============== [00:51:41] [PASSED] drm_test_drm_bridge_alloc_basic [00:51:41] [PASSED] drm_test_drm_bridge_alloc_get_put [00:51:41] ================ [PASSED] drm_bridge_alloc ================= [00:51:41] ================== drm_buddy (8 subtests) ================== [00:51:41] [PASSED] drm_test_buddy_alloc_limit [00:51:41] [PASSED] drm_test_buddy_alloc_optimistic [00:51:41] [PASSED] drm_test_buddy_alloc_pessimistic [00:51:41] [PASSED] drm_test_buddy_alloc_pathological [00:51:41] [PASSED] drm_test_buddy_alloc_contiguous [00:51:41] [PASSED] drm_test_buddy_alloc_clear [00:51:41] [PASSED] drm_test_buddy_alloc_range_bias [00:51:41] [PASSED] drm_test_buddy_fragmentation_performance [00:51:41] ==================== [PASSED] drm_buddy ==================== [00:51:41] ============= drm_cmdline_parser (40 subtests) ============= [00:51:41] [PASSED] drm_test_cmdline_force_d_only [00:51:41] [PASSED] drm_test_cmdline_force_D_only_dvi [00:51:41] [PASSED] drm_test_cmdline_force_D_only_hdmi [00:51:41] [PASSED] drm_test_cmdline_force_D_only_not_digital [00:51:41] [PASSED] drm_test_cmdline_force_e_only [00:51:41] [PASSED] drm_test_cmdline_res [00:51:41] [PASSED] drm_test_cmdline_res_vesa [00:51:41] [PASSED] drm_test_cmdline_res_vesa_rblank [00:51:41] [PASSED] drm_test_cmdline_res_rblank [00:51:41] [PASSED] drm_test_cmdline_res_bpp [00:51:41] [PASSED] drm_test_cmdline_res_refresh [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_margins [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_force_off [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_analog [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_force_on_digital [00:51:41] [PASSED] drm_test_cmdline_res_bpp_refresh_interlaced_margins_force_on [00:51:41] [PASSED] drm_test_cmdline_res_margins_force_on [00:51:41] [PASSED] drm_test_cmdline_res_vesa_margins [00:51:41] [PASSED] drm_test_cmdline_name [00:51:41] [PASSED] drm_test_cmdline_name_bpp [00:51:41] [PASSED] drm_test_cmdline_name_option [00:51:41] [PASSED] drm_test_cmdline_name_bpp_option [00:51:41] [PASSED] drm_test_cmdline_rotate_0 [00:51:41] [PASSED] drm_test_cmdline_rotate_90 [00:51:41] [PASSED] drm_test_cmdline_rotate_180 [00:51:41] [PASSED] drm_test_cmdline_rotate_270 [00:51:41] [PASSED] drm_test_cmdline_hmirror [00:51:41] [PASSED] drm_test_cmdline_vmirror [00:51:41] [PASSED] drm_test_cmdline_margin_options [00:51:41] [PASSED] drm_test_cmdline_multiple_options [00:51:41] [PASSED] drm_test_cmdline_bpp_extra_and_option [00:51:41] [PASSED] drm_test_cmdline_extra_and_option [00:51:41] [PASSED] drm_test_cmdline_freestanding_options [00:51:41] [PASSED] drm_test_cmdline_freestanding_force_e_and_options [00:51:41] [PASSED] drm_test_cmdline_panel_orientation [00:51:41] ================ drm_test_cmdline_invalid ================= [00:51:41] [PASSED] margin_only [00:51:41] [PASSED] interlace_only [00:51:41] [PASSED] res_missing_x [00:51:41] [PASSED] res_missing_y [00:51:41] [PASSED] res_bad_y [00:51:41] [PASSED] res_missing_y_bpp [00:51:41] [PASSED] res_bad_bpp [00:51:41] [PASSED] res_bad_refresh [00:51:41] [PASSED] res_bpp_refresh_force_on_off [00:51:41] [PASSED] res_invalid_mode [00:51:41] [PASSED] res_bpp_wrong_place_mode [00:51:41] [PASSED] name_bpp_refresh [00:51:41] [PASSED] name_refresh [00:51:41] [PASSED] name_refresh_wrong_mode [00:51:41] [PASSED] name_refresh_invalid_mode [00:51:41] [PASSED] rotate_multiple [00:51:41] [PASSED] rotate_invalid_val [00:51:41] [PASSED] rotate_truncated [00:51:41] [PASSED] invalid_option [00:51:41] [PASSED] invalid_tv_option [00:51:41] [PASSED] truncated_tv_option [00:51:41] ============ [PASSED] drm_test_cmdline_invalid ============= [00:51:41] =============== drm_test_cmdline_tv_options =============== [00:51:41] [PASSED] NTSC [00:51:41] [PASSED] NTSC_443 [00:51:41] [PASSED] NTSC_J [00:51:41] [PASSED] PAL [00:51:41] [PASSED] PAL_M [00:51:41] [PASSED] PAL_N [00:51:41] [PASSED] SECAM [00:51:41] [PASSED] MONO_525 [00:51:41] [PASSED] MONO_625 [00:51:41] =========== [PASSED] drm_test_cmdline_tv_options =========== [00:51:41] =============== [PASSED] drm_cmdline_parser ================ [00:51:41] ========== drmm_connector_hdmi_init (20 subtests) ========== [00:51:41] [PASSED] drm_test_connector_hdmi_init_valid [00:51:41] [PASSED] drm_test_connector_hdmi_init_bpc_8 [00:51:41] [PASSED] drm_test_connector_hdmi_init_bpc_10 [00:51:41] [PASSED] drm_test_connector_hdmi_init_bpc_12 [00:51:41] [PASSED] drm_test_connector_hdmi_init_bpc_invalid [00:51:41] [PASSED] drm_test_connector_hdmi_init_bpc_null [00:51:41] [PASSED] drm_test_connector_hdmi_init_formats_empty [00:51:41] [PASSED] drm_test_connector_hdmi_init_formats_no_rgb [00:51:41] === drm_test_connector_hdmi_init_formats_yuv420_allowed === [00:51:41] [PASSED] supported_formats=0x9 yuv420_allowed=1 [00:51:41] [PASSED] supported_formats=0x9 yuv420_allowed=0 [00:51:41] [PASSED] supported_formats=0x3 yuv420_allowed=1 [00:51:41] [PASSED] supported_formats=0x3 yuv420_allowed=0 [00:51:41] === [PASSED] drm_test_connector_hdmi_init_formats_yuv420_allowed === [00:51:41] [PASSED] drm_test_connector_hdmi_init_null_ddc [00:51:41] [PASSED] drm_test_connector_hdmi_init_null_product [00:51:41] [PASSED] drm_test_connector_hdmi_init_null_vendor [00:51:41] [PASSED] drm_test_connector_hdmi_init_product_length_exact [00:51:41] [PASSED] drm_test_connector_hdmi_init_product_length_too_long [00:51:41] [PASSED] drm_test_connector_hdmi_init_product_valid [00:51:41] [PASSED] drm_test_connector_hdmi_init_vendor_length_exact [00:51:41] [PASSED] drm_test_connector_hdmi_init_vendor_length_too_long [00:51:41] [PASSED] drm_test_connector_hdmi_init_vendor_valid [00:51:41] ========= drm_test_connector_hdmi_init_type_valid ========= [00:51:41] [PASSED] HDMI-A [00:51:41] [PASSED] HDMI-B [00:51:41] ===== [PASSED] drm_test_connector_hdmi_init_type_valid ===== [00:51:41] ======== drm_test_connector_hdmi_init_type_invalid ======== [00:51:41] [PASSED] Unknown [00:51:41] [PASSED] VGA [00:51:41] [PASSED] DVI-I [00:51:41] [PASSED] DVI-D [00:51:41] [PASSED] DVI-A [00:51:41] [PASSED] Composite [00:51:41] [PASSED] SVIDEO [00:51:41] [PASSED] LVDS [00:51:41] [PASSED] Component [00:51:41] [PASSED] DIN [00:51:41] [PASSED] DP [00:51:41] [PASSED] TV [00:51:41] [PASSED] eDP [00:51:41] [PASSED] Virtual [00:51:41] [PASSED] DSI [00:51:41] [PASSED] DPI [00:51:41] [PASSED] Writeback [00:51:41] [PASSED] SPI [00:51:41] [PASSED] USB [00:51:41] ==== [PASSED] drm_test_connector_hdmi_init_type_invalid ==== [00:51:41] ============ [PASSED] drmm_connector_hdmi_init ============= [00:51:41] ============= drmm_connector_init (3 subtests) ============= [00:51:41] [PASSED] drm_test_drmm_connector_init [00:51:41] [PASSED] drm_test_drmm_connector_init_null_ddc [00:51:41] ========= drm_test_drmm_connector_init_type_valid ========= [00:51:41] [PASSED] Unknown [00:51:41] [PASSED] VGA [00:51:41] [PASSED] DVI-I [00:51:41] [PASSED] DVI-D [00:51:41] [PASSED] DVI-A [00:51:41] [PASSED] Composite [00:51:41] [PASSED] SVIDEO [00:51:41] [PASSED] LVDS [00:51:41] [PASSED] Component [00:51:41] [PASSED] DIN [00:51:41] [PASSED] DP [00:51:41] [PASSED] HDMI-A [00:51:41] [PASSED] HDMI-B [00:51:41] [PASSED] TV [00:51:41] [PASSED] eDP [00:51:41] [PASSED] Virtual [00:51:41] [PASSED] DSI [00:51:41] [PASSED] DPI [00:51:41] [PASSED] Writeback [00:51:41] [PASSED] SPI [00:51:41] [PASSED] USB [00:51:41] ===== [PASSED] drm_test_drmm_connector_init_type_valid ===== [00:51:41] =============== [PASSED] drmm_connector_init =============== [00:51:41] ========= drm_connector_dynamic_init (6 subtests) ========== [00:51:41] [PASSED] drm_test_drm_connector_dynamic_init [00:51:41] [PASSED] drm_test_drm_connector_dynamic_init_null_ddc [00:51:41] [PASSED] drm_test_drm_connector_dynamic_init_not_added [00:51:41] [PASSED] drm_test_drm_connector_dynamic_init_properties [00:51:41] ===== drm_test_drm_connector_dynamic_init_type_valid ====== [00:51:41] [PASSED] Unknown [00:51:41] [PASSED] VGA [00:51:41] [PASSED] DVI-I [00:51:41] [PASSED] DVI-D [00:51:41] [PASSED] DVI-A [00:51:41] [PASSED] Composite [00:51:41] [PASSED] SVIDEO [00:51:41] [PASSED] LVDS [00:51:41] [PASSED] Component [00:51:41] [PASSED] DIN [00:51:41] [PASSED] DP [00:51:41] [PASSED] HDMI-A [00:51:41] [PASSED] HDMI-B [00:51:41] [PASSED] TV [00:51:41] [PASSED] eDP [00:51:41] [PASSED] Virtual [00:51:41] [PASSED] DSI [00:51:41] [PASSED] DPI [00:51:41] [PASSED] Writeback [00:51:41] [PASSED] SPI [00:51:41] [PASSED] USB [00:51:41] = [PASSED] drm_test_drm_connector_dynamic_init_type_valid == [00:51:41] ======== drm_test_drm_connector_dynamic_init_name ========= [00:51:41] [PASSED] Unknown [00:51:41] [PASSED] VGA [00:51:41] [PASSED] DVI-I [00:51:41] [PASSED] DVI-D [00:51:41] [PASSED] DVI-A [00:51:41] [PASSED] Composite [00:51:41] [PASSED] SVIDEO [00:51:41] [PASSED] LVDS [00:51:41] [PASSED] Component [00:51:41] [PASSED] DIN [00:51:41] [PASSED] DP [00:51:41] [PASSED] HDMI-A [00:51:41] [PASSED] HDMI-B [00:51:41] [PASSED] TV [00:51:41] [PASSED] eDP [00:51:41] [PASSED] Virtual [00:51:41] [PASSED] DSI [00:51:41] [PASSED] DPI [00:51:41] [PASSED] Writeback [00:51:41] [PASSED] SPI [00:51:41] [PASSED] USB [00:51:41] ==== [PASSED] drm_test_drm_connector_dynamic_init_name ===== [00:51:41] =========== [PASSED] drm_connector_dynamic_init ============ [00:51:41] ==== drm_connector_dynamic_register_early (4 subtests) ===== [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_early_on_list [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_early_defer [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_early_no_init [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_early_no_mode_object [00:51:41] ====== [PASSED] drm_connector_dynamic_register_early ======= [00:51:41] ======= drm_connector_dynamic_register (7 subtests) ======== [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_on_list [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_no_defer [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_no_init [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_mode_object [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_sysfs [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_sysfs_name [00:51:41] [PASSED] drm_test_drm_connector_dynamic_register_debugfs [00:51:41] ========= [PASSED] drm_connector_dynamic_register ========== [00:51:41] = drm_connector_attach_broadcast_rgb_property (2 subtests) = [00:51:41] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property [00:51:41] [PASSED] drm_test_drm_connector_attach_broadcast_rgb_property_hdmi_connector [00:51:41] === [PASSED] drm_connector_attach_broadcast_rgb_property === [00:51:41] ========== drm_get_tv_mode_from_name (2 subtests) ========== [00:51:41] ========== drm_test_get_tv_mode_from_name_valid =========== [00:51:41] [PASSED] NTSC [00:51:41] [PASSED] NTSC-443 [00:51:41] [PASSED] NTSC-J [00:51:41] [PASSED] PAL [00:51:41] [PASSED] PAL-M [00:51:41] [PASSED] PAL-N [00:51:41] [PASSED] SECAM [00:51:41] [PASSED] Mono [00:51:41] ====== [PASSED] drm_test_get_tv_mode_from_name_valid ======= [00:51:41] [PASSED] drm_test_get_tv_mode_from_name_truncated [00:51:41] ============ [PASSED] drm_get_tv_mode_from_name ============ [00:51:41] = drm_test_connector_hdmi_compute_mode_clock (12 subtests) = [00:51:41] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb [00:51:41] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc [00:51:41] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_10bpc_vic_1 [00:51:41] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc [00:51:41] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_12bpc_vic_1 [00:51:41] [PASSED] drm_test_drm_hdmi_compute_mode_clock_rgb_double [00:51:41] = drm_test_connector_hdmi_compute_mode_clock_yuv420_valid = [00:51:41] [PASSED] VIC 96 [00:51:41] [PASSED] VIC 97 [00:51:41] [PASSED] VIC 101 [00:51:41] [PASSED] VIC 102 [00:51:41] [PASSED] VIC 106 [00:51:41] [PASSED] VIC 107 [00:51:41] === [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_valid === [00:51:41] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_10_bpc [00:51:41] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv420_12_bpc [00:51:41] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_8_bpc [00:51:41] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_10_bpc [00:51:41] [PASSED] drm_test_connector_hdmi_compute_mode_clock_yuv422_12_bpc [00:51:41] === [PASSED] drm_test_connector_hdmi_compute_mode_clock ==== [00:51:41] == drm_hdmi_connector_get_broadcast_rgb_name (2 subtests) == [00:51:41] === drm_test_drm_hdmi_connector_get_broadcast_rgb_name ==== [00:51:41] [PASSED] Automatic [00:51:41] [PASSED] Full [00:51:41] [PASSED] Limited 16:235 [00:51:41] === [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name === [00:51:41] [PASSED] drm_test_drm_hdmi_connector_get_broadcast_rgb_name_invalid [00:51:41] ==== [PASSED] drm_hdmi_connector_get_broadcast_rgb_name ==== [00:51:41] == drm_hdmi_connector_get_output_format_name (2 subtests) == [00:51:41] === drm_test_drm_hdmi_connector_get_output_format_name ==== [00:51:41] [PASSED] RGB [00:51:41] [PASSED] YUV 4:2:0 [00:51:41] [PASSED] YUV 4:2:2 [00:51:41] [PASSED] YUV 4:4:4 [00:51:41] === [PASSED] drm_test_drm_hdmi_connector_get_output_format_name === [00:51:41] [PASSED] drm_test_drm_hdmi_connector_get_output_format_name_invalid [00:51:41] ==== [PASSED] drm_hdmi_connector_get_output_format_name ==== [00:51:41] ============= drm_damage_helper (21 subtests) ============== [00:51:41] [PASSED] drm_test_damage_iter_no_damage [00:51:41] [PASSED] drm_test_damage_iter_no_damage_fractional_src [00:51:41] [PASSED] drm_test_damage_iter_no_damage_src_moved [00:51:41] [PASSED] drm_test_damage_iter_no_damage_fractional_src_moved [00:51:41] [PASSED] drm_test_damage_iter_no_damage_not_visible [00:51:41] [PASSED] drm_test_damage_iter_no_damage_no_crtc [00:51:41] [PASSED] drm_test_damage_iter_no_damage_no_fb [00:51:41] [PASSED] drm_test_damage_iter_simple_damage [00:51:41] [PASSED] drm_test_damage_iter_single_damage [00:51:41] [PASSED] drm_test_damage_iter_single_damage_intersect_src [00:51:41] [PASSED] drm_test_damage_iter_single_damage_outside_src [00:51:41] [PASSED] drm_test_damage_iter_single_damage_fractional_src [00:51:41] [PASSED] drm_test_damage_iter_single_damage_intersect_fractional_src [00:51:41] [PASSED] drm_test_damage_iter_single_damage_outside_fractional_src [00:51:41] [PASSED] drm_test_damage_iter_single_damage_src_moved [00:51:41] [PASSED] drm_test_damage_iter_single_damage_fractional_src_moved [00:51:41] [PASSED] drm_test_damage_iter_damage [00:51:41] [PASSED] drm_test_damage_iter_damage_one_intersect [00:51:41] [PASSED] drm_test_damage_iter_damage_one_outside [00:51:41] [PASSED] drm_test_damage_iter_damage_src_moved [00:51:41] [PASSED] drm_test_damage_iter_damage_not_visible [00:51:41] ================ [PASSED] drm_damage_helper ================ [00:51:41] ============== drm_dp_mst_helper (3 subtests) ============== [00:51:41] ============== drm_test_dp_mst_calc_pbn_mode ============== [00:51:41] [PASSED] Clock 154000 BPP 30 DSC disabled [00:51:41] [PASSED] Clock 234000 BPP 30 DSC disabled [00:51:41] [PASSED] Clock 297000 BPP 24 DSC disabled [00:51:41] [PASSED] Clock 332880 BPP 24 DSC enabled [00:51:41] [PASSED] Clock 324540 BPP 24 DSC enabled [00:51:41] ========== [PASSED] drm_test_dp_mst_calc_pbn_mode ========== [00:51:41] ============== drm_test_dp_mst_calc_pbn_div =============== [00:51:41] [PASSED] Link rate 2000000 lane count 4 [00:51:41] [PASSED] Link rate 2000000 lane count 2 [00:51:41] [PASSED] Link rate 2000000 lane count 1 [00:51:41] [PASSED] Link rate 1350000 lane count 4 [00:51:41] [PASSED] Link rate 1350000 lane count 2 [00:51:41] [PASSED] Link rate 1350000 lane count 1 [00:51:41] [PASSED] Link rate 1000000 lane count 4 [00:51:41] [PASSED] Link rate 1000000 lane count 2 [00:51:41] [PASSED] Link rate 1000000 lane count 1 [00:51:41] [PASSED] Link rate 810000 lane count 4 [00:51:41] [PASSED] Link rate 810000 lane count 2 [00:51:41] [PASSED] Link rate 810000 lane count 1 [00:51:41] [PASSED] Link rate 540000 lane count 4 [00:51:41] [PASSED] Link rate 540000 lane count 2 [00:51:41] [PASSED] Link rate 540000 lane count 1 [00:51:41] [PASSED] Link rate 270000 lane count 4 [00:51:41] [PASSED] Link rate 270000 lane count 2 [00:51:41] [PASSED] Link rate 270000 lane count 1 [00:51:41] [PASSED] Link rate 162000 lane count 4 [00:51:41] [PASSED] Link rate 162000 lane count 2 [00:51:41] [PASSED] Link rate 162000 lane count 1 [00:51:41] ========== [PASSED] drm_test_dp_mst_calc_pbn_div =========== [00:51:41] ========= drm_test_dp_mst_sideband_msg_req_decode ========= [00:51:41] [PASSED] DP_ENUM_PATH_RESOURCES with port number [00:51:41] [PASSED] DP_POWER_UP_PHY with port number [00:51:41] [PASSED] DP_POWER_DOWN_PHY with port number [00:51:41] [PASSED] DP_ALLOCATE_PAYLOAD with SDP stream sinks [00:51:41] [PASSED] DP_ALLOCATE_PAYLOAD with port number [00:51:41] [PASSED] DP_ALLOCATE_PAYLOAD with VCPI [00:51:41] [PASSED] DP_ALLOCATE_PAYLOAD with PBN [00:51:41] [PASSED] DP_QUERY_PAYLOAD with port number [00:51:41] [PASSED] DP_QUERY_PAYLOAD with VCPI [00:51:41] [PASSED] DP_REMOTE_DPCD_READ with port number [00:51:41] [PASSED] DP_REMOTE_DPCD_READ with DPCD address [00:51:41] [PASSED] DP_REMOTE_DPCD_READ with max number of bytes [00:51:41] [PASSED] DP_REMOTE_DPCD_WRITE with port number [00:51:41] [PASSED] DP_REMOTE_DPCD_WRITE with DPCD address [00:51:41] [PASSED] DP_REMOTE_DPCD_WRITE with data array [00:51:41] [PASSED] DP_REMOTE_I2C_READ with port number [00:51:41] [PASSED] DP_REMOTE_I2C_READ with I2C device ID [00:51:41] [PASSED] DP_REMOTE_I2C_READ with transactions array [00:51:41] [PASSED] DP_REMOTE_I2C_WRITE with port number [00:51:41] [PASSED] DP_REMOTE_I2C_WRITE with I2C device ID [00:51:41] [PASSED] DP_REMOTE_I2C_WRITE with data array [00:51:41] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream ID [00:51:41] [PASSED] DP_QUERY_STREAM_ENC_STATUS with client ID [00:51:41] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream event [00:51:41] [PASSED] DP_QUERY_STREAM_ENC_STATUS with valid stream event [00:51:41] [PASSED] DP_QUERY_STREAM_ENC_STATUS with stream behavior [00:51:41] [PASSED] DP_QUERY_STREAM_ENC_STATUS with a valid stream behavior [00:51:41] ===== [PASSED] drm_test_dp_mst_sideband_msg_req_decode ===== [00:51:41] ================ [PASSED] drm_dp_mst_helper ================ [00:51:41] ================== drm_exec (7 subtests) =================== [00:51:41] [PASSED] sanitycheck [00:51:41] [PASSED] test_lock [00:51:41] [PASSED] test_lock_unlock [00:51:41] [PASSED] test_duplicates [00:51:41] [PASSED] test_prepare [00:51:41] [PASSED] test_prepare_array [00:51:41] [PASSED] test_multiple_loops [00:51:41] ==================== [PASSED] drm_exec ===================== [00:51:41] =========== drm_format_helper_test (17 subtests) =========== [00:51:41] ============== drm_test_fb_xrgb8888_to_gray8 ============== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ========== [PASSED] drm_test_fb_xrgb8888_to_gray8 ========== [00:51:41] ============= drm_test_fb_xrgb8888_to_rgb332 ============== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb332 ========== [00:51:41] ============= drm_test_fb_xrgb8888_to_rgb565 ============== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb565 ========== [00:51:41] ============ drm_test_fb_xrgb8888_to_xrgb1555 ============= [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======== [PASSED] drm_test_fb_xrgb8888_to_xrgb1555 ========= [00:51:41] ============ drm_test_fb_xrgb8888_to_argb1555 ============= [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======== [PASSED] drm_test_fb_xrgb8888_to_argb1555 ========= [00:51:41] ============ drm_test_fb_xrgb8888_to_rgba5551 ============= [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======== [PASSED] drm_test_fb_xrgb8888_to_rgba5551 ========= [00:51:41] ============= drm_test_fb_xrgb8888_to_rgb888 ============== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ========= [PASSED] drm_test_fb_xrgb8888_to_rgb888 ========== [00:51:41] ============= drm_test_fb_xrgb8888_to_bgr888 ============== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ========= [PASSED] drm_test_fb_xrgb8888_to_bgr888 ========== [00:51:41] ============ drm_test_fb_xrgb8888_to_argb8888 ============= [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======== [PASSED] drm_test_fb_xrgb8888_to_argb8888 ========= [00:51:41] =========== drm_test_fb_xrgb8888_to_xrgb2101010 =========== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======= [PASSED] drm_test_fb_xrgb8888_to_xrgb2101010 ======= [00:51:41] =========== drm_test_fb_xrgb8888_to_argb2101010 =========== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======= [PASSED] drm_test_fb_xrgb8888_to_argb2101010 ======= [00:51:41] ============== drm_test_fb_xrgb8888_to_mono =============== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ========== [PASSED] drm_test_fb_xrgb8888_to_mono =========== [00:51:41] ==================== drm_test_fb_swab ===================== [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ================ [PASSED] drm_test_fb_swab ================= [00:51:41] ============ drm_test_fb_xrgb8888_to_xbgr8888 ============= [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======== [PASSED] drm_test_fb_xrgb8888_to_xbgr8888 ========= [00:51:41] ============ drm_test_fb_xrgb8888_to_abgr8888 ============= [00:51:41] [PASSED] single_pixel_source_buffer [00:51:41] [PASSED] single_pixel_clip_rectangle [00:51:41] [PASSED] well_known_colors [00:51:41] [PASSED] destination_pitch [00:51:41] ======== [PASSED] drm_test_fb_xrgb8888_to_abgr8888 ========= [00:51:41] ================= drm_test_fb_clip_offset ================= [00:51:41] [PASSED] pass through [00:51:41] [PASSED] horizontal offset [00:51:41] [PASSED] vertical offset [00:51:41] [PASSED] horizontal and vertical offset [00:51:41] [PASSED] horizontal offset (custom pitch) [00:51:41] [PASSED] vertical offset (custom pitch) [00:51:41] [PASSED] horizontal and vertical offset (custom pitch) [00:51:41] ============= [PASSED] drm_test_fb_clip_offset ============= [00:51:41] =================== drm_test_fb_memcpy ==================== [00:51:41] [PASSED] single_pixel_source_buffer: XR24 little-endian (0x34325258) [00:51:41] [PASSED] single_pixel_source_buffer: XRA8 little-endian (0x38415258) [00:51:41] [PASSED] single_pixel_source_buffer: YU24 little-endian (0x34325559) [00:51:41] [PASSED] single_pixel_clip_rectangle: XB24 little-endian (0x34324258) [00:51:41] [PASSED] single_pixel_clip_rectangle: XRA8 little-endian (0x38415258) [00:51:41] [PASSED] single_pixel_clip_rectangle: YU24 little-endian (0x34325559) [00:51:41] [PASSED] well_known_colors: XB24 little-endian (0x34324258) [00:51:41] [PASSED] well_known_colors: XRA8 little-endian (0x38415258) [00:51:41] [PASSED] well_known_colors: YU24 little-endian (0x34325559) [00:51:41] [PASSED] destination_pitch: XB24 little-endian (0x34324258) [00:51:41] [PASSED] destination_pitch: XRA8 little-endian (0x38415258) [00:51:41] [PASSED] destination_pitch: YU24 little-endian (0x34325559) [00:51:41] =============== [PASSED] drm_test_fb_memcpy ================ [00:51:41] ============= [PASSED] drm_format_helper_test ============== [00:51:41] ================= drm_format (18 subtests) ================= [00:51:41] [PASSED] drm_test_format_block_width_invalid [00:51:41] [PASSED] drm_test_format_block_width_one_plane [00:51:41] [PASSED] drm_test_format_block_width_two_plane [00:51:41] [PASSED] drm_test_format_block_width_three_plane [00:51:41] [PASSED] drm_test_format_block_width_tiled [00:51:41] [PASSED] drm_test_format_block_height_invalid [00:51:41] [PASSED] drm_test_format_block_height_one_plane [00:51:41] [PASSED] drm_test_format_block_height_two_plane [00:51:41] [PASSED] drm_test_format_block_height_three_plane [00:51:41] [PASSED] drm_test_format_block_height_tiled [00:51:41] [PASSED] drm_test_format_min_pitch_invalid [00:51:41] [PASSED] drm_test_format_min_pitch_one_plane_8bpp [00:51:41] [PASSED] drm_test_format_min_pitch_one_plane_16bpp [00:51:41] [PASSED] drm_test_format_min_pitch_one_plane_24bpp [00:51:41] [PASSED] drm_test_format_min_pitch_one_plane_32bpp [00:51:41] [PASSED] drm_test_format_min_pitch_two_plane [00:51:41] [PASSED] drm_test_format_min_pitch_three_plane_8bpp [00:51:41] [PASSED] drm_test_format_min_pitch_tiled [00:51:41] =================== [PASSED] drm_format ==================== [00:51:41] ============== drm_framebuffer (10 subtests) =============== [00:51:41] ========== drm_test_framebuffer_check_src_coords ========== [00:51:41] [PASSED] Success: source fits into fb [00:51:41] [PASSED] Fail: overflowing fb with x-axis coordinate [00:51:41] [PASSED] Fail: overflowing fb with y-axis coordinate [00:51:41] [PASSED] Fail: overflowing fb with source width [00:51:41] [PASSED] Fail: overflowing fb with source height [00:51:41] ====== [PASSED] drm_test_framebuffer_check_src_coords ====== [00:51:41] [PASSED] drm_test_framebuffer_cleanup [00:51:41] =============== drm_test_framebuffer_create =============== [00:51:41] [PASSED] ABGR8888 normal sizes [00:51:41] [PASSED] ABGR8888 max sizes [00:51:41] [PASSED] ABGR8888 pitch greater than min required [00:51:41] [PASSED] ABGR8888 pitch less than min required [00:51:41] [PASSED] ABGR8888 Invalid width [00:51:41] [PASSED] ABGR8888 Invalid buffer handle [00:51:41] [PASSED] No pixel format [00:51:41] [PASSED] ABGR8888 Width 0 [00:51:41] [PASSED] ABGR8888 Height 0 [00:51:41] [PASSED] ABGR8888 Out of bound height * pitch combination [00:51:41] [PASSED] ABGR8888 Large buffer offset [00:51:41] [PASSED] ABGR8888 Buffer offset for inexistent plane [00:51:41] [PASSED] ABGR8888 Invalid flag [00:51:41] [PASSED] ABGR8888 Set DRM_MODE_FB_MODIFIERS without modifiers [00:51:41] [PASSED] ABGR8888 Valid buffer modifier [00:51:41] [PASSED] ABGR8888 Invalid buffer modifier(DRM_FORMAT_MOD_SAMSUNG_64_32_TILE) [00:51:41] [PASSED] ABGR8888 Extra pitches without DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] ABGR8888 Extra pitches with DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] NV12 Normal sizes [00:51:41] [PASSED] NV12 Max sizes [00:51:41] [PASSED] NV12 Invalid pitch [00:51:41] [PASSED] NV12 Invalid modifier/missing DRM_MODE_FB_MODIFIERS flag [00:51:41] [PASSED] NV12 different modifier per-plane [00:51:41] [PASSED] NV12 with DRM_FORMAT_MOD_SAMSUNG_64_32_TILE [00:51:41] [PASSED] NV12 Valid modifiers without DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] NV12 Modifier for inexistent plane [00:51:41] [PASSED] NV12 Handle for inexistent plane [00:51:41] [PASSED] NV12 Handle for inexistent plane without DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] YVU420 DRM_MODE_FB_MODIFIERS set without modifier [00:51:41] [PASSED] YVU420 Normal sizes [00:51:41] [PASSED] YVU420 Max sizes [00:51:41] [PASSED] YVU420 Invalid pitch [00:51:41] [PASSED] YVU420 Different pitches [00:51:41] [PASSED] YVU420 Different buffer offsets/pitches [00:51:41] [PASSED] YVU420 Modifier set just for plane 0, without DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] YVU420 Modifier set just for planes 0, 1, without DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] YVU420 Modifier set just for plane 0, 1, with DRM_MODE_FB_MODIFIERS [00:51:41] [PASSED] YVU420 Valid modifier [00:51:41] [PASSED] YVU420 Different modifiers per plane [00:51:41] [PASSED] YVU420 Modifier for inexistent plane [00:51:41] [PASSED] YUV420_10BIT Invalid modifier(DRM_FORMAT_MOD_LINEAR) [00:51:41] [PASSED] X0L2 Normal sizes [00:51:41] [PASSED] X0L2 Max sizes [00:51:41] [PASSED] X0L2 Invalid pitch [00:51:41] [PASSED] X0L2 Pitch greater than minimum required [00:51:41] [PASSED] X0L2 Handle for inexistent plane [00:51:41] [PASSED] X0L2 Offset for inexistent plane, without DRM_MODE_FB_MODIFIERS set [00:51:41] [PASSED] X0L2 Modifier without DRM_MODE_FB_MODIFIERS set [00:51:41] [PASSED] X0L2 Valid modifier [00:51:41] [PASSED] X0L2 Modifier for inexistent plane [00:51:41] =========== [PASSED] drm_test_framebuffer_create =========== [00:51:41] [PASSED] drm_test_framebuffer_free [00:51:41] [PASSED] drm_test_framebuffer_init [00:51:41] [PASSED] drm_test_framebuffer_init_bad_format [00:51:41] [PASSED] drm_test_framebuffer_init_dev_mismatch [00:51:41] [PASSED] drm_test_framebuffer_lookup [00:51:41] [PASSED] drm_test_framebuffer_lookup_inexistent [00:51:41] [PASSED] drm_test_framebuffer_modifiers_not_supported [00:51:41] ================= [PASSED] drm_framebuffer ================= [00:51:41] ================ drm_gem_shmem (8 subtests) ================ [00:51:41] [PASSED] drm_gem_shmem_test_obj_create [00:51:41] [PASSED] drm_gem_shmem_test_obj_create_private [00:51:41] [PASSED] drm_gem_shmem_test_pin_pages [00:51:41] [PASSED] drm_gem_shmem_test_vmap [00:51:41] [PASSED] drm_gem_shmem_test_get_sg_table [00:51:41] [PASSED] drm_gem_shmem_test_get_pages_sgt [00:51:41] [PASSED] drm_gem_shmem_test_madvise [00:51:41] [PASSED] drm_gem_shmem_test_purge [00:51:41] ================== [PASSED] drm_gem_shmem ================== [00:51:41] === drm_atomic_helper_connector_hdmi_check (27 subtests) === [00:51:41] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode [00:51:41] [PASSED] drm_test_check_broadcast_rgb_auto_cea_mode_vic_1 [00:51:41] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode [00:51:41] [PASSED] drm_test_check_broadcast_rgb_full_cea_mode_vic_1 [00:51:41] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode [00:51:41] [PASSED] drm_test_check_broadcast_rgb_limited_cea_mode_vic_1 [00:51:41] ====== drm_test_check_broadcast_rgb_cea_mode_yuv420 ======= [00:51:41] [PASSED] Automatic [00:51:41] [PASSED] Full [00:51:41] [PASSED] Limited 16:235 [00:51:41] == [PASSED] drm_test_check_broadcast_rgb_cea_mode_yuv420 === [00:51:41] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_changed [00:51:41] [PASSED] drm_test_check_broadcast_rgb_crtc_mode_not_changed [00:51:41] [PASSED] drm_test_check_disable_connector [00:51:41] [PASSED] drm_test_check_hdmi_funcs_reject_rate [00:51:41] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_rgb [00:51:41] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_yuv420 [00:51:41] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv422 [00:51:41] [PASSED] drm_test_check_max_tmds_rate_bpc_fallback_ignore_yuv420 [00:51:41] [PASSED] drm_test_check_driver_unsupported_fallback_yuv420 [00:51:41] [PASSED] drm_test_check_output_bpc_crtc_mode_changed [00:51:41] [PASSED] drm_test_check_output_bpc_crtc_mode_not_changed [00:51:41] [PASSED] drm_test_check_output_bpc_dvi [00:51:41] [PASSED] drm_test_check_output_bpc_format_vic_1 [00:51:41] [PASSED] drm_test_check_output_bpc_format_display_8bpc_only [00:51:41] [PASSED] drm_test_check_output_bpc_format_display_rgb_only [00:51:41] [PASSED] drm_test_check_output_bpc_format_driver_8bpc_only [00:51:41] [PASSED] drm_test_check_output_bpc_format_driver_rgb_only [00:51:41] [PASSED] drm_test_check_tmds_char_rate_rgb_8bpc [00:51:41] [PASSED] drm_test_check_tmds_char_rate_rgb_10bpc [00:51:41] [PASSED] drm_test_check_tmds_char_rate_rgb_12bpc [00:51:41] ===== [PASSED] drm_atomic_helper_connector_hdmi_check ====== [00:51:41] === drm_atomic_helper_connector_hdmi_reset (6 subtests) ==== [00:51:41] [PASSED] drm_test_check_broadcast_rgb_value [00:51:41] [PASSED] drm_test_check_bpc_8_value [00:51:41] [PASSED] drm_test_check_bpc_10_value [00:51:41] [PASSED] drm_test_check_bpc_12_value [00:51:41] [PASSED] drm_test_check_format_value [00:51:41] [PASSED] drm_test_check_tmds_char_value [00:51:41] ===== [PASSED] drm_atomic_helper_connector_hdmi_reset ====== [00:51:41] = drm_atomic_helper_connector_hdmi_mode_valid (4 subtests) = [00:51:41] [PASSED] drm_test_check_mode_valid [00:51:41] [PASSED] drm_test_check_mode_valid_reject [00:51:41] [PASSED] drm_test_check_mode_valid_reject_rate [00:51:41] [PASSED] drm_test_check_mode_valid_reject_max_clock [00:51:41] === [PASSED] drm_atomic_helper_connector_hdmi_mode_valid === [00:51:41] ================= drm_managed (2 subtests) ================= [00:51:41] [PASSED] drm_test_managed_release_action [00:51:41] [PASSED] drm_test_managed_run_action [00:51:41] =================== [PASSED] drm_managed =================== [00:51:41] =================== drm_mm (6 subtests) ==================== [00:51:41] [PASSED] drm_test_mm_init [00:51:41] [PASSED] drm_test_mm_debug [00:51:41] [PASSED] drm_test_mm_align32 [00:51:41] [PASSED] drm_test_mm_align64 [00:51:41] [PASSED] drm_test_mm_lowest [00:51:41] [PASSED] drm_test_mm_highest [00:51:41] ===================== [PASSED] drm_mm ====================== [00:51:41] ============= drm_modes_analog_tv (5 subtests) ============= [00:51:41] [PASSED] drm_test_modes_analog_tv_mono_576i [00:51:41] [PASSED] drm_test_modes_analog_tv_ntsc_480i [00:51:41] [PASSED] drm_test_modes_analog_tv_ntsc_480i_inlined [00:51:41] [PASSED] drm_test_modes_analog_tv_pal_576i [00:51:41] [PASSED] drm_test_modes_analog_tv_pal_576i_inlined [00:51:41] =============== [PASSED] drm_modes_analog_tv =============== [00:51:41] ============== drm_plane_helper (2 subtests) =============== [00:51:41] =============== drm_test_check_plane_state ================ [00:51:41] [PASSED] clipping_simple [00:51:41] [PASSED] clipping_rotate_reflect [00:51:41] [PASSED] positioning_simple [00:51:41] [PASSED] upscaling [00:51:41] [PASSED] downscaling [00:51:41] [PASSED] rounding1 [00:51:41] [PASSED] rounding2 [00:51:41] [PASSED] rounding3 [00:51:41] [PASSED] rounding4 [00:51:41] =========== [PASSED] drm_test_check_plane_state ============ [00:51:41] =========== drm_test_check_invalid_plane_state ============ [00:51:41] [PASSED] positioning_invalid [00:51:41] [PASSED] upscaling_invalid [00:51:41] [PASSED] downscaling_invalid [00:51:41] ======= [PASSED] drm_test_check_invalid_plane_state ======== [00:51:41] ================ [PASSED] drm_plane_helper ================= [00:51:41] ====== drm_connector_helper_tv_get_modes (1 subtest) ======= [00:51:41] ====== drm_test_connector_helper_tv_get_modes_check ======= [00:51:41] [PASSED] None [00:51:41] [PASSED] PAL [00:51:41] [PASSED] NTSC [00:51:41] [PASSED] Both, NTSC Default [00:51:41] [PASSED] Both, PAL Default [00:51:41] [PASSED] Both, NTSC Default, with PAL on command-line [00:51:41] [PASSED] Both, PAL Default, with NTSC on command-line [00:51:41] == [PASSED] drm_test_connector_helper_tv_get_modes_check === [00:51:41] ======== [PASSED] drm_connector_helper_tv_get_modes ======== [00:51:41] ================== drm_rect (9 subtests) =================== [00:51:41] [PASSED] drm_test_rect_clip_scaled_div_by_zero [00:51:41] [PASSED] drm_test_rect_clip_scaled_not_clipped [00:51:41] [PASSED] drm_test_rect_clip_scaled_clipped [00:51:41] [PASSED] drm_test_rect_clip_scaled_signed_vs_unsigned [00:51:41] ================= drm_test_rect_intersect ================= [00:51:41] [PASSED] top-left x bottom-right: 2x2+1+1 x 2x2+0+0 [00:51:41] [PASSED] top-right x bottom-left: 2x2+0+0 x 2x2+1-1 [00:51:41] [PASSED] bottom-left x top-right: 2x2+1-1 x 2x2+0+0 [00:51:41] [PASSED] bottom-right x top-left: 2x2+0+0 x 2x2+1+1 [00:51:41] [PASSED] right x left: 2x1+0+0 x 3x1+1+0 [00:51:41] [PASSED] left x right: 3x1+1+0 x 2x1+0+0 [00:51:41] [PASSED] up x bottom: 1x2+0+0 x 1x3+0-1 [00:51:41] [PASSED] bottom x up: 1x3+0-1 x 1x2+0+0 [00:51:41] [PASSED] touching corner: 1x1+0+0 x 2x2+1+1 [00:51:41] [PASSED] touching side: 1x1+0+0 x 1x1+1+0 [00:51:41] [PASSED] equal rects: 2x2+0+0 x 2x2+0+0 [00:51:41] [PASSED] inside another: 2x2+0+0 x 1x1+1+1 [00:51:41] [PASSED] far away: 1x1+0+0 x 1x1+3+6 [00:51:41] [PASSED] points intersecting: 0x0+5+10 x 0x0+5+10 [00:51:41] [PASSED] points not intersecting: 0x0+0+0 x 0x0+5+10 [00:51:41] ============= [PASSED] drm_test_rect_intersect ============= [00:51:41] ================ drm_test_rect_calc_hscale ================ [00:51:41] [PASSED] normal use [00:51:41] [PASSED] out of max range [00:51:41] [PASSED] out of min range [00:51:41] [PASSED] zero dst [00:51:41] [PASSED] negative src [00:51:41] [PASSED] negative dst [00:51:41] ============ [PASSED] drm_test_rect_calc_hscale ============ [00:51:41] ================ drm_test_rect_calc_vscale ================ [00:51:41] [PASSED] normal use stty: 'standard input': Inappropriate ioctl for device [00:51:41] [PASSED] out of max range [00:51:41] [PASSED] out of min range [00:51:41] [PASSED] zero dst [00:51:41] [PASSED] negative src [00:51:41] [PASSED] negative dst [00:51:41] ============ [PASSED] drm_test_rect_calc_vscale ============ [00:51:41] ================== drm_test_rect_rotate =================== [00:51:41] [PASSED] reflect-x [00:51:41] [PASSED] reflect-y [00:51:41] [PASSED] rotate-0 [00:51:41] [PASSED] rotate-90 [00:51:41] [PASSED] rotate-180 [00:51:41] [PASSED] rotate-270 [00:51:41] ============== [PASSED] drm_test_rect_rotate =============== [00:51:41] ================ drm_test_rect_rotate_inv ================= [00:51:41] [PASSED] reflect-x [00:51:41] [PASSED] reflect-y [00:51:41] [PASSED] rotate-0 [00:51:41] [PASSED] rotate-90 [00:51:41] [PASSED] rotate-180 [00:51:41] [PASSED] rotate-270 [00:51:41] ============ [PASSED] drm_test_rect_rotate_inv ============= [00:51:41] ==================== [PASSED] drm_rect ===================== [00:51:41] ============ drm_sysfb_modeset_test (1 subtest) ============ [00:51:41] ============ drm_test_sysfb_build_fourcc_list ============= [00:51:41] [PASSED] no native formats [00:51:41] [PASSED] XRGB8888 as native format [00:51:41] [PASSED] remove duplicates [00:51:41] [PASSED] convert alpha formats [00:51:41] [PASSED] random formats [00:51:41] ======== [PASSED] drm_test_sysfb_build_fourcc_list ========= [00:51:41] ============= [PASSED] drm_sysfb_modeset_test ============== [00:51:41] ================== drm_fixp (2 subtests) =================== [00:51:41] [PASSED] drm_test_int2fixp [00:51:41] [PASSED] drm_test_sm2fixp [00:51:41] ==================== [PASSED] drm_fixp ===================== [00:51:41] ============================================================ [00:51:41] Testing complete. Ran 624 tests: passed: 624 [00:51:41] Elapsed time: 32.714s total, 1.633s configuring, 30.615s building, 0.442s running + /kernel/tools/testing/kunit/kunit.py run --kunitconfig /kernel/drivers/gpu/drm/ttm/tests/.kunitconfig [00:51:41] Configuring KUnit Kernel ... Regenerating .config ... Populating config with: $ make ARCH=um O=.kunit olddefconfig [00:51:43] Building KUnit Kernel ... Populating config with: $ make ARCH=um O=.kunit olddefconfig Building with: $ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=25 [00:51:52] Starting KUnit Kernel (1/1)... [00:51:52] ============================================================ Running tests with: $ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt [00:51:52] ================= ttm_device (5 subtests) ================== [00:51:52] [PASSED] ttm_device_init_basic [00:51:52] [PASSED] ttm_device_init_multiple [00:51:52] [PASSED] ttm_device_fini_basic [00:51:52] [PASSED] ttm_device_init_no_vma_man [00:51:52] ================== ttm_device_init_pools ================== [00:51:52] [PASSED] No DMA allocations, no DMA32 required [00:51:52] [PASSED] DMA allocations, DMA32 required [00:51:52] [PASSED] No DMA allocations, DMA32 required [00:51:52] [PASSED] DMA allocations, no DMA32 required [00:51:52] ============== [PASSED] ttm_device_init_pools ============== [00:51:52] =================== [PASSED] ttm_device ==================== [00:51:52] ================== ttm_pool (8 subtests) =================== [00:51:52] ================== ttm_pool_alloc_basic =================== [00:51:52] [PASSED] One page [00:51:52] [PASSED] More than one page [00:51:52] [PASSED] Above the allocation limit [00:51:52] [PASSED] One page, with coherent DMA mappings enabled [00:51:52] [PASSED] Above the allocation limit, with coherent DMA mappings enabled [00:51:52] ============== [PASSED] ttm_pool_alloc_basic =============== [00:51:52] ============== ttm_pool_alloc_basic_dma_addr ============== [00:51:52] [PASSED] One page [00:51:52] [PASSED] More than one page [00:51:52] [PASSED] Above the allocation limit [00:51:52] [PASSED] One page, with coherent DMA mappings enabled [00:51:52] [PASSED] Above the allocation limit, with coherent DMA mappings enabled [00:51:52] ========== [PASSED] ttm_pool_alloc_basic_dma_addr ========== [00:51:52] [PASSED] ttm_pool_alloc_order_caching_match [00:51:52] [PASSED] ttm_pool_alloc_caching_mismatch [00:51:52] [PASSED] ttm_pool_alloc_order_mismatch [00:51:52] [PASSED] ttm_pool_free_dma_alloc [00:51:52] [PASSED] ttm_pool_free_no_dma_alloc [00:51:52] [PASSED] ttm_pool_fini_basic [00:51:52] ==================== [PASSED] ttm_pool ===================== [00:51:52] ================ ttm_resource (8 subtests) ================= [00:51:52] ================= ttm_resource_init_basic ================= [00:51:52] [PASSED] Init resource in TTM_PL_SYSTEM [00:51:52] [PASSED] Init resource in TTM_PL_VRAM [00:51:52] [PASSED] Init resource in a private placement [00:51:52] [PASSED] Init resource in TTM_PL_SYSTEM, set placement flags [00:51:52] ============= [PASSED] ttm_resource_init_basic ============= [00:51:52] [PASSED] ttm_resource_init_pinned [00:51:52] [PASSED] ttm_resource_fini_basic [00:51:52] [PASSED] ttm_resource_manager_init_basic [00:51:52] [PASSED] ttm_resource_manager_usage_basic [00:51:52] [PASSED] ttm_resource_manager_set_used_basic [00:51:52] [PASSED] ttm_sys_man_alloc_basic [00:51:52] [PASSED] ttm_sys_man_free_basic [00:51:52] ================== [PASSED] ttm_resource =================== [00:51:52] =================== ttm_tt (15 subtests) =================== [00:51:52] ==================== ttm_tt_init_basic ==================== [00:51:52] [PASSED] Page-aligned size [00:51:52] [PASSED] Extra pages requested [00:51:52] ================ [PASSED] ttm_tt_init_basic ================ [00:51:52] [PASSED] ttm_tt_init_misaligned [00:51:52] [PASSED] ttm_tt_fini_basic [00:51:52] [PASSED] ttm_tt_fini_sg [00:51:52] [PASSED] ttm_tt_fini_shmem [00:51:52] [PASSED] ttm_tt_create_basic [00:51:52] [PASSED] ttm_tt_create_invalid_bo_type [00:51:52] [PASSED] ttm_tt_create_ttm_exists [00:51:52] [PASSED] ttm_tt_create_failed [00:51:52] [PASSED] ttm_tt_destroy_basic [00:51:52] [PASSED] ttm_tt_populate_null_ttm [00:51:52] [PASSED] ttm_tt_populate_populated_ttm [00:51:52] [PASSED] ttm_tt_unpopulate_basic [00:51:52] [PASSED] ttm_tt_unpopulate_empty_ttm [00:51:52] [PASSED] ttm_tt_swapin_basic [00:51:52] ===================== [PASSED] ttm_tt ====================== [00:51:52] =================== ttm_bo (14 subtests) =================== [00:51:52] =========== ttm_bo_reserve_optimistic_no_ticket =========== [00:51:52] [PASSED] Cannot be interrupted and sleeps [00:51:52] [PASSED] Cannot be interrupted, locks straight away [00:51:52] [PASSED] Can be interrupted, sleeps [00:51:52] ======= [PASSED] ttm_bo_reserve_optimistic_no_ticket ======= [00:51:52] [PASSED] ttm_bo_reserve_locked_no_sleep [00:51:52] [PASSED] ttm_bo_reserve_no_wait_ticket [00:51:52] [PASSED] ttm_bo_reserve_double_resv [00:51:52] [PASSED] ttm_bo_reserve_interrupted [00:51:52] [PASSED] ttm_bo_reserve_deadlock [00:51:52] [PASSED] ttm_bo_unreserve_basic [00:51:52] [PASSED] ttm_bo_unreserve_pinned [00:51:52] [PASSED] ttm_bo_unreserve_bulk [00:51:52] [PASSED] ttm_bo_fini_basic [00:51:52] [PASSED] ttm_bo_fini_shared_resv [00:51:52] [PASSED] ttm_bo_pin_basic [00:51:52] [PASSED] ttm_bo_pin_unpin_resource [00:51:52] [PASSED] ttm_bo_multiple_pin_one_unpin [00:51:52] ===================== [PASSED] ttm_bo ====================== [00:51:52] ============== ttm_bo_validate (21 subtests) =============== [00:51:52] ============== ttm_bo_init_reserved_sys_man =============== [00:51:52] [PASSED] Buffer object for userspace [00:51:52] [PASSED] Kernel buffer object [00:51:52] [PASSED] Shared buffer object [00:51:52] ========== [PASSED] ttm_bo_init_reserved_sys_man =========== [00:51:52] ============== ttm_bo_init_reserved_mock_man ============== [00:51:52] [PASSED] Buffer object for userspace [00:51:52] [PASSED] Kernel buffer object [00:51:52] [PASSED] Shared buffer object [00:51:52] ========== [PASSED] ttm_bo_init_reserved_mock_man ========== [00:51:52] [PASSED] ttm_bo_init_reserved_resv [00:51:52] ================== ttm_bo_validate_basic ================== [00:51:52] [PASSED] Buffer object for userspace [00:51:52] [PASSED] Kernel buffer object [00:51:52] [PASSED] Shared buffer object [00:51:52] ============== [PASSED] ttm_bo_validate_basic ============== [00:51:52] [PASSED] ttm_bo_validate_invalid_placement [00:51:52] ============= ttm_bo_validate_same_placement ============== [00:51:52] [PASSED] System manager [00:51:52] [PASSED] VRAM manager [00:51:52] ========= [PASSED] ttm_bo_validate_same_placement ========== [00:51:52] [PASSED] ttm_bo_validate_failed_alloc [00:51:52] [PASSED] ttm_bo_validate_pinned [00:51:52] [PASSED] ttm_bo_validate_busy_placement [00:51:52] ================ ttm_bo_validate_multihop ================= [00:51:52] [PASSED] Buffer object for userspace [00:51:52] [PASSED] Kernel buffer object [00:51:52] [PASSED] Shared buffer object [00:51:52] ============ [PASSED] ttm_bo_validate_multihop ============= [00:51:52] ========== ttm_bo_validate_no_placement_signaled ========== [00:51:52] [PASSED] Buffer object in system domain, no page vector [00:51:52] [PASSED] Buffer object in system domain with an existing page vector [00:51:52] ====== [PASSED] ttm_bo_validate_no_placement_signaled ====== [00:51:52] ======== ttm_bo_validate_no_placement_not_signaled ======== [00:51:52] [PASSED] Buffer object for userspace [00:51:52] [PASSED] Kernel buffer object [00:51:52] [PASSED] Shared buffer object [00:51:52] ==== [PASSED] ttm_bo_validate_no_placement_not_signaled ==== [00:51:52] [PASSED] ttm_bo_validate_move_fence_signaled [00:51:52] ========= ttm_bo_validate_move_fence_not_signaled ========= [00:51:52] [PASSED] Waits for GPU [00:51:52] [PASSED] Tries to lock straight away [00:51:52] ===== [PASSED] ttm_bo_validate_move_fence_not_signaled ===== [00:51:52] [PASSED] ttm_bo_validate_happy_evict [00:51:52] [PASSED] ttm_bo_validate_all_pinned_evict [00:51:52] [PASSED] ttm_bo_validate_allowed_only_evict [00:51:52] [PASSED] ttm_bo_validate_deleted_evict [00:51:52] [PASSED] ttm_bo_validate_busy_domain_evict [00:51:52] [PASSED] ttm_bo_validate_evict_gutting [00:51:52] [PASSED] ttm_bo_validate_recrusive_evict stty: 'standard input': Inappropriate ioctl for device [00:51:52] ================= [PASSED] ttm_bo_validate ================= [00:51:52] ============================================================ [00:51:52] Testing complete. Ran 101 tests: passed: 101 [00:51:52] Elapsed time: 11.215s total, 1.653s configuring, 9.346s building, 0.187s running + cleanup ++ stat -c %u:%g /kernel + chown -R 1003:1003 /kernel ^ permalink raw reply [flat|nested] 25+ messages in thread
* ✓ Xe.CI.BAT: success for drm/xe: Do not preempt fence signaling CS instructions 2026-01-15 0:45 [PATCH] drm/xe: Do not preempt fence signaling CS instructions Matthew Brost 2026-01-15 0:52 ` ✓ CI.KUnit: success for " Patchwork @ 2026-01-15 1:35 ` Patchwork 2026-01-15 6:13 ` ✗ Xe.CI.Full: failure " Patchwork 2026-01-16 9:45 ` [PATCH] " Zbigniew Kempczyński 3 siblings, 0 replies; 25+ messages in thread From: Patchwork @ 2026-01-15 1:35 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe [-- Attachment #1: Type: text/plain, Size: 877 bytes --] == Series Details == Series: drm/xe: Do not preempt fence signaling CS instructions URL : https://patchwork.freedesktop.org/series/160113/ State : success == Summary == CI Bug Log - changes from xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d_BAT -> xe-pw-160113v1_BAT ==================================================== Summary ------- **SUCCESS** No regressions found. Participating hosts (12 -> 12) ------------------------------ No changes in participating hosts Changes ------- No changes found Build changes ------------- * Linux: xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d -> xe-pw-160113v1 IGT_8701: 8701 xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d: 733664f1edf3c01cc68e6dd0bbdb135158a98a1d xe-pw-160113v1: 160113v1 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/index.html [-- Attachment #2: Type: text/html, Size: 1425 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* ✗ Xe.CI.Full: failure for drm/xe: Do not preempt fence signaling CS instructions 2026-01-15 0:45 [PATCH] drm/xe: Do not preempt fence signaling CS instructions Matthew Brost 2026-01-15 0:52 ` ✓ CI.KUnit: success for " Patchwork 2026-01-15 1:35 ` ✓ Xe.CI.BAT: " Patchwork @ 2026-01-15 6:13 ` Patchwork 2026-01-16 9:45 ` [PATCH] " Zbigniew Kempczyński 3 siblings, 0 replies; 25+ messages in thread From: Patchwork @ 2026-01-15 6:13 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe [-- Attachment #1: Type: text/plain, Size: 39134 bytes --] == Series Details == Series: drm/xe: Do not preempt fence signaling CS instructions URL : https://patchwork.freedesktop.org/series/160113/ State : failure == Summary == CI Bug Log - changes from xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d_FULL -> xe-pw-160113v1_FULL ==================================================== Summary ------- **FAILURE** Serious unknown changes coming with xe-pw-160113v1_FULL absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in xe-pw-160113v1_FULL, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (2 -> 2) ------------------------------ No changes in participating hosts Possible new issues ------------------- Here are the unknown changes that may have been introduced in xe-pw-160113v1_FULL: ### IGT changes ### #### Possible regressions #### * igt@xe_compute_preempt@compute-preempt-many-all-ram@engine-drm_xe_engine_class_compute: - shard-bmg: [PASS][1] -> [FAIL][2] +1 other test fail [1]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_compute_preempt@compute-preempt-many-all-ram@engine-drm_xe_engine_class_compute.html [2]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_compute_preempt@compute-preempt-many-all-ram@engine-drm_xe_engine_class_compute.html * igt@xe_compute_preempt@compute-preempt-many-vram: - shard-bmg: NOTRUN -> [FAIL][3] +3 other tests fail [3]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@xe_compute_preempt@compute-preempt-many-vram.html * igt@xe_compute_preempt@compute-preempt-many@engine-drm_xe_engine_class_compute: - shard-lnl: [PASS][4] -> [FAIL][5] +7 other tests fail [4]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-lnl-7/igt@xe_compute_preempt@compute-preempt-many@engine-drm_xe_engine_class_compute.html [5]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-2/igt@xe_compute_preempt@compute-preempt-many@engine-drm_xe_engine_class_compute.html #### Warnings #### * igt@xe_exec_system_allocator@process-many-mmap-file-mlock-nomemset: - shard-lnl: [DMESG-WARN][6] ([Intel XE#4537]) -> [DMESG-WARN][7] [6]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-lnl-3/igt@xe_exec_system_allocator@process-many-mmap-file-mlock-nomemset.html [7]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-7/igt@xe_exec_system_allocator@process-many-mmap-file-mlock-nomemset.html Known issues ------------ Here are the changes found in xe-pw-160113v1_FULL that come from known issues: ### IGT changes ### #### Issues hit #### * igt@kms_3d@basic: - shard-lnl: NOTRUN -> [SKIP][8] ([Intel XE#6011]) [8]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-1/igt@kms_3d@basic.html * igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels: - shard-bmg: NOTRUN -> [SKIP][9] ([Intel XE#2370]) [9]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_atomic_transition@plane-all-modeset-transition-internal-panels.html * igt@kms_big_fb@linear-32bpp-rotate-270: - shard-bmg: NOTRUN -> [SKIP][10] ([Intel XE#2327]) +2 other tests skip [10]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_big_fb@linear-32bpp-rotate-270.html * igt@kms_big_fb@linear-64bpp-rotate-90: - shard-lnl: NOTRUN -> [SKIP][11] ([Intel XE#1407]) [11]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-1/igt@kms_big_fb@linear-64bpp-rotate-90.html * igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-180-hflip: - shard-bmg: NOTRUN -> [SKIP][12] ([Intel XE#7059]) [12]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-180-hflip.html * igt@kms_big_fb@y-tiled-addfb-size-overflow: - shard-bmg: NOTRUN -> [SKIP][13] ([Intel XE#610]) [13]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_big_fb@y-tiled-addfb-size-overflow.html * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0-hflip: - shard-bmg: NOTRUN -> [SKIP][14] ([Intel XE#1124]) +9 other tests skip [14]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-0-hflip.html * igt@kms_bw@connected-linear-tiling-3-displays-1920x1080p: - shard-bmg: NOTRUN -> [SKIP][15] ([Intel XE#2314] / [Intel XE#2894]) [15]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_bw@connected-linear-tiling-3-displays-1920x1080p.html * igt@kms_bw@linear-tiling-1-displays-2160x1440p: - shard-bmg: NOTRUN -> [SKIP][16] ([Intel XE#367]) +3 other tests skip [16]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_bw@linear-tiling-1-displays-2160x1440p.html * igt@kms_ccs@crc-primary-suspend-y-tiled-gen12-mc-ccs: - shard-bmg: NOTRUN -> [SKIP][17] ([Intel XE#3432]) [17]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_ccs@crc-primary-suspend-y-tiled-gen12-mc-ccs.html * igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc: - shard-bmg: NOTRUN -> [SKIP][18] ([Intel XE#2887]) +10 other tests skip [18]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_ccs@random-ccs-data-4-tiled-dg2-rc-ccs-cc.html * igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs@pipe-c-dp-2: - shard-bmg: NOTRUN -> [SKIP][19] ([Intel XE#2652] / [Intel XE#787]) +7 other tests skip [19]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs@pipe-c-dp-2.html * igt@kms_cdclk@plane-scaling: - shard-bmg: NOTRUN -> [SKIP][20] ([Intel XE#2724]) [20]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_cdclk@plane-scaling.html * igt@kms_chamelium_color@degamma: - shard-bmg: NOTRUN -> [SKIP][21] ([Intel XE#2325]) [21]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_chamelium_color@degamma.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - shard-bmg: NOTRUN -> [SKIP][22] ([Intel XE#2252]) +6 other tests skip [22]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_chamelium_hpd@common-hpd-after-suspend.html * igt@kms_content_protection@atomic: - shard-bmg: NOTRUN -> [FAIL][23] ([Intel XE#1178] / [Intel XE#3304]) +3 other tests fail [23]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_content_protection@atomic.html * igt@kms_content_protection@dp-mst-lic-type-0: - shard-bmg: NOTRUN -> [SKIP][24] ([Intel XE#2390] / [Intel XE#6974]) [24]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_content_protection@dp-mst-lic-type-0.html * igt@kms_content_protection@dp-mst-type-0-hdcp14: - shard-bmg: NOTRUN -> [SKIP][25] ([Intel XE#6974]) [25]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_content_protection@dp-mst-type-0-hdcp14.html * igt@kms_content_protection@lic-type-0-hdcp14@pipe-a-dp-2: - shard-bmg: NOTRUN -> [FAIL][26] ([Intel XE#3304]) +3 other tests fail [26]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_content_protection@lic-type-0-hdcp14@pipe-a-dp-2.html * igt@kms_cursor_crc@cursor-offscreen-512x170: - shard-bmg: NOTRUN -> [SKIP][27] ([Intel XE#2321]) [27]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_cursor_crc@cursor-offscreen-512x170.html * igt@kms_cursor_crc@cursor-rapid-movement-32x10: - shard-bmg: NOTRUN -> [SKIP][28] ([Intel XE#2320]) +3 other tests skip [28]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_cursor_crc@cursor-rapid-movement-32x10.html * igt@kms_cursor_legacy@flip-vs-cursor-legacy: - shard-bmg: NOTRUN -> [FAIL][29] ([Intel XE#5299]) [29]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html * igt@kms_dp_link_training@non-uhbr-sst: - shard-bmg: [PASS][30] -> [DMESG-WARN][31] ([Intel XE#5254]) [30]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_dp_link_training@non-uhbr-sst.html [31]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_dp_link_training@non-uhbr-sst.html * igt@kms_dp_linktrain_fallback@dsc-fallback: - shard-bmg: NOTRUN -> [SKIP][32] ([Intel XE#4331]) [32]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_dp_linktrain_fallback@dsc-fallback.html * igt@kms_dsc@dsc-with-output-formats-with-bpc: - shard-bmg: NOTRUN -> [SKIP][33] ([Intel XE#2244]) [33]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_dsc@dsc-with-output-formats-with-bpc.html * igt@kms_fbcon_fbt@psr: - shard-bmg: NOTRUN -> [SKIP][34] ([Intel XE#776]) [34]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_fbcon_fbt@psr.html * igt@kms_flip@2x-flip-vs-suspend-interruptible: - shard-bmg: NOTRUN -> [INCOMPLETE][35] ([Intel XE#2049] / [Intel XE#2597]) +1 other test incomplete [35]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_flip@2x-flip-vs-suspend-interruptible.html * igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling: - shard-bmg: NOTRUN -> [SKIP][36] ([Intel XE#2293] / [Intel XE#2380]) +4 other tests skip [36]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_flip_scaled_crc@flip-64bpp-yftile-to-16bpp-yftile-downscaling.html * igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode: - shard-bmg: NOTRUN -> [SKIP][37] ([Intel XE#2293]) +5 other tests skip [37]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilegen12rcccs-upscaling@pipe-a-valid-mode.html * igt@kms_frontbuffer_tracking@drrs-1p-primscrn-cur-indfb-draw-render: - shard-lnl: NOTRUN -> [SKIP][38] ([Intel XE#651]) [38]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-1/igt@kms_frontbuffer_tracking@drrs-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-shrfb-msflip-blt: - shard-lnl: NOTRUN -> [SKIP][39] ([Intel XE#656]) [39]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-1/igt@kms_frontbuffer_tracking@drrs-2p-scndscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-msflip-blt: - shard-bmg: NOTRUN -> [SKIP][40] ([Intel XE#4141]) +10 other tests skip [40]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-argb161616f-draw-render: - shard-bmg: NOTRUN -> [SKIP][41] ([Intel XE#7061]) +4 other tests skip [41]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_frontbuffer_tracking@fbc-argb161616f-draw-render.html * igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-cur-indfb-draw-mmap-wc: - shard-bmg: NOTRUN -> [SKIP][42] ([Intel XE#2311]) +24 other tests skip [42]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_frontbuffer_tracking@fbcdrrs-2p-scndscrn-cur-indfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-indfb-msflip-blt: - shard-bmg: NOTRUN -> [SKIP][43] ([Intel XE#2313]) +25 other tests skip [43]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-indfb-msflip-blt.html * igt@kms_hdr@brightness-with-hdr: - shard-bmg: NOTRUN -> [SKIP][44] ([Intel XE#3544]) [44]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_hdr@brightness-with-hdr.html * igt@kms_hdr@static-toggle-dpms@pipe-a-dp-2: - shard-bmg: [PASS][45] -> [ABORT][46] ([Intel XE#6740]) +1 other test abort [45]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_hdr@static-toggle-dpms@pipe-a-dp-2.html [46]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-9/igt@kms_hdr@static-toggle-dpms@pipe-a-dp-2.html * igt@kms_joiner@basic-max-non-joiner: - shard-bmg: NOTRUN -> [SKIP][47] ([Intel XE#4298]) [47]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_joiner@basic-max-non-joiner.html * igt@kms_joiner@switch-modeset-ultra-joiner-big-joiner: - shard-bmg: NOTRUN -> [SKIP][48] ([Intel XE#2925]) [48]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_joiner@switch-modeset-ultra-joiner-big-joiner.html * igt@kms_plane_multiple@tiling-yf: - shard-bmg: NOTRUN -> [SKIP][49] ([Intel XE#5020]) [49]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_plane_multiple@tiling-yf.html * igt@kms_pm_rpm@dpms-lpsp: - shard-bmg: NOTRUN -> [SKIP][50] ([Intel XE#1439] / [Intel XE#3141] / [Intel XE#836]) +1 other test skip [50]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_pm_rpm@dpms-lpsp.html * igt@kms_pm_rpm@package-g7: - shard-bmg: NOTRUN -> [SKIP][51] ([Intel XE#6814]) [51]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_pm_rpm@package-g7.html * igt@kms_psr2_sf@psr2-primary-plane-update-sf-dmg-area-big-fb: - shard-bmg: NOTRUN -> [SKIP][52] ([Intel XE#1406] / [Intel XE#1489]) +4 other tests skip [52]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_psr2_sf@psr2-primary-plane-update-sf-dmg-area-big-fb.html * igt@kms_psr2_su@page_flip-nv12: - shard-bmg: NOTRUN -> [SKIP][53] ([Intel XE#1406] / [Intel XE#2387]) +1 other test skip [53]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_psr2_su@page_flip-nv12.html * igt@kms_psr@fbc-psr2-cursor-plane-move: - shard-bmg: NOTRUN -> [SKIP][54] ([Intel XE#1406] / [Intel XE#2234] / [Intel XE#2850]) +9 other tests skip [54]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_psr@fbc-psr2-cursor-plane-move.html * igt@kms_psr_stress_test@flip-primary-invalidate-overlay: - shard-bmg: NOTRUN -> [SKIP][55] ([Intel XE#1406] / [Intel XE#2414]) [55]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_psr_stress_test@flip-primary-invalidate-overlay.html * igt@kms_rotation_crc@primary-y-tiled-reflect-x-180: - shard-bmg: NOTRUN -> [SKIP][56] ([Intel XE#2330]) [56]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_rotation_crc@primary-y-tiled-reflect-x-180.html * igt@kms_rotation_crc@primary-y-tiled-reflect-x-270: - shard-bmg: NOTRUN -> [SKIP][57] ([Intel XE#3414] / [Intel XE#3904]) [57]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_rotation_crc@primary-y-tiled-reflect-x-270.html * igt@kms_scaling_modes@scaling-mode-full: - shard-bmg: NOTRUN -> [SKIP][58] ([Intel XE#2413]) [58]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@kms_scaling_modes@scaling-mode-full.html * igt@kms_sharpness_filter@filter-dpms: - shard-bmg: NOTRUN -> [SKIP][59] ([Intel XE#6503]) [59]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_sharpness_filter@filter-dpms.html * igt@kms_tiled_display@basic-test-pattern-with-chamelium: - shard-bmg: NOTRUN -> [SKIP][60] ([Intel XE#2426]) [60]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@kms_tiled_display@basic-test-pattern-with-chamelium.html * igt@kms_vrr@flip-suspend: - shard-bmg: NOTRUN -> [SKIP][61] ([Intel XE#1499]) [61]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@kms_vrr@flip-suspend.html * igt@kms_vrr@lobf: - shard-bmg: NOTRUN -> [SKIP][62] ([Intel XE#2168]) [62]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@kms_vrr@lobf.html * igt@xe_compute_preempt@compute-preempt-many-vram-evict@engine-drm_xe_engine_class_compute: - shard-bmg: [PASS][63] -> [ABORT][64] ([Intel XE#3970]) +1 other test abort [63]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-7/igt@xe_compute_preempt@compute-preempt-many-vram-evict@engine-drm_xe_engine_class_compute.html [64]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@xe_compute_preempt@compute-preempt-many-vram-evict@engine-drm_xe_engine_class_compute.html * igt@xe_eudebug@vma-ufence: - shard-bmg: NOTRUN -> [SKIP][65] ([Intel XE#4837]) +3 other tests skip [65]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@xe_eudebug@vma-ufence.html * igt@xe_eudebug_online@pagefault-read-stress: - shard-bmg: NOTRUN -> [SKIP][66] ([Intel XE#6665] / [Intel XE#6681]) [66]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@xe_eudebug_online@pagefault-read-stress.html * igt@xe_eudebug_online@stopped-thread: - shard-bmg: NOTRUN -> [SKIP][67] ([Intel XE#4837] / [Intel XE#6665]) +4 other tests skip [67]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@xe_eudebug_online@stopped-thread.html * igt@xe_exec_basic@multigpu-many-execqueues-many-vm-bindexecqueue: - shard-bmg: NOTRUN -> [SKIP][68] ([Intel XE#2322]) +8 other tests skip [68]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-2/igt@xe_exec_basic@multigpu-many-execqueues-many-vm-bindexecqueue.html * igt@xe_exec_multi_queue@two-queues-priority: - shard-bmg: NOTRUN -> [SKIP][69] ([Intel XE#6874]) +23 other tests skip [69]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@xe_exec_multi_queue@two-queues-priority.html * igt@xe_exec_system_allocator@pat-index-madvise-pat-idx-uc-multi-vma: - shard-lnl: [PASS][70] -> [FAIL][71] ([Intel XE#5625]) [70]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-lnl-3/igt@xe_exec_system_allocator@pat-index-madvise-pat-idx-uc-multi-vma.html [71]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-1/igt@xe_exec_system_allocator@pat-index-madvise-pat-idx-uc-multi-vma.html * igt@xe_exec_system_allocator@threads-shared-vm-many-stride-mmap-free-huge: - shard-bmg: NOTRUN -> [SKIP][72] ([Intel XE#4943]) +21 other tests skip [72]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@xe_exec_system_allocator@threads-shared-vm-many-stride-mmap-free-huge.html * igt@xe_multigpu_svm@mgpu-concurrent-access-prefetch: - shard-bmg: NOTRUN -> [SKIP][73] ([Intel XE#6964]) +2 other tests skip [73]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@xe_multigpu_svm@mgpu-concurrent-access-prefetch.html * igt@xe_pat@pat-index-xehpc: - shard-bmg: NOTRUN -> [SKIP][74] ([Intel XE#1420]) [74]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-1/igt@xe_pat@pat-index-xehpc.html * igt@xe_pm@d3cold-multiple-execs: - shard-bmg: NOTRUN -> [SKIP][75] ([Intel XE#2284]) [75]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@xe_pm@d3cold-multiple-execs.html * igt@xe_pxp@pxp-stale-bo-exec-post-termination-irq: - shard-bmg: NOTRUN -> [SKIP][76] ([Intel XE#4733]) +1 other test skip [76]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@xe_pxp@pxp-stale-bo-exec-post-termination-irq.html * igt@xe_query@multigpu-query-mem-usage: - shard-bmg: NOTRUN -> [SKIP][77] ([Intel XE#944]) +1 other test skip [77]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-10/igt@xe_query@multigpu-query-mem-usage.html * igt@xe_sriov_flr@flr-vf1-clear: - shard-bmg: NOTRUN -> [FAIL][78] ([Intel XE#5937]) [78]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-3/igt@xe_sriov_flr@flr-vf1-clear.html #### Possible fixes #### * igt@kms_vrr@cmrr@pipe-a-edp-1: - shard-lnl: [FAIL][79] ([Intel XE#4459]) -> [PASS][80] +1 other test pass [79]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-lnl-1/igt@kms_vrr@cmrr@pipe-a-edp-1.html [80]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-7/igt@kms_vrr@cmrr@pipe-a-edp-1.html * igt@xe_compute@loop-duration-2s: - shard-bmg: [FAIL][81] -> [PASS][82] [81]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-10/igt@xe_compute@loop-duration-2s.html [82]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-9/igt@xe_compute@loop-duration-2s.html * igt@xe_exec_basic@twice-bindexecqueue-userptr: - shard-bmg: [DMESG-FAIL][83] ([Intel XE#5213] / [Intel XE#5545] / [Intel XE#6652]) -> [PASS][84] [83]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_exec_basic@twice-bindexecqueue-userptr.html [84]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_exec_basic@twice-bindexecqueue-userptr.html * igt@xe_exec_reset@gt-reset-stress: - shard-lnl: [DMESG-WARN][85] ([Intel XE#7023]) -> [PASS][86] [85]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-lnl-4/igt@xe_exec_reset@gt-reset-stress.html [86]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-lnl-4/igt@xe_exec_reset@gt-reset-stress.html * igt@xe_exec_system_allocator@madvise-multi-vma: - shard-bmg: [SKIP][87] ([Intel XE#6703]) -> [PASS][88] +55 other tests pass [87]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_exec_system_allocator@madvise-multi-vma.html [88]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_exec_system_allocator@madvise-multi-vma.html * igt@xe_exec_system_allocator@threads-many-execqueues-new-nomemset: - shard-bmg: [SKIP][89] ([Intel XE#6557] / [Intel XE#6703]) -> [PASS][90] +1 other test pass [89]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_exec_system_allocator@threads-many-execqueues-new-nomemset.html [90]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_exec_system_allocator@threads-many-execqueues-new-nomemset.html #### Warnings #### * igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip: - shard-bmg: [SKIP][91] ([Intel XE#6703]) -> [SKIP][92] ([Intel XE#1124]) [91]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html [92]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html * igt@kms_ccs@bad-pixel-format-y-tiled-gen12-rc-ccs: - shard-bmg: [SKIP][93] ([Intel XE#6703]) -> [SKIP][94] ([Intel XE#2887]) [93]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_ccs@bad-pixel-format-y-tiled-gen12-rc-ccs.html [94]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_ccs@bad-pixel-format-y-tiled-gen12-rc-ccs.html * igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs: - shard-bmg: [SKIP][95] ([Intel XE#6703]) -> [SKIP][96] ([Intel XE#2652] / [Intel XE#787]) [95]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs.html [96]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_ccs@random-ccs-data-4-tiled-lnl-ccs.html * igt@kms_chamelium_frames@hdmi-crc-nonplanar-formats: - shard-bmg: [SKIP][97] ([Intel XE#6703]) -> [SKIP][98] ([Intel XE#2252]) +1 other test skip [97]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_chamelium_frames@hdmi-crc-nonplanar-formats.html [98]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_chamelium_frames@hdmi-crc-nonplanar-formats.html * igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling: - shard-bmg: [SKIP][99] ([Intel XE#6703]) -> [SKIP][100] ([Intel XE#2293] / [Intel XE#2380]) [99]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html [100]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytileccs-upscaling.html * igt@kms_frontbuffer_tracking@drrs-1p-offscreen-pri-indfb-draw-mmap-wc: - shard-bmg: [SKIP][101] ([Intel XE#6703]) -> [SKIP][102] ([Intel XE#2311]) [101]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_frontbuffer_tracking@drrs-1p-offscreen-pri-indfb-draw-mmap-wc.html [102]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_frontbuffer_tracking@drrs-1p-offscreen-pri-indfb-draw-mmap-wc.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: - shard-bmg: [SKIP][103] ([Intel XE#6703]) -> [SKIP][104] ([Intel XE#4141]) +3 other tests skip [103]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html [104]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt.html * igt@kms_frontbuffer_tracking@fbcdrrs-argb161616f-draw-render: - shard-bmg: [SKIP][105] ([Intel XE#6703]) -> [SKIP][106] ([Intel XE#7061]) [105]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcdrrs-argb161616f-draw-render.html [106]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbcdrrs-argb161616f-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-indfb-scaledprimary: - shard-bmg: [SKIP][107] ([Intel XE#6703]) -> [SKIP][108] ([Intel XE#2313]) +4 other tests skip [107]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_frontbuffer_tracking@fbcpsr-indfb-scaledprimary.html [108]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_frontbuffer_tracking@fbcpsr-indfb-scaledprimary.html * igt@kms_psr2_sf@fbc-pr-overlay-plane-move-continuous-exceed-sf: - shard-bmg: [SKIP][109] ([Intel XE#1406] / [Intel XE#6703]) -> [SKIP][110] ([Intel XE#1406] / [Intel XE#1489]) [109]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_psr2_sf@fbc-pr-overlay-plane-move-continuous-exceed-sf.html [110]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_psr2_sf@fbc-pr-overlay-plane-move-continuous-exceed-sf.html * igt@kms_psr@psr2-suspend: - shard-bmg: [SKIP][111] ([Intel XE#1406] / [Intel XE#6703]) -> [SKIP][112] ([Intel XE#1406] / [Intel XE#2234] / [Intel XE#2850]) [111]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_psr@psr2-suspend.html [112]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_psr@psr2-suspend.html * igt@kms_psr_stress_test@invalidate-primary-flip-overlay: - shard-bmg: [SKIP][113] ([Intel XE#1406] / [Intel XE#6703]) -> [SKIP][114] ([Intel XE#1406] / [Intel XE#2414]) [113]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_psr_stress_test@invalidate-primary-flip-overlay.html [114]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_psr_stress_test@invalidate-primary-flip-overlay.html * igt@kms_rotation_crc@primary-y-tiled-reflect-x-90: - shard-bmg: [SKIP][115] ([Intel XE#6703]) -> [SKIP][116] ([Intel XE#3414] / [Intel XE#3904]) [115]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@kms_rotation_crc@primary-y-tiled-reflect-x-90.html [116]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@kms_rotation_crc@primary-y-tiled-reflect-x-90.html * igt@xe_compute@ccs-mode-basic: - shard-bmg: [SKIP][117] ([Intel XE#6703]) -> [SKIP][118] ([Intel XE#6599]) [117]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_compute@ccs-mode-basic.html [118]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_compute@ccs-mode-basic.html * igt@xe_eudebug_online@writes-caching-vram-bb-sram-target-vram: - shard-bmg: [SKIP][119] ([Intel XE#6703]) -> [SKIP][120] ([Intel XE#4837] / [Intel XE#6665]) [119]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_eudebug_online@writes-caching-vram-bb-sram-target-vram.html [120]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_eudebug_online@writes-caching-vram-bb-sram-target-vram.html * igt@xe_exec_basic@multigpu-many-execqueues-many-vm-bindexecqueue-userptr: - shard-bmg: [SKIP][121] ([Intel XE#6703]) -> [SKIP][122] ([Intel XE#2322]) [121]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_exec_basic@multigpu-many-execqueues-many-vm-bindexecqueue-userptr.html [122]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_exec_basic@multigpu-many-execqueues-many-vm-bindexecqueue-userptr.html * igt@xe_exec_multi_queue@one-queue-preempt-mode-fault-userptr: - shard-bmg: [SKIP][123] ([Intel XE#6703]) -> [SKIP][124] ([Intel XE#6874]) +4 other tests skip [123]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_exec_multi_queue@one-queue-preempt-mode-fault-userptr.html [124]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_exec_multi_queue@one-queue-preempt-mode-fault-userptr.html * igt@xe_pxp@regular-src-to-pxp-dest-rendercopy: - shard-bmg: [SKIP][125] ([Intel XE#6703]) -> [SKIP][126] ([Intel XE#4733]) [125]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d/shard-bmg-2/igt@xe_pxp@regular-src-to-pxp-dest-rendercopy.html [126]: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/shard-bmg-6/igt@xe_pxp@regular-src-to-pxp-dest-rendercopy.html [Intel XE#1124]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1124 [Intel XE#1178]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1178 [Intel XE#1406]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1406 [Intel XE#1407]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1407 [Intel XE#1420]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1420 [Intel XE#1439]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1439 [Intel XE#1489]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1489 [Intel XE#1499]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/1499 [Intel XE#2049]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2049 [Intel XE#2168]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2168 [Intel XE#2234]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2234 [Intel XE#2244]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2244 [Intel XE#2252]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2252 [Intel XE#2284]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2284 [Intel XE#2293]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2293 [Intel XE#2311]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2311 [Intel XE#2313]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2313 [Intel XE#2314]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2314 [Intel XE#2320]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2320 [Intel XE#2321]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2321 [Intel XE#2322]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2322 [Intel XE#2325]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2325 [Intel XE#2327]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2327 [Intel XE#2330]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2330 [Intel XE#2370]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2370 [Intel XE#2380]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2380 [Intel XE#2387]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2387 [Intel XE#2390]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2390 [Intel XE#2413]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2413 [Intel XE#2414]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2414 [Intel XE#2426]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2426 [Intel XE#2597]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2597 [Intel XE#2652]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2652 [Intel XE#2724]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2724 [Intel XE#2850]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2850 [Intel XE#2887]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2887 [Intel XE#2894]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2894 [Intel XE#2925]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/2925 [Intel XE#3141]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3141 [Intel XE#3304]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3304 [Intel XE#3414]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3414 [Intel XE#3432]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3432 [Intel XE#3544]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3544 [Intel XE#367]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/367 [Intel XE#3904]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3904 [Intel XE#3970]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/3970 [Intel XE#4141]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4141 [Intel XE#4298]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4298 [Intel XE#4331]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4331 [Intel XE#4459]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4459 [Intel XE#4537]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4537 [Intel XE#4733]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4733 [Intel XE#4837]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4837 [Intel XE#4943]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/4943 [Intel XE#5020]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5020 [Intel XE#5213]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5213 [Intel XE#5254]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5254 [Intel XE#5299]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5299 [Intel XE#5545]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5545 [Intel XE#5625]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5625 [Intel XE#5937]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/5937 [Intel XE#6011]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6011 [Intel XE#610]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/610 [Intel XE#6503]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6503 [Intel XE#651]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/651 [Intel XE#6557]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6557 [Intel XE#656]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/656 [Intel XE#6599]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6599 [Intel XE#6652]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6652 [Intel XE#6665]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6665 [Intel XE#6681]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6681 [Intel XE#6703]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6703 [Intel XE#6740]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6740 [Intel XE#6814]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6814 [Intel XE#6874]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6874 [Intel XE#6964]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6964 [Intel XE#6974]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/6974 [Intel XE#7023]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7023 [Intel XE#7059]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7059 [Intel XE#7061]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/7061 [Intel XE#776]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/776 [Intel XE#787]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/787 [Intel XE#836]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/836 [Intel XE#944]: https://gitlab.freedesktop.org/drm/xe/kernel/issues/944 Build changes ------------- * Linux: xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d -> xe-pw-160113v1 IGT_8701: 8701 xe-4384-733664f1edf3c01cc68e6dd0bbdb135158a98a1d: 733664f1edf3c01cc68e6dd0bbdb135158a98a1d xe-pw-160113v1: 160113v1 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/intel-xe/xe-pw-160113v1/index.html [-- Attachment #2: Type: text/html, Size: 45612 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-15 0:45 [PATCH] drm/xe: Do not preempt fence signaling CS instructions Matthew Brost ` (2 preceding siblings ...) 2026-01-15 6:13 ` ✗ Xe.CI.Full: failure " Patchwork @ 2026-01-16 9:45 ` Zbigniew Kempczyński 2026-01-16 10:12 ` Francois Dugast 2026-01-16 21:05 ` Matthew Brost 3 siblings, 2 replies; 25+ messages in thread From: Zbigniew Kempczyński @ 2026-01-16 9:45 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > If a batch buffer is complete, it makes little sense to preempt the > fence signaling instructions in the ring, as the largest portion of the > work (the batch buffer) is already done and fence signaling consists of > only a few instructions. If these instructions are preempted, the GuC > would need to perform a context switch just to signal the fence, which > is costly and delays fence signaling. Avoid this scenario by disabling > preemption immediately after the BB start instruction and re-enabling it > after executing the fence signaling instructions. > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > Cc: Carlos Santa <carlos.santa@intel.com> > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > --- > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > index a1fd99f2d539..cd645ee400b9 100644 > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > + /* Don't preempt fence signaling */ > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > + > if (job->user_fence.used) { > i = emit_flush_dw(dw, i); > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > + /* Don't preempt fence signaling */ > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > + > if (job->user_fence.used) { > i = emit_flush_dw(dw, i); > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > + /* Don't preempt fence signaling */ > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > + IGT tests which calls compute-walker, then bbe are asynchronous (don't wait for completion, pipe-control is necessary to wait on compute-walker). May you try to put arb disable after emit_render_cache_flush? -- Zbigniew > i = emit_render_cache_flush(job, dw, i); > > if (job->user_fence.used) > -- > 2.34.1 > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 9:45 ` [PATCH] " Zbigniew Kempczyński @ 2026-01-16 10:12 ` Francois Dugast 2026-01-16 16:43 ` Daniele Ceraolo Spurio 2026-01-16 21:05 ` Matthew Brost 1 sibling, 1 reply; 25+ messages in thread From: Francois Dugast @ 2026-01-16 10:12 UTC (permalink / raw) To: Zbigniew Kempczyński Cc: Matthew Brost, intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > If a batch buffer is complete, it makes little sense to preempt the > > fence signaling instructions in the ring, as the largest portion of the > > work (the batch buffer) is already done and fence signaling consists of > > only a few instructions. If these instructions are preempted, the GuC > > would need to perform a context switch just to signal the fence, which > > is costly and delays fence signaling. Avoid this scenario by disabling > > preemption immediately after the BB start instruction and re-enabling it > > after executing the fence signaling instructions. > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > Cc: Carlos Santa <carlos.santa@intel.com> > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > --- > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > index a1fd99f2d539..cd645ee400b9 100644 > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + /* Don't preempt fence signaling */ > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + > > if (job->user_fence.used) { > > i = emit_flush_dw(dw, i); > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + /* Don't preempt fence signaling */ > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + > > if (job->user_fence.used) { > > i = emit_flush_dw(dw, i); > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + /* Don't preempt fence signaling */ > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > wait for completion, pipe-control is necessary to wait on > compute-walker). > > May you try to put arb disable after emit_render_cache_flush? Thanks Zbigniew, xe_compute_preempt tests do pass with this change: diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c index cd645ee400b9..d8cceab97fa8 100644 --- a/drivers/gpu/drm/xe/xe_ring_ops.c +++ b/drivers/gpu/drm/xe/xe_ring_ops.c @@ -405,11 +405,11 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); + i = emit_render_cache_flush(job, dw, i); + /* Don't preempt fence signaling */ dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; - i = emit_render_cache_flush(job, dw, i); - if (job->user_fence.used) i = emit_store_imm_ppgtt_posted(job->user_fence.addr, job->user_fence.value, Francois > > -- > Zbigniew > > > i = emit_render_cache_flush(job, dw, i); > > > > if (job->user_fence.used) > > -- > > 2.34.1 > > ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 10:12 ` Francois Dugast @ 2026-01-16 16:43 ` Daniele Ceraolo Spurio 2026-01-16 19:51 ` Summers, Stuart 0 siblings, 1 reply; 25+ messages in thread From: Daniele Ceraolo Spurio @ 2026-01-16 16:43 UTC (permalink / raw) To: Francois Dugast, Zbigniew Kempczyński Cc: Matthew Brost, intel-xe, Carlos Santa On 1/16/2026 2:12 AM, Francois Dugast wrote: > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: >> On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: >>> If a batch buffer is complete, it makes little sense to preempt the >>> fence signaling instructions in the ring, as the largest portion of the >>> work (the batch buffer) is already done and fence signaling consists of >>> only a few instructions. If these instructions are preempted, the GuC >>> would need to perform a context switch just to signal the fence, which >>> is costly and delays fence signaling. Avoid this scenario by disabling >>> preemption immediately after the BB start instruction and re-enabling it >>> after executing the fence signaling instructions. >>> >>> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") >>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> >>> Cc: Carlos Santa <carlos.santa@intel.com> >>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>> --- >>> drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ >>> 1 file changed, 9 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c >>> index a1fd99f2d539..cd645ee400b9 100644 >>> --- a/drivers/gpu/drm/xe/xe_ring_ops.c >>> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c >>> @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc >>> >>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>> >>> + /* Don't preempt fence signaling */ >>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>> + >>> if (job->user_fence.used) { >>> i = emit_flush_dw(dw, i); >>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>> @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, >>> >>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>> >>> + /* Don't preempt fence signaling */ >>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>> + >>> if (job->user_fence.used) { >>> i = emit_flush_dw(dw, i); >>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>> @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, >>> >>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>> >>> + /* Don't preempt fence signaling */ >>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>> + >> IGT tests which calls compute-walker, then bbe are asynchronous (don't >> wait for completion, pipe-control is necessary to wait on >> compute-walker). >> >> May you try to put arb disable after emit_render_cache_flush? > Thanks Zbigniew, xe_compute_preempt tests do pass with this change: > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > index cd645ee400b9..d8cceab97fa8 100644 > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > @@ -405,11 +405,11 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > + i = emit_render_cache_flush(job, dw, i); > + The pipe control in emit_render_cache_flush is preemptable, so having that before the arb off switch invalidates what the patch is trying to do (i.e., no preemption points after the bb completes until we signal the fence). Why does disabling arbitration cause this specific pipe control to hang? Daniele > /* Don't preempt fence signaling */ > dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > - i = emit_render_cache_flush(job, dw, i); > - > if (job->user_fence.used) > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > job->user_fence.value, > > > Francois > >> -- >> Zbigniew >> >>> i = emit_render_cache_flush(job, dw, i); >>> >>> if (job->user_fence.used) >>> -- >>> 2.34.1 >>> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 16:43 ` Daniele Ceraolo Spurio @ 2026-01-16 19:51 ` Summers, Stuart 2026-01-16 20:44 ` Matthew Brost 0 siblings, 1 reply; 25+ messages in thread From: Summers, Stuart @ 2026-01-16 19:51 UTC (permalink / raw) To: Kempczynski, Zbigniew, Ceraolo Spurio, Daniele, Dugast, Francois Cc: intel-xe@lists.freedesktop.org, Brost, Matthew, Santa, Carlos On Fri, 2026-01-16 at 08:43 -0800, Daniele Ceraolo Spurio wrote: > > > On 1/16/2026 2:12 AM, Francois Dugast wrote: > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński > > wrote: > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > If a batch buffer is complete, it makes little sense to preempt > > > > the > > > > fence signaling instructions in the ring, as the largest > > > > portion of the > > > > work (the batch buffer) is already done and fence signaling > > > > consists of > > > > only a few instructions. If these instructions are preempted, > > > > the GuC > > > > would need to perform a context switch just to signal the > > > > fence, which > > > > is costly and delays fence signaling. Avoid this scenario by > > > > disabling > > > > preemption immediately after the BB start instruction and re- > > > > enabling it > > > > after executing the fence signaling instructions. > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for > > > > Intel GPUs") > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > --- > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct > > > > xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + /* Don't preempt fence signaling */ > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > + > > > > if (job->user_fence.used) { > > > > i = emit_flush_dw(dw, i); > > > > i = emit_store_imm_ppgtt_posted(job- > > > > >user_fence.addr, > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct > > > > xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + /* Don't preempt fence signaling */ > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > + > > > > if (job->user_fence.used) { > > > > i = emit_flush_dw(dw, i); > > > > i = emit_store_imm_ppgtt_posted(job- > > > > >user_fence.addr, > > > > @@ -399,6 +405,9 @@ static void > > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + /* Don't preempt fence signaling */ > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > + > > > IGT tests which calls compute-walker, then bbe are asynchronous > > > (don't > > > wait for completion, pipe-control is necessary to wait on > > > compute-walker). > > > > > > May you try to put arb disable after emit_render_cache_flush? > > Thanks Zbigniew, xe_compute_preempt tests do pass with this change: > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > index cd645ee400b9..d8cceab97fa8 100644 > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > @@ -405,11 +405,11 @@ static void > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + i = emit_render_cache_flush(job, dw, i); > > + > > The pipe control in emit_render_cache_flush is preemptable, so having > that before the arb off switch invalidates what the patch is trying > to > do (i.e., no preemption points after the bb completes until we signal > the fence). > > Why does disabling arbitration cause this specific pipe control to > hang? Are we enabling/disabling preemption from the batch too? It seems like the batch preemption control should be owned by the user and not rely on the ring configuration here (which might have other intention as seen here). Also would be interesting to know if the compute/render UMD compliance tests are passing with this change. Thanks, Stuart > > Daniele > > > /* Don't preempt fence signaling */ > > dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > - i = emit_render_cache_flush(job, dw, i); > > - > > if (job->user_fence.used) > > i = emit_store_imm_ppgtt_posted(job- > > >user_fence.addr, > > job- > > >user_fence.value, > > > > > > Francois > > > > > -- > > > Zbigniew > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > if (job->user_fence.used) > > > > -- > > > > 2.34.1 > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 19:51 ` Summers, Stuart @ 2026-01-16 20:44 ` Matthew Brost 2026-01-16 21:07 ` Summers, Stuart 0 siblings, 1 reply; 25+ messages in thread From: Matthew Brost @ 2026-01-16 20:44 UTC (permalink / raw) To: Summers, Stuart Cc: Kempczynski, Zbigniew, Ceraolo Spurio, Daniele, Dugast, Francois, intel-xe@lists.freedesktop.org, Santa, Carlos On Fri, Jan 16, 2026 at 12:51:46PM -0700, Summers, Stuart wrote: > On Fri, 2026-01-16 at 08:43 -0800, Daniele Ceraolo Spurio wrote: > > > > > > On 1/16/2026 2:12 AM, Francois Dugast wrote: > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński > > > wrote: > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > If a batch buffer is complete, it makes little sense to preempt > > > > > the > > > > > fence signaling instructions in the ring, as the largest > > > > > portion of the > > > > > work (the batch buffer) is already done and fence signaling > > > > > consists of > > > > > only a few instructions. If these instructions are preempted, > > > > > the GuC > > > > > would need to perform a context switch just to signal the > > > > > fence, which > > > > > is costly and delays fence signaling. Avoid this scenario by > > > > > disabling > > > > > preemption immediately after the BB start instruction and re- > > > > > enabling it > > > > > after executing the fence signaling instructions. > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for > > > > > Intel GPUs") > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > --- > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct > > > > > xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > >user_fence.addr, > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct > > > > > xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > >user_fence.addr, > > > > > @@ -399,6 +405,9 @@ static void > > > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > IGT tests which calls compute-walker, then bbe are asynchronous > > > > (don't > > > > wait for completion, pipe-control is necessary to wait on > > > > compute-walker). > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > Thanks Zbigniew, xe_compute_preempt tests do pass with this change: > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > index cd645ee400b9..d8cceab97fa8 100644 > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > @@ -405,11 +405,11 @@ static void > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + i = emit_render_cache_flush(job, dw, i); > > > + Yes, I also confirmed that emit_render_cache_flush() is the problematic instruction that hangs when preemption is disabled. > > > > The pipe control in emit_render_cache_flush is preemptable, so having > > that before the arb off switch invalidates what the patch is trying > > to > > do (i.e., no preemption points after the bb completes until we signal > > the fence). Yes, disabling preemption after emit_render_cache_flush() makes the render/compute engine change in this series useless, as emit_render_cache_flush() is preemptable and the goal of the series is to avoid preempting if the BB is done in the fence signaling instructions. > > > > Why does disabling arbitration cause this specific pipe control to > > hang? This is what we need to figure out. I looked at i915, and they have preemption disabled around sections very similar to emit_render_cache_flush(). I ’m raising this up the management chain to see if we can find an owner to debug it, and perhaps even get an SV trace to figure out what is going on. I believe this series, if working, would make our stack perform better, so it would be good to get something functional here. > > Are we enabling/disabling preemption from the batch too? It seems like We are not disabling preemption in the batch, only in the fence signaling. > the batch preemption control should be owned by the user and not rely > on the ring configuration here (which might have other intention as > seen here). > > Also would be interesting to know if the compute/render UMD compliance > tests are passing with this change. > Agree. Matt > Thanks, > Stuart > > > > > Daniele > > > > > /* Don't preempt fence signaling */ > > > dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > - i = emit_render_cache_flush(job, dw, i); > > > - > > > if (job->user_fence.used) > > > i = emit_store_imm_ppgtt_posted(job- > > > >user_fence.addr, > > > job- > > > >user_fence.value, > > > > > > > > > Francois > > > > > > > -- > > > > Zbigniew > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > if (job->user_fence.used) > > > > > -- > > > > > 2.34.1 > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 20:44 ` Matthew Brost @ 2026-01-16 21:07 ` Summers, Stuart 2026-01-16 21:19 ` Matthew Brost 0 siblings, 1 reply; 25+ messages in thread From: Summers, Stuart @ 2026-01-16 21:07 UTC (permalink / raw) To: Brost, Matthew Cc: Kempczynski, Zbigniew, intel-xe@lists.freedesktop.org, Ceraolo Spurio, Daniele, Santa, Carlos, Dugast, Francois On Fri, 2026-01-16 at 12:44 -0800, Matthew Brost wrote: > On Fri, Jan 16, 2026 at 12:51:46PM -0700, Summers, Stuart wrote: > > On Fri, 2026-01-16 at 08:43 -0800, Daniele Ceraolo Spurio wrote: > > > > > > > > > On 1/16/2026 2:12 AM, Francois Dugast wrote: > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński > > > > wrote: > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost > > > > > wrote: > > > > > > If a batch buffer is complete, it makes little sense to > > > > > > preempt > > > > > > the > > > > > > fence signaling instructions in the ring, as the largest > > > > > > portion of the > > > > > > work (the batch buffer) is already done and fence signaling > > > > > > consists of > > > > > > only a few instructions. If these instructions are > > > > > > preempted, > > > > > > the GuC > > > > > > would need to perform a context switch just to signal the > > > > > > fence, which > > > > > > is costly and delays fence signaling. Avoid this scenario > > > > > > by > > > > > > disabling > > > > > > preemption immediately after the BB start instruction and > > > > > > re- > > > > > > enabling it > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver > > > > > > for > > > > > > Intel GPUs") > > > > > > Cc: Daniele Ceraolo Spurio > > > > > > <daniele.ceraolospurio@intel.com> > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > --- > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > @@ -282,6 +282,9 @@ static void > > > > > > __emit_job_gen12_simple(struct > > > > > > xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > if (job->user_fence.used) { > > > > > > i = emit_flush_dw(dw, i); > > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > > > user_fence.addr, > > > > > > @@ -347,6 +350,9 @@ static void > > > > > > __emit_job_gen12_video(struct > > > > > > xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > if (job->user_fence.used) { > > > > > > i = emit_flush_dw(dw, i); > > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > > > user_fence.addr, > > > > > > @@ -399,6 +405,9 @@ static void > > > > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > IGT tests which calls compute-walker, then bbe are > > > > > asynchronous > > > > > (don't > > > > > wait for completion, pipe-control is necessary to wait on > > > > > compute-walker). > > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > Thanks Zbigniew, xe_compute_preempt tests do pass with this > > > > change: > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > index cd645ee400b9..d8cceab97fa8 100644 > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > @@ -405,11 +405,11 @@ static void > > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + i = emit_render_cache_flush(job, dw, i); > > > > + > > Yes, I also confirmed that emit_render_cache_flush() is the > problematic > instruction that hangs when preemption is disabled. > > > > > > > The pipe control in emit_render_cache_flush is preemptable, so > > > having > > > that before the arb off switch invalidates what the patch is > > > trying > > > to > > > do (i.e., no preemption points after the bb completes until we > > > signal > > > the fence). > > Yes, disabling preemption after emit_render_cache_flush() makes the > render/compute engine change in this series useless, as > emit_render_cache_flush() is preemptable and the goal of the series > is > to avoid preempting if the BB is done in the fence signaling > instructions. > > > > > > > Why does disabling arbitration cause this specific pipe control > > > to > > > hang? > > This is what we need to figure out. I looked at i915, and they have > preemption disabled around sections very similar to > emit_render_cache_flush(). > > I ’m raising this up the management chain to see if we can find an > owner > to debug it, and perhaps even get an SV trace to figure out what is > going on. I believe this series, if working, would make our stack > perform > better, so it would be good to get something functional here. > > > > > Are we enabling/disabling preemption from the batch too? It seems > > like > > We are not disabling preemption in the batch, only in the fence > signaling. This was exactly my point. From bspec, MI_ARB_ON_OFF "remains disabled until re-enabled through use of this command." So if we are explicitly disabling before the batch is running, we need to explicitly re-enable if we want to be able to preempt later for whatever reason. That said, this command is also marked privileged, so honestly we probably want to make sure this is enabled for batches that might need preemption. MI_ARB_CHECK on the other hand indicates it can be "programmed in a ring buffer or batch buffer". I don't think there's a way we can only apply MI_ARB_ON_OFF only to the fence signaling and not the batch signaling. Thanks, Stuart > > > the batch preemption control should be owned by the user and not > > rely > > on the ring configuration here (which might have other intention as > > seen here). > > > > Also would be interesting to know if the compute/render UMD > > compliance > > tests are passing with this change. > > > > Agree. > > Matt > > > Thanks, > > Stuart > > > > > > > > Daniele > > > > > > > /* Don't preempt fence signaling */ > > > > dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > > - i = emit_render_cache_flush(job, dw, i); > > > > - > > > > if (job->user_fence.used) > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > user_fence.addr, > > > > job- > > > > > user_fence.value, > > > > > > > > > > > > Francois > > > > > > > > > -- > > > > > Zbigniew > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > > > if (job->user_fence.used) > > > > > > -- > > > > > > 2.34.1 > > > > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 21:07 ` Summers, Stuart @ 2026-01-16 21:19 ` Matthew Brost 0 siblings, 0 replies; 25+ messages in thread From: Matthew Brost @ 2026-01-16 21:19 UTC (permalink / raw) To: Summers, Stuart Cc: Kempczynski, Zbigniew, intel-xe@lists.freedesktop.org, Ceraolo Spurio, Daniele, Santa, Carlos, Dugast, Francois On Fri, Jan 16, 2026 at 02:07:57PM -0700, Summers, Stuart wrote: > On Fri, 2026-01-16 at 12:44 -0800, Matthew Brost wrote: > > On Fri, Jan 16, 2026 at 12:51:46PM -0700, Summers, Stuart wrote: > > > On Fri, 2026-01-16 at 08:43 -0800, Daniele Ceraolo Spurio wrote: > > > > > > > > > > > > On 1/16/2026 2:12 AM, Francois Dugast wrote: > > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński > > > > > wrote: > > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost > > > > > > wrote: > > > > > > > If a batch buffer is complete, it makes little sense to > > > > > > > preempt > > > > > > > the > > > > > > > fence signaling instructions in the ring, as the largest > > > > > > > portion of the > > > > > > > work (the batch buffer) is already done and fence signaling > > > > > > > consists of > > > > > > > only a few instructions. If these instructions are > > > > > > > preempted, > > > > > > > the GuC > > > > > > > would need to perform a context switch just to signal the > > > > > > > fence, which > > > > > > > is costly and delays fence signaling. Avoid this scenario > > > > > > > by > > > > > > > disabling > > > > > > > preemption immediately after the BB start instruction and > > > > > > > re- > > > > > > > enabling it > > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver > > > > > > > for > > > > > > > Intel GPUs") > > > > > > > Cc: Daniele Ceraolo Spurio > > > > > > > <daniele.ceraolospurio@intel.com> > > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > > --- > > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > @@ -282,6 +282,9 @@ static void > > > > > > > __emit_job_gen12_simple(struct > > > > > > > xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > if (job->user_fence.used) { > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > > > > user_fence.addr, > > > > > > > @@ -347,6 +350,9 @@ static void > > > > > > > __emit_job_gen12_video(struct > > > > > > > xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > if (job->user_fence.used) { > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > > > > user_fence.addr, > > > > > > > @@ -399,6 +405,9 @@ static void > > > > > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > IGT tests which calls compute-walker, then bbe are > > > > > > asynchronous > > > > > > (don't > > > > > > wait for completion, pipe-control is necessary to wait on > > > > > > compute-walker). > > > > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > Thanks Zbigniew, xe_compute_preempt tests do pass with this > > > > > change: > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > index cd645ee400b9..d8cceab97fa8 100644 > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > @@ -405,11 +405,11 @@ static void > > > > > __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + i = emit_render_cache_flush(job, dw, i); > > > > > + > > > > Yes, I also confirmed that emit_render_cache_flush() is the > > problematic > > instruction that hangs when preemption is disabled. > > > > > > > > > > The pipe control in emit_render_cache_flush is preemptable, so > > > > having > > > > that before the arb off switch invalidates what the patch is > > > > trying > > > > to > > > > do (i.e., no preemption points after the bb completes until we > > > > signal > > > > the fence). > > > > Yes, disabling preemption after emit_render_cache_flush() makes the > > render/compute engine change in this series useless, as > > emit_render_cache_flush() is preemptable and the goal of the series > > is > > to avoid preempting if the BB is done in the fence signaling > > instructions. > > > > > > > > > > Why does disabling arbitration cause this specific pipe control > > > > to > > > > hang? > > > > This is what we need to figure out. I looked at i915, and they have > > preemption disabled around sections very similar to > > emit_render_cache_flush(). > > > > I ’m raising this up the management chain to see if we can find an > > owner > > to debug it, and perhaps even get an SV trace to figure out what is > > going on. I believe this series, if working, would make our stack > > perform > > better, so it would be good to get something functional here. > > > > > > > > Are we enabling/disabling preemption from the batch too? It seems > > > like > > > > We are not disabling preemption in the batch, only in the fence > > signaling. > > This was exactly my point. From bspec, MI_ARB_ON_OFF "remains disabled > until re-enabled through use of this command." So if we are explicitly > disabling before the batch is running, we need to explicitly re-enable > if we want to be able to preempt later for whatever reason. > We enable preemption after signaling the fence. See emit_user_interrupt(). > That said, this command is also marked privileged, so honestly we > probably want to make sure this is enabled for batches that might need > preemption. MI_ARB_CHECK on the other hand indicates it can be > "programmed in a ring buffer or batch buffer". I don't think we ever want to disable preemption in the BB. Mesa relies on object level preemption which is preemption in the middile of the batch. > > I don't think there's a way we can only apply MI_ARB_ON_OFF only to the > fence signaling and not the batch signaling. > The i915 disables preemption in fence signaling like we try to do here. It seems to work in the i915 but we immediately hit CI issues in Xe. This the part we need to figure out. Matt > Thanks, > Stuart > > > > > > the batch preemption control should be owned by the user and not > > > rely > > > on the ring configuration here (which might have other intention as > > > seen here). > > > > > > Also would be interesting to know if the compute/render UMD > > > compliance > > > tests are passing with this change. > > > > > > > Agree. > > > > Matt > > > > > Thanks, > > > Stuart > > > > > > > > > > > Daniele > > > > > > > > > /* Don't preempt fence signaling */ > > > > > dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > > > > - i = emit_render_cache_flush(job, dw, i); > > > > > - > > > > > if (job->user_fence.used) > > > > > i = emit_store_imm_ppgtt_posted(job- > > > > > > user_fence.addr, > > > > > job- > > > > > > user_fence.value, > > > > > > > > > > > > > > > Francois > > > > > > > > > > > -- > > > > > > Zbigniew > > > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > > > > > if (job->user_fence.used) > > > > > > > -- > > > > > > > 2.34.1 > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 9:45 ` [PATCH] " Zbigniew Kempczyński 2026-01-16 10:12 ` Francois Dugast @ 2026-01-16 21:05 ` Matthew Brost 2026-01-19 12:01 ` Zbigniew Kempczyński 1 sibling, 1 reply; 25+ messages in thread From: Matthew Brost @ 2026-01-16 21:05 UTC (permalink / raw) To: Zbigniew Kempczyński; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > If a batch buffer is complete, it makes little sense to preempt the > > fence signaling instructions in the ring, as the largest portion of the > > work (the batch buffer) is already done and fence signaling consists of > > only a few instructions. If these instructions are preempted, the GuC > > would need to perform a context switch just to signal the fence, which > > is costly and delays fence signaling. Avoid this scenario by disabling > > preemption immediately after the BB start instruction and re-enabling it > > after executing the fence signaling instructions. > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > Cc: Carlos Santa <carlos.santa@intel.com> > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > --- > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > 1 file changed, 9 insertions(+) > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > index a1fd99f2d539..cd645ee400b9 100644 > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + /* Don't preempt fence signaling */ > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + > > if (job->user_fence.used) { > > i = emit_flush_dw(dw, i); > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + /* Don't preempt fence signaling */ > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + > > if (job->user_fence.used) { > > i = emit_flush_dw(dw, i); > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > + /* Don't preempt fence signaling */ > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > + > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > wait for completion, pipe-control is necessary to wait on > compute-walker). > This asynchronous behavior may explain things. Is this a common use case? Also do you know if render engines have similar asynchronous behaviors or is this specific to compute engines? Lastly, the i915 disables preemption on both render / compute engines immediately after the BB before emitting the pipe control. Is this async behavior a new few feature in Xe2 parts which only the Xe driver supports? This might explain why the i915 works and Xe does not. Matt > May you try to put arb disable after emit_render_cache_flush? > > -- > Zbigniew > > > i = emit_render_cache_flush(job, dw, i); > > > > if (job->user_fence.used) > > -- > > 2.34.1 > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-16 21:05 ` Matthew Brost @ 2026-01-19 12:01 ` Zbigniew Kempczyński 2026-01-20 21:10 ` Daniele Ceraolo Spurio 2026-01-20 21:11 ` Matthew Brost 0 siblings, 2 replies; 25+ messages in thread From: Zbigniew Kempczyński @ 2026-01-19 12:01 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > If a batch buffer is complete, it makes little sense to preempt the > > > fence signaling instructions in the ring, as the largest portion of the > > > work (the batch buffer) is already done and fence signaling consists of > > > only a few instructions. If these instructions are preempted, the GuC > > > would need to perform a context switch just to signal the fence, which > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > preemption immediately after the BB start instruction and re-enabling it > > > after executing the fence signaling instructions. > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > --- > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > index a1fd99f2d539..cd645ee400b9 100644 > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + /* Don't preempt fence signaling */ > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > + > > > if (job->user_fence.used) { > > > i = emit_flush_dw(dw, i); > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + /* Don't preempt fence signaling */ > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > + > > > if (job->user_fence.used) { > > > i = emit_flush_dw(dw, i); > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + /* Don't preempt fence signaling */ > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > + > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > wait for completion, pipe-control is necessary to wait on > > compute-walker). > > > > This asynchronous behavior may explain things. Is this a common use > case? Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are not doing this relying on kmd. > > Also do you know if render engines have similar asynchronous behaviors > or is this specific to compute engines? I don't know, I think Mesa folks may know the answer. > > Lastly, the i915 disables preemption on both render / compute engines > immediately after the BB before emitting the pipe control. Is this async > behavior a new few feature in Xe2 parts which only the Xe driver > supports? This might explain why the i915 works and Xe does not. Test exercises WMTP and this is supported starting at Xe2+. Probably what test is doing has a meaning in this case. First compute-walker submits kernel which loops until it will observe some memory write. Second job executes compute-walker with kernel which does some quick job. But first occupies all EU's so second job can be preempted only when preemption occurs and SIP will be executed. So if we disable preemption immediately we submit compute-walker I think we have no change to enter SIP and switch. Even if I add pipe-control to batch level according to Daniele comment job it is still preemptable and we move pipe-control location from kmd -> batch level.. -- Zbigniew > > Matt > > > May you try to put arb disable after emit_render_cache_flush? > > > > -- > > Zbigniew > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > if (job->user_fence.used) > > > -- > > > 2.34.1 > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-19 12:01 ` Zbigniew Kempczyński @ 2026-01-20 21:10 ` Daniele Ceraolo Spurio 2026-01-20 21:26 ` Matthew Brost 2026-01-22 9:22 ` Zbigniew Kempczyński 2026-01-20 21:11 ` Matthew Brost 1 sibling, 2 replies; 25+ messages in thread From: Daniele Ceraolo Spurio @ 2026-01-20 21:10 UTC (permalink / raw) To: Zbigniew Kempczyński, Matthew Brost; +Cc: intel-xe, Carlos Santa On 1/19/2026 4:01 AM, Zbigniew Kempczyński wrote: > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: >> On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: >>> On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: >>>> If a batch buffer is complete, it makes little sense to preempt the >>>> fence signaling instructions in the ring, as the largest portion of the >>>> work (the batch buffer) is already done and fence signaling consists of >>>> only a few instructions. If these instructions are preempted, the GuC >>>> would need to perform a context switch just to signal the fence, which >>>> is costly and delays fence signaling. Avoid this scenario by disabling >>>> preemption immediately after the BB start instruction and re-enabling it >>>> after executing the fence signaling instructions. >>>> >>>> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") >>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> >>>> Cc: Carlos Santa <carlos.santa@intel.com> >>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>>> --- >>>> drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ >>>> 1 file changed, 9 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c >>>> index a1fd99f2d539..cd645ee400b9 100644 >>>> --- a/drivers/gpu/drm/xe/xe_ring_ops.c >>>> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c >>>> @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc >>>> >>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>> >>>> + /* Don't preempt fence signaling */ >>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>> + >>>> if (job->user_fence.used) { >>>> i = emit_flush_dw(dw, i); >>>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>>> @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, >>>> >>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>> >>>> + /* Don't preempt fence signaling */ >>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>> + >>>> if (job->user_fence.used) { >>>> i = emit_flush_dw(dw, i); >>>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>>> @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, >>>> >>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>> >>>> + /* Don't preempt fence signaling */ >>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>> + >>> IGT tests which calls compute-walker, then bbe are asynchronous (don't >>> wait for completion, pipe-control is necessary to wait on >>> compute-walker). >>> >> This asynchronous behavior may explain things. Is this a common use >> case? > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > not doing this relying on kmd. > >> Also do you know if render engines have similar asynchronous behaviors >> or is this specific to compute engines? > I don't know, I think Mesa folks may know the answer. > >> Lastly, the i915 disables preemption on both render / compute engines >> immediately after the BB before emitting the pipe control. Is this async >> behavior a new few feature in Xe2 parts which only the Xe driver >> supports? This might explain why the i915 works and Xe does not. > Test exercises WMTP and this is supported starting at Xe2+. Probably > what test is doing has a meaning in this case. First compute-walker > submits kernel which loops until it will observe some memory write. > Second job executes compute-walker with kernel which does some quick job. > But first occupies all EU's so second job can be preempted only when > preemption occurs and SIP will be executed. So if we disable preemption > immediately we submit compute-walker I think we have no change to enter > SIP and switch. Even if I add pipe-control to batch level according > to Daniele comment job it is still preemptable and we move pipe-control > location from kmd -> batch level.. So basically the test requires a preemption but does not put any preemption points within the batch? I'd argue that the fact that the test works at all is by chance, because the kernel just happens to add a preemption point after the BB and the batch doesn't wait for the results before completing. IMO it should be ok to go ahead with this patch and rework the test, but we probably need an ack from a maintainer because something that worked before (even if just by chance) is not going to work anymore. Daniele > > -- > Zbigniew > >> Matt >> >>> May you try to put arb disable after emit_render_cache_flush? >>> >>> -- >>> Zbigniew >>> >>>> i = emit_render_cache_flush(job, dw, i); >>>> >>>> if (job->user_fence.used) >>>> -- >>>> 2.34.1 >>>> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-20 21:10 ` Daniele Ceraolo Spurio @ 2026-01-20 21:26 ` Matthew Brost 2026-01-20 21:27 ` Matthew Brost 2026-01-22 9:22 ` Zbigniew Kempczyński 1 sibling, 1 reply; 25+ messages in thread From: Matthew Brost @ 2026-01-20 21:26 UTC (permalink / raw) To: Daniele Ceraolo Spurio; +Cc: Zbigniew Kempczyński, intel-xe, Carlos Santa On Tue, Jan 20, 2026 at 01:10:20PM -0800, Daniele Ceraolo Spurio wrote: > > > On 1/19/2026 4:01 AM, Zbigniew Kempczyński wrote: > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > would need to perform a context switch just to signal the fence, which > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > after executing the fence signaling instructions. > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > --- > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > wait for completion, pipe-control is necessary to wait on > > > > compute-walker). > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > case? > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > not doing this relying on kmd. > > > > > Also do you know if render engines have similar asynchronous behaviors > > > or is this specific to compute engines? > > I don't know, I think Mesa folks may know the answer. > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > immediately after the BB before emitting the pipe control. Is this async > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > supports? This might explain why the i915 works and Xe does not. > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > what test is doing has a meaning in this case. First compute-walker > > submits kernel which loops until it will observe some memory write. > > Second job executes compute-walker with kernel which does some quick job. > > But first occupies all EU's so second job can be preempted only when > > preemption occurs and SIP will be executed. So if we disable preemption > > immediately we submit compute-walker I think we have no change to enter > > SIP and switch. Even if I add pipe-control to batch level according > > to Daniele comment job it is still preemptable and we move pipe-control > > location from kmd -> batch level.. > > So basically the test requires a preemption but does not put any preemption > points within the batch? I'd argue that the fact that the test works at all > is by chance, because the kernel just happens to add a preemption point > after the BB and the batch doesn't wait for the results before completing. > IMO it should be ok to go ahead with this patch and rework the test, but we > probably need an ack from a maintainer because something that worked before So my reply to Zbigniew. I'd like to know if this test works with pipe controls in the batch. Then I believe we need to confirm: - Compute runtime inserts pipe controls in the batch - Get extensive CI runs of compute runtime, Mesa, and application As long as we haven't regressed anything, we should be good to merge this behavior change. If not, then we stuck with the existing behavior but perhaps could add an opt-in exec queue flag to create the behavior. Matt > (even if just by chance) is not going to work anymore. > > Daniele > > > > > -- > > Zbigniew > > > > > Matt > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > -- > > > > Zbigniew > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > if (job->user_fence.used) > > > > > -- > > > > > 2.34.1 > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-20 21:26 ` Matthew Brost @ 2026-01-20 21:27 ` Matthew Brost 0 siblings, 0 replies; 25+ messages in thread From: Matthew Brost @ 2026-01-20 21:27 UTC (permalink / raw) To: Daniele Ceraolo Spurio; +Cc: Zbigniew Kempczyński, intel-xe, Carlos Santa On Tue, Jan 20, 2026 at 01:26:01PM -0800, Matthew Brost wrote: > On Tue, Jan 20, 2026 at 01:10:20PM -0800, Daniele Ceraolo Spurio wrote: > > > > > > On 1/19/2026 4:01 AM, Zbigniew Kempczyński wrote: > > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > > would need to perform a context switch just to signal the fence, which > > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > --- > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > if (job->user_fence.used) { > > > > > > i = emit_flush_dw(dw, i); > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > if (job->user_fence.used) { > > > > > > i = emit_flush_dw(dw, i); > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > > wait for completion, pipe-control is necessary to wait on > > > > > compute-walker). > > > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > > case? > > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > > not doing this relying on kmd. > > > > > > > Also do you know if render engines have similar asynchronous behaviors > > > > or is this specific to compute engines? > > > I don't know, I think Mesa folks may know the answer. > > > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > > immediately after the BB before emitting the pipe control. Is this async > > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > > supports? This might explain why the i915 works and Xe does not. > > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > > what test is doing has a meaning in this case. First compute-walker > > > submits kernel which loops until it will observe some memory write. > > > Second job executes compute-walker with kernel which does some quick job. > > > But first occupies all EU's so second job can be preempted only when > > > preemption occurs and SIP will be executed. So if we disable preemption > > > immediately we submit compute-walker I think we have no change to enter > > > SIP and switch. Even if I add pipe-control to batch level according > > > to Daniele comment job it is still preemptable and we move pipe-control > > > location from kmd -> batch level.. > > > > So basically the test requires a preemption but does not put any preemption > > points within the batch? I'd argue that the fact that the test works at all > > is by chance, because the kernel just happens to add a preemption point > > after the BB and the batch doesn't wait for the results before completing. > > IMO it should be ok to go ahead with this patch and rework the test, but we > > probably need an ack from a maintainer because something that worked before > > So my reply to Zbigniew. I'd like to know if this test works with pipe > controls in the batch. > > Then I believe we need to confirm: > > - Compute runtime inserts pipe controls in the batch > - Get extensive CI runs of compute runtime, Mesa, and application > > As long as we haven't regressed anything, we should be good to merge > this behavior change. > > If not, then we stuck with the existing behavior but perhaps could add > an opt-in exec queue flag to create the behavior. > Typo: s/create/change Matt > Matt > > > (even if just by chance) is not going to work anymore. > > > > Daniele > > > > > > > > -- > > > Zbigniew > > > > > > > Matt > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > > > -- > > > > > Zbigniew > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > if (job->user_fence.used) > > > > > > -- > > > > > > 2.34.1 > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-20 21:10 ` Daniele Ceraolo Spurio 2026-01-20 21:26 ` Matthew Brost @ 2026-01-22 9:22 ` Zbigniew Kempczyński 2026-01-22 17:47 ` Daniele Ceraolo Spurio 1 sibling, 1 reply; 25+ messages in thread From: Zbigniew Kempczyński @ 2026-01-22 9:22 UTC (permalink / raw) To: Daniele Ceraolo Spurio; +Cc: Matthew Brost, intel-xe, Carlos Santa On Tue, Jan 20, 2026 at 01:10:20PM -0800, Daniele Ceraolo Spurio wrote: > > > On 1/19/2026 4:01 AM, Zbigniew Kempczyński wrote: > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > would need to perform a context switch just to signal the fence, which > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > after executing the fence signaling instructions. > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > --- > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > wait for completion, pipe-control is necessary to wait on > > > > compute-walker). > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > case? > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > not doing this relying on kmd. > > > > > Also do you know if render engines have similar asynchronous behaviors > > > or is this specific to compute engines? > > I don't know, I think Mesa folks may know the answer. > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > immediately after the BB before emitting the pipe control. Is this async > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > supports? This might explain why the i915 works and Xe does not. > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > what test is doing has a meaning in this case. First compute-walker > > submits kernel which loops until it will observe some memory write. > > Second job executes compute-walker with kernel which does some quick job. > > But first occupies all EU's so second job can be preempted only when > > preemption occurs and SIP will be executed. So if we disable preemption > > immediately we submit compute-walker I think we have no change to enter > > SIP and switch. Even if I add pipe-control to batch level according > > to Daniele comment job it is still preemptable and we move pipe-control > > location from kmd -> batch level.. > > So basically the test requires a preemption but does not put any preemption > points within the batch? I'd argue that the fact that the test works at all > is by chance, because the kernel just happens to add a preemption point > after the BB and the batch doesn't wait for the results before completing. > IMO it should be ok to go ahead with this patch and rework the test, but we > probably need an ack from a maintainer because something that worked before > (even if just by chance) is not going to work anymore. Why user would need to explicitely add preemption points within batch? It's imo driver responsibility to enable/disable preemption and additional preemption points in the batch may change preemption distribution, not the ability to preempt. Compute-walkers we already had in IGT tests (gpgpu-fill) were called in fire-and-forget mode leaving pipe-control to kmd. Code written before I joined the team were written with this assumption and I haven't seen any objection to this approach. So I assumed kmd will take care of job completion when batch returns to ring. If this won't apply anymore we just need to change IGT tests to add pipe-control in the batch. And ensure nothing else is broken (compute / mesa). I'm going to send pipe-control patch to IGTs, imo it will fix the WMTP case. Sync wait at the batch level should keep execution with preemption enabled allowing to call SIP and switch the context. -- Zbigniew > > Daniele > > > > > -- > > Zbigniew > > > > > Matt > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > -- > > > > Zbigniew > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > if (job->user_fence.used) > > > > > -- > > > > > 2.34.1 > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-22 9:22 ` Zbigniew Kempczyński @ 2026-01-22 17:47 ` Daniele Ceraolo Spurio 2026-01-27 20:14 ` Matthew Brost 0 siblings, 1 reply; 25+ messages in thread From: Daniele Ceraolo Spurio @ 2026-01-22 17:47 UTC (permalink / raw) To: Zbigniew Kempczyński; +Cc: Matthew Brost, intel-xe, Carlos Santa On 1/22/2026 1:22 AM, Zbigniew Kempczyński wrote: > On Tue, Jan 20, 2026 at 01:10:20PM -0800, Daniele Ceraolo Spurio wrote: >> >> On 1/19/2026 4:01 AM, Zbigniew Kempczyński wrote: >>> On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: >>>> On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: >>>>> On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: >>>>>> If a batch buffer is complete, it makes little sense to preempt the >>>>>> fence signaling instructions in the ring, as the largest portion of the >>>>>> work (the batch buffer) is already done and fence signaling consists of >>>>>> only a few instructions. If these instructions are preempted, the GuC >>>>>> would need to perform a context switch just to signal the fence, which >>>>>> is costly and delays fence signaling. Avoid this scenario by disabling >>>>>> preemption immediately after the BB start instruction and re-enabling it >>>>>> after executing the fence signaling instructions. >>>>>> >>>>>> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") >>>>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> >>>>>> Cc: Carlos Santa <carlos.santa@intel.com> >>>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>>>>> --- >>>>>> drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ >>>>>> 1 file changed, 9 insertions(+) >>>>>> >>>>>> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c >>>>>> index a1fd99f2d539..cd645ee400b9 100644 >>>>>> --- a/drivers/gpu/drm/xe/xe_ring_ops.c >>>>>> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c >>>>>> @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc >>>>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>>>> + /* Don't preempt fence signaling */ >>>>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>>>> + >>>>>> if (job->user_fence.used) { >>>>>> i = emit_flush_dw(dw, i); >>>>>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>>>>> @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, >>>>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>>>> + /* Don't preempt fence signaling */ >>>>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>>>> + >>>>>> if (job->user_fence.used) { >>>>>> i = emit_flush_dw(dw, i); >>>>>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>>>>> @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, >>>>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>>>> + /* Don't preempt fence signaling */ >>>>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>>>> + >>>>> IGT tests which calls compute-walker, then bbe are asynchronous (don't >>>>> wait for completion, pipe-control is necessary to wait on >>>>> compute-walker). >>>>> >>>> This asynchronous behavior may explain things. Is this a common use >>>> case? >>> Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are >>> not doing this relying on kmd. >>> >>>> Also do you know if render engines have similar asynchronous behaviors >>>> or is this specific to compute engines? >>> I don't know, I think Mesa folks may know the answer. >>> >>>> Lastly, the i915 disables preemption on both render / compute engines >>>> immediately after the BB before emitting the pipe control. Is this async >>>> behavior a new few feature in Xe2 parts which only the Xe driver >>>> supports? This might explain why the i915 works and Xe does not. >>> Test exercises WMTP and this is supported starting at Xe2+. Probably >>> what test is doing has a meaning in this case. First compute-walker >>> submits kernel which loops until it will observe some memory write. >>> Second job executes compute-walker with kernel which does some quick job. >>> But first occupies all EU's so second job can be preempted only when >>> preemption occurs and SIP will be executed. So if we disable preemption >>> immediately we submit compute-walker I think we have no change to enter >>> SIP and switch. Even if I add pipe-control to batch level according >>> to Daniele comment job it is still preemptable and we move pipe-control >>> location from kmd -> batch level.. >> So basically the test requires a preemption but does not put any preemption >> points within the batch? I'd argue that the fact that the test works at all >> is by chance, because the kernel just happens to add a preemption point >> after the BB and the batch doesn't wait for the results before completing. >> IMO it should be ok to go ahead with this patch and rework the test, but we >> probably need an ack from a maintainer because something that worked before >> (even if just by chance) is not going to work anymore. > Why user would need to explicitely add preemption points within batch? > It's imo driver responsibility to enable/disable preemption and additional > preemption points in the batch may change preemption distribution, > not the ability to preempt. If the batch logic requires a preemption (like in this case where the batch needs a different batch on the same engine to signal it), then IMO the user should make sure that there is a preemption point in the batch. The driver does keep preemption enabled while the batch is executing, but I don't think we want to guarantee that preemption will be enabled or that there will be a preemption point after the batch has completed. The fact that there is a preemption point after the batch is kind of by chance, just because the instruction we use to do a memory flush happens to be preemptable. > Compute-walkers we already had in IGT tests (gpgpu-fill) were called > in fire-and-forget mode leaving pipe-control to kmd. Code written > before I joined the team were written with this assumption and I haven't > seen any objection to this approach. So I assumed kmd will take care > of job completion when batch returns to ring. If this won't apply > anymore we just need to change IGT tests to add pipe-control in the > batch. And ensure nothing else is broken (compute / mesa). Agreed we need to make sure that no one apart from IGT is already relying on this, otherwise as Matt said we'll need to make this an opt-in behavior. Daniele > > I'm going to send pipe-control patch to IGTs, imo it will fix the > WMTP case. Sync wait at the batch level should keep execution with > preemption enabled allowing to call SIP and switch the context. > > -- > Zbigniew > >> Daniele >> >>> -- >>> Zbigniew >>> >>>> Matt >>>> >>>>> May you try to put arb disable after emit_render_cache_flush? >>>>> >>>>> -- >>>>> Zbigniew >>>>> >>>>>> i = emit_render_cache_flush(job, dw, i); >>>>>> if (job->user_fence.used) >>>>>> -- >>>>>> 2.34.1 >>>>>> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-22 17:47 ` Daniele Ceraolo Spurio @ 2026-01-27 20:14 ` Matthew Brost 0 siblings, 0 replies; 25+ messages in thread From: Matthew Brost @ 2026-01-27 20:14 UTC (permalink / raw) To: Daniele Ceraolo Spurio; +Cc: Zbigniew Kempczyński, intel-xe, Carlos Santa On Thu, Jan 22, 2026 at 09:47:37AM -0800, Daniele Ceraolo Spurio wrote: > > > On 1/22/2026 1:22 AM, Zbigniew Kempczyński wrote: > > On Tue, Jan 20, 2026 at 01:10:20PM -0800, Daniele Ceraolo Spurio wrote: > > > > > > On 1/19/2026 4:01 AM, Zbigniew Kempczyński wrote: > > > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > > > would need to perform a context switch just to signal the fence, which > > > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > > --- > > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > if (job->user_fence.used) { > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > if (job->user_fence.used) { > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > > > wait for completion, pipe-control is necessary to wait on > > > > > > compute-walker). > > > > > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > > > case? > > > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > > > not doing this relying on kmd. > > > > > > > > > Also do you know if render engines have similar asynchronous behaviors > > > > > or is this specific to compute engines? > > > > I don't know, I think Mesa folks may know the answer. > > > > > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > > > immediately after the BB before emitting the pipe control. Is this async > > > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > > > supports? This might explain why the i915 works and Xe does not. > > > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > > > what test is doing has a meaning in this case. First compute-walker > > > > submits kernel which loops until it will observe some memory write. > > > > Second job executes compute-walker with kernel which does some quick job. > > > > But first occupies all EU's so second job can be preempted only when > > > > preemption occurs and SIP will be executed. So if we disable preemption > > > > immediately we submit compute-walker I think we have no change to enter > > > > SIP and switch. Even if I add pipe-control to batch level according > > > > to Daniele comment job it is still preemptable and we move pipe-control > > > > location from kmd -> batch level.. > > > So basically the test requires a preemption but does not put any preemption > > > points within the batch? I'd argue that the fact that the test works at all > > > is by chance, because the kernel just happens to add a preemption point > > > after the BB and the batch doesn't wait for the results before completing. > > > IMO it should be ok to go ahead with this patch and rework the test, but we > > > probably need an ack from a maintainer because something that worked before > > > (even if just by chance) is not going to work anymore. > > Why user would need to explicitely add preemption points within batch? > > It's imo driver responsibility to enable/disable preemption and additional > > preemption points in the batch may change preemption distribution, > > not the ability to preempt. > > If the batch logic requires a preemption (like in this case where the batch > needs a different batch on the same engine to signal it), then IMO the user > should make sure that there is a preemption point in the batch. The driver > does keep preemption enabled while the batch is executing, but I don't think > we want to guarantee that preemption will be enabled or that there will be a > preemption point after the batch has completed. The fact that there is a > preemption point after the batch is kind of by chance, just because the > instruction we use to do a memory flush happens to be preemptable. > > > Compute-walkers we already had in IGT tests (gpgpu-fill) were called > > in fire-and-forget mode leaving pipe-control to kmd. Code written > > before I joined the team were written with this assumption and I haven't > > seen any objection to this approach. So I assumed kmd will take care > > of job completion when batch returns to ring. If this won't apply > > anymore we just need to change IGT tests to add pipe-control in the > > batch. And ensure nothing else is broken (compute / mesa). > > Agreed we need to make sure that no one apart from IGT is already relying on > this, otherwise as Matt said we'll need to make this an opt-in behavior. > +1. Zbigniew has an IGT fix for this. Next steps are to confirm with Mesa / Compute nothing breaks with this series. Not exactly sure how to drive this part - I'd say just blindly push and see if anything breaks but since this a fixes patch stable could pick this up when we unsure if it actually ready. Matt > Daniele > > > > > I'm going to send pipe-control patch to IGTs, imo it will fix the > > WMTP case. Sync wait at the batch level should keep execution with > > preemption enabled allowing to call SIP and switch the context. > > > > -- > > Zbigniew > > > > > Daniele > > > > > > > -- > > > > Zbigniew > > > > > > > > > Matt > > > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > > > > > -- > > > > > > Zbigniew > > > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > if (job->user_fence.used) > > > > > > > -- > > > > > > > 2.34.1 > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-19 12:01 ` Zbigniew Kempczyński 2026-01-20 21:10 ` Daniele Ceraolo Spurio @ 2026-01-20 21:11 ` Matthew Brost 2026-01-22 8:44 ` Zbigniew Kempczyński 1 sibling, 1 reply; 25+ messages in thread From: Matthew Brost @ 2026-01-20 21:11 UTC (permalink / raw) To: Zbigniew Kempczyński; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Mon, Jan 19, 2026 at 01:01:34PM +0100, Zbigniew Kempczyński wrote: > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > fence signaling instructions in the ring, as the largest portion of the > > > > work (the batch buffer) is already done and fence signaling consists of > > > > only a few instructions. If these instructions are preempted, the GuC > > > > would need to perform a context switch just to signal the fence, which > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > preemption immediately after the BB start instruction and re-enabling it > > > > after executing the fence signaling instructions. > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > --- > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > 1 file changed, 9 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + /* Don't preempt fence signaling */ > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > + > > > > if (job->user_fence.used) { > > > > i = emit_flush_dw(dw, i); > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + /* Don't preempt fence signaling */ > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > + > > > > if (job->user_fence.used) { > > > > i = emit_flush_dw(dw, i); > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > + /* Don't preempt fence signaling */ > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > + > > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > wait for completion, pipe-control is necessary to wait on > > > compute-walker). > > > > > > > This asynchronous behavior may explain things. Is this a common use > > case? > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > not doing this relying on kmd. > It would be good confirm this. > > > > Also do you know if render engines have similar asynchronous behaviors > > or is this specific to compute engines? > > I don't know, I think Mesa folks may know the answer. > Let me ask around about this. > > > > Lastly, the i915 disables preemption on both render / compute engines > > immediately after the BB before emitting the pipe control. Is this async > > behavior a new few feature in Xe2 parts which only the Xe driver > > supports? This might explain why the i915 works and Xe does not. > > Test exercises WMTP and this is supported starting at Xe2+. Probably > what test is doing has a meaning in this case. First compute-walker > submits kernel which loops until it will observe some memory write. > Second job executes compute-walker with kernel which does some quick job. > But first occupies all EU's so second job can be preempted only when > preemption occurs and SIP will be executed. So if we disable preemption > immediately we submit compute-walker I think we have no change to enter > SIP and switch. Even if I add pipe-control to batch level according > to Daniele comment job it is still preemptable and we move pipe-control > location from kmd -> batch level.. Does the test work with a pipe control in the batch? That would be a good data point - if let me know how I can change the test I can test out too. It is fine the batch preempts, we actually want that. Mid-batch preemption is not what we are trying to prevent - we are trying to prevent preemption of the fence signaling after the batch is done. As long as we don't regress any user applications we can safely make this change - it is fine to break IGTs which are not doing the right thing wrt to batch programming. Matt > > -- > Zbigniew > > > > > Matt > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > -- > > > Zbigniew > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > if (job->user_fence.used) > > > > -- > > > > 2.34.1 > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-20 21:11 ` Matthew Brost @ 2026-01-22 8:44 ` Zbigniew Kempczyński 2026-01-27 7:20 ` Zbigniew Kempczyński 0 siblings, 1 reply; 25+ messages in thread From: Zbigniew Kempczyński @ 2026-01-22 8:44 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Tue, Jan 20, 2026 at 01:11:18PM -0800, Matthew Brost wrote: > On Mon, Jan 19, 2026 at 01:01:34PM +0100, Zbigniew Kempczyński wrote: > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > would need to perform a context switch just to signal the fence, which > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > after executing the fence signaling instructions. > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > --- > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > if (job->user_fence.used) { > > > > > i = emit_flush_dw(dw, i); > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > + > > > > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > wait for completion, pipe-control is necessary to wait on > > > > compute-walker). > > > > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > case? > > > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > not doing this relying on kmd. > > > > It would be good confirm this. > > > > > > > Also do you know if render engines have similar asynchronous behaviors > > > or is this specific to compute engines? > > > > I don't know, I think Mesa folks may know the answer. > > > > Let me ask around about this. > > > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > immediately after the BB before emitting the pipe control. Is this async > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > supports? This might explain why the i915 works and Xe does not. > > > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > what test is doing has a meaning in this case. First compute-walker > > submits kernel which loops until it will observe some memory write. > > Second job executes compute-walker with kernel which does some quick job. > > But first occupies all EU's so second job can be preempted only when > > preemption occurs and SIP will be executed. So if we disable preemption > > immediately we submit compute-walker I think we have no change to enter > > SIP and switch. Even if I add pipe-control to batch level according > > to Daniele comment job it is still preemptable and we move pipe-control > > location from kmd -> batch level.. > > Does the test work with a pipe control in the batch? That would be a > good data point - if let me know how I can change the test I can test > out too. I'm going to add appropriate pipe-control to pipeline and send the patch. -- Zbigniew > > It is fine the batch preempts, we actually want that. Mid-batch > preemption is not what we are trying to prevent - we are trying to > prevent preemption of the fence signaling after the batch is done. As > long as we don't regress any user applications we can safely make this > change - it is fine to break IGTs which are not doing the right thing > wrt to batch programming. > > Matt > > > > > -- > > Zbigniew > > > > > > > > Matt > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > -- > > > > Zbigniew > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > if (job->user_fence.used) > > > > > -- > > > > > 2.34.1 > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-22 8:44 ` Zbigniew Kempczyński @ 2026-01-27 7:20 ` Zbigniew Kempczyński 2026-01-27 20:15 ` Matthew Brost 0 siblings, 1 reply; 25+ messages in thread From: Zbigniew Kempczyński @ 2026-01-27 7:20 UTC (permalink / raw) To: Matthew Brost; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Thu, Jan 22, 2026 at 09:44:14AM +0100, Zbigniew Kempczyński wrote: > On Tue, Jan 20, 2026 at 01:11:18PM -0800, Matthew Brost wrote: > > On Mon, Jan 19, 2026 at 01:01:34PM +0100, Zbigniew Kempczyński wrote: > > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > > would need to perform a context switch just to signal the fence, which > > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > --- > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > if (job->user_fence.used) { > > > > > > i = emit_flush_dw(dw, i); > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > if (job->user_fence.used) { > > > > > > i = emit_flush_dw(dw, i); > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > + > > > > > > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > > wait for completion, pipe-control is necessary to wait on > > > > > compute-walker). > > > > > > > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > > case? > > > > > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > > not doing this relying on kmd. > > > > > > > It would be good confirm this. > > > > > > > > > > Also do you know if render engines have similar asynchronous behaviors > > > > or is this specific to compute engines? > > > > > > I don't know, I think Mesa folks may know the answer. > > > > > > > Let me ask around about this. > > > > > > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > > immediately after the BB before emitting the pipe control. Is this async > > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > > supports? This might explain why the i915 works and Xe does not. We don't have platforms which supports WMTP in i915 driver. This imo explains why there're no issues observed there. I mean regardless preemption state disabled/enabled all instructions soon or later completes. > > > > > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > > what test is doing has a meaning in this case. First compute-walker > > > submits kernel which loops until it will observe some memory write. > > > Second job executes compute-walker with kernel which does some quick job. > > > But first occupies all EU's so second job can be preempted only when > > > preemption occurs and SIP will be executed. So if we disable preemption > > > immediately we submit compute-walker I think we have no change to enter > > > SIP and switch. Even if I add pipe-control to batch level according > > > to Daniele comment job it is still preemptable and we move pipe-control > > > location from kmd -> batch level.. > > > > Does the test work with a pipe control in the batch? That would be a > > good data point - if let me know how I can change the test I can test > > out too. > > I'm going to add appropriate pipe-control to pipeline and send the > patch. This change: https://patchwork.freedesktop.org/series/160484/ along with your patch passes the test. -- Zbigniew > > -- > Zbigniew > > > > > It is fine the batch preempts, we actually want that. Mid-batch > > preemption is not what we are trying to prevent - we are trying to > > prevent preemption of the fence signaling after the batch is done. As > > long as we don't regress any user applications we can safely make this > > change - it is fine to break IGTs which are not doing the right thing > > wrt to batch programming. > > > > Matt > > > > > > > > -- > > > Zbigniew > > > > > > > > > > > Matt > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > > > -- > > > > > Zbigniew > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > > > if (job->user_fence.used) > > > > > > -- > > > > > > 2.34.1 > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-27 7:20 ` Zbigniew Kempczyński @ 2026-01-27 20:15 ` Matthew Brost 2026-02-26 17:35 ` Matthew Brost 0 siblings, 1 reply; 25+ messages in thread From: Matthew Brost @ 2026-01-27 20:15 UTC (permalink / raw) To: Zbigniew Kempczyński; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Tue, Jan 27, 2026 at 08:20:36AM +0100, Zbigniew Kempczyński wrote: > On Thu, Jan 22, 2026 at 09:44:14AM +0100, Zbigniew Kempczyński wrote: > > On Tue, Jan 20, 2026 at 01:11:18PM -0800, Matthew Brost wrote: > > > On Mon, Jan 19, 2026 at 01:01:34PM +0100, Zbigniew Kempczyński wrote: > > > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > > > would need to perform a context switch just to signal the fence, which > > > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > > --- > > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > if (job->user_fence.used) { > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > if (job->user_fence.used) { > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > + > > > > > > > > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > > > wait for completion, pipe-control is necessary to wait on > > > > > > compute-walker). > > > > > > > > > > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > > > case? > > > > > > > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > > > not doing this relying on kmd. > > > > > > > > > > It would be good confirm this. > > > > > > > > > > > > > Also do you know if render engines have similar asynchronous behaviors > > > > > or is this specific to compute engines? > > > > > > > > I don't know, I think Mesa folks may know the answer. > > > > > > > > > > Let me ask around about this. > > > > > > > > > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > > > immediately after the BB before emitting the pipe control. Is this async > > > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > > > supports? This might explain why the i915 works and Xe does not. > > We don't have platforms which supports WMTP in i915 driver. This imo explains why > there're no issues observed there. I mean regardless preemption state > disabled/enabled all instructions soon or later completes. > > > > > > > > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > > > what test is doing has a meaning in this case. First compute-walker > > > > submits kernel which loops until it will observe some memory write. > > > > Second job executes compute-walker with kernel which does some quick job. > > > > But first occupies all EU's so second job can be preempted only when > > > > preemption occurs and SIP will be executed. So if we disable preemption > > > > immediately we submit compute-walker I think we have no change to enter > > > > SIP and switch. Even if I add pipe-control to batch level according > > > > to Daniele comment job it is still preemptable and we move pipe-control > > > > location from kmd -> batch level.. > > > > > > Does the test work with a pipe control in the batch? That would be a > > > good data point - if let me know how I can change the test I can test > > > out too. > > > > I'm going to add appropriate pipe-control to pipeline and send the > > patch. > > This change: https://patchwork.freedesktop.org/series/160484/ > > along with your patch passes the test. > Thanks! Great data point. Now just need to test out Mesa / Compute. I suspect they properly insert pipe controls in batches as preemption points but need to confirm. Matt > -- > Zbigniew > > > > > -- > > Zbigniew > > > > > > > > It is fine the batch preempts, we actually want that. Mid-batch > > > preemption is not what we are trying to prevent - we are trying to > > > prevent preemption of the fence signaling after the batch is done. As > > > long as we don't regress any user applications we can safely make this > > > change - it is fine to break IGTs which are not doing the right thing > > > wrt to batch programming. > > > > > > Matt > > > > > > > > > > > -- > > > > Zbigniew > > > > > > > > > > > > > > Matt > > > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > > > > > -- > > > > > > Zbigniew > > > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > > > > > if (job->user_fence.used) > > > > > > > -- > > > > > > > 2.34.1 > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-01-27 20:15 ` Matthew Brost @ 2026-02-26 17:35 ` Matthew Brost 2026-02-26 17:49 ` Daniele Ceraolo Spurio 0 siblings, 1 reply; 25+ messages in thread From: Matthew Brost @ 2026-02-26 17:35 UTC (permalink / raw) To: Zbigniew Kempczyński; +Cc: intel-xe, Daniele Ceraolo Spurio, Carlos Santa On Tue, Jan 27, 2026 at 12:15:52PM -0800, Matthew Brost wrote: > On Tue, Jan 27, 2026 at 08:20:36AM +0100, Zbigniew Kempczyński wrote: > > On Thu, Jan 22, 2026 at 09:44:14AM +0100, Zbigniew Kempczyński wrote: > > > On Tue, Jan 20, 2026 at 01:11:18PM -0800, Matthew Brost wrote: > > > > On Mon, Jan 19, 2026 at 01:01:34PM +0100, Zbigniew Kempczyński wrote: > > > > > On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: > > > > > > On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: > > > > > > > On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: > > > > > > > > If a batch buffer is complete, it makes little sense to preempt the > > > > > > > > fence signaling instructions in the ring, as the largest portion of the > > > > > > > > work (the batch buffer) is already done and fence signaling consists of > > > > > > > > only a few instructions. If these instructions are preempted, the GuC > > > > > > > > would need to perform a context switch just to signal the fence, which > > > > > > > > is costly and delays fence signaling. Avoid this scenario by disabling > > > > > > > > preemption immediately after the BB start instruction and re-enabling it > > > > > > > > after executing the fence signaling instructions. > > > > > > > > > > > > > > > > Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") > > > > > > > > Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> > > > > > > > > Cc: Carlos Santa <carlos.santa@intel.com> > > > > > > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com> > > > > > > > > --- > > > > > > > > drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ > > > > > > > > 1 file changed, 9 insertions(+) > > > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > > index a1fd99f2d539..cd645ee400b9 100644 > > > > > > > > --- a/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > > +++ b/drivers/gpu/drm/xe/xe_ring_ops.c > > > > > > > > @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc > > > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > > + > > > > > > > > if (job->user_fence.used) { > > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > > > @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, > > > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > > + > > > > > > > > if (job->user_fence.used) { > > > > > > > > i = emit_flush_dw(dw, i); > > > > > > > > i = emit_store_imm_ppgtt_posted(job->user_fence.addr, > > > > > > > > @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, > > > > > > > > > > > > > > > > i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); > > > > > > > > > > > > > > > > + /* Don't preempt fence signaling */ > > > > > > > > + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; > > > > > > > > + > > > > > > > > > > > > > > IGT tests which calls compute-walker, then bbe are asynchronous (don't > > > > > > > wait for completion, pipe-control is necessary to wait on > > > > > > > compute-walker). > > > > > > > > > > > > > > > > > > > This asynchronous behavior may explain things. Is this a common use > > > > > > case? > > > > > > > > > > Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are > > > > > not doing this relying on kmd. > > > > > > > > > > > > > It would be good confirm this. > > > > > > > > > > > > > > > > Also do you know if render engines have similar asynchronous behaviors > > > > > > or is this specific to compute engines? > > > > > > > > > > I don't know, I think Mesa folks may know the answer. > > > > > > > > > > > > > Let me ask around about this. > > > > > > > > > > > > > > > > Lastly, the i915 disables preemption on both render / compute engines > > > > > > immediately after the BB before emitting the pipe control. Is this async > > > > > > behavior a new few feature in Xe2 parts which only the Xe driver > > > > > > supports? This might explain why the i915 works and Xe does not. > > > > We don't have platforms which supports WMTP in i915 driver. This imo explains why > > there're no issues observed there. I mean regardless preemption state > > disabled/enabled all instructions soon or later completes. > > > > > > > > > > > > Test exercises WMTP and this is supported starting at Xe2+. Probably > > > > > what test is doing has a meaning in this case. First compute-walker > > > > > submits kernel which loops until it will observe some memory write. > > > > > Second job executes compute-walker with kernel which does some quick job. > > > > > But first occupies all EU's so second job can be preempted only when > > > > > preemption occurs and SIP will be executed. So if we disable preemption > > > > > immediately we submit compute-walker I think we have no change to enter > > > > > SIP and switch. Even if I add pipe-control to batch level according > > > > > to Daniele comment job it is still preemptable and we move pipe-control > > > > > location from kmd -> batch level.. > > > > > > > > Does the test work with a pipe control in the batch? That would be a > > > > good data point - if let me know how I can change the test I can test > > > > out too. > > > > > > I'm going to add appropriate pipe-control to pipeline and send the > > > patch. > > > > This change: https://patchwork.freedesktop.org/series/160484/ > > > > along with your patch passes the test. > > > > Thanks! Great data point. Now just need to test out Mesa / Compute. I > suspect they properly insert pipe controls in batches as preemption > points but need to confirm. > Both Mesa / Compute have completed CI runs with this patch and reported no regressions. Can I get an RB on this patch to merge? Zbigniew - did you ever get the IGT change merged? Matt > Matt > > > -- > > Zbigniew > > > > > > > > -- > > > Zbigniew > > > > > > > > > > > It is fine the batch preempts, we actually want that. Mid-batch > > > > preemption is not what we are trying to prevent - we are trying to > > > > prevent preemption of the fence signaling after the batch is done. As > > > > long as we don't regress any user applications we can safely make this > > > > change - it is fine to break IGTs which are not doing the right thing > > > > wrt to batch programming. > > > > > > > > Matt > > > > > > > > > > > > > > -- > > > > > Zbigniew > > > > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > May you try to put arb disable after emit_render_cache_flush? > > > > > > > > > > > > > > -- > > > > > > > Zbigniew > > > > > > > > > > > > > > > i = emit_render_cache_flush(job, dw, i); > > > > > > > > > > > > > > > > if (job->user_fence.used) > > > > > > > > -- > > > > > > > > 2.34.1 > > > > > > > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] drm/xe: Do not preempt fence signaling CS instructions 2026-02-26 17:35 ` Matthew Brost @ 2026-02-26 17:49 ` Daniele Ceraolo Spurio 0 siblings, 0 replies; 25+ messages in thread From: Daniele Ceraolo Spurio @ 2026-02-26 17:49 UTC (permalink / raw) To: Matthew Brost, Zbigniew Kempczyński; +Cc: intel-xe, Carlos Santa On 2/26/2026 9:35 AM, Matthew Brost wrote: > On Tue, Jan 27, 2026 at 12:15:52PM -0800, Matthew Brost wrote: >> On Tue, Jan 27, 2026 at 08:20:36AM +0100, Zbigniew Kempczyński wrote: >>> On Thu, Jan 22, 2026 at 09:44:14AM +0100, Zbigniew Kempczyński wrote: >>>> On Tue, Jan 20, 2026 at 01:11:18PM -0800, Matthew Brost wrote: >>>>> On Mon, Jan 19, 2026 at 01:01:34PM +0100, Zbigniew Kempczyński wrote: >>>>>> On Fri, Jan 16, 2026 at 01:05:01PM -0800, Matthew Brost wrote: >>>>>>> On Fri, Jan 16, 2026 at 10:45:39AM +0100, Zbigniew Kempczyński wrote: >>>>>>>> On Wed, Jan 14, 2026 at 04:45:46PM -0800, Matthew Brost wrote: >>>>>>>>> If a batch buffer is complete, it makes little sense to preempt the >>>>>>>>> fence signaling instructions in the ring, as the largest portion of the >>>>>>>>> work (the batch buffer) is already done and fence signaling consists of >>>>>>>>> only a few instructions. If these instructions are preempted, the GuC >>>>>>>>> would need to perform a context switch just to signal the fence, which >>>>>>>>> is costly and delays fence signaling. Avoid this scenario by disabling >>>>>>>>> preemption immediately after the BB start instruction and re-enabling it >>>>>>>>> after executing the fence signaling instructions. >>>>>>>>> >>>>>>>>> Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") >>>>>>>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> >>>>>>>>> Cc: Carlos Santa <carlos.santa@intel.com> >>>>>>>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com> >>>>>>>>> --- >>>>>>>>> drivers/gpu/drm/xe/xe_ring_ops.c | 9 +++++++++ >>>>>>>>> 1 file changed, 9 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/drivers/gpu/drm/xe/xe_ring_ops.c b/drivers/gpu/drm/xe/xe_ring_ops.c >>>>>>>>> index a1fd99f2d539..cd645ee400b9 100644 >>>>>>>>> --- a/drivers/gpu/drm/xe/xe_ring_ops.c >>>>>>>>> +++ b/drivers/gpu/drm/xe/xe_ring_ops.c >>>>>>>>> @@ -282,6 +282,9 @@ static void __emit_job_gen12_simple(struct xe_sched_job *job, struct xe_lrc *lrc >>>>>>>>> >>>>>>>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>>>>>>> >>>>>>>>> + /* Don't preempt fence signaling */ >>>>>>>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>>>>>>> + >>>>>>>>> if (job->user_fence.used) { >>>>>>>>> i = emit_flush_dw(dw, i); >>>>>>>>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>>>>>>>> @@ -347,6 +350,9 @@ static void __emit_job_gen12_video(struct xe_sched_job *job, struct xe_lrc *lrc, >>>>>>>>> >>>>>>>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>>>>>>> >>>>>>>>> + /* Don't preempt fence signaling */ >>>>>>>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>>>>>>> + >>>>>>>>> if (job->user_fence.used) { >>>>>>>>> i = emit_flush_dw(dw, i); >>>>>>>>> i = emit_store_imm_ppgtt_posted(job->user_fence.addr, >>>>>>>>> @@ -399,6 +405,9 @@ static void __emit_job_gen12_render_compute(struct xe_sched_job *job, >>>>>>>>> >>>>>>>>> i = emit_bb_start(batch_addr, ppgtt_flag, dw, i); >>>>>>>>> >>>>>>>>> + /* Don't preempt fence signaling */ >>>>>>>>> + dw[i++] = MI_ARB_ON_OFF | MI_ARB_DISABLE; >>>>>>>>> + >>>>>>>> IGT tests which calls compute-walker, then bbe are asynchronous (don't >>>>>>>> wait for completion, pipe-control is necessary to wait on >>>>>>>> compute-walker). >>>>>>>> >>>>>>> This asynchronous behavior may explain things. Is this a common use >>>>>>> case? >>>>>> Compute runtime if I'm not wrong uses pipe-control explicitely. IGT are >>>>>> not doing this relying on kmd. >>>>>> >>>>> It would be good confirm this. >>>>> >>>>>>> Also do you know if render engines have similar asynchronous behaviors >>>>>>> or is this specific to compute engines? >>>>>> I don't know, I think Mesa folks may know the answer. >>>>>> >>>>> Let me ask around about this. >>>>> >>>>>>> Lastly, the i915 disables preemption on both render / compute engines >>>>>>> immediately after the BB before emitting the pipe control. Is this async >>>>>>> behavior a new few feature in Xe2 parts which only the Xe driver >>>>>>> supports? This might explain why the i915 works and Xe does not. >>> We don't have platforms which supports WMTP in i915 driver. This imo explains why >>> there're no issues observed there. I mean regardless preemption state >>> disabled/enabled all instructions soon or later completes. >>> >>>>>> Test exercises WMTP and this is supported starting at Xe2+. Probably >>>>>> what test is doing has a meaning in this case. First compute-walker >>>>>> submits kernel which loops until it will observe some memory write. >>>>>> Second job executes compute-walker with kernel which does some quick job. >>>>>> But first occupies all EU's so second job can be preempted only when >>>>>> preemption occurs and SIP will be executed. So if we disable preemption >>>>>> immediately we submit compute-walker I think we have no change to enter >>>>>> SIP and switch. Even if I add pipe-control to batch level according >>>>>> to Daniele comment job it is still preemptable and we move pipe-control >>>>>> location from kmd -> batch level.. >>>>> Does the test work with a pipe control in the batch? That would be a >>>>> good data point - if let me know how I can change the test I can test >>>>> out too. >>>> I'm going to add appropriate pipe-control to pipeline and send the >>>> patch. >>> This change: https://patchwork.freedesktop.org/series/160484/ >>> >>> along with your patch passes the test. >>> >> Thanks! Great data point. Now just need to test out Mesa / Compute. I >> suspect they properly insert pipe controls in batches as preemption >> points but need to confirm. >> > Both Mesa / Compute have completed CI runs with this patch and reported > no regressions. > > Can I get an RB on this patch to merge? I thought I had already given an r-b since I did review the patch when you posted it, but apparently I forgot in the midst of the discussion. Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Daniele > > Zbigniew - did you ever get the IGT change merged? > > Matt > >> Matt >> >>> -- >>> Zbigniew >>> >>>> -- >>>> Zbigniew >>>> >>>>> It is fine the batch preempts, we actually want that. Mid-batch >>>>> preemption is not what we are trying to prevent - we are trying to >>>>> prevent preemption of the fence signaling after the batch is done. As >>>>> long as we don't regress any user applications we can safely make this >>>>> change - it is fine to break IGTs which are not doing the right thing >>>>> wrt to batch programming. >>>>> >>>>> Matt >>>>> >>>>>> -- >>>>>> Zbigniew >>>>>> >>>>>>> Matt >>>>>>> >>>>>>>> May you try to put arb disable after emit_render_cache_flush? >>>>>>>> >>>>>>>> -- >>>>>>>> Zbigniew >>>>>>>> >>>>>>>>> i = emit_render_cache_flush(job, dw, i); >>>>>>>>> >>>>>>>>> if (job->user_fence.used) >>>>>>>>> -- >>>>>>>>> 2.34.1 >>>>>>>>> ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2026-02-26 17:49 UTC | newest] Thread overview: 25+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-15 0:45 [PATCH] drm/xe: Do not preempt fence signaling CS instructions Matthew Brost 2026-01-15 0:52 ` ✓ CI.KUnit: success for " Patchwork 2026-01-15 1:35 ` ✓ Xe.CI.BAT: " Patchwork 2026-01-15 6:13 ` ✗ Xe.CI.Full: failure " Patchwork 2026-01-16 9:45 ` [PATCH] " Zbigniew Kempczyński 2026-01-16 10:12 ` Francois Dugast 2026-01-16 16:43 ` Daniele Ceraolo Spurio 2026-01-16 19:51 ` Summers, Stuart 2026-01-16 20:44 ` Matthew Brost 2026-01-16 21:07 ` Summers, Stuart 2026-01-16 21:19 ` Matthew Brost 2026-01-16 21:05 ` Matthew Brost 2026-01-19 12:01 ` Zbigniew Kempczyński 2026-01-20 21:10 ` Daniele Ceraolo Spurio 2026-01-20 21:26 ` Matthew Brost 2026-01-20 21:27 ` Matthew Brost 2026-01-22 9:22 ` Zbigniew Kempczyński 2026-01-22 17:47 ` Daniele Ceraolo Spurio 2026-01-27 20:14 ` Matthew Brost 2026-01-20 21:11 ` Matthew Brost 2026-01-22 8:44 ` Zbigniew Kempczyński 2026-01-27 7:20 ` Zbigniew Kempczyński 2026-01-27 20:15 ` Matthew Brost 2026-02-26 17:35 ` Matthew Brost 2026-02-26 17:49 ` Daniele Ceraolo Spurio
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox