Announcement

Collapse
No announcement yet.

RadeonSI Gallium3D Gets UBO/TBO Support, OpenGL 3.3

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

  • #11
    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. Don't get your hopes up yet.
    RadeonSI performance is pretty widely spread across the board. With Color Tiling enabled it can get up to 80% catalyst speeds with certain applications, though it averages more around 50-60%. Still not bad, all things considered.

    Comment


    • #12
      Originally posted by dffx View Post
      RadeonSI performance is pretty widely spread across the board. With Color Tiling enabled it can get up to 80% catalyst speeds with certain applications, though it averages more around 50-60%. Still not bad, all things considered.
      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.

      Comment


      • #13
        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.
        That's not true at all.

        If you are running a game at 50fps instead of 100fps, it just shows that your driver has an extra 10ms of overhead per frame. Could that be because it's missing some hardware feature? Sure. It could also be because the driver is mistakenly pushing out an extra memory flush each frame. It could also be because of a bunch of cpu usage each frame. It could be because of a bunch of different issues.

        The main hardware features that are currently missing are: HyperZ, proper-clocking (new kernel will enable it for some, but not all SI cards), and geometry shaders + GL4 features.

        Could there be others? Sure - but one other thing you can be sure of is that the performance isn't simply due to AMD using firmware blobs. That's idiotic.

        Comment


        • #14
          For whatever reason, the APUs perform amazing on r600g. it's starting to look like Radeon SI will be in shape for the Kaveri launch, which will get one more sale from me if the same thing applies.

          Comment


          • #15
            Originally posted by zanny View Post
            if AMD would stop crippling their gpus with firmware blobs some of the Red Hat or Novell guys would help
            Novell's already been down that road with the radeonhd driver (and in case you don't remember, it didn't end well)...

            Comment


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

                      Working...
                      X