Announcement

Collapse
No announcement yet.

UBO+TBO Support Comes To Radeon R600 Gallium3D

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by disi View Post
    What I really wait for, is the time when we can tell it which clockspeed to use manually. Then I would put the memory clock on half speed and the gpu clock maybe 1/4 or so
    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.
    Last edited by Sidicas; 12-17-2012, 04:54 AM.

    Comment


    • #17
      In this topic I have seens some reports of impressive open-source performance. I think it is indeed true that the Gallium drivers are quite fast, but... not everybody is as lucky as you when it comes to power management. Some cards from AMD and NVIDIA start in a low power level by default. Other cards are in a high power level by default. Because dynamic power management isn't implemented or working yet in open drivers this is causing huge differences in performance between cards, and that's also why the open drivers are reported to suck; that's on cards which are in a low level by default or allows no manual setting of power levels yet, or reported by people who don't want to change the level manually every time.

      Comment


      • #18
        Originally posted by smitty3268 View Post
        It's funny, because it seems like most of the people claiming it sucks are like you - nvidia users who haven't even tried the AMD driver because they've heard it sucks so much.
        I own both Nvidia and AMD GPUs, and in my experience AMD's driver support is quite lacking. Although Nvidia only supports a closed source blob, you can usually be sure that all advertised features work as expected and with good performance. With AMD, no matter if you use the open source or closed source drivers, not so much. Fortunately the open source driver is advancing quite nicely lately.

        IMHO, AMD should focus driver efforts on one codebase. I don't really care if that is fglrx or the radeon open source drivers, but the duplicate effort currently going on is wasting resources without getting good results.

        Comment


        • #19
          Originally posted by smitty3268 View Post
          It's funny, because it seems like most of the people claiming it sucks are like you - nvidia users who haven't even tried the AMD driver because they've heard it sucks so much.
          Yes, the tireless FUD trolls are doing their damage.

          I've been on Free AMD drivers for years now. The major remaining issues for everyday users are dynamic power management and performance. On the other hand, they are stable and reliable, and finally catching up on full OpenGL support.

          If you can live with a 30% performance drop for a while, and don't mind switching power modes by hand before you play a game, they are a good choice for most people.

          Comment


          • #20
            Originally posted by brent View Post
            I own both Nvidia and AMD GPUs, and in my experience AMD's driver support is quite lacking. Although Nvidia only supports a closed source blob, you can usually be sure that all advertised features work as expected and with good performance. With AMD, no matter if you use the open source or closed source drivers, not so much. Fortunately the open source driver is advancing quite nicely lately.

            IMHO, AMD should focus driver efforts on one codebase. I don't really care if that is fglrx or the radeon open source drivers, but the duplicate effort currently going on is wasting resources without getting good results.
            Can you run an external monitor via USB on NVIDIA or AMD binary drivers? Like 'Plug&See'?
            I asked because NVIDIA recently got xrandr support...

            Comment


            • #21
              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.

              Comment


              • #22
                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, 11:26 AM.

                Comment


                • #23
                  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

                  Comment


                  • #24
                    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.

                    Comment


                    • #25
                      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


                      • #26
                        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.

                        Comment


                        • #27
                          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.

                          Comment


                          • #28
                            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?

                            Comment

                            Working...
                            X