Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> writes: > 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! > I wonder if this was intentional. However acting on behalf of the more busy engine on the calculation smells more correct. Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
