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

Hi i did my own little test run with this shoot001 demo on my r360 9800pro with r360 bios. I can see with both demiruds and humus interaction.vfp a speed increase, but demiruds resamples the original lightning much better then humus one humus one is creating somekind of overbrightness or white pixels as many people discovered them in his previous versions allready those problems aren't existing with demiruds changes but both of them render the scene different as ID wanted it to be rendered for sure. The Speed increase with cp af8 are +5 fps and ingame af +2 fps catalyst 4.9b

My results can be downloaded here

http://cruncher.mufflastig.com/interaction-test.rar

 

Well, what I'm basically saying is that apart from things like "r3x0/R4x0 paths," it may be the engine itself with regards to its configuration settings (not just the stock config files but also the WinRar text config files open to modders) as it ships is simply "distinctively unoptimized" for R3/4x0, while otoh "distinctively optimized" for nV4x...

Carmack states that the nVidia drivers he saw for his closed tests (conducted with software unavailable for public scrutiny in regards to such things as configuration settings) were heavily optimized for the stock state of the D3 engine to such a degree that even minor changes in some of these configuration settings would knock nV4x "off the fast track" in the game (and even moreso for nV3x.) At least, that's certainly how I interpret his comments--which certainly could have been far more specific in the enumeration of examples to illustrate JC's points unambiguously. It's not really clear to me how much of the nVx optimization resides in the nVx drivers, or in the D3 engine stock config settings, or most probably both... At any rate, I think the positive effect of Humus' minor config setting changes for R3/4x0, and the negative effect on nVx performance they elicit, certainly seems to illustrate JC's point with undeniable clarity.

 

Where is the stock price increase?
Funny isnt it...Doom is released and the stocks of both nvidia and ati go down

 

I believe the driver IQ bug others are referring to is an attempt to explain why filtering isn't being applied properly on ATI cards when application-controlled AF is used, and this is what you have been responding to.

This is different to what Humus is talking about above. Humus is referring to claims that it is a driver bug for the ATI driver to apply AF to the specular lookup table when AF is forced using the control panel. This is correct -- the control panel doesn't know what the texture is being used for, and so you can hardly blame it if it plays it safe and applies AF to all textures.

But the first issue remains an open question -- why do the NVIDIA and Matrox cards apply texture filtering correctly in application-controlled mode, but the ATI cards do not?

You have suggested that there is something "wrong" with the way D3 is asking the driver to apply filtering. This is possible, but it does seem a little unlikely, given that the API for applying AF is simply to specify a number for the anisotropy to apply to that texture, and it is unlikely that D3 "forgets" to specify that number only on ATI cards. It seems more likely that the ATI cards simply ignore that specification.

You have asked why, if that were the case, this problem hasn't been seen before in other games, but were any of the other games using OpenGL? If there are other OpenGL games that don't have this problem using application-controlled AF then it would point the finger at D3, but if all of the other examples were actually using Direct3D then I would strongly suspect the ATI OpenGL driver was simply ignoring the filtering specifications from the application. There certainly isn't enough evidence to state that D3 is "garbling the instructions", especially when the instructions amount to setting a single parameter.

 

From what I've seen, the image quality is significantly improved with CP forced AF instead of App forced AF. With the tweak, you get the improved image quality of CP forced AF and the performance of App forced AF.

How this isn't win win, and why you and other nvidia "fanb*ys" been bitching up a storm for the past 40+ pages is beyond me. And those [H]OCP threads are completely absurd. Improved image quality without the performance penalty is fantastic in my opinion.

Good lord I just can't wait for HL2 to come out and all this bullcrap to start all over again. Yeesh.

 

I'll post this in here too just in case:

I've done some testing on my computer:

Athlon 64 3200+ 1MB cache, rev.CG @215FSB
MSI K8T Neo-FIS2R, BIOS v.1.70
1GB Corsair TwinX3200LLPT @2-3-2-6
Visiontek Xstasy RADEON x800 Pro @stock speed, Spirit 1.4.1 (based on the Cat 4.9b)
Win XP pro sp2

No other tweaks than Humus' latest, which I believe is the following:

Tests run in High quality, 1280x1024, 8xAF, otherwise default

CPQ = Anisotroping filtering set in control panel, Quality
CPP = Anisotroping filtering set in control panel, Performance
APP = Anisotroping filtering set from application

w/o Humus - diff CP - diff APP
CPQ 41.0
CPP 41.0
APP 50.6 23.4%

