ATI R500 Gallium3D Performance In June 2010

[Mez']

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.

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

[curaga]

Thanks everyone. This is why I come here @ Phoronix

[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

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

[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.

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

[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

[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.

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