ATI's Gallium3D Driver Is Still Playing Catch-Up

[airlied]

The main r300g->r300c gap closer was reworking the vertex/index buffer submission to be a lot more efficent like the r300c code. I think there
is probably a still bit more upside here, but I haven't had a chance to find it yet

I think the final speeds up in order of when they'll get done look like won't be driver code optimisations as much as gpu feature usage:

1. Color tiling - need to enable by default and fix regressions
2. Z clears
3. Color buffer fastfill clears
4. Proper HIZ support.
5. Better GLSL compiler. Intel are working on a new GLSL compiler front end, that + r300g GSOC project should produce something a fair bit nicer.

Dave.

[dstaubsauger]

wow thanks! is that lonely mesa package in that repo the only thing needed to install the driver?

[bridgman]

Here you go :

xorg-edgers to the rescue

http://launchpad.net/~xorg-edgers/archive/radeon

Currently, these mesa packages install on plain lucid (and not on top of the main xorg-edgers PPA), but since this might change later, please check the PPA page description before upgrading from it or asking questions.

...

(great, 1 minute edit window and brain-dead mobile browser)
Correct URL: https://launchpad.net/~xorg-edgers/+archive/radeon

[bridgman]

I think Tormod just posted a link to a packaged build on another thread. I have to run right now but will look for it later if you don't find it.

[dstaubsauger]

this is great news! thanks to everyone involved in making those ati chips work again with an open driver!

are there any tutorials on how to install this awesome thing on ubuntu without breaking the package management/etc? i'm aware of the fact that this is still considered unstable software.

[MostAwesomeDude]

By and large, the performance improvements have been to core parts of the Gallium interface. I am planning to have a GSoC student to work on GL 2.x features to flesh that out, but as far as performance goes, it's largely hit-and-miss. I can think of only a couple spots that can really get sped up, and those will come relatively soon.

[L33F3R]

lol a little offtopic but i just noticed Bridgman, that your location is toronto-ish. Markham boy are we ? Fuck i would do anything to stay home in the dot right now, Montreal is a fucking dump .

Good to see G3D isnt a total flop. If what you say about the bottleneck is valid and the performance can be jumped then by all means you have made a customer out of good ole L33F3R.

[bridgman]

I was referring to the parts which are different between 300c and 300g, ie mostly the mesa-core-to-gallium3d interface and the 300g driver itself (since that's the part which affects classic vs gallium3d performance) but I don't think any parts of the stack have really been optimized much yet. The focus has been primarily on getting functionality in place on the new architecture so that there's something worth optimizing

[V!NCENT]

I expect OpenCL performance is going to be driven by two things - shader compiler efficiency packing multiple instructions into a VLIW, and memory manager maturity. Both are hard but not impossible, and I *think* the OpenCL use cases should be less varied than OpenGL and easier to deal with. Other than that, raw power of the GPU should drive things.

That was what I was hoping for

Remember that there hasn't been a lot of optimization on the Gallium3D code base yet, just a push to get to classic Mesa levels so that 300g can replace 300.

What do you mean by 'the' Gallium3D code base? KMS+Mesa? KMS+rxxxg+Mese? Or everything related to a r300GPU to make 3D work?

[bridgman]

BTW the shape of the resolution vs performance curves (generally flat) indicates that performance is basically CPU limited right now, so a round of profiling and optimizing should make a hefty difference. The question is whether the bulk of the CPU time is being used in the HW driver stack or in the upper level Mesa code.

I'm not sure which of those to hope for