<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [HAWAII] GPU doesn't reclock, poor 3D performance" href="https://bugs.freedesktop.org/show_bug.cgi?id=82201#c26">Comment # 26</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [HAWAII] GPU doesn't reclock, poor 3D performance" href="https://bugs.freedesktop.org/show_bug.cgi?id=82201">bug 82201</a> from <a class="email" href="mailto:kai@dev.carbon-project.org" title="Kai <kai@dev.carbon-project.org>"> Kai</a> <pre>After observing, that setting radeon.dpm=1 all the time doesn't guarantee a reclocking GPU all the time, I went back to looking, what I did *exactly* in the cases, where I got a reclocking GPU. I found, that I either had a reclocking GPU in the previous boot* or executed the VBIOS dump before. Doing the VBIOS dump causes several lines of "radeon 0000:01:00.0: Invalid ROM contents" appearing in dmesg's output and I get a reclocking GPU on the subsequent boot (can be easily verified with a vblank_mode=0 glxgears run, just look at the frames count, if it's in the 20k vicinity, the GPU reclocks; also, you can hear the fan going up after a few seconds). Not sure, what this means. I can only add, that booting with Catalyst gives me a reclocking GPU all the time. So it doesn't sound like a defect graphics card. But I hope it helps in tracking this issue down. I haven't tried yet, whether this survives a suspend to disk or RAM. * Using "poweroff" instead of "reboot" works as well, as long as you don't wait too long (sounds a bit like some memory is kept alive by a capacitor for some time after powering off). This explains my success of the run I detailed in <a href="show_bug.cgi?id=82201#c17">comment #17</a> AFAICT.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>