Page 3 of 3 FirstFirst 123
Results 21 to 28 of 28

Thread: UBO+TBO Support Comes To Radeon R600 Gallium3D

  1. #21
    Join Date
    May 2011
    Posts
    353

    Default

    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.

  2. #22
    Join Date
    Nov 2009
    Posts
    379

    Default

    Quote Originally Posted by AlbertP View Post
    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.
    This works flawless with the open driver, thanks to the recent improvements to the xorg-server.

    http://support.plugable.com/plugable...nd_displaylink
    Last edited by disi; 12-17-2012 at 12:26 PM.

  3. #23
    Join Date
    Nov 2009
    Posts
    379

    Default

    Quote Originally Posted by Sidicas View Post
    Have 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
                    ;;
    I've been running that for several months now, clocking up for gaming and watching videos. Clocking back down for writing e-mails / web browsing.. and it works great.
    Does that look healthy?
    Code:
    [root@disi-bigtop]/home/disi/data_local/images# rovclock -i
    Radeon overclock 0.6e by Hasw (hasw@hasw.net)
    
    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

  4. #24
    Join Date
    Dec 2007
    Posts
    2,404

    Default

    Quote Originally Posted by Sidicas View Post
    Have 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
                    ;;
    I've been running that for several months now, clocking up for gaming and watching videos. Clocking back down for writing e-mails / web browsing.. and it works great.
    First 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.

  5. #25
    Join Date
    Oct 2011
    Location
    Rural Alberta, Canada
    Posts
    1,058

    Default

    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.

  6. #26
    Join Date
    May 2009
    Posts
    44

    Default

    Quote Originally Posted by agd5f View Post
    First 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.

  7. #27
    Join Date
    Jan 2010
    Posts
    368

    Default

    Quote Originally Posted by Xeno View Post
    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)?
    It's the clock gating that's missing for R600+ GPUs. This halts clocks of different parts of the GPU if they aren't needed. Unfortunately there's no information about this feature available at all, and supposedly it's quite complicated. It's quite a letdown, because clock gating is fully supported on R500 GPUs (the implementation is quite different on these GPUs).

    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.

  8. #28
    Join Date
    Nov 2009
    Posts
    379

    Default

    Quote Originally Posted by agd5f View Post
    First 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.
    At least, now I know it won't work with my card. It would be helpful to fine tune the e.g. memory clock... like in my case the external monitor is not detected and I would like to have like ~300MHz memory clock instead of 150MHz?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •