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
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).
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):
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:
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.)