w Humus:
CPQ 54.4 - 32.7% - 7.5%
CPP 55.5 - 35.4% - 9.7%
APP 55.8 - 36.1% - 10.3%

As a side note I myself run with 4xAF as I see very little difference from 8xAF, giving me 56.1 fps. I still hit lows of 28 in demo1, and being a long since hardcore online quaker I can't tolerate much less even in single-player.

Well, I guess in Doom 3 I'm not particularly CPU-bound even with an x800 Pro, seeing I get a significant 10% performance gain even compared to the lossy IQ of application controlled AF without Humus' tweak. And the gain compared to Control panel AF is not that far from the infamous 40% claim... If there is a similar gain on the X800XT PE I'm guessing ATI is closing in on Nvidia, and I certainly think there is a real reason for comparing cards with this tweak in mind.

BTW, if I use the "timedemo demo1.demo usecache" I still get a few fps more if a do a second run :? ah, well...

 

Holy Shit! I just gained 10 fps by enabling Triple Buffering. I urge everyone to verify this setting under the OpenGL Compatibility panel... it seems to be disabled by default. Of course, you also need to have vsync enabled.

With a P4 3.3GHz, 1GB, x800xt-pe @ default speed, Cat4.9b, Triple Buffering @ 100Hz, Doom3 in High Quality mode, and the Humus tweak:

timedemo demo1:
1280x1024 16xAFQ NoAA 63.7 fps
1280x1024 16xAFQ 2xAA 58.4 fps

 

Wow, and you think 16x AF is actually going to make any kind of difference in visual quality at all? Just set it to 4x, that's the most you're going to notice.

It's funny how these people with the new and best video cards are always so stupid about how to use the video card. Usually spoiled little kids anyway who don't know shit about computers.

 

I prefer to put up with the tearing and keep both vsync and triple buffering off. That way I get better framerates at the lower end, which for me is what really counts, not the highs.

 

Crazy! I HATE tearing. CS needs vsynv and Doom3 does too, for me at least. Takes away from the game too much....

Also, I notice a diff between 4xAF and 16xAF, at least in CS and CZ.....

 

vsync is wonderfull when FPS don't go under the frequency u set (60 Hz, 85 Hz, ..) but don't forget that if you set vsync at 60 Hz and your game only do 59 fps, your fps will drop to 30 fps and sometimes to another fraction if you are lucky

unless you have a 6800 ultra, vsync will do more arm then good.

 

Anyone know how to make diagram based frame rate results on timeline from D3 demo1? I thought Fraps could be good but it measures frame rate just one time per second.

I'm interested to know how much Humus tweak will increase slowest parts. It's not big deal if you for example get 60 fps instead 50 fps but it's big deal if you get 30 fps instead 20 fps.

Although this is a free tweak so nothing to complain about it. Just want to see more detailed information how this tweak affects to frame rates in different situations.

 

Not if you have triple-buffering enabled.

 

You can use FRAPS to record the frame rate over a period of time and log the results in a text file. Stick the figures into a spreadsheet and bingo - a plot of fps against time.

 

Well, the Cpanel is programmed to do it one way--it doesn't make any decisions--it simply does what it's been programmed to do. It's there for one purpose--to force filtering treatments for games which do not support such settings internally. It's strictly a one-size-fits-all proposition.

Forget the API for a moment as I think that's where you might be confusing things a bit. I'm talking about the game engine and how it issues instructions to various IHV drivers. The fact that it does "fine" with nVx and Matrox (according to reports), but not with ATi drivers in this regard, is entirely congruent with what I've been postulating, which is that there's something in the way the D3-engine treats the ATi drivers with respect to texture treatment instruction that is "distinctively unoptimized" for the Catalysts... Seems a pretty clear concept.

The reason this seems likely to me at present is two-fold: first, because *I don't have any other games* which fail to properly instruct the Catalysts as to texture treatments when they are set within the game and the Cpanel is set to App Preference, and so whenever possible I use in-game settings (only impossible when a game lacks such internal configuration parameters--only then do I use the Cpanel to force them); second, the Catalysts have been shipping for quite sometime, and are certainly nothing if not mature, while D3 is brand new and is undoubtedly facing a series of patches in the coming months for a variety of issues.

Think about how illogical that presumption is on several fronts:

*ATi has released a 4.9 beta driver (which I'm using) specifically for D3. This particular problem still manifests, which seems ridiculous, if your speculation had merit, as this driver was released specifically for D3, and this problem is so obvious it certainly would have been addressed in the 4.9b.

*Second, your presumption is that the "Application Preference" setting in the Cats for OpenGL simply is there for cosmetic purposes and doesn't do anything. That's fairly ludicrous, since I think it would have been discovered long before now in the almost *two years* the Cats have been shipping, don't you?

*Third, although it's been awhile, I seem to recall no trouble at all with Q3 and the Cats set to App Preference while using Q3 for certain internally set Q3 settings--including some filtering settings. If anything I recall thinking how much better Q3 rendered under the Cats than I'd ever seen it on my nV25.

What I've been saying though is that there's no more reason at this time to suspect an ATi driver bug of this kind than there is to suspect a D3-engine bug. It's because I don't have this problem with any other games I have that I suspect it's got something to do with some "distinctively unoptimized" characteristic of the stock D3-engine shipping config, and am leaning in that direction.

Finally, I am worried over ID Software's complete silence on this very obvious issue. Since the problem is so obvious to all of us, I marvel at the fact that this situation seems to have escaped the attention of ID Software *completely*, as we haven't heard a single solitary peep out of them about this. If we presume that ID bothered at any time to actually test its software with shipping ATi products and drivers, then it is an absolute impossibility that this situation would have escaped their attention, and in that case *had it been a Catalyst driver bug* of the type you describe I am quite sure that Carmack would have said so publicly--without a doubt (as he hasn't been bashful about making negative comments about ATi driver characteristics that are not bugs at all...). The fact that we've heard nothing from ID over what had to have been a "sore-thumb" issue abundantly apparent to them for quite sometime prior to the game shipping is a fact which serves to strongly reinforce my "distinctively unoptimized" point of view...

 

i don't like triple buf, it adds some lag. but i don't see how we can get tearings if FPS is lower then refresh rate.

i tried the vsync+3buf, and despite having nearly the same Frame rate, it feels a lot less smoother and less responsive.
are there other option influencing this ?

 

Tearing will always be there when vsync is disabled because the video card will swap its buffers whenever it can, which will almost always be while the monitor is refreshing.

 

I tried that and benched timedemo three times. Each time there was different frame rates per second like -/+ 0-3 fps and frame rate string is hard to keep sync with earlier strings so they length varied also.

Anyway, I made some kind of diagram and it showed that Humus tweak was actually slower in some parts but where frame rate was high enough anyway like 30 fps or above, tweak boosted them even higher to compensate some lowest frame rates (below 30 fps) which got even lower and probably that's why average frame rate is higher.

Although it is just a timedemo and Fraps benchmark results varied too much each time and were out of sync. Can't say sure. Just some quick experiment which I would like others to pay attention too. Minimum frame rates are the most important to get boost, right? Can't sacrfice any minimum frame rates to get boost to highest frame rates.

 

You could check out Hanners' exellent Doom3 - X800 investigation. Has all the benches you need.

 

We don't know what went on between JC and ATi. Perhaps ATi promised to fix this in a hurried driver release? Be that as it may, ATi is another party that is conspicuously silent on this issue. This is all the more strange as the app-AF bug is the reason for people forcing AF via the control panel which in turn is the reason why Humus' tweak makes such an amazing difference in some cases.

The 40% speed increase reported by Humus consists mostly of avoiding the huge speed decrease caused by the unfortunate confluence how CP-forced AF interacts with texture lookups; the actual speed increase seems to be on the order of 5% (1-3 fps) for most users who reported their results in this thread.

Humus has correctly rejected any statements that described the CP-AF behaviour as a bug (I was guilty of that as well, although in my case it was due an oversight during snipping/rewriting a paragraph). But Humus has said nothing at all about the app-AF thingy, even though he must have been aware of the issue both from reports in this thread and since he was forcing AF via the CP himself.

Perhaps the filtering problem has something to do with the logic in the Catalyst that switches to correct filtering if it detects things like coloured mip-maps (like those used in IQ testing) and switches to a faster, less accurate, method if not? Perhaps this logic has more than two levels to choose between, and the low intensity contrast in the textures that exhibit the problem might have caused the logic to select the most aggressive optimization level. Remember, the banding reported in another thread was due to zones with an intensity difference of 1, which is something that the card can do nothing at all about (unless you expect it to dither, hehe) and which would have been completely invisible were it not for super-bright gamma.

As regards your allegations of hanky-panky on id's part in order to make ATi products look bad - if you feel it is worth discussing it then why don't you make a thread for this topic? The current topic is for Humus and his tweak.