Detonator 52.14 Test & 52.10 Re-Test

October 8, 2003 / by Leonidas / page 1 of 7

This translation has been made possible by our community who wanted all the people without German language skills to be able to read the article as well. We'd like to apologize for our English language skills ;-).

   Intro

Our article about the Detonator 52.10 is, as already mentioned, erroneous, because we didn't notice even two "optimizations" in the driver. Thus, all of our statements about the Detonator must be renounced, and we need to completely re-test this driver. Today, we will re-test the Detonator 52.10 to make up for the errors of the previous article. Likewise, we also want to look at the image quality and the performance of the newer 52.14, which is used by some web sites already for the nVidia cards in the Radeon 9800XT reviews.

Before we start, a short explanation concerning the Detonator 50 series: The Detonator 51.75, which has been leaked in the meantime, was distributed by nVidia to some hardware pages explicitly for use in Half Life 2 benchmarks. Thereafter, they had intended to make the driver public in mid-september. However, after it was found out that the filter quality was heavily compromized by "optimizations", nVidia suddenly changed their mind and declared the driver as Beta which "should not be installed on any system." The "optimizations" that had been found were declared to be simply bugs in the driver.

The new drivers 52.10 and 52.14 now also only have Beta status. Both were only distributed to beta testers and were, as mentioned afore, used by some hardware reviewers in the Radeon 9800XT reviews. So far, they did not leak yet - and we will not leak them either, so please don't ask us about them. There still is the rumor that the Detonator 52.15, which hasn't been spotted anywhere this far, and which should be fairly similar to the 52.10 and 52.14 drivers, will be officially released by nVidia at the end of this week.

The important matter is that nVidia did promise to remove the "bug" concerning the forced "optimizations" in the successor of the 51.75. In our first test of the Detonator 52.10, we erroneously stated it had next to none "optimizations". This, however, has been an error on our side (btw caused by the different color calibrations of the displays used in the test - we better should compare screenshots on the same display), which only came to our notice afterwards. For this mistake, we'd like to express our sincere apologies, and we want to rectify everything with the now following re-test.

   OpenGL Filter Quality

Ok, now that that is out of the way, let's take another, closer look at the Detonator 52.10 and its successor, the 52.14, which has an identical image quality according to our investigations. We won't look at the Detonator 51.75 anymore, because this driver or another one with the same filter technique probably won't be released.

To make a clean comparison to an unoptimized driver, we have used the programs D3D AF-Tester and (for OpenGL) Texture Filter TestApp, which are useful for comparing the filter quality, together with the Detonator 45.23. The default filter quality is without a fault, as we know (except for an application-specific "optimization" of Unreal Tournament 2003), this implicate texture stage 0 as well as all other texture stages, as you can see on the following screenshots:

45.23 Direct3D 0xAF

45.23 Direct3D 2xAF

45.23 Direct3D 4xAF

45.23 Direct3D 8xAF

45.23 OpenGL 0xAF

45.23 OpenGL 2xAF

45.23 OpenGL 4xAF

45.23 OpenGL 8xAF

On the OpenGL screenshots you can already see how the filter quality is under OpenGL and also in the drivers 52.10 and 52.14: Exactly as in 45.23 - but only under OpenGL! In this API, there are no noticeable optimizations, regardless if you set the anisotropic filter in the application or by means of the control panel. By the way, using the new version 1.3 of the Texture Filter TestApp we are for the first time able to search for hidden "optimizations" in the texture stages 1-3. As mentioned afore, we didn't find anything in all three drivers, so we don't need to pursue the topic of "optimizations" in OpenGL any longer.