[PATCH 1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size

[PATCH 1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size

[José Roberto de Souza]

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

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 707d49c12638..573b034a02fd 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -714,7 +714,14 @@ static bool intel_fbc_hw_tracking_covers_screen(struct intel_crtc *crtc)
 	struct intel_fbc *fbc = &dev_priv->fbc;
 	unsigned int effective_w, effective_h, max_w, max_h;
 
-	if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
+	if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+		max_w = 5120;
+		/* BSpec: 21664 WA: 1109 */
+		if (IS_CNL_REVID(dev_priv, CNL_REVID_A0, CNL_REVID_A0))
+			max_h = 4092;
+		else
+			max_h = 4096;
+	} else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
 		max_w = 4096;
 		max_h = 4096;
 	} else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
-- 
2.17.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths

[José Roberto de Souza]

A simple page flip can cause the CFB required size to increase and
if it is bigger than the currently allocated CFB it needs to be
resized to activate FBC again.

Until now this case was not being handled but CI is starting to
get some of this errors.

So here it will free the old CFB and a try to allocate the required
CFB in the schedule activation work, it will happen after one vblank
so is guarantee that FBC was completed disabled and is not using CFB.

Also in case that there is no enough stolen memory to allocate the
new CFB it will try 3 times per full modeset as the CFB requirement
could be reduced in the next non-full modeset.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105683
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 +++
 drivers/gpu/drm/i915/intel_fbc.c | 46 +++++++++++++++++++++-----------
 2 files changed, 33 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5373b171bb96..4ce19b45f67d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -566,6 +566,9 @@ struct intel_fbc {
 	} work;
 
 	const char *no_fbc_reason;
+
+	bool cfb_try_resize;
+	u8 cfb_resize_tries_left;
 };
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 573b034a02fd..7d77936db3ec 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -41,6 +41,9 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
+static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+static int intel_fbc_alloc_cfb(struct intel_crtc *crtc);
+
 static inline bool fbc_supported(struct drm_i915_private *dev_priv)
 {
 	return HAS_FBC(dev_priv);
@@ -446,6 +449,15 @@ static void intel_fbc_work_fn(struct work_struct *__work)
 		goto retry;
 	}
 
+	if (fbc->cfb_try_resize && fbc->cfb_resize_tries_left) {
+		__intel_fbc_cleanup_cfb(dev_priv);
+		if (intel_fbc_alloc_cfb(crtc)) {
+			fbc->no_fbc_reason = "not enough stolen memory";
+			fbc->cfb_resize_tries_left--;
+			goto out;
+		}
+	}
+
 	intel_fbc_hw_activate(dev_priv);
 
 	work->scheduled = false;
@@ -850,22 +862,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 		return false;
 	}
 
-	/* It is possible for the required CFB size change without a
-	 * crtc->disable + crtc->enable since it is possible to change the
-	 * stride without triggering a full modeset. Since we try to
-	 * over-allocate the CFB, there's a chance we may keep FBC enabled even
-	 * if this happens, but if we exceed the current CFB size we'll have to
-	 * disable FBC. Notice that it would be possible to disable FBC, wait
-	 * for a frame, free the stolen node, then try to reenable FBC in case
-	 * we didn't get any invalidate/deactivate calls, but this would require
-	 * a lot of tracking just for a specific case. If we conclude it's an
-	 * important case, we can implement it later. */
-	if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
-	    fbc->compressed_fb.size * fbc->threshold) {
-		fbc->no_fbc_reason = "CFB requirements changed";
-		return false;
-	}
-
 	/*
 	 * Work around a problem on GEN9+ HW, where enabling FBC on a plane
 	 * having a Y offset that isn't divisible by 4 causes FIFO underrun
@@ -877,6 +873,23 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 		return false;
 	}
 
+	/* It is possible for the required CFB size change without a
+	 * crtc->disable + crtc->enable since it is possible to change the
+	 * stride without triggering a full modeset. Since we try to
+	 * over-allocate the CFB, there's a chance we may keep FBC enabled even
+	 * if this happens, but if we exceed the current CFB size we'll have to
+	 * resize CFB.
+	 */
+	if (!drm_mm_node_allocated(&fbc->compressed_fb) ||
+	    (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
+	     fbc->compressed_fb.size * fbc->threshold)) {
+		fbc->cfb_try_resize = true;
+		DRM_DEBUG_KMS("CFB requirements have changed, activation  \
+			      work will try to resize it");
+	} else {
+		fbc->cfb_try_resize = false;
+	}
+
 	return true;
 }
 
@@ -1208,6 +1221,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
 
 	fbc->enabled = true;
 	fbc->crtc = crtc;
+	fbc->cfb_resize_tries_left = 3;
 out:
 	mutex_unlock(&fbc->lock);
 }
