ATI Radeon 9000pro linux driver comparison Page 3

3D Games Performance

Unreal Tournament

This is quite an old (but still popular) game. It is known not to scale very well with faster graphic cards, so it should run at almost the same speed in all resolutions. 3dcenters utbench demo was used, as well as the intro-flyby (which should be a bit less cpu limited). Almost all graphic details options of course set to the highest setting possible. UseS3TC was set to 0.

(Windows results for lower resolutions were not recorded)

The dri driver is the only one which shows a strong dependency at resolution. Interestingly, when watching the flyby, the framerate didn't change much with increasing resolution, except almost at the end of the flyby when it was really slow - with the higher resolutions it dropped easily to below 10fps. This is strange as the other drivers had no slowdown at all at that place - could be some software fallback which, considering the age of this game, would be disappointing. ATI's driver is just very slightly faster in all resolutions than XiG Summit.

This time the scores are closer together, though the DRI driver again seems to drop more when the resolution is increased than the other drivers. ATI and XiG are again almost dead-even.

Quake III Arena

The built-in "demo four" was used for benchmarking. All graphic detail options were set to the highest possible quality, r_ext_compressed_textures was set to 0.

The ATI linux driver seems to be almost as fast as in the Windows driver, it actually beats it in the lower resolutions. The XiG Summit driver doesn't look very well here, but it is still significantly faster than the dri driver.

Return to Castle Wolfenstein

3dcenters checkpoint demo was used for benchmarking. Just as with Quake III, r_ext_compressed_textures was set to 0 to not penalize the dri driver. Almost all graphic detail options were set to their highest setting, though the texture detail was varied from normal to high.

The driver from ATI had some trouble with this game. In the 800x600 and 1024x768 resolutions it almost locked up always at the exact same point (picture was completely frozen, sound was looping). However, after 11 seconds it just continued to play back the demo like nothing happened. The scores in the chart therefore were corrected by those 11 seconds - they represent the performance you'd get if ATI eleminates this bug. Interestingly, this did not happen at 1280x1024. To fix this bug you can also disable all OpenGL extensions in RTCW, this will cause a performance hit however (the performance with the high texture detail setting was roughly 13% lower for all resolutions with the extensions disabled). The workaround suggested in forums of setting only r_ext_compiled_vertex_array to 0 unfortunately resulted in a (real) lockup. ATI had another problem with this benchmark, if the demo was run multiple times it was always faster the first time after a vid_restart, especially in the higher resolutions and when the high detail texture setting was used (up to 20% faster the first time!). In the chart above the higher scores were used.
The dri driver suffered a lot by using the high detail texture setting, what can't be seen in the graph is that it was unplayable in all resolutions, as at some places it had not enough local memory for all textures and thus the performance dropped to about 5 fps for some seconds. This is due to the static buffer allocation of the driver, so there is exactly the same amount of memory available for textures if you run it at 800x600 or at 1280x1024 (in case you're wondering, only 34MB memory is available for textures for this 64MB card when running the X server at 1280x1024x24). It is of course possible to start the X server in a lower resolution, but this is beyond the scope of this article. No other driver had problems with texture thrashing in any resolution. Interestingly, the ATI driver showed almost no difference between high and normal detail texture setting (keep the strange behaviour in mind though), it might be possible however it converts all textures to 16bit.

Unreal Tournament 2003

All graphic quality options were set to their highest setting, with the exception of texture detail which was only set to the second-highest setting. It doesn't seem possible to disable texture compression for this game, so all drivers except the dri driver probably used compressed textures.

ATI's driver is definitely comparable to the windows driver here, the XiG Summit driver does also quite well. The same can't be said for the dri driver which takes the last place by a large margin. Even worse, there were quite a few rendering errors with the dri driver. The first anomaly already happens in the options menu, the mouse pointer has some weird shadow. More serious however are that it fails to render the damage amplifier correctly (it is almost fully transparent, making it hard to spot), the elevator platform misses the texture (it's completely white), the water in the pond looks like fog instead. Furthermore, character shadows did not work correctly (there were just dark squares around the characters) and the dynamic lighting wasn't correct neither (this bug could be related to the lighting problems in NWN). The last issue is sometimes the textures seem to flicker, i.e. they change the color completely (this issue seems to have the same cause as the errors in 3dsmax02 and the colorful flashes in NWN). Setting the environment var R200_NO_TCL=1 does help only with some of the issues (the colorful flashes, dynamic lighting, elevator texture), but of course causes the framerate to drop even more and does not correct the other issues (the damage amplifier is now blue instead of transparent, the supposed-to-be-water fog is now bright orange instead of dark green).
ATI's linux and windows driver also didn't render the water in the pond correctly, it looked just like the water was missing completely.

(the botmatch played back in windows was very different though)

The botmatch demos are much more cpu limited than the flyby demos, so the performance differences are smaller here, and at least with ATI's linux and windows drivers the performance in all resolutions was more or less identical. (It should be noted that some people report lockups with the dri driver in this game, though I was unable to reproduce this.)

Neverwinter Nights

No nice performance graph, sorry. First, I don't even know how to record a framerate (trace fps is nice but doesn't cut it), and the issues the drivers had with this title would make a comparison invalid anyway. All graphic detail options were set to their highest setting, except AA and texture quality. The game will always use the lowest (compatility) texture setting if the driver does not support s3tc (you can still set it to different values, but they will be ignored). If you're interested what the difference between the different texture settings is you can read about it (modem users beware! Large PNGs).
ATI's driver didn't do a very good here, it simply locked up (either already in the options menu or right when the loading of a game was finished). So this gives a 0 for playability, even though the loading menu was rendered quite fast. Next driver please...
The XiG Summit driver ran the game, though had some issues. "Environment Mapping on Creatures" had to be switched off because the texture would flicker heavily when enabled. Creature Shadows didn't work at all (regardless the detail setting). For some odd reason, only the compatiblity texture setting worked, setting it to any higher setting would instantly crash the game (segfault) - if a higher setting was already in the nwn.ini file the game would segfault at startup. And last (this seems to be a game limitation, not a driver issue) the game will always use the resolution of the X server, even in windowed mode, it was not possible to set it to anything lower than 1280x1024. Apart from these issues, the game seemed to run quite fast, however keep in mind that creature shadows were not working (they have a very significant cost in terms of rendering time).
The dri driver also has some issues with this game. There were some severe lighting bugs in some areas (especially at night). But what made it hardly bearable was that some textures flickered in all colors. And of course only the lowest quality texture setting could be used. It was possible to get rid of the lighting bugs and flickering by setting R200_NO_TCL=1, however this approximately halved the framerate. It was also possible to get rid of the flickering / wrong colors (but not the lighting errors) by using a very simple patch (which also corrected the same problem for 3dsmax02 and UT2k3), though nobody knows why this patch even works (it does certainly not correct the root cause of the problem, it also comes with a performance hit and it is not guaranteed to help on all systems - the patch just decreases R200_CMD_BUF_SZ in r200_context.h from 8*1024 to 1024).
Some screenshots to illustrate both the lighting issues and the colorful flashes problem (standard first, with patch second then lastly the correct image by just using R200_NO_TCL=1 - this is a rather drastic example, usually the lighting isn't THAT wrong):
nwn with lighting and flickering bugs

Performance (when not using R200_NO_TCL) was not great, but seemed playable up to 1024x768. Definitely slower than the XiG Summit driver, but that's an invalid comparison since the shadows worked with the dri driver.

Conclusion

And the winner is...
Well this is no shoot-out, so there is no winner. However, it seems clear that the XiG Summit driver is the most mature one - while it didn't render everything correctly, it was the only one which never caused a GPU / X lockup (though I could never run it for more than 25 minutes...). It also had strong 2d performance and solid 3d performance, but lacks some "standard" XFree86 extensions, didn't do very well in the xawtv department and last but not least, costs more than the 0$ pricetag the other drivers have. ATI offered the highest game performance, but had slow 2d performance, didn't do very well with xawtv either, always caused 100% cpu load when a 3d application was running and wasn't too stable. The dri driver has the best system / XFree86 integration (shouldn't come as a surprise), but took the rear in 3d performance and had the most rendering errors. So draw your own conclusion...

Feedback

You can email the author, flames should be directly sent to /dev/null instead.

previous page