I was trying to get some benchmarking numbers for a performance issue I thought I was seeing in l4d2 (CAGF would drop down to 350 during the benchmark run, despite intel_gpu_top reporting 98% render ring busy, and the only stalls being swapbuffers throttling), so I wanted to compare against just always having the GPU at maximum. However, when I tried doing back to back test runs on some other apps, switching between i915_min_freq of 350 (default) and 1250 (max), after a transition from 1250 to 350, it would take about 2 seconds for the frequency to climb up to maximum during a benchmark. On repeated runs of the benchmark after that, it would make a quick jump from CAGF of 350 to 1250. This means that my usual method of comparing performance between the two modes sees a spurious performance delta, up to 40% for citybench.
(dinq 2b749b2ea1356a34449bb83c03eb7e43513b3f20 )
Created attachment 77121 [details] use hsw rps thresholds vpg has given us totally new rps thresholds for hsw, and I guess we can try whether they make more sense on ivb/snb, too. Does this help (both for the slow ramp and the spurious downclock)?
Eric, is this still an issue? The attached patch has been available upstream since v3.6 as commit: commit 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 15 10:41:45 2012 +0200 drm/i915: use hsw rps tuning values everywhere on gen6+
I presume they're using the sysfs interfaces for most of the benchmarking. Eric, can we close this?
Well, I'm now frequently seeing it take a minute of activity to get the GPU to kick into high frequency, so I wouldn't describe things as "working", and I wouldn't be able to distinguish a mere 2 seconds any more.
Speaking as me: I'm not interested in how long it takes to kick into high frequency. I'm interested in the how long it takes until it kicks into a high enough frequency to hit the target framerate. (Inversely, if it takes far too long to throttle back down, I also am interested in solving such issues). I've heard of tests where even that is an issue though. Do we have a record of any of those type of failures? Is your original bug an example of that? Do we have a target for what's an acceptable delay?
Well, the one yesterday was the app running at 3fps instead of 8.
I presume Eric is no longer very interested in this bug, and judging by the activity here in the last two years, nobody else has really shown interest either. I admit a bug may exist, but having this one hang around clearly isn't helping. Anyway, please reopen or file new bugs at fdo if the problem persists and you can provide further details. Thanks.