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

Oh my, what a statement...

 

Well whatever, I dont know too much about computers, I just know that patches fix alot of stuff.

Any updates?

 

I am running a 9800XT 256MB with the beta 4.9 drivers, I applied all the tweaks that humas mentioned and am I am getting great performance. However, I seem to be getting some flickering of light for some reason, I also have 8xAF forced in the CP as recommended.

 

yeah I was seeing some light flickers on some baldheaded scientist guy.

 

Geeez…

I must be the only person here who gets about a 1fps improvement with the tweak enabled on a X800PRO......Just typical

Wish I had one of them there magic GFX cards/PC's that gain a 10fps +

 

I was thinking the same thing.

If a lower end PC has higher framerate than a higher end PC under the same game in the same situation and the game has been optimised for the higher end PC. What can be the problem?

Hardware conflicts, software conflicts(drivers, etc..), hardware/software configuration, maintenance failure. The list cna go on forever.

 

Your still getting more framerates than me, so stop complaining

 

forcing it in the "CP"?

 

There are two "static" demos with the game. Just use

Code:

playdemo shot_demo001

or

Code:

playdemo shot_demo002

from the console and take a shot. The second one shows differences too, but not as pronounced as shot_demo001.

 

Not quite correct, at least not for D3D, if I remember well. Forced via CP the Catalysts perform trilinear AF only on the first texture stage, bilinear on the rest. This is true for all ATI cards from R300 on with drivers after, I think, 3.5 or something around that. It's no hardware limitation though, as trilinear on all stages can be forced via a registry hack. "rtool" (or was it "atuner"? well, maybe both) can be used for that. The "brilinear" optimizations were introduced in R360 and did go unnoticed until R420, thus they seem to be quite good. Concerning OGL I'd have to look up some old tests.
Btw: I am quite sure that my current settings use this registry hack and my CP+tweak shot has full trilinear. Well, if this applies to OGL at all, that is.

Hmm ... a CP does not request AF in the same way as an application, it forces global behaviour via some constant, I guess. What the application can do (and D3 obviously does) is to request specific AF degrees on a per-texture basis. The problem is, that ATI drivers don't seem to honour these requests correctly. This looks incredibly broken to me. Probably it's time to get someone from ATI involved, to massively file bug reports, I don't know what

In any case: This performance boost only masks a massive problem with the Cats.

 

By who?
I had more than a decent improvement on my 9700Pro and I posted some scores a few pages back. there have been mixed results, but I'm sure I'm not alone with the improvements.

 

Just in case anyone is wondering I got the Plasma mod to work beautifully and with decent performance, however that means no shadows. Anyways check it out at this link

http://www.doom3world.org/phpbb2/viewtopic.php?t=2959&start=20

scroll down a bit. Trust me, it really makes a difference. I have a Geforce 4 Ti 4200 and it's still playable.

btw, can someone see if they can add parallax mapping to Doom 3. For the bumpmaps you can make a prog that opens each *_local.tga (they're the normal maps) analysis it to generate a hightmap, and saves that info in the alpha channel. Then in the shader add a the few lines needed for parallax mapping. I wanna see some screenies too, I would do it myself but my vid card sucks :'(

 

Don't get too excited, it's just a video card. You're going to have to buy a new one in a month, if you're one of those spoiled people who always needs to have the best there is.

 

Did humus give any advice on config file tweaks? Or did he mention any specifically that I may of missed. This thread has gone on for pages and filtering through would be a real drag.

 

Yeah, does it matter if you extracted all of your files out of the 4 pak files? Im not getting any preformance increase with humus's tweak, and im getting white artifacts even with AF turned on with it.

 

To prevent this thread from utterly killing the server, off-topic posts (plus other irrelevent material) will be deleted. Please submit posts that are only directly concerned with Humus' work - thanks.

 

Wrong! R3XX gets the same benefits. The point is, that you get the increase only for AF forced via the CP.

As I see it now, application controlled AF at least in Doom3 is badly broken across the board. D3 requests AF only for certain textures and they are filtered badly. As there are much less textures to be filtered, this is quite fast, probably also because of the bad quality.

CP controlled AF filters all textures with good result, but as there is a much bigger workload the overall impact is severe. Application controlled is, dependent on hardware, memory, clocks, etc, faster by anything between 15% and maybe even Humus' 40%.

What the tweak does, is to replace texture lookups in a shader that gets used everywhere in every frame with math operations. Thus the overall number of textures to be filtered is reduced again. By chance this happens to bring a performance boost that happens to even out the loss that occurs with CP controlled filtering.

When AF is controlled by the application, the total number of filtered textures is so much smaller, that the tweak does not change too much. This make me wonder if we see a hysteresis kind of behaviour here. Reducing the number of filtered textures below a certain threshold may allow ATI chips to perform at full speed, crossing the threshold may cause some overflow or cause cache anomalies.

In general the benefit for R420 seems to be bigger, but I guess that's only due to the fact that the are faster at math.

 

On the topic of getting good performance with AF

Some of the info discussed seems unclear.

• Concerning control panel and in game AF for ATI cards:
  
  Does Performance AF in the control panel really look better than in game AF, in terms of artifacts/aliasing? If so, for which in game LOD settings is this the case? And what control panel setting for LOD (mip map detail level)?
  
  It sounds to me like game controlled AI could possibly be offering an additive LOD bias to control panel settings, while control panel forced AF effectively applies only the control panel LOD. This makes sense given the relative performance (equivalent or better) and image quality (better when even bilinear is specified in the control panel).
  Does this fit OpenGL's possible handling of LOD bias and AF?
  
  One way to evaluate would be to set the config file LOD bias to 0 and compare in game 8x AF image quality to the default LOD assigned for High and Ultra quality, and then compare it to 8xAF control panel AF modes.
  
• Concerning performance loss in 6800 cards for some changes:
  
  What is the status of trilinear optimizations and control panel/forced AF setting for performance loss when the MAD_SAT changes lose performance? It appears there is no case with performance improvement, but information on what results in the least performance loss among these possibilities would be useful for isolating where the bandwidth net gain manifests, or whether it can manifest at all.
  Given the 6800 strength in math ops, and similar limited bandwidth to the X800 series, the lack of benefit is surprising, though perhaps things are as simple as having application detection turn off AF for the affected textures for control panel forced AF. Another possibility would be 2x AF for other than stage 0 textures as a general policy, but I thought that behavior did not currently occur in OpenGL.
  A note to IHV-centric conversation: neither of these (hypothetical) optimizations are bad in this case (this is exactly the case where I think they belong, actually) except as far as they lead to misinformation...stated another way, these optimizations would seem purely beneficial to people playing the game but adverse for comparing performance when their existence is undisclosed.
  
  The normalization behavior (if I understood observations of a lack of benefit correctly?) seems odd as well. Perhaps the "on the path" optimization Carmack speaks of is taking these legitimate opportunities for performance improvement and doing a shader replacement to use them? This would make sense with the results (if I understand what has been stated correctly), but would then seem to indicate it was an immediate and universal mistake to not include a path in the game itself that recognized cards able to use math ops to better effect, especially if they benefit more with higher quality image settings?
  Such a (hypothetical) optimization would seem certainly valid in nature, but it belongs in the developer shader code, not in IHV drivers while absent in the developer shader code, where they can punish an IHV for leaving the developer shader code alone in the driver because the developer shader code simply picked one optimization principle to the exclusion of another.
  Since the principle is simply one of "faster at doing math than texture look up", such a path wouldn't be an IHV path, and it could even be controlled by an option labelled "use shader processing instead of bandwidth". Though there is still the question of being sure of why the powerful shader/restricted relative bandwidth 6800 isn't operating accordingly in this case, unless you assume Carmack's comments on nVidia driver treatment (if applicable to the 6800 and not just NV3x) is a conclusive answer.

Perhaps some of this is answered in Carmack's responses, providing some insight into what is going on with the "monolithic" path decisions in the final release, and/or perhaps what is planned for updates? I'm looking forward to further info on what his responses explain.

 

Re: On the topic of getting good performance with AF

And I'm looking forward to the day, when you decide to post more, like you used to do Demalion.

 

Neeyik .. maybe just mention for all the new comers where they can d/l humus' patch or the fact that it's on page 15.

BTW.. sorry about what I posted before.

BTW .. Well done again guys