public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
To: "José Roberto de Souza" <jose.souza@intel.com>,
	intel-gfx@lists.freedesktop.org
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Jani Nikula" <jani.nikula@intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support
Date: Thu, 2 Sep 2021 21:42:08 +0300	[thread overview]
Message-ID: <eac0bca4-4b41-5a54-4b36-b439e4efd9fb@intel.com> (raw)
In-Reply-To: <20210825005840.170796-8-jose.souza@intel.com>



On 8/25/21 3:58 AM, 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.
> 
> 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
> 
> 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);
Hi,
Even if the userspace informs us of the dirty (damage) region of the 
front buffer being used, GEN9 to GEN12 still uses the HW Tracking 
function for PSR and FBC.
And if you look at the description of the intel_psr_flush() function, 
you can see that there are the following restrictions.

"Since the hardware frontbuffer tracking has gaps we need to integrate 
with the software frontbuffer tracking."

If this restriction is still valid from GEN9 to GEN12, even if the 
existing frontbuffer tracking function is not used, when 
intel_user_framebuffer_dirty() is called, in the case of PSR, 
psr_force_hw_tracking_exit() is called or intel_psr_exit() and 
schedule_work(psr.work) seems to be required.

In the case of FBC, it seems that calls to FBC deactive / FBC activate 
should be added.

If GEN9 to GEN12 do not have the above restrictions, please ignore this 
comment.

G.G.
> +
> +	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 91453f7dbd656..20c135a2bba33 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1721,6 +1721,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)
> 

  reply	other threads:[~2021-09-02 18:42 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25  0:58 [Intel-gfx] [PATCH v2 0/8] Drop frontbuffer rendering support from Skylake and newer José Roberto de Souza
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 1/8] drm/i915/display: Drop PSR support from HSW and BDW José Roberto de Souza
2021-08-25 15:50   ` Rodrigo Vivi
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 2/8] drm/i915/display: Move DRRS code its own file José Roberto de Souza
2021-08-25 15:55   ` Rodrigo Vivi
2021-08-25 17:23     ` Souza, Jose
2021-08-25 18:52       ` Rodrigo Vivi
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 3/8] drm/i915/display: Renaming DRRS functions to intel_drrs_*() José Roberto de Souza
2021-08-25 15:56   ` Rodrigo Vivi
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 4/8] drm/i915/display: Some code improvements and code style fixes for DRRS José Roberto de Souza
2021-09-02 15:15   ` Gwan-gyeong Mun
2021-09-03 20:36     ` Souza, Jose
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 5/8] drm/i915/display: Share code between intel_drrs_flush and intel_drrs_invalidate José Roberto de Souza
2021-09-02 15:57   ` Gwan-gyeong Mun
2021-09-03 21:52     ` Souza, Jose
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 6/8] drm/i915/display: Prepare DRRS for frontbuffer rendering drop José Roberto de Souza
2021-09-02 16:09   ` Gwan-gyeong Mun
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 7/8] drm/i915/display/skl+: Drop frontbuffer rendering support José Roberto de Souza
2021-09-02 18:42   ` Gwan-gyeong Mun [this message]
2021-09-03 22:09     ` Souza, Jose
2021-09-04  0:26       ` Souza, Jose
2021-09-06  9:44         ` Gwan-gyeong Mun
2021-08-25  0:58 ` [Intel-gfx] [PATCH v2 8/8] drm/i915/display: Drop PSR " José Roberto de Souza
2021-09-06 16:05   ` Gwan-gyeong Mun
2021-08-25  1:01 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Drop frontbuffer rendering support from Skylake and newer (rev2) Patchwork
2021-08-25  1:03 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-25  1:33 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-08-25 15:57 ` [Intel-gfx] [PATCH v2 0/8] Drop frontbuffer rendering support from Skylake and newer Rodrigo Vivi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eac0bca4-4b41-5a54-4b36-b439e4efd9fb@intel.com \
    --to=gwan-gyeong.mun@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=jose.souza@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox