A Big Comparison Of The AMD Catalyst, Mesa & Gallium3D Drive

[xeros]

The benchmark really miss the test of low end cards and the test of last forking fglrx for r300-r500 (even that it would need to run on old Ubuntu 8.10).

Edit:
And the one-core cpu, 32bit arch, too.

[xeros]

Edit:
s/forking/working/

Btw. the test should include the lowest and highest FPS, too and if it could be or where it could be possible to check - what FPS was in the most of the time (median) instead of arithmic average counted. I don't know if any game measures that but it would be useful to have such information, too.

[damg]

The main reason why I *cannot* use Fedora/OpenSUSE is that their font rendering sucks. Ubuntu's font rendering is way better.

Now that the TrueType bytecode patent has expired, future versions shouldn't have this issue.

Also, for people living where software patents don't apply (like in Europe), you can just install the freetype-freeworld package which gives you exactly the same font rendering as Debian/Ubuntu.

[Danny]

I think it would be helpful to include a comparison of somewhat basic feature sets of the drivers being used for the benchmarks. So for example:

Catalyst:
Has Page Flipping
Has <insert feature here>

r300g:
Does not have Page Flipping (not enabled or whatever)
Does not have OpenGL 3 support
Does not have <insert feature here>

Just increases awareness and puts the OSS drivers in a better position in one way as they might be performing decently without the respective features.

Also, what would one have to go through to become a developer from scratch? As in if one does not know programming in the respective language and no knowledge of graphics programming, is not a university student but can spend some time as a part-time dev? I'm just thinking in terms of solving man power issues and spreading the development more into the community.

[bridgman]

Hi Danny;

A good first step towards being a developer would be to learn some basic OpenGL programming. You can use OpenGL from a number of different programming languages but it's probably worth picking up C at the same time. You're going to start by copying sample code snippets anyways, so in a sense the programming language doesn't matter as long as you have a working compiler.

Alternatively, learning to build and install the drivers from source would be a good place to start.

[chrisr]

Page Flipping is apparently &quot;DONE&quot;, as of Linux 2.6.38

r300g:
Does not have Page Flipping (not enabled or whatever)

That's for r300g and r600g, apparently.

http://www.x.org/wiki/RadeonFeature

[jakubo]

catalyst uses multithreading, right?
what would be the results of the benchmarks without it? (assuming these have been made with multiple cores enabled)
could it be the oss drivers would be satisfactory if multithreaded?

[spirit]

That's for r300g and r600g, apparently.

http://www.x.org/wiki/RadeonFeature

I confirm, on my RV620 chipset:

cat /var/log/Xorg.0.log|grep Pageflipping
7.614] (II) RADEON(0): KMS Pageflipping: enabled

[bridgman]

catalyst uses multithreading, right?
what would be the results of the benchmarks without it? (assuming these have been made with multiple cores enabled)
could it be the oss drivers would be satisfactory if multithreaded?

Yes, the Catalyst driver hands off most of the rendering work to a separate thread, allowing it to return more quickly to the calling application.

The open source devs have done some preliminary testing with fglrx on a single core system -- right now the open driver with rendering stubbed out is still slower than fglrx running on a single core. The initial conclusion from that testing is that while multithreading will probably be part of the eventual solution there are other, bigger bottlenecks that need to be looked at first.

If multithreading were easy to implement in the open source drivers it would probably still be worth doing early because it would help to hide some of the other bottlenecks, but as I understand it the implementation is not considered to be easy at this point.

As time permits we are trying to dig into how the Catalyst driver state change logic is coded and see if there are ideas which can be applied to the open drivers. The open source driver code seems pretty efficient though, which is why there is some head-scratching going on.

There are other areas such as the shader compiler where everyone understands that the code could be made more efficient (with a lot of work), but we should be able to get higher performance than we are seeing today even with the current shader compiler.

I haven't gone through the current code in detail, but AFAIK there is still some gains to be had from work that is already underway. Things like tiling, page flipping and HyperZ are being worked on as time permits and I don't think they were all reflected in the current benchmark numbers. As an example, I think the open drivers currently use tiling for the colour buffers (ie the render target) but not for textures.

The unhappy thing about performance improvement is that you don't get big performance gains from one place -- you get gains in the 1-5% range from each of a number of areas, and each of those gains requires a lot of work and makes the code more complex to maintain and troubleshoot in the future.

[Drago]

Bridgman, I am sure if you do not know where the bottlenecks are, you(and other developers) have suspects. Is it in kernelmode or usermode part of the stack?