Announcement

Collapse
No announcement yet.

ATI R500 Gallium3D Performance In June 2010

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

  • #31
    Originally posted by crumja View Post
    Marek, any idea of the time frame it will take to use all of the hardware? It's somewhat distressing now that it seems you're the only dev working on r300g. Corbin's disappeared and I don't see commits from AMD's employees on mesa.
    Concerning performance, I have 3 goals:
    - implement Hierarchical Zbuffering along with fast Z clear (HiZ)
    - reduce the CPU overhead
    - figure out why the *F* Tremulous is so slow

    There's going to be a Mesa 7.9 release soon. By then, I'd like all bugs to be fixed or worked around. HiZ might make its way to Mesa 7.9.1, but it will probably need a new kernel too.

    There's also one very interesting feature being worked on by Corbin so stay tuned. Another developer Tom Stellard is currently working on the r300 compiler to implement missing GLSL features as part of his GSoC project.

    Comment


    • #32
      Originally posted by bridgman View Post
      r3xx/4xx - launched 2002-2003, support in 2006 maybe ? (3-4 yrs)
      r5xx - launched 2005-2006, support in 2008 (2-3 yrs)
      r6xx - launched 2007, support in 2009 (~2 yrs)
      r7xx - launched 2008, support in 2009 (~1.5 yrs)
      Evergreen - launched 2009, support in 2010 (should be <1 yr)
      To be fair, that's the time to initial support with basic 2D, 3D, modesetting, and Xvideo. It doesn't include the time for 3D to be within 70% of fglrx. Granted, that's an immense task and will never fully be completed.

      Marek, is hierarchical Z-buffering the same thing as the marketing feature HyperZ? Also, how much sharing can there be among the various GLSL compilers for different hardware (r300g, r600g, i965g, vmwgfx, etc)?

      Comment


      • #33
        Originally posted by crumja View Post
        To be fair, that's the time to initial support with basic 2D, 3D, modesetting, and Xvideo. It doesn't include the time for 3D to be within 70% of fglrx.
        Agreed. I was measuring from launch to the time when support for the new chip was at approximately the same level as support for the previous generation, not improvements to common code across the entire driver stack.

        Comment


        • #34
          Originally posted by bridgman View Post
          r3xx/4xx - launched 2002-2003, support in 2006 maybe ? (3-4 yrs)
          r5xx - launched 2005-2006, support in 2008 (2-3 yrs)
          r6xx - launched 2007, support in 2009 (~2 yrs)
          r7xx - launched 2008, support in 2009 (~1.5 yrs)
          Evergreen - launched 2009, support in 2010 (should be <1 yr)

          etc...
          so should keep going... ?
          Evergreen+1 - 0.5 year
          Evergreen+2 - supported before hardware released

          Comment


          • #35
            - we decided to have Richard push the 6xx/7xx 3D driver to support GL2 and GLSL so we could see how many new applications would start to work
            I wonder, how was one dev able to get OpenGL 2.0 on r600 in a couple of months, when r500 still doesn't have it (in classic, after X years)?

            If you cite the decision that "it wasn't worth it", seeing it was that easy, it would have been worthy, no?

            Comment


            • #36
              The shaders are much more advanced on r6xx+ (and they are unified) so it's much easier to write basic GL 2.0 support. The older hardware requires complex emulation of things like flow control and loops so it's much harder to write, plus you have to do it for both vertex and fragment shaders since they aren't unified.

              Comment


              • #37
                Originally posted by crumja View Post
                Marek, is hierarchical Z-buffering the same thing as the marketing feature HyperZ? Also, how much sharing can there be among the various GLSL compilers for different hardware (r300g, r600g, i965g, vmwgfx, etc)?
                HiZ is the subset of HyperZ that has the biggest impact on performance compared to other HyperZ features.

                Originally posted by curaga View Post
                I wonder, how was one dev able to get OpenGL 2.0 on r600 in a couple of months, when r500 still doesn't have it (in classic, after X years)?
                Maybe because every developer that cares about this hardware prefers Gallium?

                Comment


                • #38
                  Originally posted by curaga View Post
                  I wonder, how was one dev able to get OpenGL 2.0 on r600 in a couple of months, when r500 still doesn't have it (in classic, after X years)?

                  If you cite the decision that "it wasn't worth it", seeing it was that easy, it would have been worthy, no?
                  The key reasons were :

                  1. Richard was very familiar with the r6xx/7xx code (since he had just finished writing it) but not at all familiar with the r3xx-5xx code, so adding GLSL to r6xx/7xx was arguably "low-hanging fruit" while r3xx-5xx was not

                  2. r6xx/7xx hardware has a full set of flow control instructions which are embedded in the shader code stream, while the flow control implementation on earlier GPU generations had a completely different programming model *and* considerably more limited

                  Comment


                  • #39
                    Thanks everyone. This is why I come here @ Phoronix

                    Comment


                    • #40
                      It looks like World of Padman, Urban Terror and Smoking Guns are FPS locked? I don't believe it is a hz refresh problem though but maybe it is a cpu fallback problem. Ie code that is still not tested properly and thus not optimised either.

                      Originally posted by bridgman View Post
                      The key reasons were :

                      1. Richard was very familiar with the r6xx/7xx code (since he had just finished writing it) but not at all familiar with the r3xx-5xx code, so adding GLSL to r6xx/7xx was arguably "low-hanging fruit" while r3xx-5xx was not

                      2. r6xx/7xx hardware has a full set of flow control instructions which are embedded in the shader code stream, while the flow control implementation on earlier GPU generations had a completely different programming model *and* considerably more limited
                      <suckup mode on>I'm very impressed that linux drivers on AMD are getting better, much sooner than once was when ATi was it's own company. I might have to go get myself a x5870 to go with my AMD 955 cpu. I'm still using my nvidia 9800 GTX+ which is quite happy at the moment. I'm not happy with nvidias win7 drivers which I can say is a first for nvidia. Usually they are the ones that set the standard but times are changing. Keep up the good work! </suckup mode off>

                      Comment


                      • #41
                        Apart from the quite good performance of the r300g driver, I'm quite disappointed as for now with the unstability of the driver, it causes quite a lot of crashes with my Mobility x700. Another shortcoming is that I can't get Compiz to work when XRandR enables a second screen, and can even cause absolute freezes with an artefacts-fill screen. This is a bit annoying knowing that my Compiz settings won't always come back identical, which means I must every now and then check everything back yet again. When falling back on the classic mesa stack, I don't have any of those issues

                        I guess it is due to the experimental state of the r300g, but still, before improving the features, it could be useful to work on stability.

                        Comment


                        • #42
                          Today I was able to make Enemy Territory: Quake Wars work seemlessly with graphics details set on "Normal" and this is a 2008 game with a very advanced rendering engine so I wouldn't say it's worse than other radeon drivers.

                          I think the stability of Compiz is more influenced by the DRI state tracker than anything else, but I might be wrong. If you can somehow get a backtrace, please create a bug in the FDO bugzilla with the backtrace attached.

                          We know about the hardlocks on RV410 but it looks like no developer has a clue about what goes wrong there (and I don't think any r300g developer uses this chipset).

                          Comment


                          • #43
                            The main problem I have is terrible lag with gallium. Apart from that it runs significantly faster than plain old mesa.
                            But that doesnt help much if it trails an estimated 300ms behind my input.

                            Comment


                            • #44
                              Mez', when you "fall back to the classic mesa stack" does that also involve going back to UMS/DRI1 or are you still running KMS/DRI2, just with the classic mesa driver ?

                              Comment


                              • #45
                                For compiz or any other GL compositor, they need to check the max texture size supported by the hardware before starting; unfortunately, they usually don't. The max texture size on r3xx/r4xx is 2048 pixels so if you desktop is larger than that, you will have display issues regardless of what driver you use.

                                Comment

                                Working...
                                X