That you can't do this yet is a limitation of the X Server and not of the binary or open drivers. It is possible to run a separate X server and maybe with some tweaking Xinerama (so no 3D acceleration on any monitor) can be made working too.
Announcement
Collapse
No announcement yet.
UBO+TBO Support Comes To Radeon R600 Gallium3D
Collapse
X
-
Originally posted by AlbertP View PostThat you can't do this yet is a limitation of the X Server and not of the binary or open drivers. It is possible to run a separate X server and maybe with some tweaking Xinerama (so no 3D acceleration on any monitor) can be made working too.
Last edited by disi; 17 December 2012, 12:26 PM.
Comment
-
Originally posted by Sidicas View PostHave you tried rovclock? You just have to be careful with it as being too aggressive seems to cause hardware instability.
script for Radeon Mobility X700 only...
Code:start) echo "low" > /sys/class/drm/card0/device/power_profile #Must sleep here. Changing clocks before power_profile change finishes can #cause hardware instability. sleep 3s rovclock -c 180 -m 150 ;; stop) echo "high" > /sys/class/drm/card0/device/power_profile #Must sleep here. Changing clocks before power_profile change finishes can #cause hardware instability. sleep 3s rovclock -c 357.75 -m 330.75 ;;
Code:[root@disi-bigtop]/home/disi/data_local/images# rovclock -i Radeon overclock 0.6e by Hasw ([email protected]) Found ATI card on 01:00, device id: 0x6720 I/O base address: 0xe000 Video BIOS shadow found @ 0xc0000 Invalid reference clock from BIOS: 0.0 MHz Memory size: 0 kB Memory channels: 1, CD,CH only: 0 tRcdRD: 3 tRcdWR: 1 tRP: 3 tRAS: 6 tRRD: 1 tR2W-CL: 1 tWR: 1 tW2R: 0 tW2Rsb: 0 tR2R: 1 tRFC: 13 tWL(0.5): 0 tCAS: 0 tCMD: 0 tSTR: 0 zsh: floating point exception (core dumped) rovclock -i
Comment
-
Originally posted by Sidicas View PostHave you tried rovclock? You just have to be careful with it as being too aggressive seems to cause hardware instability.
script for Radeon Mobility X700 only...
Code:start) echo "low" > /sys/class/drm/card0/device/power_profile #Must sleep here. Changing clocks before power_profile change finishes can #cause hardware instability. sleep 3s rovclock -c 180 -m 150 ;; stop) echo "high" > /sys/class/drm/card0/device/power_profile #Must sleep here. Changing clocks before power_profile change finishes can #cause hardware instability. sleep 3s rovclock -c 357.75 -m 330.75 ;;
Secondly, changing the power profiles already sets the sclk and mclk properly in the driver. Why are you running rovclock as well? If it's even working at all on your board, all it's doing is messing up the logic in the driver by banging on the hardware behind it's back.
Comment
-
For me the free R600-R700 drivers have been in a real good state since the transition to Gallium3D was completed. I mean, I was able to play Trine 2 which is a fairly graphically advanced title a few days after the initial binaries were released on the free drivers without any problems. I initially hit a problem with getting the game to run which I thought was a driver problem, but in the end it was actually a problem with the game itself (which has since been fixed). Since then it has pretty reliably been handling pretty much every game I have been throwing at it. My tastes for older/indie games may play a role here, but it is still working quite nicely for me.
Power management has been working fine for me with the power state modes (I even made myself a separate GUI application for handling the toggling of these power modes) and I have had little to no problems with stability. About the only thing I could ask for is somewhat better performance and potentially dynamic power management (although for me the current setup is working well), and there are several different performance fixes in the latest code. My card is a Diamond Radeon HD 4670 with 1 GB of vram.
Comment
-
Originally posted by agd5f View PostFirst off, don't use rovclock. It only really supported r1xx-r3xx asics, and even then, it never took into account the post dividers for sclk and mclk so unless the post divider was set to 1, it programmed the wrong clocks. It also doesn't properly set the vram timing a lot of asics. On newer asics it will not work at all because the relevant registers have all changed so you are just banging on completely unrelated registers which will likely cause other problems.
Secondly, changing the power profiles already sets the sclk and mclk properly in the driver. Why are you running rovclock as well? If it's even working at all on your board, all it's doing is messing up the logic in the driver by banging on the hardware behind it's back.
agd5f, Is it possible that superior power efficiency of fglrx comes from ability to suspend parts of gpu (ie reduce available shader units amount and diasble not used other parts of the chip on the fly)?
I did few tests on two laptops eqipped with Radeon 4330m (Samsung R522) and 5650m (Sony Vaio, can't tell the exact model right now). According to te powertop there were huge defference on power usage comparing to Catalys when computers were idle or under light load (reading documents, logs ion konsole, windows switch etc...). Both lappies using FOSS driver idled at about 18Watts, under light load power usage rose to about 22-24 watts (powr profile low).
The same tasks under fglrx used about 15W (downloading nexuiz and flightgear from Fedora repo over wifi while scrolling trough logs made Sony using 16.1W). Idle power usage was even more impessive: ~11W for Sony, my R522 could go as low as 9.7W if left untouched for about 15 minutes.
Interesting thing is in both cases with foss driver used, power usage was able to go dow to ~15Watt when screen "dpms off" kicked in. IIRC there is optoin "DynamicPM" which disables most of the gpu when displays are sturned off, could it be thae way to get closer to pm levels presn in fglrx?
FLRX has to do something radically different than radeon driver to explain this.
Comment
-
Originally posted by Xeno View Postagd5f, Is it possible that superior power efficiency of fglrx comes from ability to suspend parts of gpu (ie reduce available shader units amount and diasble not used other parts of the chip on the fly)?
We'd need basic support for clock gating and dynamic frequency switching (without relying on AtomBIOS) to get anywhere near fglrx in terms of power efficiency. Maybe in 10 years. I'm dead serious.
Comment
-
Originally posted by agd5f View PostFirst off, don't use rovclock. It only really supported r1xx-r3xx asics, and even then, it never took into account the post dividers for sclk and mclk so unless the post divider was set to 1, it programmed the wrong clocks. It also doesn't properly set the vram timing a lot of asics. On newer asics it will not work at all because the relevant registers have all changed so you are just banging on completely unrelated registers which will likely cause other problems.
Secondly, changing the power profiles already sets the sclk and mclk properly in the driver. Why are you running rovclock as well? If it's even working at all on your board, all it's doing is messing up the logic in the driver by banging on the hardware behind it's back.
Comment
Comment