From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
The frontbuffer tracking code is supposed to handle plane
updates via ORIGIN_FLIP. Right now we're also doing internal
ORIGIN_DIRTYFB flushes for some reason. Can't see the point
so get rid of them.
In fact on GLK+ these are acively harmful and only risk angering
the hardware and causing FBC to scan out corrupted data. The
hardware flip nuke mechanism will take care of things for FBC.
With all the redundant manual nukes removed at least workloads
that don't do any frontbuffer rendering should be safe from
hitting that corruption.
Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index a10e26380ef3..bd48272311d2 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1718,8 +1718,6 @@ intel_find_initial_plane_obj(struct intel_crtc *intel_crtc,
intel_plane_copy_uapi_to_hw_state(intel_state, intel_state,
intel_crtc);
- intel_frontbuffer_flush(to_intel_frontbuffer(fb), ORIGIN_DIRTYFB);
-
atomic_or(to_intel_plane(primary)->frontbuffer_bit,
&to_intel_frontbuffer(fb)->bits);
}
@@ -10633,7 +10631,6 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
return ret;
i915_gem_object_wait_priority(obj, 0, &attr);
- i915_gem_object_flush_frontbuffer(obj, ORIGIN_DIRTYFB);
if (!new_plane_state->uapi.fence) { /* implicit fencing */
struct dma_fence *fence;
--
2.26.3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
