3d features


The drivers all support OpenGL 1.3, however the supported extensions differ quite a lot. You can view the full glxinfo output for ATI's driver, for the DRI driver and for the XiG Summit driver if you want. Update: Technically, the dri drivers can't be called "OpenGL driver", as they do not pass the OpenGL conformance tests. These tests are only available to SGI licensees, there was some fuss about the possibility of having open-source OpenGL drivers some time ago but I don't know what the current status of this is (note that software-mesa which these drivers are based on does indeed pass the conformance tests, this of course does not mean that the dri drivers will pass the tests as well). According to XiG, ATI's driver do not pass the conformance tests neither.
Some of the major differences:
- The dri driver does not support GL_EXT_texture_compression_s3tc (and the older GL_S3_s3tc, though this one is not supported by the XiG Summit driver neither), only GL_ARB_texture_compression which isn't too useful alone (as it doesn't specify a texture compression format - it reports a nice 0 supported formats via GL_NUM_COMPRESSED_TEXTURE_FORMATS_ARB). This is because s3tc was patented by S3 (the patent now belongs to VIA) and implementing it without a license might be of questionable legality (at least in countries where software patents are allowed). Microsoft bought a license so everybody can implement it freely in a Direct3d driver (as DXTC), but unfortunately the OpenGL ARB couldn't do the same easily (they are not a legal entity if I'm not mistaken).
- The ATI driver is the only one which supports GL_ARB_vertex_program and GL_ATI_fragment_shader. The other drivers therefore have no support for vertex and fragment shaders (GL_ARB_fragment_program isn't supported with ATI's driver neither as it is not suited for this generation of graphic card).
- The dri driver can only do 2 textures per pass (reported by GL_MAX_TEXTURE_UNITS_ARB), the xig summit driver 4 and ATI's driver 6 (which is the maximum the hardware can do). Older games (such as Quake III) will not use more than 2, however newer games (such as UT2k3) definitely can use more than 2, which will likely cause some performance hit with the dri driver (since the game needs to switch to multi-pass rendering).
- What can't be seen from the glxinfo output is that the dri driver does not support any HyperZ features, since ATI doesn't want to have them exposed in an open source driver. The 9000pro does not have a hierarchical Z buffer, but still has Fast Z Clear and Z Buffer compression. Not supporting HyperZ will cause some performance loss, in theory the loss will be higher for cards which have not so much memory bandwidth (so a 9000 should suffer more than a 9000pro, as it has only ~10% lower GPU clock but ~30% lower memory clock - the cards limited to a 64bit memory bus should suffer even more). Unfortunately it was impossible to measure the impact of HyperZ, since the tweakers available for windows will allow disabling HyperZ but there wasn't any difference at all. ATI's driver for linux should support HyperZ, but I've no idea if the XiG Summit driver does. Update: XiG confirmed that they do not support the HyperZ features. They do support some features the other drivers don't support, namely stereo and multisampling (implemented with supersampling) visuals.

With neither driver it's possible to force AF or AA. However, games which support AF themselves should be able to use it through the GL_EXT_texture_filter_anisotropic extension which all of these drivers support. Update: Apparently, it is possible to force 2x, 4x, 6x or even 8x FSAA with the XiG summit driver, though not in all resolutions (depending on how much memory your graphic card has). Some quick testing with games shows it works with QuakeIII and RTCW, but not with NWN. And, of course, as expected from supersampling, the framerate in games will really suffer - basically you can expect 1/2 the performance with 2xFSAA and 1/4 the performance with 4xFSAA (I won't even mention the other modes) as a best-case scenario - if you're not hitting a performance bottleneck because you're running out of texture space.

3D Performance - SpecViewperf 7.1

