The R300 GLSL Compiler Improvements Are Coming

[oibaf]

Little update: Hardware Loops Take 2

Some code was also committed to mesa on 2010-07-03:

Commit message / Author / Files / Lines
r300g: fix warnings Marek Ol??k 1 -2/+5
r300/compiler: Fix loop unrolling Tom Stellard 1 -1/+15
r300/compiler: Use hardware flow control instructions for loops on r500. Tom Stellard 8 -44/+154
r300g: Fix typo in r300_reg.h Tom Stellard 1 -2/+2
r300/compiler: Don't continue copy propagation inside loops. Tom Stellard 1 -0/+5
r300/compiler: Print debug info for flow control instructions. Tom Stellard 1 -5/+73
r300/compiler: Enable hardware IF statements for r500 cards. Tom Stellard 2 -5/+6
r300/compiler: In the peephole optimizer, ELSE should mark the end of a Tom Stellard 1 -2/+13
r300/compiler: Correctly calculate the max number of iterations for loops. Tom Stellard 1 -17/+8
r300/compiler: Handle loops in deadcode analysis. Tom Stellard 5 -77/+112

[xiando]

I think it would be better to focus on the newer parts... how many people still actually have those parts and are worried about getting peak performance out of them?

I used my athlon2k boxen with the AGP slot and PCI slots until smoke started eminating from the motherboard one spring morning. It served me well until that point in time and I would not have replaced it if I was not forced to do so. Support for old parts/systems is important. I'd also like to point out that the AMD drones are more likely to care about support for their fancy new parts, which makes it even more important that free-to-do-as-they-please developers improve support for the older parts.

[marek]

Gallium is inexplicably slow with AGP

Are you 100% sure AGP is the culprit or are you just guessing?

[chrisr]

How could I ever be 100% sure?

Are you 100% sure AGP is the culprit or are you just guessing?

I am simply quoting the opinion of one the AMD people who has stated that AGP "seems to be the common factor" in all cases where Gallium has been reported as slow.

If you have a different theory then please be my guest. I have one of these slow machines in my possession... ;-).

[chrisr]

Aha! I have found the reference...

Are you 100% sure AGP is the culprit or are you just guessing?

I hope this link works:

http://www.phoronix.com/forums/showpost.php?p=124740&postcount=30

Failing that, it was Bridgman who said:

There may be an AGP vs PCIE difference here as well. That seems to be the other common factor to people seeing lower performance with the new stack. Make sure you're running the latest -ati (X driver) as well.

[bridgman]

If you're referring to my comment, I was definitely guessing. There were a few users reporting slower-then-expected performance with the 300g driver, but not much info was provided other than verifying that they were actually running 300g and not the software rasterizer. AGP seemed to be a common factor across all (three ?), but there's no reason to treat AGP's contribution as anything more than a hypothesis.

[chrisr]

Alternative hypotheses are welcome...

If you're referring to my comment, I was definitely guessing.

My basic test-case is: start celestia, and try to rotate the Earth by right-dragging it. This is very responsive with Mesa classic, but drags horribly with Gallium. The hardware in RV350 AGP.

[bridgman]

So I guess one good question for the forum is whether anyone else is running Celestia on 300g, what their experience is, and what hardware and other driver bits they are running.

On the other hand, Celestia may not be a great test case here -- it seems to have different rendering paths for GL2 and for lower levels, so there would probably be different application code running on 300g than on the classic Mesa driver (since 300g exposes GL 2.1 while classic only exposes ~GL 1.5 IIRC).

[bridgman]

Did a bit more reading on Celestia implementation... seems like the GL2 (GLSL) code paths may do substantially more processing than the <GL2 (ARB) paths.

I don't know if there is a Celestia option to force the ARB code paths or whether the driver would have to be hacked to expose a lower level of GL support, but one of those would at least allow an apples-to-apples comparison where the same application code is used with both 300g and classic driver implementations.

[chrisr]

I'm talking about the &quot;OpenGL Vertex Program&quot; rendering path in both cases

On the other hand, Celestia may not be a great test case here -- it seems to have different rendering paths for GL2 and for lower levels

You can choose which rendering path to use by pressing Ctrl-V. I am aware that r300g defaults to "OpenGL 2.0" whereas r300c can do no better than "OpenGL Vertex Program", but I am remembering to set r300g to "OpenGL Vertex Program" before making my comparison... ;-).