Currently, we sum the render and media cycles (on different engines) to compute a percentage - but we fail to factor in the duplication into the threshold calculations. This makes us very eager to upclock! If we just consider the maximum busy cycles of either counter, we should have an accurate reflection on whether there are cycles to spare to handle the workload at this frequency. Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> --- drivers/gpu/drm/i915/i915_irq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 88b591e4c6ea..5084daf81776 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1098,8 +1098,8 @@ static bool vlv_c0_above(struct drm_i915_private *dev_priv, * being blitted in X after being rendered in mesa. To account for * this we need to combine both engines into our activity counter. */ - c0 = now->render_c0 - old->render_c0; - c0 += now->media_c0 - old->media_c0; + c0 = max(now->render_c0 - old->render_c0, + now->media_c0 - old->media_c0); c0 *= mul * VLV_CZ_CLOCK_TO_MILLI_SEC; return c0 >= time; -- 2.11.0 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
