[Intel-gfx] [PATCH 11/11] drm/i915: only recompress FBC after flushing a drawing operation
Paulo Zanoni
paulo.r.zanoni at intel.com
Wed Dec 2 04:15:27 PST 2015
There's no need to stop and restart FBC, which is quite expensive as
we have to revalidate the CRTC state. After flushing a drawing
operation we know the CRTC state hasn't changed, so a nuke
(recompress) should be fine.
v2: Make it simpler (Chris).
v3: Rewrite the patch again due to patch order changes.
v4: Rewrite commit message (Chris).
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
---
drivers/gpu/drm/i915/intel_fbc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index af621de..a1988a4 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -935,8 +935,12 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
dev_priv->fbc.busy_bits &= ~frontbuffer_bits;
if (!dev_priv->fbc.busy_bits && dev_priv->fbc.enabled) {
- __intel_fbc_deactivate(dev_priv);
- __intel_fbc_update(dev_priv->fbc.crtc);
+ if (origin != ORIGIN_FLIP && dev_priv->fbc.active) {
+ intel_fbc_recompress(dev_priv);
+ } else {
+ __intel_fbc_deactivate(dev_priv);
+ __intel_fbc_update(dev_priv->fbc.crtc);
+ }
}
mutex_unlock(&dev_priv->fbc.lock);
--
2.6.2
More information about the Intel-gfx
mailing list