Wow. Just wow.
I installed the OSS driver+the whole shebang (mesa devel, kernel 3.11, libdrm, ati drv 7.10 or whatever the latest it is) for UVD and dpm on a A8-5500 APU (7560D IGP). Took me a while, especially after the installation, to actually get the system to use these libs.
Having played with and on it, i have to say that the radeon OSS drivers really kick ass. Really.Code:
$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD ARUBA
OpenGL version string: 3.0 Mesa 9.3.0-devel (git-bff0d87)
OpenGL shading language version string: 1.30
- The idle temperature is 2 or 3 degrees higher than with fglrx which is very acceptable.
The following were features that werent working before:
- dpm clocking works perfectly - it clocks up and down when its neded, doesnt stay up needlessly. This is true for both the uvd and gpu clock speeds (monitor it by /sys/kernel/debug/dri/0/radeon_pm_info).
- the CPU speed adjusts as it should - previously, despite the governor demanding higher clock speeds, reflected in /proc/cpuinfo, the ACTUAL speed was the LOWEST possible (measured with cpufreq-aperf). Took me an eternity to compile the kernel on it and i didnt know why is that hellishly slow initially when cpuinfo reported 3.2 GHz speeds (which is misleading because that is the requested, highest possible p-state, and seems like the old radeon driver is picky about stuff ike that and didnt allow it). It took me some time to figure out how to actually crank up the speeds.
Also, it seems that Turbo Core is working aswell (3.488 GHz was the maximum recorded with fglrx aswell) - cpufreq-aperf reports the following with 1 thread loaded:
Interesting that 2 cores are up to speed in reality (cpuinfo shows only 1 at the nominal 3.2 GHz) - probably because of the modular design.Code:
CPU Average freq(KHz) Time in C0 Time in Cx C0 percentage
000 1376000 00 sec 103 ms 00 sec 896 ms 10
001 1376000 00 sec 086 ms 00 sec 913 ms 08
002 3488000 00 sec 015 ms 00 sec 984 ms 01
003 3488000 00 sec 998 ms 00 sec 001 ms 99
- the dynamic voltage adjusting onn the APU is working correctly (it goes down to 0.9v and up until 1.34 or so, like with fglrx). Previously it stayed at 1.34 or 1.44 permanently, causing +10-12 C temperatures.
-vdpau decoding works (has some kinks in xbmc - namely if i switched from windowed to fullscreen or vice versa, screen went black, had to kill it from tty1, but mplayer was good so far).
And the thing that blew me away the most is:
TF2 is actually plays SMOOTHER than with fglrx (i mean plays perfectly, including less loading times). Never expected this.
OTOH DoD (Day of Defeat, on hl1 engine) is actually SLOWER THAN TF2 on Source engine. Weird.
Also, i played around in the browser (Seamonkey, uses Firefox' engine) with the WebGl (OpenGL rendered DIRECTLY by the browser) demos over here:
To my surprise, the demos worked well, i tried the flight sim, the car visualizer, the sphere in the water, the pearl boy - all worked without a hitch.
I use Debian Testing 64-bit, Xfce 4.10 (no compositing). Until now i used exclusively fglrx.
I planned only a test with these new features but i think i'll stick around a bit more... :)
Awesome work, devs. http://www.depressionforums.org/foru...efault/bow.gif
On my Radeon HD 6870 it doesn't seem to work atm. Then again, I've heard so many good opinions about DPM that I'm really looking forward to it.
This is what will make me switch to the OS drivers. For gaming (which I rarely do nowadays) I've got my PS3 and soon a PS4.
Yes, I'm using that exact firmware from the before mentioned download link (BARTS_smc). I even tried linux-firmware-git.
When did you try out that feaure? Because I've read that it worked before for some hd 6870 users but it is now broken, could be a regression.
Any idea of when we will be able to change the value of these power modes?
I need to use a specific clock ratio of 0.57 (969Mhz Core / 1700Mhz Memory) for my array of Radeon 7970. OpenCL work but that reclocking is the only missing thing that prevent me switching (so i'm stuck with Crapalyst 13.1 patched for kernel 3.10, Newer drivers crash from time to time...)
I'm assuming that it's a regression as I've heard from some people that dpm worked for them before but now doesn't anymore.
Linux Saturn 3.11.0-rc4 #1 SMP PREEMPT Mon Aug 5 01:36:06
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barts PRO [Radeon HD 6850]
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Barts HDMI Audio [Radeon HD 6800 Series]
Works for me too. Debian Testing 64-bit, kernel 3.11.0-rc4, A8-5500/HD 7560D, mesa, xf86-ati from git (libdrm is at the newest release version).
The thing that bothers me is the fact that if i turn off the video output (dpms), after a few hours of idleness the computer freezes totally. I made a script that simulates mouse movement with xdotool every half hour (only if the monitor is off) to wake up the monitor (it turns off after 4 minutes) - since i put that in crontab, i havent had any freezes. Turning off dpms altogether too helps.
1. Making use of the dpm feature requires more than just the kernel and compiled mesa/etc - you have to make absolutely sure the new libs are actually used. Even after an update you have to recheck (ldd /usr/bin/glxinfo), maybe ldconfig decides to do a stunt and puts back some old libs...
2. I have seen some weird boot up behavior, such as the APU being powered with its maximum voltage until i did a dpms cycle (off/on) or i changed to another vt and back (which i suppose does something similar). After that the voltage regulation kicked in as it should.