Using OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD SUMO2 OpenGL version string: 2.1 Mesa 8.0.3 OpenGL shading language version string: 1.20 AMD A4-3400 APU with Radeon(tm) HD Graphics Fedora 17 64bit Linux amd 3.4.5-2.fc17.x86_64 #1 SMP Mon Jul 16 20:52:08 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux According to http://wiki.x.org/wiki/RadeonFeature should echo profile > /sys/class/drm/card0/device/power_method echo high > /sys/class/drm/card0/device/power_profile put the GPU in high performance mode and echo profile > /sys/class/drm/card0/device/power_method echo low > /sys/class/drm/card0/device/power_profile in low performance mode. glxgears gives 60 FPS in both cases, which leads me to beleive that power management does work.
(In reply to comment #0) > glxgears gives 60 FPS in both cases, which leads me to beleive that power > management does work. Does your glxgears print this? > Running synchronized to the vertical refresh. The framerate should be > approximately the same as the monitor refresh rate.
Yes it does.
(In reply to comment #2) > Yes it does. So... vsync is making glxgears run at 60 FPS no matter what..
I see. If I do glxgears -geometry 1600x1024+0+0 then I get 40 FPS in both cases instead of 60fps. It takes ~3% CPU. If I start a 3D game in Wine, it feels the same (very slow).
There should be a way to check the engine clock to see if it's running at full speed: # cat /sys/kernel/debug/dri/0/radeon_pm_info You'll need debugfs mounted first. There was some talk on Phoronix about another APU running with very low clocks, could be something similar here perhaps? http://phoronix.com/forums/showthread.php?72046-E-450-graphics-performance-issues
Very interesting thread. It seams to be the same problem I have. Regardless of the power settings I never get a higher engine clock than ~75kHz. [root@amd ~]# cat /sys/kernel/debug/dri/0/radeon_pm_info default engine clock: 200000 kHz current engine clock: 73950 kHz default memory clock: 533000 kHz
You might have the same problem as me, see http://lists.freedesktop.org/archives/dri-devel/2012-July/025159.html First, the engine clock readout seems to be completely bogus on APUs, disregard it. Second, the power management functions limit the maximum engine clock to the default engine clock. On most standalone GPUs, the default clock seems to be equivalent to the maximum p-state's clock, so that is fine. Not so much on the APUs! I'm interested in what the AtomBIOS PowerPlay table looks like on your device. Can you boot with drm.debug=6 in the kernel command line and tell me what it says in the log?
Created attachment 64512 [details] dmesg with drm.debug=6
Created attachment 64513 [details] xorg log with drm.debug=6
Very interesting! What can you gather from the attached logs where I have booted with drm.debug=6 ?
Not much, actually, the table looks very similar to AMD PALM / Radeon 6320 on my netbook. The GPU part of Zacate and Llano is probably very similar, except for clocks and number of shader cores. And that means you suffer from the same issues. IMHO the sanity check that limits the clock should be removed altogether, as it doesn't make much sense. If you fancy recompiling the kernel, just comment this out from radeon_pm.c: 189 if (sclk > rdev->pm.default_sclk) 190 sclk = rdev->pm.default_sclk; This should get clock switching going.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/284.
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.