drm/i915: drrs_invalidate at flip schedule
Subsystems (2)
PATCH 1/1 drm/i915: drrs_invalidate at flip schedule
After scheduling a flip for obj, we are supposed to invalidate the drrs.
Action:
Adding a call to intel_edp_drrs_invalidate at
intel_frontbuffer_flip_prepare.
--- drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/intel_frontbuffer.c +1 -0
@@ -244,6 +244,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); +intel_edp_drrs_invalidate (dev, frontbuffer_bits);intel_psr_single_frame_update (dev); }
Signature · 6 lines
1.7.9.5 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 9 lines · Ramalingam C
After scheduling a flip for obj, we are supposed to invalidate the drrs.
Action:
Adding a call tointel_edp_drrs_invalidateat
intel_frontbuffer_flip_prepare.Signed-off-by Ramalingam C <[email protected]>Signed-off-by Chris Wilson <[email protected]>
Just Cc: Chris Wilson <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90418
Ok, looks correct. This invalidate will be paired with a flush after the flip completes to reschedule the downclock of the refresh rates.
I think a comment would be useful to explain the relationship here, or better would be a new intel_edp_drrs_flip_prepare() stub so that the internal details of drrs are kept out of intel_frontbuffer.c and the comment can refer to the adjacent functions for reference. -Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 13 lines · Chris Wilson
Quoted 9 lines · Ramalingam C
After scheduling a flip for obj, we are supposed to invalidate the drrs.
Action:
Adding a call tointel_edp_drrs_invalidateatintel_frontbuffer_flip_prepare.Signed-off-by Ramalingam C <[email protected]>Signed-off-by Chris Wilson <[email protected]>Just Cc: Chris Wilson <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90418
Quoted 7 lines
Ok, looks correct. This invalidate will be paired with a flush after the flip completes to reschedule the downclock of the refresh rates.
I think a comment would be useful to explain the relationship here, or better would be a new
intel_edp_drrs_flip_prepare()stub so that the internal details of drrs are kept out ofintel_frontbuffer.cand the comment can refer to the adjacent functions for reference.
But in flip preparation we would want to invalidate the PSR (software implementation) also.
In that case we could create a function called intel_frontbuffer_flip_invalidate() instead of edp_drrs_flip_prepare. This will be invoking the invalidation for the PSR and DRRS. And this function could be called from intel_frontbuffer_flip_prepare().
Incase If FBC invalidate also needed at flip preparation, then we could create a common function called intel_frontbuffer_invalidate parallel to intel_frontbuffer_flush which will be used by intel_fb_obj_invalidate and intel_frontbuffer_flip_prepare.
Please share your view. whether FBC invalidate is required on flip preparation?
Quoted 2 lines
-Chris
Signature · 7 lines
Thanks, --Ram _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 31 lines · Ramalingam C
Quoted 13 lines · Chris Wilson
Quoted 9 lines · Ramalingam C
After scheduling a flip for obj, we are supposed to invalidate the drrs.
Action:
Adding a call tointel_edp_drrs_invalidateat
intel_frontbuffer_flip_prepare.Signed-off-by Ramalingam C <[email protected]>Signed-off-by Chris Wilson <[email protected]>Just Cc: Chris Wilson <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=90418Quoted 7 lines
Ok, looks correct. This invalidate will be paired with a flush after the flip completes to reschedule the downclock of the refresh rates.
I think a comment would be useful to explain the relationship here, or better would be a new
intel_edp_drrs_flip_prepare()stub so that the internal details of drrs are kept out ofintel_frontbuffer.cand the comment can refer to the adjacent functions for reference.But in flip preparation we would want to invalidate the PSR (software implementation) also.
In that case we could create a function calledintel_frontbuffer_flip_invalidate()instead ofedp_drrs_flip_prepare.
This will be invoking the invalidation for the PSR and DRRS. And this function could be called fromintel_frontbuffer_flip_prepare().
Quoted 8 lines
Incase If FBC invalidate also needed at flip preparation, then we could create a common function called
intel_frontbuffer_invalidateparallel tointel_frontbuffer_flushwhich will be used byintel_fb_obj_invalidateandintel_frontbuffer_flip_prepare.Please share your view. whether FBC invalidate is required on flip preparation?
It is (intel_disable_fbc is being directly by the flip code).
I would stick to calling it intel_frontbuffer_flip_prepare/flip_complete to distinguish it from invalidate/flush - they are not equivalent in all cases. And I would push that naming convention down to the backends. Given that we have 3 (almost 4) users of this, we may want to move this over to a notifier system and have the backends register themselves rather than continually adapting intel_frontbuffer.c to the requirements of different backends. Task for a rainy day.
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Task id: 6412 -------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
PNV 276/276 276/276 ILK 302/302 302/302 SNB -1 314/314 313/314 IVB 338/338 338/338 BYT 286/286 286/286 BDW 320/320 320/320
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
SNB igt@pm_rpm@dpms-mode-unset-non-lpsp DMESG_WARN(13)PASS(1) DMESG_WARN(1)
(dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 18 lines · Ramalingam C
After scheduling a flip for obj, we are supposed to invalidate the drrs.
Action:
Adding a call tointel_edp_drrs_invalidateat
intel_frontbuffer_flip_prepare.Signed-off-by Ramalingam C <[email protected]>Signed-off-by Chris Wilson <[email protected]>--- drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + 1 file changed, 1 insertion(+)drivers/gpu/drm/i915/intel_frontbuffer.c +0
-0
drivers/gpu/drm/i915/intel_frontbuffer.c void intel_frontbuffer_flip_prepare(struct drm_device *dev, · line 247
Quoted 4 lines
drivers/gpu/drm/i915/intel_frontbuffer.c +1
-0@@ -244,6 +244,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); +intel_edp_drrs_invalidate (dev, frontbuffer_bits);
Nope. The problem here is that drrs wants business, but the frontbuffer tracking only gives you coherency signals (flush/invalidate). But for business both flush and invalidate indicate that there's something going on on the screen. Which means you _must_ uplock the display in both drrs_flush and drrs_invalidate.
By applaying the upclocking only to the flip codepath you're only papering over this bug in one specific case, but not for all the other paths where frontbuffer rendering is possible.
-Daniel
Quoted 6 lines
drivers/gpu/drm/i915/intel_frontbuffer.c +0
-0intel_psr_single_frame_update (dev); }Signature · 1 line
1.7.9.5
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Sorry for late response. I was away for longer.
Daniel,
As we have the intel_frontbuffer_flush, I have created the intel_frontbuffer_invalidate. This can be called from flip preparation notification to handle the frontbuffer invalidation. I will share the patches now.
Quoted 40 lines · Daniel Vetter
Quoted 18 lines · Ramalingam C
After scheduling a flip for obj, we are supposed to invalidate the drrs.
Action:
Adding a call tointel_edp_drrs_invalidateatintel_frontbuffer_flip_prepare.Signed-off-by Ramalingam C <[email protected]>Signed-off-by Chris Wilson <[email protected]>--- drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + 1 file changed, 1 insertion(+)drivers/gpu/drm/i915/intel_frontbuffer.c +0
-0drivers/gpu/drm/i915/intel_frontbuffer.c void intel_frontbuffer_flip_prepare(struct drm_device *dev, · line 247
Quoted 4 lines
drivers/gpu/drm/i915/intel_frontbuffer.c +1
-0@@ -244,6 +244,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); +intel_edp_drrs_invalidate (dev, frontbuffer_bits);Nope. The problem here is that drrs wants business, but the frontbuffer tracking only gives you coherency signals (flush/invalidate). But for business both flush and invalidate indicate that there's something going on on the screen. Which means you _must_ uplock the display in both
drrs_flushanddrrs_invalidate.By applaying the upclocking only to the flip codepath you're only papering over this bug in one specific case, but not for all the other paths where frontbuffer rendering is possible.
-DanielQuoted 6 lines
drivers/gpu/drm/i915/intel_frontbuffer.c +0
-0intel_psr_single_frame_update (dev); }Signature · 1 line
1.7.9.5
Signature · 7 lines
Thanks, --Ram _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 9 lines · Ramalingam C
Sorry for late response. I was away for longer.
Daniel,
As we have the
intel_frontbuffer_flush, I have created theintel_frontbuffer_invalidate.
This can be called from flip preparation notification to handle the frontbuffer invalidation.
I will share the patches now.
You need to fix up the broken DRRS code - the frontbuffer tracking code is perfectly fine. See below diff with inline comments.
Cheers, Daniel
And my Signed-off-by: Daniel Vetter <[email protected]> in case the patch works as-is.
drivers/gpu/drm/i915/intel_dp.c +11 -2
@@ -5487,6 +5487,7 @@ void intel_edp_drrs_invalidate(struct drm_device *dev, crtc =dp_to_dig_port (dev_priv->drrs.dp)->base.base.crtc; pipe =to_intel_crtc (crtc)->pipe; +/* invalidate means busy screen hence upclock */ if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) { intel_dp_set_drrs_state(dev_priv->dev, dev_priv->drrs.dp->attached_connector->panel.
@@ -5532,8 +5533,16 @@ void intel_edp_drrs_flush(struct drm_device *dev, pipe =to_intel_crtc (crtc)->pipe; dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits; -if (dev_priv->drrs.refresh_rate_type !=DRRS_LOW_RR && - !dev_priv->drrs.busy_frontbuffer_bits) +/* flush means busy screen hence upclock */ +if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) { +intel_dp_set_drrs_state (dev_priv->dev, + dev_priv->drrs.dp->attached_connector->panel. + fixed_mode->vrefresh); + } + +/* flush also means no more activity hence schedule downclock if all +* other fbs are quiescent too */ +if (!dev_priv->drrs.busy_frontbuffer_bits)schedule_delayed_work (&dev_priv->drrs.work,msecs_to_jiffies (1000 ));mutex_unlock (&dev_priv->drrs.mutex);
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Daniel,
Only now i am understanding your comment in previous mail that is "need to upclock in both flush and validate". Yup this change is what needed. Tested to be working fine.
The Documentation for the intel_edp_drrs_flush() mislead me to expect
invalidate call for each framebuffer change. I have just corrected this documentation as part your change and sending it to you.
Thanks.
Quoted 49 lines · Daniel Vetter
Quoted 9 lines · Ramalingam C
Sorry for late response. I was away for longer.
Daniel,
As we have the
intel_frontbuffer_flush, I have created theintel_frontbuffer_invalidate.
This can be called from flip preparation notification to handle the frontbuffer invalidation.
I will share the patches now.You need to fix up the broken DRRS code - the frontbuffer tracking code is perfectly fine. See below diff with inline comments.
Cheers, Daniel
And my Signed-off-by: Daniel Vetter <[email protected]> in case the patch works as-is.
drivers/gpu/drm/i915/intel_dp.c +11
-2@@ -5487,6 +5487,7 @@ void intel_edp_drrs_invalidate(struct drm_device *dev, crtc =dp_to_dig_port (dev_priv->drrs.dp)->base.base.crtc; pipe =to_intel_crtc (crtc)->pipe; +/* invalidate means busy screen hence upclock */ if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) { intel_dp_set_drrs_state(dev_priv->dev, dev_priv->drrs.dp->attached_connector->panel.@@ -5532,8 +5533,16 @@ void intel_edp_drrs_flush(struct drm_device *dev, pipe =to_intel_crtc (crtc)->pipe; dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits; -if (dev_priv->drrs.refresh_rate_type !=DRRS_LOW_RR && - !dev_priv->drrs.busy_frontbuffer_bits) +/* flush means busy screen hence upclock */ +if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) { +intel_dp_set_drrs_state (dev_priv->dev, + dev_priv->drrs.dp->attached_connector->panel. + fixed_mode->vrefresh); + } + +/* flush also means no more activity hence schedule downclock if all +* other fbs are quiescent too */ +if (!dev_priv->drrs.busy_frontbuffer_bits)schedule_delayed_work (&dev_priv->drrs.work,msecs_to_jiffies (1000 ));mutex_unlock (&dev_priv->drrs.mutex);
Signature · 7 lines
Thanks, --Ram _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
PATCH 1/1 drm/i915: Restarting the Idleness DRRS in drrs_flush
Corrected the documentation on the intel_edp_drrs_flush and intel_edp_drrs_invalidate.
And accordingly edp_drrs_flush function is modified to restart the idleness detection after upclocking.
--- drivers/gpu/drm/i915/intel_dp.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-)
drivers/gpu/drm/i915/intel_dp.c +20 -10
@@ -5455,13 +5455,12 @@ unlock: }/** -* intel_edp_drrs_invalidate - Invalidate DRRS +* intel_edp_drrs_invalidate - Disable Idleness DRRS * @dev: DRM device * @frontbuffer_bits: frontbuffer plane tracking bits * -* When there is a disturbance on screen (due to cursor movement/time -* update etc), DRRS needs to be invalidated, i.e. need to switch to -* high RR. +* This function gets called everytime rendering on the given planes start. +* Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR). * * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits. */
@@ -5486,6 +5485,7 @@ void intel_edp_drrs_invalidate(struct drm_device *dev, crtc =dp_to_dig_port (dev_priv->drrs.dp)->base.base.crtc; pipe =to_intel_crtc (crtc)->pipe; +/* invalidate means busy screen hence upclock */ if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) { intel_dp_set_drrs_state(dev_priv->dev, dev_priv->drrs.dp->attached_connector->panel.
@@ -5499,13 +5499,14 @@ void intel_edp_drrs_invalidate(struct drm_device *dev, }/** -* intel_edp_drrs_flush - Flush DRRS +* intel_edp_drrs_flush - Restart Idleness DRRS * @dev: DRM device * @frontbuffer_bits: frontbuffer plane tracking bits * -* When there is no movement on screen, DRRS work can be scheduled. -* This DRRS work is responsible for setting relevant registers after a -* timeout of 1 second. +* This function gets called every time rendering on the given planes has +* completed or flip on a crtc is completed. So DRRS should be upclocked +* (LOW_RR -> HIGH_RR). And also Idleness detection should be started again, +* if no other planes are dirty. * * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits. */
@@ -5531,8 +5532,17 @@ void intel_edp_drrs_flush(struct drm_device *dev, pipe =to_intel_crtc (crtc)->pipe; dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits; -if (dev_priv->drrs.refresh_rate_type !=DRRS_LOW_RR && - !dev_priv->drrs.busy_frontbuffer_bits) +/* flush means busy screen hence upclock */ +if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) +intel_dp_set_drrs_state (dev_priv->dev, + dev_priv->drrs.dp->attached_connector->panel. + fixed_mode->vrefresh); + +/* +* flush also means no more activity hence schedule downclock, if all +* other fbs are quiescent too +*/ +if (!dev_priv->drrs.busy_frontbuffer_bits)schedule_delayed_work (&dev_priv->drrs.work,msecs_to_jiffies (1000 ));mutex_unlock (&dev_priv->drrs.mutex);
Signature · 6 lines
1.7.9.5 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH] drm/i915: Restarting the Idleness DRRS in drrs_flush
Quoted 7 lines · Ramalingam C
Corrected the documentation on the
intel_edp_drrs_flushandintel_edp_drrs_invalidate.And accordingly
edp_drrs_flushfunction is modified to restart the idleness detection after upclocking.Signed-off-by Daniel Vetter <[email protected]>
Thanks for testing and updating the comments. I've added a note to the commit that the kerneldoc is from you and applied the patch. -Daniel
Quoted 75 lines
--- drivers/gpu/drm/i915/intel_dp.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-)drivers/gpu/drm/i915/intel_dp.c +20
-10@@ -5455,13 +5455,12 @@ unlock: }/** -* intel_edp_drrs_invalidate - Invalidate DRRS +* intel_edp_drrs_invalidate - Disable Idleness DRRS * @dev: DRM device * @frontbuffer_bits: frontbuffer plane tracking bits * -* When there is a disturbance on screen (due to cursor movement/time -* update etc), DRRS needs to be invalidated, i.e. need to switch to -* high RR. +* This function gets called everytime rendering on the given planes start. +* Hence DRRS needs to be Upclocked, i.e. (LOW_RR -> HIGH_RR). * * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits. */ @@ -5486,6 +5485,7 @@ void intel_edp_drrs_invalidate(struct drm_device *dev, crtc =dp_to_dig_port (dev_priv->drrs.dp)->base.base.crtc; pipe =to_intel_crtc (crtc)->pipe; +/* invalidate means busy screen hence upclock */ if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) { intel_dp_set_drrs_state(dev_priv->dev, dev_priv->drrs.dp->attached_connector->panel.@@ -5499,13 +5499,14 @@ void intel_edp_drrs_invalidate(struct drm_device *dev, }/** -* intel_edp_drrs_flush - Flush DRRS +* intel_edp_drrs_flush - Restart Idleness DRRS * @dev: DRM device * @frontbuffer_bits: frontbuffer plane tracking bits * -* When there is no movement on screen, DRRS work can be scheduled. -* This DRRS work is responsible for setting relevant registers after a -* timeout of 1 second. +* This function gets called every time rendering on the given planes has +* completed or flip on a crtc is completed. So DRRS should be upclocked +* (LOW_RR -> HIGH_RR). And also Idleness detection should be started again, +* if no other planes are dirty. * * Dirty frontbuffers relevant to DRRS are tracked in busy_frontbuffer_bits. */ @@ -5531,8 +5532,17 @@ void intel_edp_drrs_flush(struct drm_device *dev, pipe =to_intel_crtc (crtc)->pipe; dev_priv->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits; -if (dev_priv->drrs.refresh_rate_type !=DRRS_LOW_RR && - !dev_priv->drrs.busy_frontbuffer_bits) +/* flush means busy screen hence upclock */ +if (dev_priv->drrs.refresh_rate_type ==DRRS_LOW_RR ) +intel_dp_set_drrs_state (dev_priv->dev, + dev_priv->drrs.dp->attached_connector->panel. + fixed_mode->vrefresh); + +/* +* flush also means no more activity hence schedule downclock, if all +* other fbs are quiescent too +*/ +if (!dev_priv->drrs.busy_frontbuffer_bits)schedule_delayed_work (&dev_priv->drrs.work,msecs_to_jiffies (1000 ));mutex_unlock (&dev_priv->drrs.mutex);Signature · 1 line
1.7.9.5
Signature · 7 lines
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
PATCH 1/2 drm/i915: fb_obj invalidate is divided into two functions
In reply to Daniel Vetterfb_obj invalidate is divided into two functions. So that we can invoke the frontbuffer invalidation from the flip preparation also.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90418
--- drivers/gpu/drm/i915/intel_frontbuffer.c | 42 +++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 9 deletions(-)
drivers/gpu/drm/i915/intel_frontbuffer.c +33 -9
@@ -119,6 +119,33 @@ static void intel_mark_fb_busy(struct drm_device *dev, }/** +* intel_frontbuffer_invalidate - Invalidate frontbuffer +* @dev: DRM device +* @ring: set for asynchronous rendering +* @origin: which operation caused the invalidation +* @frontbuffer_bits: frontbuffer plane tracking bits +* +* This function gets called every time rendering on the given planes has +* started and frontbuffer caching must be invalidated. +* +* Can be called without any locks held. +*/ +void intel_frontbuffer_invalidate (struct drm_device *dev, +struct intel_engine_cs *ring, +enum fb_op_origin origin, +unsigned frontbuffer_bits) +{ +struct drm_i915_private *dev_priv = dev->dev_private; + +intel_mark_fb_busy (dev, frontbuffer_bits, ring); + +intel_psr_invalidate (dev, frontbuffer_bits); +intel_edp_drrs_invalidate (dev, frontbuffer_bits); +intel_fbc_invalidate (dev_priv, frontbuffer_bits, origin); +} + + +/** * intel_fb_obj_invalidate - invalidate frontbuffer object * @obj: GEM object to invalidate * @ring: set for asynchronous rendering
@@ -136,26 +163,23 @@ void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj, {struct drm_device *dev = obj->base.dev;struct drm_i915_private *dev_priv = dev->dev_private; +unsigned frontbuffer_bits;WARN_ON (!mutex_is_locked (&dev->struct_mutex));if (!obj->frontbuffer_bits)return ; + frontbuffer_bits = obj->frontbuffer_bits; +if (ring) {mutex_lock (&dev_priv->fb_tracking.lock); - dev_priv->fb_tracking.busy_bits - |= obj->frontbuffer_bits; - dev_priv->fb_tracking.flip_bits - &= ~obj->frontbuffer_bits; + dev_priv->fb_tracking.busy_bits |= frontbuffer_bits; + dev_priv->fb_tracking.flip_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); } -intel_mark_fb_busy (dev, obj->frontbuffer_bits, ring); - -intel_psr_invalidate (dev, obj->frontbuffer_bits); -intel_edp_drrs_invalidate (dev, obj->frontbuffer_bits); -intel_fbc_invalidate (dev_priv, obj->frontbuffer_bits, origin); +intel_frontbuffer_invalidate (dev, ring, origin, frontbuffer_bits); }/**
Signature · 6 lines
1.7.9.5 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
PATCH 2/2 drm/i915: frontbuffer invalidate at flip schedule
After scheduling a flip for obj, frontbuffer should be invalidated. Hence intel_frontbuffer_invalidate is invoked at flip preparation.
References: https://bugs.freedesktop.org/show_bug.cgi?id=90418
--- drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/intel_frontbuffer.c +1 -0
@@ -268,6 +268,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); +intel_frontbuffer_invalidate (dev,NULL ,ORIGIN_FLIP , frontbuffer_bits);intel_psr_single_frame_update (dev); }
Signature · 6 lines
1.7.9.5 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 2/2] drm/i915: frontbuffer invalidate at flip schedule
Quoted 15 lines · Ramalingam C
After scheduling a flip for obj, frontbuffer should be invalidated. Hence
intel_frontbuffer_invalidateis invoked at flip preparation.Signed-off-by Ramalingam C <[email protected]>Cc Chris Wilson <[email protected]>References: https://bugs.freedesktop.org/show_bug.cgi?id=90418
--- drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + 1 file changed, 1 insertion(+)drivers/gpu/drm/i915/intel_frontbuffer.c +0
-0
drivers/gpu/drm/i915/intel_frontbuffer.c void intel_frontbuffer_flip_prepare(struct drm_device *dev, · line 272
Quoted 5 lines
drivers/gpu/drm/i915/intel_frontbuffer.c +1
-0@@ -268,6 +268,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); +intel_frontbuffer_invalidate (dev,NULL ,ORIGIN_FLIP , frontbuffer_bits);intel_psr_single_frame_update (dev);
This then has the side effect of calling psr_invalidate (psr_exit) followed by the single-shot psr update, which doesn't seem desirable. -Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 2/2] drm/i915: frontbuffer invalidate at flip schedule
True.
Chris and Vivi,
I am trying to understand the PSR exit and entry along with SFU requirement here. AFAIK in existing code also
on rendering start fb_obj_invalidate is calling thepsr_invalidate(psr_exit)
on flip prepare single frame update is done
on flip complete frontbuffer_invalidate is callingpsr_flush(psr_reenable)
on rendering complete fb_obj_flush is calling thepsr_flush(psr_reenable)
On Every rendering start if we exit the PSR, then there is no advantage of setting SFU at flip prepare. Please correct me if I am wrong.
Quoted 25 lines · Chris Wilson
Quoted 15 lines · Ramalingam C
After scheduling a flip for obj, frontbuffer should be invalidated. Hence
intel_frontbuffer_invalidateis invoked at flip preparation.Signed-off-by Ramalingam C <[email protected]>Cc Chris Wilson <[email protected]>References: https://bugs.freedesktop.org/show_bug.cgi?id=90418
--- drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + 1 file changed, 1 insertion(+)drivers/gpu/drm/i915/intel_frontbuffer.c +0
-0drivers/gpu/drm/i915/intel_frontbuffer.c void intel_frontbuffer_flip_prepare(struct drm_device *dev, · line 272
Quoted 5 lines
drivers/gpu/drm/i915/intel_frontbuffer.c +1
-0@@ -268,6 +268,7 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;mutex_unlock (&dev_priv->fb_tracking.lock); +intel_frontbuffer_invalidate (dev,NULL ,ORIGIN_FLIP , frontbuffer_bits);intel_psr_single_frame_update (dev);This then has the side effect of calling
psr_invalidate(psr_exit) followed by the single-shot psr update, which doesn't seem desirable. -Chris
Signature · 7 lines
Thanks, --Ram _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH 2/2] drm/i915: frontbuffer invalidate at flip schedule
In reply to Ramalingam CTask id: 6569 -------------------------------------Summary-------------------------------------
Platform Delta drm-intel-nightly Series Applied
PNV 276/276 276/276 ILK 303/303 303/303 SNB 312/312 312/312 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321
-------------------------------------Detailed-------------------------------------
Platform Test drm-intel-nightly Series Applied
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx