On Fri, Mar 03, 2023 at 05:00:03PM +0200, Ville Syrjälä wrote:
On Fri, Mar 03, 2023 at 06:48:43AM -0800, Rob Clark wrote:
On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin tvrtko.ursulin@linux.intel.com wrote:
On 03/03/2023 03:21, Rodrigo Vivi wrote:
On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
From: Rob Clark robdclark@chromium.org
missing some wording here...
v2: rebase
Signed-off-by: Rob Clark robdclark@chromium.org
drivers/gpu/drm/i915/i915_request.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 7503dcb9043b..44491e7e214c 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence *fence) return i915_request_enable_breadcrumb(to_request(fence)); }
+static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline) +{
- struct i915_request *rq = to_request(fence);
- if (i915_request_completed(rq))
return;- if (i915_request_started(rq))
return;why do we skip the boost if already started? don't we want to boost the freq anyway?
I'd wager Rob is just copying the current i915 wait boost logic.
Yup, and probably incorrectly.. Matt reported fewer boosts/sec compared to your RFC, this could be the bug
I don't think i915 calls drm_atomic_helper_wait_for_fences() so that could explain something.
Oh, I guess this wasn't even supposed to take over the current display boost stuff since you didn't remove the old one.
The current one just boosts after a missed vblank. The deadline could use your timer approach I suppose and boost already a bit earlier in the hopes of not missing the vblank.