-- 
2.17.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
URL   : https://patchwork.freedesktop.org/series/41303/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
51c1ab0d8ad0 drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
38a8e6805626 drm/i915/fbc: Resize CFB in non-full modeset paths
-:110: WARNING:LINE_CONTINUATIONS: Avoid line continuations in quoted strings
#110: FILE: drivers/gpu/drm/i915/intel_fbc.c:887:
+		DRM_DEBUG_KMS("CFB requirements have changed, activation  \

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths

[Chris Wilson]

Quoting José Roberto de Souza (2018-04-06 21:53:49)
> A simple page flip can cause the CFB required size to increase and
> if it is bigger than the currently allocated CFB it needs to be
> resized to activate FBC again.

I would have expected the answer to be to plug into atomic. During the
prepare phase, you evaluate the planes for compatibility with FBC, and
record what actions you plan to take in the commit (including allocating
the next slab of stolen if required). Everything now goes through the
same atomic prepare/commit, so it should be possible to eliminate all
guess work.

Hopefully Maarten can either explain it better or why it shouldn't be
done that at all. ;)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
URL   : https://patchwork.freedesktop.org/series/41303/
State : warning

== Summary ==

Series 41303v1 series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
https://patchwork.freedesktop.org/api/1.0/series/41303/revisions/1/mbox/

---- Possible new issues:

Test gem_exec_gttfill:
        Subgroup basic:
                pass       -> SKIP       (fi-pnv-d510)

---- Known issues:

