Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Gets UBO/TBO Support, OpenGL 3.3

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

  • #16
    Originally posted by zanny View Post
    If you are getting half performance of another software implementation of a driver, there are some fundamental missing features of the gpu you aren't using. Maybe if AMD would stop crippling their gpus with firmware blobs some of the Red Hat or Novell guys would help use the SI architecture to its potential, but as long as we only get face value FOSS drivers over obfuscated hardware we're stuck with the halfhearted efforts AMD is making.
    By your comment it seems you may not be familiar with the method in which the open source drivers are developed. While AMD does provide support for open source driver development (even employing a few developers) they are largely "on their own" and they are not backed up by the large volume of developers and engineers that otherwise work for AMD. I certainly don't profess to know what resources they AMD open source devs have at their disposal, but Xorg devs certainly only have a limited set of resources to work with. If you're going to fault AMD for anything, fault them for not operating like Intel does and don't push for fully open source driver development across the board, don't fault the limited (but steadily increasing) performance of the open source, community developed driver.

    Comment


    • #17
      Originally posted by Ancurio View Post
      Feature parity =/= efficiency parity. Everything could be looking correctly graphics wise while still running at 30% of the binary blob's speed.
      I know, but Michael has been providing enough relevant benchmarks lately, and performance is "good enough" for everything I need. It's already beating catalyst in some benchmarks, and it's steadily rising.

      I have to admit, I'm upgrading for windows gaming performance. Guild Wars 2 @ 2560x1440 is demanding enough that I wouldn't even accept the overhead of the wine layer, and I don't play other games at the moment. Otherwise, my old GPU is fast enough for all my linux needs, so all I'm looking for right now is simply a regression-free upgrade.

      I'm hoping that during 2014, when SteamOS takes off, the OSS drivers will have closed the gap enough that I can look at gaming on linux again.

      Comment


      • #18
        Originally posted by dffx View Post
        By your comment it seems you may not be familiar with the method in which the open source drivers are developed. While AMD does provide support for open source driver development (even employing a few developers) they are largely "on their own" and they are not backed up by the large volume of developers and engineers that otherwise work for AMD. I certainly don't profess to know what resources they AMD open source devs have at their disposal, but Xorg devs certainly only have a limited set of resources to work with. If you're going to fault AMD for anything, fault them for not operating like Intel does and don't push for fully open source driver development across the board, don't fault the limited (but steadily increasing) performance of the open source, community developed driver.
        Actually, the way it works is that AMD employees write a basic driver and release it together with documentation and source. Then the community improves it.

        RadeonSI was written almost entirely by AMD employees on AMD payroll. Now the time is coming for the community to optimise it.

        The experience of r300g and r600g is a really positive one. Both drivers started with poor performance, but increased rapidly until they (almost) matched Catalyst. RadeonSI is on that path now -- mostly working, optimisations beginning.

        Comment


        • #19
          Originally posted by pingufunkybeat View Post
          RadeonSI was written almost entirely by AMD employees on AMD payroll. Now the time is coming for the community to optimise it.
          I am not sure there are many that can do this in the community.

          Comment


          • #20
            Originally posted by 89c51 View Post
            I am not sure there are many that can do this in the community.
            Well, there's a good thing about this. There were several community developers who could do this, and now many of them are working for AMD: Marek, Tom and Christian were all community developers who were later hired by AMD to work on the drivers full-time.

            Marek did a huge number of optimisations and added many features to r600g and r300g before joining AMD. Christian König figured out and implemented HDMI audio before joining AMD, etc.

            Then there are experienced developers such as Dave Airlie and Jerome Glisse of Red Hat, who are paid to work on open drivers, but not by AMD.

            Hopefully, there will be new community members popping up. With something as complex as GPU drivers, it will always be a small number, but even a small number of talented guys can make a huge difference.

            Comment


            • #21
              glsl mixture

              After todays update from git it says I have openGL 3.0 AND 3.1:

              glxinfo | grep Open
              ATTENTION: default value of option force_s3tc_enable overridden by environment.
              OpenGL vendor string: X.Org
              OpenGL renderer string: Gallium 0.4 on AMD TAHITI
              OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.0-devel
              OpenGL core profile shading language version string: 1.40
              OpenGL core profile context flags: (none)
              OpenGL core profile extensions:
              OpenGL version string: 3.0 Mesa 10.0.0-devel
              OpenGL shading language version string: 1.30
              OpenGL context flags: (none)
              OpenGL extensions:

              what could be causing this?

              Comment


              • #22
                Originally posted by tomtomme View Post
                After todays update from git it says I have openGL 3.0 AND 3.1:

                glxinfo | grep Open
                ATTENTION: default value of option force_s3tc_enable overridden by environment.
                OpenGL vendor string: X.Org
                OpenGL renderer string: Gallium 0.4 on AMD TAHITI
                OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.0-devel
                OpenGL core profile shading language version string: 1.40
                OpenGL core profile context flags: (none)
                OpenGL core profile extensions:
                OpenGL version string: 3.0 Mesa 10.0.0-devel
                OpenGL shading language version string: 1.30
                OpenGL context flags: (none)
                OpenGL extensions:

                what could be causing this?
                It's the core version. The 3.0 is the compatibility version. Basically, if you have a game (such as Natural Selection 2) that requires 3.1 compatibility version, then you won't be able to use it. I've heard it said that the compatibility version is the "true" OpenGL version, but I don't know that I put much credence in that.

                That said, my glxinfo doesn't give a core profile.

                Code:
                DRI_PRIME=1 glxinfo -t | grep OpenGL
                OpenGL vendor string: X.Org
                OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
                OpenGL version string: 3.0 Mesa 10.0.0-devel (git-86cdff5)
                OpenGL shading language version string: 1.30
                OpenGL context flags: (none)
                OpenGL extensions:
                Does anyone know why that is? My mesa-demos package is: mesa-demos 8.1.0-1

                Comment


                • #23
                  Code:
                  OpenGL vendor string: X.Org
                  OpenGL renderer string: Gallium 0.4 on AMD TAHITI
                  OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.0.0-devel (git-86cdff5)
                  OpenGL core profile shading language version string: 1.40
                  OpenGL core profile context flags: (none)
                  OpenGL core profile extensions:
                  OpenGL version string: 3.0 Mesa 10.0.0-devel (git-86cdff5)
                  OpenGL shading language version string: 1.30
                  OpenGL context flags: (none)
                  OpenGL extensions:
                  At least, kwin now works with 3.1 opengl.

                  Comment


                  • #24
                    Originally posted by dffx View Post
                    It's the core version. The 3.0 is the compatibility version. Basically, if you have a game (such as Natural Selection 2) that requires 3.1 compatibility version, then you won't be able to use it. I've heard it said that the compatibility version is the "true" OpenGL version, but I don't know that I put much credence in that.

                    That said, my glxinfo doesn't give a core profile.

                    Code:
                    DRI_PRIME=1 glxinfo -t | grep OpenGL
                    OpenGL vendor string: X.Org
                    OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN
                    OpenGL version string: 3.0 Mesa 10.0.0-devel (git-86cdff5)
                    OpenGL shading language version string: 1.30
                    OpenGL context flags: (none)
                    OpenGL extensions:
                    Does anyone know why that is? My mesa-demos package is: mesa-demos 8.1.0-1
                    My mesa-demos is 9.0.99
                    In addition I have mesa-demo-x at verstion 8.1.0

                    Comment


                    • #25
                      Originally posted by dffx View Post
                      By your comment it seems you may not be familiar with the method in which the open source drivers are developed. While AMD does provide support for open source driver development (even employing a few developers) they are largely "on their own" and they are not backed up by the large volume of developers and engineers that otherwise work for AMD. I certainly don't profess to know what resources they AMD open source devs have at their disposal, but Xorg devs certainly only have a limited set of resources to work with. If you're going to fault AMD for anything, fault them for not operating like Intel does and don't push for fully open source driver development across the board, don't fault the limited (but steadily increasing) performance of the open source, community developed driver.
                      I'm not faulting the code in the open, I'm faulting the effective inability for your average joe to really help implement the critical missing functionality of the SI hardware because the firmware blobs are obfuscated you can't know if you are actually utilzing the hardware properly. If they would release the microcode specs, the firmware, and any design documentation that explains exactly how to optimally use their pipeline, I (and other devs I imagine) might fathom spending a few hundred hours trying to make the mesa driver work with their new hardware.

                      Comment


                      • #26
                        Originally posted by zanny View Post
                        I'm not faulting the code in the open, I'm faulting the effective inability for your average joe to really help implement the critical missing functionality of the SI hardware because the firmware blobs are obfuscated you can't know if you are actually utilzing the hardware properly. If they would release the microcode specs, the firmware, and any design documentation that explains exactly how to optimally use their pipeline, I (and other devs I imagine) might fathom spending a few hundred hours trying to make the mesa driver work with their new hardware.
                        I think you're reading much more into the microcode than is actually there. All the documentation describes behaviour of chip+microcode, and the binary driver programs to the same interface. Have you actually read the current documentation ?

                        Comment


                        • #27
                          Originally posted by tomtomme View Post
                          My mesa-demos is 9.0.99
                          In addition I have mesa-demo-x at verstion 8.1.0
                          Hmmm, wonder what your mesa-demos package is. As far as I can tell, 8.1.0 is the latest stable release: http://cgit.freedesktop.org/mesa/demos

                          Which is likely what your mesa-demo-x package is.

                          What distro?

                          Comment


                          • #28
                            Stupid 2-minute edit limit.

                            There seems to be ongoing confusion between firmware (executed on the CPU) and microcode (part of the GPU HW design). The Linux interface to load microcode images has "firmware" in the name which probably doesn't help.

                            A number of hardware blocks on the GPU are designed around microcode rather than pure random logic, even seemingly "dumb" blocks like the memory controller. We release those microcode images under a license which allows redistribution in Linux distros or devices and the driver loads them into the hardware -- the chip is pretty much "dead" until the microcode images are loaded because the microcode is effectively part of the hardware design.

                            Documentation is at : http://www.x.org/wiki/RadeonFeature/#index10h2 . Maybe start with "AMD Southern Islands / Sea Islands Acceleration".

                            Comment


                            • #29
                              Originally posted by bridgman View Post
                              Stupid 2-minute edit limit.
                              Uh? Didn't Michael remove it?
                              ## VGA ##
                              AMD: X1950XTX, HD3870, HD5870
                              Intel: GMA45, HD3000 (Core i5 2500K)

                              Comment


                              • #30
                                Originally posted by darkbasic View Post
                                Uh? Didn't Michael remove it?
                                Sort of -- IIRC there used to be a ~1 minute limit -- Michael bumped it to 30 minutes a year or so ago. Now it seems to be back to 2 minutes.

                                zanny:

                                - the "firmware" debates related to using AtomBIOS -- low level firmware shared by VBIOS and gfx drivers -- not the on-GPU microcode

                                - you might find starting with 5xx acceleration and moving forward works better than starting with SI/CI and moving backward, since each new programming guide assumes some familiarity with the previous generations rather than making each subsequent doc longer and harder to read

                                Comment

                                Working...
                                X