<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [snb] Frequent framerate drops" href="https://bugs.freedesktop.org/show_bug.cgi?id=81682#c23">Comment # 23</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [snb] Frequent framerate drops" href="https://bugs.freedesktop.org/show_bug.cgi?id=81682">bug 81682</a> from <a class="email" href="mailto:chris@chris-wilson.co.uk" title="Chris Wilson <chris@chris-wilson.co.uk>"> Chris Wilson</a> <pre>(In reply to <a href="show_bug.cgi?id=81682#c21">comment #21</a>) > Interesting, when it recovered, for a short time it went up to 1100MHz > gpufreq, and the fps suddenly became smooth as silk, 50fps at least. Whilst > it may not be the proper solution, is there a re to force the gpu up to a > high freq while I'm gaming? I'm happy to continue debugging with you, but at > least I could choose when I'm going to get the fps drops :) You can force the requested frequency to max with "cat /sys/class/drm/card0/gt_RP0_freq_mhz > /sys/class/drm/card0/gt_max_freq_mhz". It should not be any better than the autotuning (and likely to be worse). However, that will not stop the hardware from throttling down to meet thermal limits. Looking at the perf output, the unknown symbols are just from a lack of debug packages, but I think we have enough to suggest that cpufreq is a major factor in the error. During the stall, it is going mad. Disabling cpufreq (echo performance > /sys/.../scaling_governor) would be a good test.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>