intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
@ 2021-09-09 19:49 José Roberto de Souza
  2021-09-09 19:49 ` [Intel-gfx] [PATCH CI 2/2] drm/i915/display: Drop PSR " José Roberto de Souza
                   ` (4 more replies)
  0 siblings, 5 replies; 14+ messages in thread
From: José Roberto de Souza @ 2021-09-09 19:49 UTC (permalink / raw)
  To: intel-gfx
  Cc: Gwan-gyeong Mun, Daniel Vetter, Ville Syrjälä,
	Jani Nikula, Rodrigo Vivi, José Roberto de Souza

By now all the userspace applications should have migrated to atomic
or at least be calling DRM_IOCTL_MODE_DIRTYFB.

With that we can kill frontbuffer rendering support in i915 for
modern platforms.

So here converting legacy APIs into atomic commits so it can be
properly handled by driver i915.

Several IGT tests will fail with this changes, because some tests
were stressing those frontbuffer rendering scenarios that no userspace
should be using by now, fixes to IGT should be sent soon.

v2:
- return earlier to not set fb_tracking.busy/flip_bits
- added a warn on to make sure we are not setting the busy/flip_bits

Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
---
 drivers/gpu/drm/i915/display/intel_cursor.c    |  6 ++----
 drivers/gpu/drm/i915/display/intel_fb.c        |  8 +++++++-
 .../gpu/drm/i915/display/intel_frontbuffer.c   | 18 ++++++++++++++++++
 drivers/gpu/drm/i915/i915_drv.h                |  2 ++
 4 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c
index c7618fef01439..5aa996c3b7980 100644
--- a/drivers/gpu/drm/i915/display/intel_cursor.c
+++ b/drivers/gpu/drm/i915/display/intel_cursor.c
@@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
 			   u32 src_w, u32 src_h,
 			   struct drm_modeset_acquire_ctx *ctx)
 {
+	struct drm_i915_private *i915 = to_i915(_crtc->dev);
 	struct intel_plane *plane = to_intel_plane(_plane);
 	struct intel_crtc *crtc = to_intel_crtc(_crtc);
 	struct intel_plane_state *old_plane_state =
@@ -633,12 +634,9 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
 	 * PSR2 selective fetch also requires the slow path as
 	 * PSR2 plane and transcoder registers can only be updated during
 	 * vblank.
-	 *
-	 * FIXME bigjoiner fastpath would be good
 	 */
 	if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
-	    crtc_state->update_pipe || crtc_state->bigjoiner ||
-	    crtc_state->enable_psr2_sel_fetch)
+	    crtc_state->update_pipe || !HAS_FRONTBUFFER_RENDERING(i915))
 		goto slow;
 
 	/*
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c
index e4b8602ec0cd2..3eb60785c9f29 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -3,6 +3,7 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include <drm/drm_damage_helper.h>
 #include <drm/drm_framebuffer.h>
 #include <drm/drm_modeset_helper.h>
 
@@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
 					unsigned int num_clips)
 {
 	struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+	struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
 	i915_gem_object_flush_if_display(obj);
-	intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
 
+	if (!HAS_FRONTBUFFER_RENDERING(i915))
+		return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
+						 num_clips);
+
+	intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
 	return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 0492446cd04ad..3860f87dac31c 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -112,6 +112,9 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
 void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
 				    unsigned frontbuffer_bits)
 {
+	if (!HAS_FRONTBUFFER_RENDERING(i915))
+		return;
+
 	spin_lock(&i915->fb_tracking.lock);
 	i915->fb_tracking.flip_bits |= frontbuffer_bits;
 	/* Remove stale busy bits due to the old buffer. */
