How to boost your Doom3 performance by 40% on ATI hardware

Ok cool. Good job either way. So how many bugs do you find that you don't publicly announce?

 

Is the Steam problem being worked on?

 

What you're saying applies to D3D only AFAIK.

-FUDie

 

First off, I've been TRYING to keep up with this thread, but I apologize in advance if this has been covered already...

The version of interaction.vfp in the RAR file you linked to still seems to have the same code as before, that is:

MUL R1.w, R1.w, R1.w;

rather than what I quoted above. I know essentially nothing about about 3D programming (although I at least know what AA and AF mean ), so I have no idea what removing the ".w" changes. In layman's terms, does it improve performance, quality, both, or one at the expense of the other? A technical explanation would be nice but it's a crapshoot as to whether I'll understand it. :?

 

Except it's very clear that this is what occuring from the screenshots. Close enough, and the screens are identical (whether CP or app AF). Far enough away and they're also identical. Between there's massive aliasing with application anisotropic filtering. That's a clear signature that this is going on. All that would remain to prove it beyond a shadow of a doubt would be to use colored MIP levels to show that the first colored MIP map is at the point where the two ways of selecting anisotropic become identical again.

I find it most likely that the current OpenGL drivers assume that when anisotropic is selected by the application, that anisotropic filtering should only be selected for the minifcation filter. That would be just fine if the definitions of magnification and minification were independent of the filters chosen.

 

I've entered level 5 in the game, here they use a different kind of floor than previous. This floor messes up even with the Cp AF.

 

None of this has anything to do with what I quoted you as saying above! This is not a problem with bilinear/trilinear. This is a problem with the mag filter being set incorrectly.

Except this is wrong too, as Humus noted earlier. Change the filter mode in the game to GL_LINEAR then GL_LINEAR_MIPMAP_LINEAR and everything is fine. Probably a state bug in the driver someplace.

-FUDie

 

And I didn't say anything about bilinear/trilinear.

If you're not going to read what I post, why reply?

 

Benchmark Results

I would like to share some results with some of the discussed tweaks. All tests include cache usage activated in the Doom3config and ATI's 2x Temporal AA. I used TimeDemo Demo1.demo on the following hardware:

Intel P4 3.0GHz
1 gig Corsair XMS PC3200 RAM
Western Digital 32gig Raptor HD
ATI Radeon 9800pro (128MB).

And here are my results:

Demo1.demo benchmark, NO-TWEAK, 16x Application AF=============Avg. (2 runs) : 33.25FPS
Demo1.demo benchmark, NO-TWEAK, 16x Control Panel AF===========Avg. (2 runs) : 27.55FPS
Demo1.demo benchmark, Demirug, 16x Application AF==============Avg. (2 runs) : 35.55FPS
Demo1.demo benchmark, Demirug, 16x Control Panel AF============Avg. (2 runs) : 35.10FPS
Demo1.demo benchmark, Humus, 16x Application AF================Avg. (2 runs) : 36.75FPS
Demo1.demo benchmark, Humus, 16x Control Panel AF==============Avg. (2 runs) : 36.00FPS

 

Benchmark Results

Bleh. I left out that I'm using "High-mode" @1024x768 Quality textures.

 

This particular issue was bugging me so I created a little toggle and put it in my autoexec so as soon as you load a new level you just hit c twice and you're definitely trilinear:

seta filter "image_filter gl_linear; set filter_toggle vstr image"
seta image "image_filter gl_linear_mipmap_linear; set filter_toggle vstr filter"
seta filter_toggle "vstr filter"
bind c "vstr filter_toggle"

 

Re: Benchmark Results

Don't use the average of the first two runs. The first run caches some stuff, and is always slower.

 

As been said before... To avoid the first run caching problem, just start the timedemo with

timedemo demo1 usecache (edited spelling)

 

Absolutely the best answer yet...