Test Env: ------------------------------------ Platform: HSW Arch: x86 OS: Fedora 19 Xserver: (server-1.14-branch)xorg-server-1.14.4.901 Xf86_video_intel: (master)2.99.906 Kernel: kernel-3.12.2_20131203+-2.x86_64 Reproduced Steps: ------------------------------------ 1. rpm -ivh kernel-3.12.2_20131203+-2.x86_64.rpm 2. Start up X. 3. Check the minimum frequency: cat /sys/class/drm/card0/gt_min_freq_mhz 4. Check the maximum frequency：cat /sys/class/drm/card0/gt_max_freq_mhz 5. Check the current frequency: cat /sys/class/drm/card0/gt_cur_freq_mhz 6. Start glxgears && cat /sys/class/drm/card0/gt_cur_freq_mhz 7. Stop glxgears && cat /sys/class/drm/card0/gt_cur_freq_mhz The expected phenomenon should be: when start glxgears, the current frequency should be reach to max frequency(e.g. 1100MHz), when stop glxgears, the current frequency should be fall down to minimum frequency(e.g. 200MHz) quickly. However, actually, when we start glxgears, we cat /sys/class/drm/card0/gt_cur_freq_mhz and got frequency remain minimum value, after 30 mins, the value reach to peak value. At this time, when we kill glxgears, the peak value fall down a little(e.g. 100HMz, from 1100MHz to 1000MHz) instead of our expected minimum value(e.g. 200MHz). Reproduced Rate: ------------------------------------ 100%
Can you please retest with latest drm-intel-nightly? Chris' turbo improvements should help here a lot.
glxgears in its default configuration can hit its framerate with min frequency.
They also have an issue with the freq not going down quickly afterwards, imo that's worth testing a bit ...
It's so unlikely, one suspects a reporting error.
Daniel Vetter & Chris Wilson , we tried with kernel 3.13.0-rc1_drm-intel-nightly_41199e_20131207+ with the following two experiments: 1. Experiment One: 1> Made a script to cat /sys/class/drm/card0/gt_cur_freq_mhz every second and name the script as ls_cur_freq_mhz.sh, you can refer to the following details: #file: ls_cur_freq_mhz.sh #!/bin/bash peak_freq=$(cat /sys/class/drm/card0/gt_max_freq_mhz) min_freq=$(cat /sys/class/drm/card0/gt_min_freq_mhz) echo "freq_rangle: [${min_freq}~${peak_freq}]MHz" while true do cur_freq=$(cat /sys/class/drm/card0/gt_cur_freq_mhz) echo "current frequency is: ${cur_freq}" sleep 1 done 2> . ls_cur_freq_mhz.sh in one terminal; 3> Startup glxgears & in another terminal; 4> check the current frequency output, if got current frequency is 200, just repeat 3>, until got frequency is 1100. 4> pkill glxgears and moniter the current frequency output. In kernel 3.13.0-rc1_drm-intel-nightly_41199e_20131207+, we tried more than 20 times, generally, run 2 glxgears at background will lead to current frequency to 1100MHz. Then, we pkill glxgears and moniter the current frequency output. The frequency falling down immediately just corresponding we kill the glxgears process. In kernel kernel-3.12.2_20131203+-2.x86_64, we found more than 2 glxgears can also trigger to peak frequency, but after we kill all the glxgears via pkill, the current frequency output still just fall down by 100(from 1100 to 1000). 2. Experiment Two: Still use script ls_cur_freq_mhz.sh to moniter the current frequency output. However, we changed a heavy-load game with fullscreen mode. Accordingly, we discover kernel 3.13.0-rc1_drm-intel-nightly_41199e_20131207+ can reach to peak frequency 1100, and can fall down to 200 as soon as the game process exit. However, when we changed kernel to kernel-3.12.2_20131203+-2.x86_64, the frequency output changed from 300 to 1100, and when the game process exit the current frequency keep at 550. this will no change though there is no workload running. (In reply to comment #3) > They also have an issue with the freq not going down quickly afterwards, imo > that's worth testing a bit ...
So not a bug in upstream.
(In reply to comment #6) > So not a bug in upstream. Okay, thanks for your comments, Chris Wilson. So marked this as verified.
Closing old verified.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.