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.
Technically, the dri drivers
can't be called "OpenGL driver", as they do not pass the OpenGL
conformance tests (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 driver passes the tests as well). According to XiG, ATI's
drivers do not pass the conformance tests neither (since this is a
minor point for home users, I didn't bother to ask SGI).
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).
- Compared to the last comparison, not much has changed in terms of
OpenGL extensions supported. DRI dropped GLX_MESA_agp_offset and
GLX_NV_vertex_array_range in favor of GLX_MESA_allocate_memory. XiG
removed support for the obsolete GL_EXT_vertex_weighting extension. ATI
has replaced GL_SGI_texture_edge_clamp with GL_SGIS_texture_edge_clamp,
and, much more importantly, now supports GL_ARB_vertex_buffer_object.
- 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
these 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 allowed disabling HyperZ but it didn't make
any
difference at all - apparently the driver no longer allows to switch
this off. ATI's driver for linux should support HyperZ, and the XiG
summit driver doesn't. Both ATI and XiG offer stereo support.
With neither driver it's possible to force AF. 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 (of course, with all these older Radeons, you can't use
trilinear filtering together with anisotropic filtering). FSAA can be
forced (2x, 4x, 6x or even 8x) with the XiG summit
driver, though not in all resolutions (depending on how much memory
your graphic card has, for my 64MB card the limit is 1024x768, if you
use a desktop resolution higher than that you can still force FSAA but
the driver reverts to a software fallback which is probably not what
you want). Some quick testing with games shows it works quite well,
however only if the application uses less than the theoretically
possible 1024x768 - if 1024x768 is used, the screen is completely
garbled. A similar thing happens when you use the forced FSAA with a
glxgears window slightly smaller than that limit and move it beyond the
borders of the screen. 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. Neither ATI nor DRI support FSAA for the
R200/RV250 based cards.
3D Performance - SpecViewperf 7.1
The XiG Summit driver easily wins all of the benchmarks this time. You
can look at all results
yourself.
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 almost 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).
The wrong colors can also be easily
seen on other subtests, and sometimes a lot of polygons simply disappeared.
Compared to the last comparison, the dri driver lost ~15%, the
performance of all other drivers remains the same.
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 not even half as fast as the
other two linux drivers here.
The ATI driver loses ~20% performance compared to the older driver, the
DRI driver loses ~30%.
dx-08: the XiG Summit driver easily beats the others on this one. The
dri driver manages to keep 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.
The new ATI driver is again almost 20% slower than the old one.
light-06: another easy victory for the XiG driver, the windows and ATI
driver are close and DRI takes the rear.
The new ATI driver lost some performance, XiG and the windows driver
gained some. However, DRI is ~30% slower than last time -
interestingly, by looking at the subtests, you can see that it is not
even half as fast in the wireframe tests (subtests 1 and 3), but
actually slightly faster in the solid tests (subtests 2 and 4).
proe-02: In contrast to the last comparison, XiG is fastest again. The
rendering errors this driver had in subtests 3 and 7 have been fixed,
and as a result the performance has improved quite a bit (as the driver
no longer renders things it doesn't need to). This is now the only
specviewperf test the windows Catalyst driver is slower than the ATI
Linux driver - and the windows driver even fails to render 2 subtests
of it correctly: First image shows correct rendering (in this case from
DRI), second one Catalyst 3.8.
ugs-03: another easy win for XiG. 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...). The excessive
memory usage is likely caused by the inefficent handling
of display lists, and should get fixed when Mesa 5.1 (6.0) will be
merged with DRI (not before XFree86 4.4 though afaik).
What can't be seen in the benchmarks is that the setup time for some of
the subtests was over 3 minutes under windows, all linux drivers (even
the DRI driver which caused a lot of swapping) had much lower setup
times, never exceeding 20-30 seconds.
Here are some screenshots (first ATI, then summit, then dri) of the 4th
subtest:
Compared to the last article, the dri driver again loses 20% (given how
it looks, probably not really relevant). However, the ATI driver loses
55%, it's less than half as fast as the old version of the driver! Both
the windows score and the XiG score remain unchanged.