Test gem_mmap_gtt:
        Subgroup basic-small-bo-tiledx:
                fail       -> PASS       (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-a:
                incomplete -> PASS       (fi-skl-6700k2) fdo#103191

fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191

fi-bdw-5557u     total:285  pass:264  dwarn:0   dfail:0   fail:0   skip:21  time:430s
fi-bdw-gvtdvm    total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  time:444s
fi-blb-e6850     total:285  pass:220  dwarn:1   dfail:0   fail:0   skip:64  time:381s
fi-bsw-n3050     total:285  pass:239  dwarn:0   dfail:0   fail:0   skip:46  time:549s
fi-bwr-2160      total:285  pass:180  dwarn:0   dfail:0   fail:0   skip:105 time:297s
fi-bxt-dsi       total:285  pass:255  dwarn:0   dfail:0   fail:0   skip:30  time:512s
fi-bxt-j4205     total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  time:512s
fi-byt-j1900     total:285  pass:250  dwarn:0   dfail:0   fail:0   skip:35  time:521s
fi-byt-n2820     total:285  pass:246  dwarn:0   dfail:0   fail:0   skip:39  time:510s
fi-cfl-8700k     total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  time:412s
fi-cfl-s3        total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  time:562s
fi-cfl-u         total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  time:514s
fi-cnl-y3        total:285  pass:259  dwarn:0   dfail:0   fail:0   skip:26  time:588s
fi-elk-e7500     total:285  pass:226  dwarn:0   dfail:0   fail:0   skip:59  time:419s
fi-gdg-551       total:285  pass:177  dwarn:0   dfail:0   fail:0   skip:108 time:317s
fi-glk-1         total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  time:541s
fi-glk-j4005     total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  time:486s
fi-hsw-4770      total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  time:405s
fi-ilk-650       total:285  pass:225  dwarn:0   dfail:0   fail:0   skip:60  time:424s
fi-ivb-3520m     total:285  pass:256  dwarn:0   dfail:0   fail:0   skip:29  time:472s
fi-ivb-3770      total:285  pass:252  dwarn:0   dfail:0   fail:0   skip:33  time:434s
fi-kbl-7500u     total:285  pass:260  dwarn:1   dfail:0   fail:0   skip:24  time:472s
fi-kbl-7567u     total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  time:459s
fi-kbl-r         total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  time:509s
fi-pnv-d510      total:285  pass:219  dwarn:1   dfail:0   fail:0   skip:65  time:633s
fi-skl-6260u     total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  time:444s
fi-skl-6600u     total:285  pass:258  dwarn:0   dfail:0   fail:0   skip:27  time:533s
fi-skl-6700k2    total:285  pass:261  dwarn:0   dfail:0   fail:0   skip:24  time:502s
fi-skl-6770hq    total:285  pass:265  dwarn:0   dfail:0   fail:0   skip:20  time:510s
fi-skl-guc       total:285  pass:257  dwarn:0   dfail:0   fail:0   skip:28  time:430s
fi-skl-gvtdvm    total:285  pass:262  dwarn:0   dfail:0   fail:0   skip:23  time:447s
fi-snb-2520m     total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  time:583s
fi-snb-2600      total:285  pass:245  dwarn:0   dfail:0   fail:0   skip:40  time:399s

e023242a3ebab3e7a4e5d7647d7b08c0d2be5d4c drm-tip: 2018y-04m-06d-19h-07m-27s UTC integration manifest
38a8e6805626 drm/i915/fbc: Resize CFB in non-full modeset paths
51c1ab0d8ad0 drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size

== Logs ==

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

Re: [PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths

[Jani Nikula]

On Fri, 06 Apr 2018, José Roberto de Souza <jose.souza@intel.com> wrote:
> A simple page flip can cause the CFB required size to increase and
> if it is bigger than the currently allocated CFB it needs to be
> resized to activate FBC again.
>
> Until now this case was not being handled but CI is starting to
> get some of this errors.
>
> So here it will free the old CFB and a try to allocate the required
> CFB in the schedule activation work, it will happen after one vblank
> so is guarantee that FBC was completed disabled and is not using CFB.
>
> Also in case that there is no enough stolen memory to allocate the
> new CFB it will try 3 times per full modeset as the CFB requirement
> could be reduced in the next non-full modeset.
>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105683
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 +++
>  drivers/gpu/drm/i915/intel_fbc.c | 46 +++++++++++++++++++++-----------
>  2 files changed, 33 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5373b171bb96..4ce19b45f67d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -566,6 +566,9 @@ struct intel_fbc {
>  	} work;
>  
>  	const char *no_fbc_reason;
> +
> +	bool cfb_try_resize;
> +	u8 cfb_resize_tries_left;
>  };
>  
>  /*
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
> index 573b034a02fd..7d77936db3ec 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -41,6 +41,9 @@
>  #include "intel_drv.h"
>  #include "i915_drv.h"
>  
> +static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
> +static int intel_fbc_alloc_cfb(struct intel_crtc *crtc);
> +
>  static inline bool fbc_supported(struct drm_i915_private *dev_priv)
>  {
>  	return HAS_FBC(dev_priv);
> @@ -446,6 +449,15 @@ static void intel_fbc_work_fn(struct work_struct *__work)
>  		goto retry;
>  	}
>  
> +	if (fbc->cfb_try_resize && fbc->cfb_resize_tries_left) {
> +		__intel_fbc_cleanup_cfb(dev_priv);
> +		if (intel_fbc_alloc_cfb(crtc)) {
> +			fbc->no_fbc_reason = "not enough stolen memory";
> +			fbc->cfb_resize_tries_left--;
> +			goto out;
> +		}
> +	}
> +
>  	intel_fbc_hw_activate(dev_priv);
>  
>  	work->scheduled = false;
> @@ -850,22 +862,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>  		return false;
>  	}
>  
> -	/* It is possible for the required CFB size change without a
> -	 * crtc->disable + crtc->enable since it is possible to change the
> -	 * stride without triggering a full modeset. Since we try to
> -	 * over-allocate the CFB, there's a chance we may keep FBC enabled even
> -	 * if this happens, but if we exceed the current CFB size we'll have to
> -	 * disable FBC. Notice that it would be possible to disable FBC, wait
> -	 * for a frame, free the stolen node, then try to reenable FBC in case
> -	 * we didn't get any invalidate/deactivate calls, but this would require
> -	 * a lot of tracking just for a specific case. If we conclude it's an
> -	 * important case, we can implement it later. */
> -	if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> -	    fbc->compressed_fb.size * fbc->threshold) {
> -		fbc->no_fbc_reason = "CFB requirements changed";
> -		return false;
> -	}
> -
>  	/*
>  	 * Work around a problem on GEN9+ HW, where enabling FBC on a plane
>  	 * having a Y offset that isn't divisible by 4 causes FIFO underrun
> @@ -877,6 +873,23 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
>  		return false;
>  	}
>  
> +	/* It is possible for the required CFB size change without a
> +	 * crtc->disable + crtc->enable since it is possible to change the
> +	 * stride without triggering a full modeset. Since we try to
> +	 * over-allocate the CFB, there's a chance we may keep FBC enabled even
> +	 * if this happens, but if we exceed the current CFB size we'll have to
> +	 * resize CFB.
> +	 */
> +	if (!drm_mm_node_allocated(&fbc->compressed_fb) ||
> +	    (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
> +	     fbc->compressed_fb.size * fbc->threshold)) {
> +		fbc->cfb_try_resize = true;
> +		DRM_DEBUG_KMS("CFB requirements have changed, activation  \
> +			      work will try to resize it");

Either the string entirely on one line, or the string split to two, but
please never line continuation within the string.

BR,
Jani.


> +	} else {
> +		fbc->cfb_try_resize = false;
> +	}
> +
>  	return true;
>  }
>  
> @@ -1208,6 +1221,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
>  
>  	fbc->enabled = true;
>  	fbc->crtc = crtc;
> +	fbc->cfb_resize_tries_left = 3;
>  out:
>  	mutex_unlock(&fbc->lock);
>  }

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths

