Announcement

Collapse
No announcement yet.

AMD R600g Now Does TBO, UBO & Advertises GLSL 1.40

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

  • AMD R600g Now Does TBO, UBO & Advertises GLSL 1.40

    Phoronix: AMD R600g Now Does TBO, UBO & Advertises GLSL 1.40

    Last year UBO and TBO for the Radeon R600 Gallium3D driver was talked about and early patches proposed, but merged on Friday was finally this support for Uniform Buffer Objects and Texture Buffer Objects. With the OpenGL UBO/TBO support, the Radeon R600g driver is now advertising GLSL 1.40 as needed for OpenGL 3.1 compliance...

    http://www.phoronix.com/vr.php?view=MTI3Mjk

  • #2
    Wow. I just looked at the TODO list: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
    It looks like GLSL 1.5 is the last big hurdle for full OpenGL 3.3 compliance.
    Good work, mesa devs!

    Comment


    • #3
      Originally posted by DanL View Post
      Wow. I just looked at the TODO list: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
      It looks like GLSL 1.5 is the last big hurdle for full OpenGL 3.3 compliance.
      Good work, mesa devs!
      You forgot Geometry shaders. That's the really big problem as AFAIK no further progress anymore (GLSL gets love from Intel OTC).

      Comment


      • #4
        Originally posted by zxy_thf View Post
        You forgot Geometry shaders. That's the really big problem as AFAIK no further progress anymore (GLSL gets love from Intel OTC).
        Lets hope it and Clover gets hammered out and commited fast so that this fall's distro update cycle can have full OpenGL 3.3 and OpenCL 1.2 support activated by default in the OSS drivers.

        Then onward to OpenGL 4 glory!

        Comment


        • #5
          Problem loading the driver

          Does anyone have this problem with these latest commits:

          libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/r600_dri.so
          libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so
          libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/xorg/modules/dri/r600_dri.so: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE)
          libGL error: unable to load driver: r600_dri.so
          libGL error: driver pointer missing
          libGL error: failed to load driver: r600

          Comment


          • #6
            Originally posted by zxy_thf View Post
            You forgot Geometry shaders. That's the really big problem as AFAIK no further progress anymore (GLSL gets love from Intel OTC).
            There is a tree on github with unproven geometry shader code for r600g, intel would need to add 965 support, it just needs a lot of piglit tests and a lot of review, the last missing bit then is GL_ARB_texture_multisample which is also under construction by another dev for 965, which could be fixed up for gallium fairly easily hopefully.

            but writing the piglit tests for geometry shaders is probably the biggest problem.

            Dave.

            Comment


            • #7
              It's interesting that OpenGL 3.3 is ready, according http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt. Does that mean when GL 3.2 gets done we automatically have and GL 3.3?

              Comment


              • #8
                Originally posted by pejakm View Post
                It's interesting that OpenGL 3.3 is ready, according http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt. Does that mean when GL 3.2 gets done we automatically have and GL 3.3?
                yeah pretty much.

                Comment


                • #9
                  Originally posted by pejakm View Post
                  Does anyone have this problem with these latest commits:
                  [...]
                  https://bugs.freedesktop.org/show_bug.cgi?id=59282

                  Comment


                  • #10
                    Cool work devs!

                    I have a question, whats the state of power-saving on AMD? I tried using the open source driver on my laptop (A4 chipset) several months ago and the battery life was too short. (10 with binary driver compared to 2 hours with the open source driver) Is there anyone working on this issue?

                    Thank you for your time and hope you guys have a great weekend!

                    Comment


                    • #11
                      Originally posted by ua=42 View Post
                      I have a question, whats the state of power-saving on AMD?
                      Apparently, there is very advanced code going through technical review over at AMD. Nobody knows how long that could take.

                      In the meantime, you should use profiles, which work perfectly with FLOSS drivers. Force low power state on boot, and switch manually to high power state before gaming or anything intensive.

                      Check here for instructions: http://www.x.org/wiki/RadeonFeature

                      Comment


                      • #12
                        Originally posted by pingufunkybeat View Post
                        Check here for instructions: http://www.x.org/wiki/RadeonFeature
                        Better version from the Arch wiki: https://wiki.archlinux.org/index.php...th_KMS_enabled

                        With root access, you have two choices:

                        1. Dynamic frequency switching (depending on GPU load)

                        # echo dynpm > /sys/class/drm/card0/device/power_method

                        The "dynpm" method dynamically changes the clocks based on the number of pending fences, so performance is ramped up when running GPU intensive apps, and ramped down when the GPU is idle. The re-clocking is attempted during vertical blanking periods, but due to the timing of the re-clocking functions, does not always complete in the blanking period, which can lead to flicker in the display. Due to this, dynpm only works when a single head is active.
                        Note: The "profile" method mentioned below is not as aggressive as "dynpm," but is currently much more stable and flicker free and works with multiple heads active.

                        2. Profile-based frequency switching

                        # echo profile > /sys/class/drm/card0/device/power_method

                        The "profile" mode will allow you to select one of the five profiles below. Different profiles, for the most part, end up changing the frequency/voltage of the card.

                        "default" uses the default clocks and does not change the power state. This is the default behavior.
                        "auto" selects between "mid" and "high" power states based on the whether the system is on battery power or not. The "low" power state are selected when the monitors are in the dpms off state.
                        "low" forces the gpu to be in the low power state all the time. Note that "low" can cause display problems on some laptops; this is why auto only uses "low" when displays are off.
                        "mid" forces the gpu to be in the "mid" power state all the time. The "low" power state is selected when the monitors are in the dpms off state.
                        "high" forces the gpu to be in the "high" power state all the time. The "low" power state is selected when the monitors are in the dpms off state.

                        So lets say we want the "low" option...for this, run the following command:

                        # echo low > /sys/class/drm/card0/device/power_profile

                        Replace "low" with any of the aforementioned profiles as necessary.
                        Note: Echoing a profile value to this file is not permanent, so when you find something that fits your needs, you will need to add it to /etc/rc.local, so it is executed at system startup, in case you are using initscripts. In case of using systemd there will be no /etc/rc.local file, you can use following udev rule:

                        dynpm-method example:

                        $ cat /etc/udev/rules.d/30-local.rules

                        KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="radeon", ATTR{device/power_method}="dynpm"

                        auto-profile example:

                        $ cat /etc/udev/rules.d/30-local.rules

                        KERNEL=="card0", SUBSYSTEM=="drm", DRIVERS=="radeon", ATTR{device/power_method}="profile", ATTR{device/power_profile}="auto"

                        Note: Gnome-shell users may be interested in the following extension: Radeon Power Profile Manager for manually controlling the GPU profiles.

                        Comment


                        • #13
                          Unfrotunatelly FOSS driver pm capabilies are light-years behind catalyst. If powertop numbers from 2 mobile chipsets (radeon 4330 and 5650) are in any way meaningfull, going from high to low profile on idle/low load saves about 2watts, going from radeon low profile to catalysts gives another 5W. Also the problem is not just battery life, heat is even ore important. Fryning +1000$ laptop is way uncool. (pun kinda intended).

                          To add, KDE users might wanna try RadeonPM plasmoid. It shows cards hw info (GPU/merm frequency, voltage and temp if sensors are provided) and allows switching profiles, pm methods.
                          Last edited by Xeno; 01-12-2013, 03:21 PM.

                          Comment


                          • #14
                            Compiled the latest code and still there's no OpenGL 3.1. Looking at GL3.txt at docs I see that for r600 GL_ARB_draw_instanced isn't yet done.

                            Comment


                            • #15
                              Originally posted by pejakm View Post
                              Compiled the latest code and still there's no OpenGL 3.1. Looking at GL3.txt at docs I see that for r600 GL_ARB_draw_instanced isn't yet done.
                              glxinfo won't report core profiles yet, nothing to do with draw instanced.

                              So until we fix glxinfo it'll only show 3.0.

                              Dave.

                              Comment

                              Working...
                              X