ATI R500 Gallium3D Performance In June 2010

[marek]

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.

[crumja]

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)?

[bridgman]

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.

[krazy]

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

[curaga]

- 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?

[agd5f]

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.

[marek]

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.

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?

[bridgman]

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

[curaga]

Thanks everyone. This is why I come here @ Phoronix

[b15hop]

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.

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>