@@ -132,6 +135,12 @@ void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
 void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
 				     unsigned frontbuffer_bits)
 {
+	if (!HAS_FRONTBUFFER_RENDERING(i915)) {
+		drm_WARN_ON_ONCE(&i915->drm, i915->fb_tracking.flip_bits |
+					     i915->fb_tracking.busy_bits);
+		return;
+	}
+
 	spin_lock(&i915->fb_tracking.lock);
 	/* Mask any cancelled flips. */
 	frontbuffer_bits &= i915->fb_tracking.flip_bits;
@@ -156,6 +165,9 @@ void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
 void intel_frontbuffer_flip(struct drm_i915_private *i915,
 			    unsigned frontbuffer_bits)
 {
+	if (!HAS_FRONTBUFFER_RENDERING(i915))
+		return;
+
 	spin_lock(&i915->fb_tracking.lock);
 	/* Remove stale busy bits due to the old buffer. */
 	i915->fb_tracking.busy_bits &= ~frontbuffer_bits;
@@ -170,6 +182,9 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,
 {
 	struct drm_i915_private *i915 = to_i915(front->obj->base.dev);
 
+	if (!HAS_FRONTBUFFER_RENDERING(i915))
+		return;
+
 	if (origin == ORIGIN_CS) {
 		spin_lock(&i915->fb_tracking.lock);
 		i915->fb_tracking.busy_bits |= frontbuffer_bits;
@@ -191,6 +206,9 @@ void __intel_fb_flush(struct intel_frontbuffer *front,
 {
 	struct drm_i915_private *i915 = to_i915(front->obj->base.dev);
 
+	if (!HAS_FRONTBUFFER_RENDERING(i915))
+		return;
+
 	if (origin == ORIGIN_CS) {
 		spin_lock(&i915->fb_tracking.lock);
 		/* Filter out new bits since rendering started. */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 37c1ca266bcdf..3324ba8d8523c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1699,6 +1699,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_ASYNC_FLIPS(i915)		(DISPLAY_VER(i915) >= 5)
 
+#define HAS_FRONTBUFFER_RENDERING(i915)	(DISPLAY_VER(i915) < 9)
+
 /* Only valid when HAS_DISPLAY() is true */
 #define INTEL_DISPLAY_ENABLED(dev_priv) \
 	(drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)), !(dev_priv)->params.disable_display)
-- 
2.33.0


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

* [Intel-gfx] [PATCH CI 2/2] drm/i915/display: Drop PSR frontbuffer rendering support
  2021-09-09 19:49 [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
@ 2021-09-09 19:49 ` José Roberto de Souza
  2021-09-09 20:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/display/skl+: Drop " Patchwork
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 14+ messages in thread
From: José Roberto de Souza @ 2021-09-09 19:49 UTC (permalink / raw)
  To: intel-gfx; +Cc: Gwan-gyeong Mun, José Roberto de Souza

After commit "drm/i915/display/skl+: Drop frontbuffer rendering
support" frontbuffer rendering is not supported for display 9 and
newer and as PSR is only supported by default in display 9 and newer
we can now drop all frontbuffer rendering support for PSR code.

Some DC3CO code was commented with a macro, because the function
caller is being dropped. As DC3CO is already disabled by default
because it requires changes in its sequences

Two DC3CO functions lost their callers while dropping frontbuffer
rendering but as DC3CO is already disabled by default because it
requires fixes, will leave this task to whoever will fix DC3CO.

Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
---
 .../drm/i915/display/intel_display_debugfs.c  |   2 -
 .../drm/i915/display/intel_display_types.h    |   2 -
 .../gpu/drm/i915/display/intel_frontbuffer.c  |   2 -
 drivers/gpu/drm/i915/display/intel_psr.c      | 186 ++----------------
 drivers/gpu/drm/i915/display/intel_psr.h      |   8 +-
 5 files changed, 18 insertions(+), 182 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 68f4ba8c46e75..33d71edfc0630 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -374,8 +374,6 @@ static int intel_psr_status(struct seq_file *m, struct intel_dp *intel_dp)
 	seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
 		   enableddisabled(enabled), val);
 	psr_source_status(intel_dp, m);
-	seq_printf(m, "Busy frontbuffer bits: 0x%08x\n",
-		   psr->busy_frontbuffer_bits);
 
 	/*
 	 * SKL+ Perf counter is reset to 0 everytime DC state is entered
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
index c7bcf9183447b..ddd51aa1649c3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1512,7 +1512,6 @@ struct intel_psr {
 	enum transcoder transcoder;
 	bool active;
 	struct work_struct work;
-	unsigned int busy_frontbuffer_bits;
 	bool sink_psr2_support;
 	bool link_standby;
 	bool colorimetry_support;
@@ -1523,7 +1522,6 @@ struct intel_psr {
 	ktime_t last_entry_attempt;
 	ktime_t last_exit;
 	bool sink_not_reliable;
-	bool irq_aux_error;
 	u16 su_w_granularity;
 	u16 su_y_granularity;
 	u32 dc3co_exitline;
diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
index 3860f87dac31c..1d8314d3712f4 100644
--- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
@@ -93,7 +93,6 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
 
 	might_sleep();
 	intel_drrs_flush(i915, frontbuffer_bits);
-	intel_psr_flush(i915, frontbuffer_bits, origin);
 	intel_fbc_flush(i915, frontbuffer_bits, origin);
 }
 
@@ -195,7 +194,6 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,
 	trace_intel_frontbuffer_invalidate(frontbuffer_bits, origin);
 
 	might_sleep();
-	intel_psr_invalidate(i915, frontbuffer_bits, origin);
 	intel_drrs_invalidate(i915, frontbuffer_bits);
 	intel_fbc_invalidate(i915, frontbuffer_bits, origin);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c
index 3f6fb7d67f84d..8c9bd5846a8d0 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -224,15 +224,12 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, u32 psr_iir)
 		drm_warn(&dev_priv->drm, "[transcoder %s] PSR aux error\n",
 			 transcoder_name(cpu_transcoder));
 
-		intel_dp->psr.irq_aux_error = true;
-
 		/*
 		 * If this interruption is not masked it will keep
 		 * interrupting so fast that it prevents the scheduled
 		 * work to run.
 		 * Also after a PSR error, we don't want to arm PSR
 		 * again so we don't care about unmask the interruption
-		 * or unset irq_aux_error.
 		 */
 		val = intel_de_read(dev_priv, imr_reg);
 		val |= EDP_PSR_ERROR(trans_shift);
@@ -614,14 +611,6 @@ static void psr2_program_idle_frames(struct intel_dp *intel_dp,
 	intel_de_write(dev_priv, EDP_PSR2_CTL(intel_dp->psr.transcoder), val);
 }
 
-static void tgl_psr2_enable_dc3co(struct intel_dp *intel_dp)
-{
-	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-
-	psr2_program_idle_frames(intel_dp, 0);
-	intel_display_power_set_target_dc_state(dev_priv, DC_STATE_EN_DC3CO);
-}
-
 static void tgl_psr2_disable_dc3co(struct intel_dp *intel_dp)
 {
 	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
@@ -1177,7 +1166,6 @@ static void intel_psr_enable_locked(struct intel_dp *intel_dp,
 	drm_WARN_ON(&dev_priv->drm, intel_dp->psr.enabled);
 
 	intel_dp->psr.psr2_enabled = crtc_state->has_psr2;
-	intel_dp->psr.busy_frontbuffer_bits = 0;
 	intel_dp->psr.pipe = to_intel_crtc(crtc_state->uapi.crtc)->pipe;
 	intel_dp->psr.transcoder = crtc_state->cpu_transcoder;
 	/* DC5/DC6 requires at least 6 idle frames */
@@ -1784,36 +1772,6 @@ void intel_psr_wait_for_idle(const struct intel_crtc_state *new_crtc_state)
 	}
 }
 
-static bool __psr_wait_for_idle_locked(struct intel_dp *intel_dp)
-{
-	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
-	i915_reg_t reg;
-	u32 mask;
-	int err;
-
-	if (!intel_dp->psr.enabled)
-		return false;
-
-	if (intel_dp->psr.psr2_enabled) {
-		reg = EDP_PSR2_STATUS(intel_dp->psr.transcoder);
-		mask = EDP_PSR2_STATUS_STATE_MASK;
-	} else {
-		reg = EDP_PSR_STATUS(intel_dp->psr.transcoder);
-		mask = EDP_PSR_STATUS_STATE_MASK;
-	}
-
-	mutex_unlock(&intel_dp->psr.lock);
-
-	err = intel_de_wait_for_clear(dev_priv, reg, mask, 50);
-	if (err)
-		drm_err(&dev_priv->drm,
-			"Timed out waiting for PSR Idle for re-enable\n");
-
-	/* After the unlocked wait, verify that PSR is still wanted! */
-	mutex_lock(&intel_dp->psr.lock);
-	return err == 0 && intel_dp->psr.enabled;
-}
-
 static int intel_psr_fastset_force(struct drm_i915_private *dev_priv)
 {
 	struct drm_connector_list_iter conn_iter;
@@ -1912,16 +1870,6 @@ int intel_psr_debug_set(struct intel_dp *intel_dp, u64 val)
 	return ret;
 }
 
-static void intel_psr_handle_irq(struct intel_dp *intel_dp)
-{
-	struct intel_psr *psr = &intel_dp->psr;
-
-	intel_psr_disable_locked(intel_dp);
-	psr->sink_not_reliable = true;
-	/* let's make sure that sink is awaken */
-	drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
-}
-
 static void intel_psr_work(struct work_struct *work)
 {
 	struct intel_dp *intel_dp =
@@ -1929,75 +1877,30 @@ static void intel_psr_work(struct work_struct *work)
 
 	mutex_lock(&intel_dp->psr.lock);
 
-	if (!intel_dp->psr.enabled)
-		goto unlock;
-
-	if (READ_ONCE(intel_dp->psr.irq_aux_error))
-		intel_psr_handle_irq(intel_dp);
-
-	/*
-	 * We have to make sure PSR is ready for re-enable
-	 * otherwise it keeps disabled until next full enable/disable cycle.
-	 * PSR might take some time to get fully disabled
-	 * and be ready for re-enable.
-	 */
-	if (!__psr_wait_for_idle_locked(intel_dp))
-		goto unlock;
-
-	/*
-	 * The delayed work can race with an invalidate hence we need to
-	 * recheck. Since psr_flush first clears this and then reschedules we
-	 * won't ever miss a flush when bailing out here.
-	 */
-	if (intel_dp->psr.busy_frontbuffer_bits || intel_dp->psr.active)
-		goto unlock;
+	/* Handling PSR error interruption */
+	intel_psr_disable_locked(intel_dp);
+	intel_dp->psr.sink_not_reliable = true;
+	/* let's make sure that sink is awaken */
+	drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
 
-	intel_psr_activate(intel_dp);
-unlock:
 	mutex_unlock(&intel_dp->psr.lock);
 }
 
-/**
- * intel_psr_invalidate - Invalidade PSR
- * @dev_priv: i915 device
- * @frontbuffer_bits: frontbuffer plane tracking bits
- * @origin: which operation caused the invalidate
- *
- * Since the hardware frontbuffer tracking has gaps we need to integrate
- * with the software frontbuffer tracking. This function gets called every
- * time frontbuffer rendering starts and a buffer gets dirtied. PSR must be
- * disabled if the frontbuffer mask contains a buffer relevant to PSR.
- *
- * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits."
+/*
+ * TODO: Functions below lost their callers to a refactor but as DC3CO is
+ * already disabled by default because it requires fixes, will leave this task
+ * to whoever will fix DC3CO.
  */
-void intel_psr_invalidate(struct drm_i915_private *dev_priv,
-			  unsigned frontbuffer_bits, enum fb_op_origin origin)
-{
-	struct intel_encoder *encoder;
-
-	if (origin == ORIGIN_FLIP)
-		return;
-
-	for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
-		unsigned int pipe_frontbuffer_bits = frontbuffer_bits;
-		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
-		mutex_lock(&intel_dp->psr.lock);
-		if (!intel_dp->psr.enabled) {
-			mutex_unlock(&intel_dp->psr.lock);
-			continue;
-		}
-
-		pipe_frontbuffer_bits &=
-			INTEL_FRONTBUFFER_ALL_MASK(intel_dp->psr.pipe);
-		intel_dp->psr.busy_frontbuffer_bits |= pipe_frontbuffer_bits;
+#if 0
 
-		if (pipe_frontbuffer_bits)
-			intel_psr_exit(intel_dp);
+static void tgl_psr2_enable_dc3co(struct intel_dp *intel_dp)
+{
+	struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
-		mutex_unlock(&intel_dp->psr.lock);
-	}
+	psr2_program_idle_frames(intel_dp, 0);
+	intel_display_power_set_target_dc_state(dev_priv, DC_STATE_EN_DC3CO);
 }
+
 /*
  * When we will be completely rely on PSR2 S/W tracking in future,
  * intel_psr_flush() will invalidate and flush the PSR for ORIGIN_FLIP
@@ -2032,62 +1935,7 @@ tgl_dc3co_flush(struct intel_dp *intel_dp, unsigned int frontbuffer_bits,
 	mutex_unlock(&intel_dp->psr.lock);
 }
 
-/**
- * intel_psr_flush - Flush PSR
- * @dev_priv: i915 device
- * @frontbuffer_bits: frontbuffer plane tracking bits
- * @origin: which operation caused the flush
- *
- * Since the hardware frontbuffer tracking has gaps we need to integrate
- * with the software frontbuffer tracking. This function gets called every
- * time frontbuffer rendering has completed and flushed out to memory. PSR
- * can be enabled again if no other frontbuffer relevant to PSR is dirty.
- *
- * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits.
- */
-void intel_psr_flush(struct drm_i915_private *dev_priv,
-		     unsigned frontbuffer_bits, enum fb_op_origin origin)
-{
-	struct intel_encoder *encoder;
-
-	for_each_intel_encoder_with_psr(&dev_priv->drm, encoder) {
-		unsigned int pipe_frontbuffer_bits = frontbuffer_bits;
-		struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
-
-		if (origin == ORIGIN_FLIP) {
-			tgl_dc3co_flush(intel_dp, frontbuffer_bits, origin);
-			continue;
-		}
-
-		mutex_lock(&intel_dp->psr.lock);
-		if (!intel_dp->psr.enabled) {
-			mutex_unlock(&intel_dp->psr.lock);
-			continue;
-		}
-
-		pipe_frontbuffer_bits &=
-			INTEL_FRONTBUFFER_ALL_MASK(intel_dp->psr.pipe);
-		intel_dp->psr.busy_frontbuffer_bits &= ~pipe_frontbuffer_bits;
-
-		/*
-		 * If the PSR is paused by an explicit intel_psr_paused() call,
-		 * we have to ensure that the PSR is not activated until
-		 * intel_psr_resume() is called.
-		 */
-		if (intel_dp->psr.paused) {
-			mutex_unlock(&intel_dp->psr.lock);
-			continue;
-		}
-
-		/* By definition flush = invalidate + flush */
-		if (pipe_frontbuffer_bits)
-			psr_force_hw_tracking_exit(intel_dp);
-
-		if (!intel_dp->psr.active && !intel_dp->psr.busy_frontbuffer_bits)
-			schedule_work(&intel_dp->psr.work);
-		mutex_unlock(&intel_dp->psr.lock);
-	}
-}
+#endif
 
 /**
  * intel_psr_init - Init basic PSR work and mutex.
diff --git a/drivers/gpu/drm/i915/display/intel_psr.h b/drivers/gpu/drm/i915/display/intel_psr.h
index 641521b101c82..58e2e5c2b81ef 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.h
+++ b/drivers/gpu/drm/i915/display/intel_psr.h
@@ -6,7 +6,7 @@
 #ifndef __INTEL_PSR_H__
 #define __INTEL_PSR_H__
 
-#include "intel_frontbuffer.h"
+#include <linux/types.h>
 
 struct drm_connector;
 struct drm_connector_state;
@@ -29,12 +29,6 @@ void intel_psr_update(struct intel_dp *intel_dp,
 		      const struct intel_crtc_state *crtc_state,
 		      const struct drm_connector_state *conn_state);
 int intel_psr_debug_set(struct intel_dp *intel_dp, u64 value);
-void intel_psr_invalidate(struct drm_i915_private *dev_priv,
-			  unsigned frontbuffer_bits,
-			  enum fb_op_origin origin);
-void intel_psr_flush(struct drm_i915_private *dev_priv,
-		     unsigned frontbuffer_bits,
-		     enum fb_op_origin origin);
 void intel_psr_init(struct intel_dp *intel_dp);
 void intel_psr_compute_config(struct intel_dp *intel_dp,
 			      struct intel_crtc_state *crtc_state);
-- 
2.33.0


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

* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-09 19:49 [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
  2021-09-09 19:49 ` [Intel-gfx] [PATCH CI 2/2] drm/i915/display: Drop PSR " José Roberto de Souza
@ 2021-09-09 20:02 ` Patchwork
  2021-09-09 20:20 ` [Intel-gfx] [PATCH CI 1/2] " Ville Syrjälä
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2021-09-09 20:02 UTC (permalink / raw)
  To: José Roberto de Souza; +Cc: intel-gfx

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
URL   : https://patchwork.freedesktop.org/series/94522/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
8ed17fa41e37 drm/i915/display/skl+: Drop frontbuffer rendering support
d1a6a5a3ecab drm/i915/display: Drop PSR frontbuffer rendering support
-:251: WARNING:IF_0: Consider removing the code enclosed by this #if 0 and its #endif
#251: FILE: drivers/gpu/drm/i915/display/intel_psr.c:1894:
+#if 0

total: 0 errors, 1 warnings, 0 checks, 298 lines checked



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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-09 19:49 [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
  2021-09-09 19:49 ` [Intel-gfx] [PATCH CI 2/2] drm/i915/display: Drop PSR " José Roberto de Souza
  2021-09-09 20:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/display/skl+: Drop " Patchwork
@ 2021-09-09 20:20 ` Ville Syrjälä
  2021-09-09 20:23   ` Souza, Jose
  2021-09-09 20:33 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] " Patchwork
  2021-09-14  0:17 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support (rev2) Patchwork
  4 siblings, 1 reply; 14+ messages in thread
From: Ville Syrjälä @ 2021-09-09 20:20 UTC (permalink / raw)
  To: José Roberto de Souza
  Cc: intel-gfx, Gwan-gyeong Mun, Daniel Vetter, Jani Nikula, Rodrigo Vivi

On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> By now all the userspace applications should have migrated to atomic
> or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> 
> With that we can kill frontbuffer rendering support in i915 for
> modern platforms.
> 
> So here converting legacy APIs into atomic commits so it can be
> properly handled by driver i915.
> 
> Several IGT tests will fail with this changes, because some tests
> were stressing those frontbuffer rendering scenarios that no userspace
> should be using by now, fixes to IGT should be sent soon.
> 

I just gave this a try here and it's unusable. glxgears went from
9000 to 120 fps (was expecting 60fps tbh, not sure why I get
double), everything lags like mad, if I drag a window around
glxgears/other windows stop updating entirely, etc. NAK

> v2:
> - return earlier to not set fb_tracking.busy/flip_bits
> - added a warn on to make sure we are not setting the busy/flip_bits
> 
> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c    |  6 ++----
>  drivers/gpu/drm/i915/display/intel_fb.c        |  8 +++++++-
>  .../gpu/drm/i915/display/intel_frontbuffer.c   | 18 ++++++++++++++++++
>  drivers/gpu/drm/i915/i915_drv.h                |  2 ++
>  4 files changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c
> index c7618fef01439..5aa996c3b7980 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>  			   u32 src_w, u32 src_h,
>  			   struct drm_modeset_acquire_ctx *ctx)
>  {
> +	struct drm_i915_private *i915 = to_i915(_crtc->dev);
>  	struct intel_plane *plane = to_intel_plane(_plane);
>  	struct intel_crtc *crtc = to_intel_crtc(_crtc);
>  	struct intel_plane_state *old_plane_state =
> @@ -633,12 +634,9 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
>  	 * PSR2 selective fetch also requires the slow path as
>  	 * PSR2 plane and transcoder registers can only be updated during
>  	 * vblank.
> -	 *
> -	 * FIXME bigjoiner fastpath would be good
>  	 */
>  	if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
> -	    crtc_state->update_pipe || crtc_state->bigjoiner ||
> -	    crtc_state->enable_psr2_sel_fetch)
> +	    crtc_state->update_pipe || !HAS_FRONTBUFFER_RENDERING(i915))
>  		goto slow;
>  
>  	/*
> diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c
> index e4b8602ec0cd2..3eb60785c9f29 100644
> --- a/drivers/gpu/drm/i915/display/intel_fb.c
> +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> @@ -3,6 +3,7 @@
>   * Copyright © 2021 Intel Corporation
>   */
>  
> +#include <drm/drm_damage_helper.h>
>  #include <drm/drm_framebuffer.h>
>  #include <drm/drm_modeset_helper.h>
>  
> @@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
>  					unsigned int num_clips)
>  {
>  	struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
>  
>  	i915_gem_object_flush_if_display(obj);
> -	intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
>  
> +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> +		return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
> +						 num_clips);
> +
> +	intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
>  	return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> index 0492446cd04ad..3860f87dac31c 100644
> --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> @@ -112,6 +112,9 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
>  void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
>  				    unsigned frontbuffer_bits)
>  {
> +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> +		return;
> +
>  	spin_lock(&i915->fb_tracking.lock);
>  	i915->fb_tracking.flip_bits |= frontbuffer_bits;
>  	/* Remove stale busy bits due to the old buffer. */
> @@ -132,6 +135,12 @@ void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
>  void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
>  				     unsigned frontbuffer_bits)
>  {
> +	if (!HAS_FRONTBUFFER_RENDERING(i915)) {
> +		drm_WARN_ON_ONCE(&i915->drm, i915->fb_tracking.flip_bits |
> +					     i915->fb_tracking.busy_bits);
> +		return;
> +	}
> +
>  	spin_lock(&i915->fb_tracking.lock);
>  	/* Mask any cancelled flips. */
>  	frontbuffer_bits &= i915->fb_tracking.flip_bits;
> @@ -156,6 +165,9 @@ void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
>  void intel_frontbuffer_flip(struct drm_i915_private *i915,
>  			    unsigned frontbuffer_bits)
>  {
> +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> +		return;
> +
>  	spin_lock(&i915->fb_tracking.lock);
>  	/* Remove stale busy bits due to the old buffer. */
>  	i915->fb_tracking.busy_bits &= ~frontbuffer_bits;
> @@ -170,6 +182,9 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,
>  {
>  	struct drm_i915_private *i915 = to_i915(front->obj->base.dev);
>  
> +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> +		return;
> +
>  	if (origin == ORIGIN_CS) {
>  		spin_lock(&i915->fb_tracking.lock);
>  		i915->fb_tracking.busy_bits |= frontbuffer_bits;
> @@ -191,6 +206,9 @@ void __intel_fb_flush(struct intel_frontbuffer *front,
>  {
>  	struct drm_i915_private *i915 = to_i915(front->obj->base.dev);
>  
> +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> +		return;
> +
>  	if (origin == ORIGIN_CS) {
>  		spin_lock(&i915->fb_tracking.lock);
>  		/* Filter out new bits since rendering started. */
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 37c1ca266bcdf..3324ba8d8523c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1699,6 +1699,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>  
>  #define HAS_ASYNC_FLIPS(i915)		(DISPLAY_VER(i915) >= 5)
>  
> +#define HAS_FRONTBUFFER_RENDERING(i915)	(DISPLAY_VER(i915) < 9)
> +
>  /* Only valid when HAS_DISPLAY() is true */
>  #define INTEL_DISPLAY_ENABLED(dev_priv) \
>  	(drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)), !(dev_priv)->params.disable_display)
> -- 
> 2.33.0

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-09 20:20 ` [Intel-gfx] [PATCH CI 1/2] " Ville Syrjälä
@ 2021-09-09 20:23   ` Souza, Jose
  2021-09-09 20:28     ` Ville Syrjälä
  0 siblings, 1 reply; 14+ messages in thread
From: Souza, Jose @ 2021-09-09 20:23 UTC (permalink / raw)
  To: ville.syrjala
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > By now all the userspace applications should have migrated to atomic
> > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > 
> > With that we can kill frontbuffer rendering support in i915 for
> > modern platforms.
> > 
> > So here converting legacy APIs into atomic commits so it can be
> > properly handled by driver i915.
> > 
> > Several IGT tests will fail with this changes, because some tests
> > were stressing those frontbuffer rendering scenarios that no userspace
> > should be using by now, fixes to IGT should be sent soon.
> > 
> 
> I just gave this a try here and it's unusable. glxgears went from
> 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> double), everything lags like mad, if I drag a window around
> glxgears/other windows stop updating entirely, etc. NAK

Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
Will try it in my end.

> 
> > v2:
> > - return earlier to not set fb_tracking.busy/flip_bits
> > - added a warn on to make sure we are not setting the busy/flip_bits
> > 
> > Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > ---
> >  drivers/gpu/drm/i915/display/intel_cursor.c    |  6 ++----
> >  drivers/gpu/drm/i915/display/intel_fb.c        |  8 +++++++-
> >  .../gpu/drm/i915/display/intel_frontbuffer.c   | 18 ++++++++++++++++++
> >  drivers/gpu/drm/i915/i915_drv.h                |  2 ++
> >  4 files changed, 29 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c b/drivers/gpu/drm/i915/display/intel_cursor.c
> > index c7618fef01439..5aa996c3b7980 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> > @@ -617,6 +617,7 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> >  			   u32 src_w, u32 src_h,
> >  			   struct drm_modeset_acquire_ctx *ctx)
> >  {
> > +	struct drm_i915_private *i915 = to_i915(_crtc->dev);
> >  	struct intel_plane *plane = to_intel_plane(_plane);
> >  	struct intel_crtc *crtc = to_intel_crtc(_crtc);
> >  	struct intel_plane_state *old_plane_state =
> > @@ -633,12 +634,9 @@ intel_legacy_cursor_update(struct drm_plane *_plane,
> >  	 * PSR2 selective fetch also requires the slow path as
> >  	 * PSR2 plane and transcoder registers can only be updated during
> >  	 * vblank.
> > -	 *
> > -	 * FIXME bigjoiner fastpath would be good
> >  	 */
> >  	if (!crtc_state->hw.active || intel_crtc_needs_modeset(crtc_state) ||
> > -	    crtc_state->update_pipe || crtc_state->bigjoiner ||
> > -	    crtc_state->enable_psr2_sel_fetch)
> > +	    crtc_state->update_pipe || !HAS_FRONTBUFFER_RENDERING(i915))
> >  		goto slow;
> >  
> >  	/*
> > diff --git a/drivers/gpu/drm/i915/display/intel_fb.c b/drivers/gpu/drm/i915/display/intel_fb.c
> > index e4b8602ec0cd2..3eb60785c9f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_fb.c
> > +++ b/drivers/gpu/drm/i915/display/intel_fb.c
> > @@ -3,6 +3,7 @@
> >   * Copyright © 2021 Intel Corporation
> >   */
> >  
> > +#include <drm/drm_damage_helper.h>
> >  #include <drm/drm_framebuffer.h>
> >  #include <drm/drm_modeset_helper.h>
> >  
> > @@ -1235,10 +1236,15 @@ static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
> >  					unsigned int num_clips)
> >  {
> >  	struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > +	struct drm_i915_private *i915 = to_i915(obj->base.dev);
> >  
> >  	i915_gem_object_flush_if_display(obj);
> > -	intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
> >  
> > +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> > +		return drm_atomic_helper_dirtyfb(fb, file, flags, color, clips,
> > +						 num_clips);
> > +
> > +	intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
> >  	return 0;
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/display/intel_frontbuffer.c b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> > index 0492446cd04ad..3860f87dac31c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> > +++ b/drivers/gpu/drm/i915/display/intel_frontbuffer.c
> > @@ -112,6 +112,9 @@ static void frontbuffer_flush(struct drm_i915_private *i915,
> >  void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
> >  				    unsigned frontbuffer_bits)
> >  {
> > +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> > +		return;
> > +
> >  	spin_lock(&i915->fb_tracking.lock);
> >  	i915->fb_tracking.flip_bits |= frontbuffer_bits;
> >  	/* Remove stale busy bits due to the old buffer. */
> > @@ -132,6 +135,12 @@ void intel_frontbuffer_flip_prepare(struct drm_i915_private *i915,
> >  void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
> >  				     unsigned frontbuffer_bits)
> >  {
> > +	if (!HAS_FRONTBUFFER_RENDERING(i915)) {
> > +		drm_WARN_ON_ONCE(&i915->drm, i915->fb_tracking.flip_bits |
> > +					     i915->fb_tracking.busy_bits);
> > +		return;
> > +	}
> > +
> >  	spin_lock(&i915->fb_tracking.lock);
> >  	/* Mask any cancelled flips. */
> >  	frontbuffer_bits &= i915->fb_tracking.flip_bits;
> > @@ -156,6 +165,9 @@ void intel_frontbuffer_flip_complete(struct drm_i915_private *i915,
> >  void intel_frontbuffer_flip(struct drm_i915_private *i915,
> >  			    unsigned frontbuffer_bits)
> >  {
> > +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> > +		return;
> > +
> >  	spin_lock(&i915->fb_tracking.lock);
> >  	/* Remove stale busy bits due to the old buffer. */
> >  	i915->fb_tracking.busy_bits &= ~frontbuffer_bits;
> > @@ -170,6 +182,9 @@ void __intel_fb_invalidate(struct intel_frontbuffer *front,
> >  {
> >  	struct drm_i915_private *i915 = to_i915(front->obj->base.dev);
> >  
> > +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> > +		return;
> > +
> >  	if (origin == ORIGIN_CS) {
> >  		spin_lock(&i915->fb_tracking.lock);
> >  		i915->fb_tracking.busy_bits |= frontbuffer_bits;
> > @@ -191,6 +206,9 @@ void __intel_fb_flush(struct intel_frontbuffer *front,
> >  {
> >  	struct drm_i915_private *i915 = to_i915(front->obj->base.dev);
> >  
> > +	if (!HAS_FRONTBUFFER_RENDERING(i915))
> > +		return;
> > +
> >  	if (origin == ORIGIN_CS) {
> >  		spin_lock(&i915->fb_tracking.lock);
> >  		/* Filter out new bits since rendering started. */
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> > index 37c1ca266bcdf..3324ba8d8523c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1699,6 +1699,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> >  
> >  #define HAS_ASYNC_FLIPS(i915)		(DISPLAY_VER(i915) >= 5)
> >  
> > +#define HAS_FRONTBUFFER_RENDERING(i915)	(DISPLAY_VER(i915) < 9)
> > +
> >  /* Only valid when HAS_DISPLAY() is true */
> >  #define INTEL_DISPLAY_ENABLED(dev_priv) \
> >  	(drm_WARN_ON(&(dev_priv)->drm, !HAS_DISPLAY(dev_priv)), !(dev_priv)->params.disable_display)
> > -- 
> > 2.33.0
> 


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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-09 20:23   ` Souza, Jose
@ 2021-09-09 20:28     ` Ville Syrjälä
  2021-09-13 22:54       ` Souza, Jose
  0 siblings, 1 reply; 14+ messages in thread
From: Ville Syrjälä @ 2021-09-09 20:28 UTC (permalink / raw)
  To: Souza, Jose
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > By now all the userspace applications should have migrated to atomic
> > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > 
> > > With that we can kill frontbuffer rendering support in i915 for
> > > modern platforms.
> > > 
> > > So here converting legacy APIs into atomic commits so it can be
> > > properly handled by driver i915.
> > > 
> > > Several IGT tests will fail with this changes, because some tests
> > > were stressing those frontbuffer rendering scenarios that no userspace
> > > should be using by now, fixes to IGT should be sent soon.
> > > 
> > 
> > I just gave this a try here and it's unusable. glxgears went from
> > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > double), everything lags like mad, if I drag a window around
> > glxgears/other windows stop updating entirely, etc. NAK
> 
> Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> Will try it in my end.

Doesn't really matter as long as you don't have a compositor making a
mess of things. This machine is a cfl running mate w/ compositor off,
and some 1920x1200 display.

-- 
Ville Syrjälä
Intel

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

* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-09 19:49 [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
                   ` (2 preceding siblings ...)
  2021-09-09 20:20 ` [Intel-gfx] [PATCH CI 1/2] " Ville Syrjälä
@ 2021-09-09 20:33 ` Patchwork
  2021-09-14  0:17 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support (rev2) Patchwork
  4 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2021-09-09 20:33 UTC (permalink / raw)
  To: Souza, Jose; +Cc: intel-gfx

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

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
URL   : https://patchwork.freedesktop.org/series/94522/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21007
====================================================

Summary
-------

  **FAILURE**

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

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

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

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

### IGT changes ###

#### Possible regressions ####

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-skl-guc:         [PASS][1] -> [FAIL][2] +3 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-skl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-skl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-rkl-11600:       [PASS][3] -> [FAIL][4] +3 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-rkl-11600/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-rkl-11600/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-tgl-y:           [PASS][5] -> [FAIL][6] +3 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-tgl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-tgl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-cfl-guc:         [PASS][7] -> [FAIL][8] +3 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-cfl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-cfl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-icl-y:           [PASS][9] -> [FAIL][10] +3 similar issues
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-icl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-icl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-rkl-guc:         [PASS][11] -> [FAIL][12] +3 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-rkl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-rkl-guc/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-skl-6700k2:      [PASS][13] -> [FAIL][14] +3 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-skl-6700k2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-skl-6700k2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
    - fi-icl-u2:          [PASS][15] -> [FAIL][16] +3 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-cfl-8700k:       [PASS][17] -> [FAIL][18] +3 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-cfl-8700k/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-cfl-8700k/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-cfl-8109u:       [PASS][19] -> [FAIL][20] +3 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-cfl-8109u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-cfl-8109u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-glk-dsi:         [PASS][21] -> [FAIL][22] +3 similar issues
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-glk-dsi/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-glk-dsi/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-kbl-soraka:      [PASS][23] -> [FAIL][24] +3 similar issues
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-kbl-soraka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-kbl-soraka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
    - fi-kbl-r:           [PASS][25] -> [FAIL][26] +3 similar issues
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-kbl-r/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-kbl-r/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
    - fi-bxt-dsi:         [PASS][27] -> [FAIL][28] +3 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-bxt-dsi/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-bxt-dsi/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
    - fi-tgl-1115g4:      [PASS][29] -> [FAIL][30] +3 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-tgl-1115g4/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-tgl-1115g4/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
    - fi-skl-6600u:       [PASS][31] -> [FAIL][32] +3 similar issues
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-skl-6600u/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-skl-6600u/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
    - fi-cml-u2:          [PASS][33] -> [FAIL][34] +3 similar issues
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-cml-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-cml-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html

  
#### Suppressed ####

  The following results come from untrusted machines, tests, or statuses.
  They do not affect the overall result.

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - {fi-ehl-2}:         [PASS][35] -> [FAIL][36] +3 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-ehl-2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-ehl-2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
    - {fi-tgl-dsi}:       [PASS][37] -> [FAIL][38] +3 similar issues
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-tgl-dsi/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-tgl-dsi/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html

  * igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
    - {fi-jsl-1}:         [PASS][39] -> [FAIL][40] +3 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-jsl-1/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@amdgpu/amd_basic@semaphore:
    - fi-bdw-5557u:       NOTRUN -> [SKIP][41] ([fdo#109271]) +27 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-bdw-5557u/igt@amdgpu/amd_basic@semaphore.html

  * igt@core_hotunplug@unbind-rebind:
    - fi-bdw-5557u:       NOTRUN -> [WARN][42] ([i915#3718])
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-bdw-5557u/igt@core_hotunplug@unbind-rebind.html

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-rkl-guc:         [PASS][43] -> [SKIP][44] ([fdo#109308])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-rkl-guc/igt@i915_pm_rpm@basic-pci-d3-state.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-rkl-guc/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@i915_selftest@live@gt_mocs:
    - fi-tgl-1115g4:      [PASS][45] -> [DMESG-WARN][46] ([i915#2867]) +14 similar issues
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-tgl-1115g4/igt@i915_selftest@live@gt_mocs.html

  * igt@i915_selftest@live@hangcheck:
    - fi-snb-2600:        [PASS][47] -> [INCOMPLETE][48] ([i915#3921])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-snb-2600/igt@i915_selftest@live@hangcheck.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-snb-2600/igt@i915_selftest@live@hangcheck.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-bdw-5557u:       NOTRUN -> [SKIP][49] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-bdw-5557u/igt@kms_chamelium@dp-crc-fast.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@gt_pm:
    - {fi-jsl-1}:         [DMESG-FAIL][50] ([i915#1886]) -> [PASS][51]
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10565/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21007/fi-jsl-1/igt@i915_selftest@live@gt_pm.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109308]: https://bugs.freedesktop.org/show_bug.cgi?id=109308
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886
  [i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#3718]: https://gitlab.freedesktop.org/drm/intel/issues/3718
  [i915#3921]: https://gitlab.freedesktop.org/drm/intel/issues/3921


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

  Missing    (8): fi-ilk-m540 bat-adls-5 bat-dg1-6 fi-bsw-cyan bat-adlp-4 fi-ctg-p8600 fi-bdw-samus bat-jsl-1 


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

  * Linux: CI_DRM_10565 -> Patchwork_21007

  CI-20190529: 20190529
  CI_DRM_10565: 8c3cd60dcfa81a649b14f0705eb5e5c9336f1881 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_6201: be0d02ff0775235ead63ccb1e3a1e8c10f0209cf @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
  Patchwork_21007: d1a6a5a3ecab2736feb7528f8ba7b32089c5a418 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d1a6a5a3ecab drm/i915/display: Drop PSR frontbuffer rendering support
8ed17fa41e37 drm/i915/display/skl+: Drop frontbuffer rendering support

== Logs ==

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

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

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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-09 20:28     ` Ville Syrjälä
@ 2021-09-13 22:54       ` Souza, Jose
  2021-09-15 13:48         ` Ville Syrjälä
  0 siblings, 1 reply; 14+ messages in thread
From: Souza, Jose @ 2021-09-13 22:54 UTC (permalink / raw)
  To: ville.syrjala, daniel
  Cc: Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

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

On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > By now all the userspace applications should have migrated to atomic
> > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > 
> > > > With that we can kill frontbuffer rendering support in i915 for
> > > > modern platforms.
> > > > 
> > > > So here converting legacy APIs into atomic commits so it can be
> > > > properly handled by driver i915.
> > > > 
> > > > Several IGT tests will fail with this changes, because some tests
> > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > should be using by now, fixes to IGT should be sent soon.
> > > > 
> > > 
> > > I just gave this a try here and it's unusable. glxgears went from
> > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > double), everything lags like mad, if I drag a window around
> > > glxgears/other windows stop updating entirely, etc. NAK
> > 
> > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > Will try it in my end.
> 
> Doesn't really matter as long as you don't have a compositor making a
> mess of things. This machine is a cfl running mate w/ compositor off,
> and some 1920x1200 display.
> 

Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ


I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.

Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
their behavior changed.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-HACK-Make-drm_atomic_helper_dirtyfb-non-blocking.patch --]
[-- Type: text/x-patch; name="0001-HACK-Make-drm_atomic_helper_dirtyfb-non-blocking.patch", Size: 1244 bytes --]

From 47c5b1f918363686cd8cf51239a298dd78f9fae6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20Roberto=20de=20Souza?= <jose.souza@intel.com>
Date: Mon, 13 Sep 2021 14:16:31 -0700
Subject: [PATCH] HACK: Make drm_atomic_helper_dirtyfb() non-blocking
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hack just to show up that making non-blocking atomic commits helps
to compensate the performance regressions when converting frotbuffer
dirty calls to drm_atomic_helper_dirtyfb() in desktop enviroments
without compositing.

I know that this goes against the documentation in
drm_atomic_helper_dirtyfb().

Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
---
 drivers/gpu/drm/drm_damage_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_damage_helper.c b/drivers/gpu/drm/drm_damage_helper.c
index 8eeff0c7bdd47..1740144674ce3 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -177,7 +177,7 @@ int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
 					  damage);
 	}
 
-	ret = drm_atomic_commit(state);
+	ret = drm_atomic_nonblocking_commit(state);
 
 out:
 	if (ret == -EDEADLK) {
-- 
2.33.0


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

* [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support (rev2)
  2021-09-09 19:49 [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
                   ` (3 preceding siblings ...)
  2021-09-09 20:33 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] " Patchwork
@ 2021-09-14  0:17 ` Patchwork
  4 siblings, 0 replies; 14+ messages in thread
From: Patchwork @ 2021-09-14  0:17 UTC (permalink / raw)
  To: Souza, Jose; +Cc: intel-gfx

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support (rev2)
URL   : https://patchwork.freedesktop.org/series/94522/
State : failure

== Summary ==

Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".



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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-13 22:54       ` Souza, Jose
@ 2021-09-15 13:48         ` Ville Syrjälä
  2021-09-15 15:57           ` Ville Syrjälä
  2021-09-15 19:50           ` Souza, Jose
  0 siblings, 2 replies; 14+ messages in thread
From: Ville Syrjälä @ 2021-09-15 13:48 UTC (permalink / raw)
  To: Souza, Jose
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote:
> On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > > By now all the userspace applications should have migrated to atomic
> > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > > 
> > > > > With that we can kill frontbuffer rendering support in i915 for
> > > > > modern platforms.
> > > > > 
> > > > > So here converting legacy APIs into atomic commits so it can be
> > > > > properly handled by driver i915.
> > > > > 
> > > > > Several IGT tests will fail with this changes, because some tests
> > > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > > should be using by now, fixes to IGT should be sent soon.
> > > > > 
> > > > 
> > > > I just gave this a try here and it's unusable. glxgears went from
> > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > > double), everything lags like mad, if I drag a window around
> > > > glxgears/other windows stop updating entirely, etc. NAK
> > > 
> > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > > Will try it in my end.
> > 
> > Doesn't really matter as long as you don't have a compositor making a
> > mess of things. This machine is a cfl running mate w/ compositor off,
> > and some 1920x1200 display.
> > 
> 
> Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
> drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
> drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
> drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
> 
> 
> I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
> With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
> 
> Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
> their behavior changed.

Non-blocking update would make sense to me, whereas a blocking
update makes no sense given how this is used by actual userspace.

But this still changes the whole approach to eg. FBC nukes, so it's
going to require some actual thought and testing to make sure it
actually works as intended. I think by just essentially page flipping
to the same buffer we're going to depend on semi-undefined behaviour
for FBC. So I'm a bit worried that this is going to introduce new bugs.
I have verified on ancient platforms that FBC does in fact flip nuke
when flipping to the same buffer (and now we even (ab)use that fact
in the frontbuffer tracking code), but I've not done that for any new
platforms.

The other concern is that introducing additional atomic commits this
might trip up the page flip->-EBUSY stuff. Whether that is going
to cause any real grief to userspace is unknown at this time. I guess
we'd have to come up with a test that actually hits that and make sure
the ddx doesn't get confused and instead just gracefully falls back to
the blit path.

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-15 13:48         ` Ville Syrjälä
@ 2021-09-15 15:57           ` Ville Syrjälä
  2021-09-15 16:49             ` Ville Syrjälä
  2021-09-15 19:50           ` Souza, Jose
  1 sibling, 1 reply; 14+ messages in thread
From: Ville Syrjälä @ 2021-09-15 15:57 UTC (permalink / raw)
  To: Souza, Jose
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Wed, Sep 15, 2021 at 04:48:49PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote:
> > On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > > > By now all the userspace applications should have migrated to atomic
> > > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > > > 
> > > > > > With that we can kill frontbuffer rendering support in i915 for
> > > > > > modern platforms.
> > > > > > 
> > > > > > So here converting legacy APIs into atomic commits so it can be
> > > > > > properly handled by driver i915.
> > > > > > 
> > > > > > Several IGT tests will fail with this changes, because some tests
> > > > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > > > should be using by now, fixes to IGT should be sent soon.
> > > > > > 
> > > > > 
> > > > > I just gave this a try here and it's unusable. glxgears went from
> > > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > > > double), everything lags like mad, if I drag a window around
> > > > > glxgears/other windows stop updating entirely, etc. NAK
> > > > 
> > > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > > > Will try it in my end.
> > > 
> > > Doesn't really matter as long as you don't have a compositor making a
> > > mess of things. This machine is a cfl running mate w/ compositor off,
> > > and some 1920x1200 display.
> > > 
> > 
> > Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
> > drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
> > drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
> > drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
> > 
> > 
> > I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
> > With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
> > 
> > Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
> > their behavior changed.
> 
> Non-blocking update would make sense to me, whereas a blocking
> update makes no sense given how this is used by actual userspace.

Actually neither maybe makes total sense since userspace probably
isn't expecting -EBUSY from dirtyfb. So we might end up with stale
junk on the screen if no further updates come in after an -EBUSY.

The current frontbuffer stuff works much more like a mailbox style
update so we don't lose stuff and neither do we block.

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-15 15:57           ` Ville Syrjälä
@ 2021-09-15 16:49             ` Ville Syrjälä
  2021-09-15 20:05               ` Souza, Jose
  0 siblings, 1 reply; 14+ messages in thread
From: Ville Syrjälä @ 2021-09-15 16:49 UTC (permalink / raw)
  To: Souza, Jose
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Wed, Sep 15, 2021 at 06:57:19PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 15, 2021 at 04:48:49PM +0300, Ville Syrjälä wrote:
> > On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote:
> > > On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > > > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > > > > By now all the userspace applications should have migrated to atomic
> > > > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > > > > 
> > > > > > > With that we can kill frontbuffer rendering support in i915 for
> > > > > > > modern platforms.
> > > > > > > 
> > > > > > > So here converting legacy APIs into atomic commits so it can be
> > > > > > > properly handled by driver i915.
> > > > > > > 
> > > > > > > Several IGT tests will fail with this changes, because some tests
> > > > > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > > > > should be using by now, fixes to IGT should be sent soon.
> > > > > > > 
> > > > > > 
> > > > > > I just gave this a try here and it's unusable. glxgears went from
> > > > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > > > > double), everything lags like mad, if I drag a window around
> > > > > > glxgears/other windows stop updating entirely, etc. NAK
> > > > > 
> > > > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > > > > Will try it in my end.
> > > > 
> > > > Doesn't really matter as long as you don't have a compositor making a
> > > > mess of things. This machine is a cfl running mate w/ compositor off,
> > > > and some 1920x1200 display.
> > > > 
> > > 
> > > Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
> > > drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
> > > drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
> > > drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
> > > 
> > > 
> > > I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
> > > With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
> > > 
> > > Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
> > > their behavior changed.
> > 
> > Non-blocking update would make sense to me, whereas a blocking
> > update makes no sense given how this is used by actual userspace.
> 
> Actually neither maybe makes total sense since userspace probably
> isn't expecting -EBUSY from dirtyfb. So we might end up with stale
> junk on the screen if no further updates come in after an -EBUSY.

One option would be to teach userspace to retry after an -EBUSY, but
without a completion event from dirtyfb it's going to be hard to know
when to retry.

> 
> The current frontbuffer stuff works much more like a mailbox style
> update so we don't lose stuff and neither do we block.

I suppose the obvious solution would be to teach kms to do proper
mailbox updates. But that is not entirely trivial. One way to simplify
the proposal a bit is to limit it to pure pageflips, which would
suffice for dirtyfb as well obviously. That way watermarks and other
potentially tricky stuff wouldn't change.

But actually figuring out the proper commit sequence for this might
take some doing. The way I think it should work is that we just let
each commit through without blocking on the previous one. A later
commit may simply overwrite the hardware registers before the
values written by the previous commit get latched. The vblank evasion
stuff would make it perfectly safe.

The hardest thing there is probably figuring out how to handle all
the pre/post_plane_update() stuff  properly since we can't know
ahead of time whether the flip gets latched or not, and so we can't
really use the old state during state computation to make any
decisions affecting our future behaviour. But given that async flips
are more or less working today might mean that I'm worried about nothing.
Either that or async flips are in fact broken in some funny ways I've not
yet realized...

The other problem for actual mailbox page flips is completion events/out
fences. The current out fence I think is not really suitable for cases
where a flip ends up getting overwritten by a later one, and thus the
fb rotation no longer follows the normal fifo order. But of we don't
expose actual mailbox page flips through the uapi then we could avoid
worrying about this stuff initially.

-- 
Ville Syrjälä
Intel

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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-15 13:48         ` Ville Syrjälä
  2021-09-15 15:57           ` Ville Syrjälä
@ 2021-09-15 19:50           ` Souza, Jose
  1 sibling, 0 replies; 14+ messages in thread
From: Souza, Jose @ 2021-09-15 19:50 UTC (permalink / raw)
  To: ville.syrjala
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Wed, 2021-09-15 at 16:48 +0300, Ville Syrjälä wrote:
> On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote:
> > On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > > > By now all the userspace applications should have migrated to atomic
> > > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > > > 
> > > > > > With that we can kill frontbuffer rendering support in i915 for
> > > > > > modern platforms.
> > > > > > 
> > > > > > So here converting legacy APIs into atomic commits so it can be
> > > > > > properly handled by driver i915.
> > > > > > 
> > > > > > Several IGT tests will fail with this changes, because some tests
> > > > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > > > should be using by now, fixes to IGT should be sent soon.
> > > > > > 
> > > > > 
> > > > > I just gave this a try here and it's unusable. glxgears went from
> > > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > > > double), everything lags like mad, if I drag a window around
> > > > > glxgears/other windows stop updating entirely, etc. NAK
> > > > 
> > > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > > > Will try it in my end.
> > > 
> > > Doesn't really matter as long as you don't have a compositor making a
> > > mess of things. This machine is a cfl running mate w/ compositor off,
> > > and some 1920x1200 display.
> > > 
> > 
> > Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
> > drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
> > drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
> > drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
> > 
> > 
> > I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
> > With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
> > 
> > Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
> > their behavior changed.
> 
> Non-blocking update would make sense to me, whereas a blocking
> update makes no sense given how this is used by actual userspace.
> 
> But this still changes the whole approach to eg. FBC nukes, so it's
> going to require some actual thought and testing to make sure it
> actually works as intended. I think by just essentially page flipping
> to the same buffer we're going to depend on semi-undefined behaviour
> for FBC. So I'm a bit worried that this is going to introduce new bugs.
> I have verified on ancient platforms that FBC does in fact flip nuke
> when flipping to the same buffer (and now we even (ab)use that fact
> in the frontbuffer tracking code), but I've not done that for any new
> platforms.

I believe the current fbc tests in kms_frontbuffer_tracking already stress this.
For PSR2 hardware tracking in SKL and TGL I have validated(PSR2 is not covered by kms_frontbuffer_tracking due pipe CRC not work with it) this and
flipping to the same buffer causes the hardware to properly update the screen.

> 
> The other concern is that introducing additional atomic commits this
> might trip up the page flip->-EBUSY stuff. Whether that is going
> to cause any real grief to userspace is unknown at this time. I guess
> we'd have to come up with a test that actually hits that and make sure
> the ddx doesn't get confused and instead just gracefully falls back to
> the blit path.
> 


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

* Re: [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support
  2021-09-15 16:49             ` Ville Syrjälä
@ 2021-09-15 20:05               ` Souza, Jose
  0 siblings, 0 replies; 14+ messages in thread
From: Souza, Jose @ 2021-09-15 20:05 UTC (permalink / raw)
  To: ville.syrjala
  Cc: daniel, Mun, Gwan-gyeong, Nikula, Jani, intel-gfx, Vivi, Rodrigo

On Wed, 2021-09-15 at 19:49 +0300, Ville Syrjälä wrote:
> On Wed, Sep 15, 2021 at 06:57:19PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 15, 2021 at 04:48:49PM +0300, Ville Syrjälä wrote:
> > > On Mon, Sep 13, 2021 at 10:54:14PM +0000, Souza, Jose wrote:
> > > > On Thu, 2021-09-09 at 23:28 +0300, Ville Syrjälä wrote:
> > > > > On Thu, Sep 09, 2021 at 08:23:20PM +0000, Souza, Jose wrote:
> > > > > > On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > > > > > > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > > > > > > By now all the userspace applications should have migrated to atomic
> > > > > > > > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> > > > > > > > 
> > > > > > > > With that we can kill frontbuffer rendering support in i915 for
> > > > > > > > modern platforms.
> > > > > > > > 
> > > > > > > > So here converting legacy APIs into atomic commits so it can be
> > > > > > > > properly handled by driver i915.
> > > > > > > > 
> > > > > > > > Several IGT tests will fail with this changes, because some tests
> > > > > > > > were stressing those frontbuffer rendering scenarios that no userspace
> > > > > > > > should be using by now, fixes to IGT should be sent soon.
> > > > > > > > 
> > > > > > > 
> > > > > > > I just gave this a try here and it's unusable. glxgears went from
> > > > > > > 9000 to 120 fps (was expecting 60fps tbh, not sure why I get
> > > > > > > double), everything lags like mad, if I drag a window around
> > > > > > > glxgears/other windows stop updating entirely, etc. NAK
> > > > > > 
> > > > > > Can you share your setup? What GPU? Desktop environment? Mesa version? resolutions of sinks?
> > > > > > Will try it in my end.
> > > > > 
> > > > > Doesn't really matter as long as you don't have a compositor making a
> > > > > mess of things. This machine is a cfl running mate w/ compositor off,
> > > > > and some 1920x1200 display.
> > > > > 
> > > > 
> > > > Making drm_atomic_helper_dirtyfb() do a non-blocking atomic commit makes user experience pretty similar to the one with compositing enabled:
> > > > drm_atomic_commit() + compositor off: https://youtu.be/NBt6smXs99U
> > > > drm_atomic_nonblocking_commit() + compositor off: https://youtu.be/QiMhkeGX_L8
> > > > drm_atomic_nonblocking_commit() + compositor on: https://youtu.be/KdpJyJ5k6sQ
> > > > 
> > > > 
> > > > I do not completly agree with the comment in drm_atomic_helper_dirtyfb() about why it uses a blocking implementation.
> > > > With frontbuffer rendering the registers are programmed but the content could only show up for user a whole frame later.
> > > > 
> > > > Perhaps if this solutions is accetable we could have a non-blocking version of drm_atomic_helper_dirtyfb() so the drivers current using it don't have
> > > > their behavior changed.
> > > 
> > > Non-blocking update would make sense to me, whereas a blocking
> > > update makes no sense given how this is used by actual userspace.
> > 
> > Actually neither maybe makes total sense since userspace probably
> > isn't expecting -EBUSY from dirtyfb. So we might end up with stale
> > junk on the screen if no further updates come in after an -EBUSY.

1000 dirtyfb calls will only have a different dirty areas, when executing a dirtyfb atomic commit we could append all the pending dirty areas into
this atomic commit and remove all the pending dirtyfb atomic commits.
I doubt that userspace will be able to fill WQ_MAX_ACTIVE dirtyfb calls in one single frame.

> 
> One option would be to teach userspace to retry after an -EBUSY, but
> without a completion event from dirtyfb it's going to be hard to know
> when to retry.
> 
> > 
> > The current frontbuffer stuff works much more like a mailbox style
> > update so we don't lose stuff and neither do we block.
> 
> I suppose the obvious solution would be to teach kms to do proper
> mailbox updates. But that is not entirely trivial. One way to simplify
> the proposal a bit is to limit it to pure pageflips, which would
> suffice for dirtyfb as well obviously. That way watermarks and other
> potentially tricky stuff wouldn't change.
> 
> But actually figuring out the proper commit sequence for this might
> take some doing. The way I think it should work is that we just let
> each commit through without blocking on the previous one. A later
> commit may simply overwrite the hardware registers before the
> values written by the previous commit get latched. The vblank evasion
> stuff would make it perfectly safe.
> 
> The hardest thing there is probably figuring out how to handle all
> the pre/post_plane_update() stuff  properly since we can't know
> ahead of time whether the flip gets latched or not, and so we can't
> really use the old state during state computation to make any
> decisions affecting our future behaviour. But given that async flips
> are more or less working today might mean that I'm worried about nothing.
> Either that or async flips are in fact broken in some funny ways I've not
> yet realized...
> 
> The other problem for actual mailbox page flips is completion events/out
> fences. The current out fence I think is not really suitable for cases
> where a flip ends up getting overwritten by a later one, and thus the
> fb rotation no longer follows the normal fifo order. But of we don't
> expose actual mailbox page flips through the uapi then we could avoid
> worrying about this stuff initially.
> 


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

end of thread, other threads:[~2021-09-15 20:05 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-09 19:49 [Intel-gfx] [PATCH CI 1/2] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
2021-09-09 19:49 ` [Intel-gfx] [PATCH CI 2/2] drm/i915/display: Drop PSR " José Roberto de Souza
2021-09-09 20:02 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/2] drm/i915/display/skl+: Drop " Patchwork
2021-09-09 20:20 ` [Intel-gfx] [PATCH CI 1/2] " Ville Syrjälä
2021-09-09 20:23   ` Souza, Jose
2021-09-09 20:28     ` Ville Syrjälä
2021-09-13 22:54       ` Souza, Jose
2021-09-15 13:48         ` Ville Syrjälä
2021-09-15 15:57           ` Ville Syrjälä
2021-09-15 16:49             ` Ville Syrjälä
2021-09-15 20:05               ` Souza, Jose
2021-09-15 19:50           ` Souza, Jose
2021-09-09 20:33 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] " Patchwork
2021-09-14  0:17 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer rendering support (rev2) Patchwork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).