[Souza, Jose]

On Fri, 2018-04-06 at 22:03 +0100, Chris Wilson wrote:
> Quoting José Roberto de Souza (2018-04-06 21:53:49)
> > A simple page flip can cause the CFB required size to increase and
> > if it is bigger than the currently allocated CFB it needs to be
> > resized to activate FBC again.
> 
> I would have expected the answer to be to plug into atomic. During
> the
> prepare phase, you evaluate the planes for compatibility with FBC,
> and
> record what actions you plan to take in the commit (including
> allocating
> the next slab of stolen if required). Everything now goes through the
> same atomic prepare/commit, so it should be possible to eliminate all
> guess work.
> 
> Hopefully Maarten can either explain it better or why it shouldn't be
> done that at all. ;)
> -Chris


Hi Chris

You mean check if FBC needs to resize CFB inside
intel_crtc_compute_config() if so set state->mode_changed=true, to
cause a full modeset? This way intel_fbc_disable() and
intel_fbc_enable() will be called.

Yeah looks better than current solution, do you have any objections
Paulo?

Thanks
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths

[José Roberto de Souza]

A simple page flip can cause the CFB required size to increase and
if it is bigger than the currently allocated CFB it needs to be
resized to activate FBC again.

Until now this case was not being handled but CI is starting to
get some of this errors.

So here it will free the old CFB and try to allocate the required
CFB in the schedule activation work, it will happen after one vblank
so is guarantee that FBC was completed disabled and is not using CFB.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105683
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_fbc.c | 45 ++++++++++++++++++++------------
 2 files changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 735f695cb889..5a5c3b9e421e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -586,6 +586,8 @@ struct intel_fbc {
 	} work;
 
 	const char *no_fbc_reason;
+
+	bool cfb_try_resize;
 };
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index eb0f95390968..62f0c99d45c2 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -41,6 +41,9 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
+static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+static int intel_fbc_alloc_cfb(struct intel_crtc *crtc);
+
 static inline bool fbc_supported(struct drm_i915_private *dev_priv)
 {
 	return HAS_FBC(dev_priv);
@@ -446,6 +449,15 @@ static void intel_fbc_work_fn(struct work_struct *__work)
 		goto retry;
 	}
 
+	if (fbc->cfb_try_resize) {
+		fbc->cfb_try_resize = false;
+		__intel_fbc_cleanup_cfb(dev_priv);
+		if (intel_fbc_alloc_cfb(crtc)) {
+			fbc->no_fbc_reason = "not enough stolen memory";
+			goto out;
+		}
+	}
+
 	intel_fbc_hw_activate(dev_priv);
 
 	work->scheduled = false;
@@ -846,22 +858,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 		return false;
 	}
 
-	/* It is possible for the required CFB size change without a
-	 * crtc->disable + crtc->enable since it is possible to change the
-	 * stride without triggering a full modeset. Since we try to
-	 * over-allocate the CFB, there's a chance we may keep FBC enabled even
-	 * if this happens, but if we exceed the current CFB size we'll have to
-	 * disable FBC. Notice that it would be possible to disable FBC, wait
-	 * for a frame, free the stolen node, then try to reenable FBC in case
-	 * we didn't get any invalidate/deactivate calls, but this would require
-	 * a lot of tracking just for a specific case. If we conclude it's an
-	 * important case, we can implement it later. */
-	if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
-	    fbc->compressed_fb.size * fbc->threshold) {
-		fbc->no_fbc_reason = "CFB requirements changed";
-		return false;
-	}
-
 	/*
 	 * Work around a problem on GEN9+ HW, where enabling FBC on a plane
 	 * having a Y offset that isn't divisible by 4 causes FIFO underrun
@@ -873,6 +869,22 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
 		return false;
 	}
 
+	if (!drm_mm_node_allocated(&fbc->compressed_fb))
+		return false;
+
+	/* It is possible for the required CFB size change without a
+	 * crtc->disable + crtc->enable since it is possible to change the
+	 * stride without triggering a full modeset. Since we try to
+	 * over-allocate the CFB, there's a chance we may keep FBC enabled even
+	 * if this happens, but if we exceed the current CFB size we'll have to
+	 * resize CFB.
+	 */
+	if (intel_fbc_calculate_cfb_size(dev_priv, &fbc->state_cache) >
+	    (fbc->compressed_fb.size * fbc->threshold)) {
+		fbc->cfb_try_resize = true;
+		DRM_DEBUG_KMS("CFB memory requirements have changed");
+	}
+
 	return true;
 }
 
@@ -1204,6 +1216,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
 
 	fbc->enabled = true;
 	fbc->crtc = crtc;
+	fbc->cfb_try_resize = false;
 out:
 	mutex_unlock(&fbc->lock);
 }
-- 
2.17.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx