drm/i915: only recompress FBC after flushing a drawing operation
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@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
This commit is contained in:
parent
820bcabbf0
commit
ee7d6cfa4b
|
@ -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);
|
||||
|
|
Loading…
Reference in New Issue