SpecViewperf 7.1 performance
This benchmark definitely provides some interesting numbers. Interestingly, ATI's linux driver is faster than the windows driver in 4 of the 6 tests and only slower in the remaining two. Though overall the XiG Summit driver is the fastest here in 4 of the 6 tests. You can look at all results yourself. Update: new ugs-03 numbers for XiG Summit (for more information see below). The XiG driver is now the fastest in 5 of the 6 tests (not reflected in the graph, but in the results table).

However, some more thorough analysis is needed:

3dsmax-02: ATI's driver does not show a strong performance here, it's easily beaten even by the dri driver which finished last in all other SpecViewperf tests. However, the dri driver failed to render some of the 14 subtests correctly, in most of the subtests sometimes some colors appear completely wrong, and in some subtests there were severe errors which look like z-buffer issues.
First correct picture, then the picture rendered by the dri drivers (note that all screenshots taken with the DRI drivers are without the EnablePageFlip option, but the performance figures are with PageFlip enabled - for some reason the screenshots taken by SpecViewperf turned out completely black except for the frame counter when PageFlip was enabled, though the rendering as seen on screen didn't change).
correct ArchSmooth06 picture wrongly rendered ArchSmooth06 picture
The wrong colors can also be easily seen on other subtests, and sometimes a lot of polygons simply disappeared.

drv-09: Can't comment much on rendering errors. This test looks just too wrong to spot rendering errors. There always seem to be z-fighting issues and it just looks weird regardless what driver is used, even with software rendering. The dri driver is only half as fast as the other two linux drivers here.

dx-08: the XiG Summit driver easily beats the others on this one. The dri driver manages to keep almost up with ATI's linux driver, though looking at the individual scores it is lucky that the first two subtests have 60% of the overall weight - it is 2-3 times slower than the other drivers in subtests 3,5,8 and 10.

light-06: another easy victory for the XiG driver, the other ones (including the windows driver) are all relatively close.

proe-02: this time ATI is fastest. The reason XiG is not fastest is because of subtest 3 and 7 where the XiG driver is only half as fast as the ATI driver and gets beaten even by the dri driver - probably because it renders a lot more than all other drivers, all others only render the polygons which are in the foreground but XiG renders even those which should not be visible...
It's easy to see on the screenshots (first ATI, then XiG):
correct proe07 picture wrongly rendered proe07 picture

ugs-03: another win for ATI, this time the XiG drivers get beaten is because of subtests 3 & 4 which use a lot of transparency - ATI is 5 to 10 times slower on these two tests. There were some slight visual differences in tests 1-4 when comparing the ATI driver to the XiG driver, and judging by the images on the spec website the ATI driver seems to do the more correct rendering. However, ugs-03 is a complete disaster for the dri driver. Not only because of the performance (subtests 5-8 which are wireframe are ~10 times slower than either the XiG or ATI driver), but it couldn't render the first 4 tests correctly. Tests 1-4 were rendered black and white, additionally tests 3 and 4 also lacked transparency. Furthermore, the memory footprint was really large when using the dri driver, about 1.2GB which caused some swapping. Both the ATI and XiG driver used only around 300MB of memory! For the record, I've also tried software rendering (LIBGL_ALWAYS_INDIRECT set), but this apparently didn't fit into memory and swap space (1GB ram, 1GB swap) and just hang when all memory was exhausted (where's the OOM killer when you need it...).
Here are some screenshots (first ATI, then summit, then dri) of the 4th subtest:
ATI rendering ugs04 xig summit rendering ugs04 dri rendering ugs04 really incorrect
Update: the reason the XiG driver was so much slower on tests 3 and 4 was because a too small agpsize was used and thus some data obviously didn't fit into some buffers and it had nothing to do with the transparency effects. The results when the agpsize was adjusted to 56MB instead of the (default) 16MB were much better (on ONLY these two tests, all other SpecViewperf benchmarks remained the same). (For the record, I also increased the agpsize with the dri driver which had absolutely no effect. I couldn't figure out how to change this setting with ATI's driver but it's likely using already a larger value.)

previous page next page