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

What i want to know is where are all the sites that jumped onto ati and disabled the aniso optimizations ? Why are they now not doing articles on this ?

 

Re: Yah ....

OK, well I guess by the same token no reviewer will dare to test D3 with any 3rd-party mods of any sort, and of course no reviewer will dare make changes to any of the config files that come with with D3, because obviously ID never actually meant for anyone to *change* anything from the default settings as the game ships in the box...? So all of those very accessible, very easily changeable configuration files in D3 are just there for show--and not meant to actually be used or accessed by anybody, because that wouldn't be fair? Heh...

People somehow keep missing the point that Humus changed nothing in the D3 config files that Carmack didn't intend users to have ready access to. If he hadn't wanted to make these files accessible he'd never in a million years have set them up in such an easily accessible fashion. In reading some of these posts I get the feeling some people think WinRar is some kind of proprietary ID compression scheme that Humus "broke into" or something, and that the code in these text files was encrypted--which of course Humus also "hacked" to break the 1024-bit encryption enclosing them...

(Uh-huh--If he had attempted all of that--well, let's just say I imagine he'd still be "hacking" through proprietary schemes and encryption at this time with little time available to worry about little things like substituting power functions for lookup tables in the game...)

I think Humus' tweaks are great--certainly work splendidly for me--as I'm now getting very nice framerates at 1152x864 x2 FSAA (set in game) and 16xAF (set via the Cpanel.) I'm running with default gamma and brightness, shadows on, and r_lightscale at 5 (which reduces the pitch-black square-footage in the game to what I consider a much more manageable area), vsync ON & double-buffering (to conserve local 3d-card ram for textures) on my R9800P, AXP 3200+, 1-gig system. Oh, yea, "Ultra-Quality" mode is now my favorite tex-quality mode by far.

(About UQ and ID's "512mb 3d card" recommendation--seems to me that as I can't think of any 512mb cards available at present, that ID's recommendation as to UQ mode for the game is really just another way of saying, "We couldn't get this mode to run consistently without hitching, so we suppose you'd need a 512mb card to run it that way--if you could buy one"... Believe it or not, truthfully, such rare hitching as I encounter with UQ is no more frequent than it was in HQ compressed. I've also added r_image_preload "1" to my autoexec.config, which I suspect is the actual hitching-reducer involved here, as I noticed the command only shows up in the Doomconfig file when UQ is selected--but then seems to disappear later for some reason I'm not entirely sure of--which is why I moved it into autoexec.)

I agree with previous posters who've pointed out that something is putzed in the D3-engine instructions to the drivers for AF, because I get much better treatment using the Cpanel AF override than I do setting AF in-game--99% of the texture-aliasing I was getting using 16AF from in-game is gone using the Cpanel AF, so I'm satisfied Humus tweaks were not causing what I was seeing there for awhile before using the Cpanel override for AF. I'm also using the 4.7 CATs, as well. As the Rev reminded me, I'm relieved, but also very pleased, to be getting this kind of performance from the R9800P in this game. It's quite a bit better than initial reports led me to believe it would be, and performance is very fluid 98% of the time. This game should be a snap for x800s, without a doubt, imo.

 

You have to remember that JC's commentary is only absorbed and referenced by party-liners when it agrees with their respective creeds and dogmas... In all of the other instances, he may as well not have said anything.

 

no, he wrote the code that way because it would be THE SAME.

HOLY CRAP LIONS.

it's NV GT4-style approximation through shader replacement. congratulations, folks. I should probably dig up some old posts. they'd be funny in this context.

(note: in this case, it's not necessarily bad. if it improves your gameplay experience. WOOHOO. more pants for you. but BENCHMARKING WITH IT? congratulations, those of you who think that "Oh, this is levelling the playing field!" games aren't supposed to run at the same speeds on all cards, not because of some magical vendor support BUT BECAUSE CARDS ARE DIFFERENT AND DO NOT DO EVERYTHING EQUALLY WELL OR POORLY. the end. god, people are hypocrites. NVIDIA forces something, they're the devil. an ATI employee (no offense against Humus, I like the guy, but he is what he is) posts a replacement shader for Doom 3 that grants some performance improvement and then it's the best thing since sliced bread and everybody should use it because the scores line up better?! HELLO?! WHERE HAVE ALL THE SANE PEOPLE GONE?!

and Rev, no, I wouldn't think B3D would ever do something silly like that.)

 

Enlighten the code n00bs, please?

Performance tweaks, funny/cool graphics tweaks ? Potentially "upgrading" the engine to perform optimally on the OGL 1.5 cards instead of having reused code catered to previous generation cards.. ?

 

Baron isn't it a little different when the so called tweak actually IMPROVES visuals instead of degrading them? I'm sorry but its not fair to compare visuals + framerates improvements to the old nvidiashader replacement's which most of the time look horrible compared to the original shader and ONLY improved performance. They are just in completly different categories.

If you had actually tryed humus's newest tweak you would realize that this does not degrade visuals AT ALL his original did have some area's that weren't perfect but humus has done an awsome job fixing that will some hints from carmack.

All I have to say is THANKYOU HUMUS AF is finally useable on my 9700pro and the entire game is more enjoyable thanks to you.

 

Beautiful work.

Barton 2500+ @ 3200+
512 Dual DDR
9500np Softmod 9700 Pro

HQ 1024x768 16xAF Normal: 27.8 fps
HQ 1024x768 16xAF Humus: 34.8 fps

25% increase in performance. Basically free 16xAF. And not a single artifact of any kind.

Thanks!!

 

Right, which is why he also said...

I wonder how often I'll have to repost those comments before the meaning is absorbed... Poor JC--oft quoted but rarely understood in context...

Don't get that at all, but I do get that JC's idea, love it or leave it, was to enable the older cards to render the same as the newer cards, hence the only method possible for the older hardware was also used for the newer hardware. Which of course obviously doesn't mean the newer hardware is incapable of identical or better IQ through other methods not available for the older cards at all.

Again, the crucial points are deliberately ignored and overlooked. "Replacement shaders" that you say nVidia forced were found in the nVidia drivers and nVidia went to great lengths to ensure they would operate on a game-specific basis, no user input required or tolerated, and no amount of in-game tweaking could bring about the same result. That's light years' different from this instance, in which there is *no* replacement shader code in the ATi drivers recognizing D3 and specifically tailored to the game--nope, instead, what Humus did was to modify an *internal D3 textfile* to better address the hardware capabilities of R3x0 + under presently shipping drivers, a textfile which Carmack *intended* be accessible for user modification.

Your analogy relies totally on semantics but is wholly inapplicable from a factual standpoint. Such changes to D3 configuration text files could be made by *anybody*, not just Humus, and for a wide variety of changes completely unrelated to the targets Humus was addressing. World of difference.

 

NVIDIA didn't say, "here is this tweak to improve performance!". Instead they did things "behind the user's back", lowering image quality and overriding control-panel settings. That was deceptive. This Humus thing is nothing but positive. It's pure win. If you actually look at what JC says, he says: "there isn't any real strong argument against replacing it [the lookup table] with code". So it's fine.

 

I don't buy this. You're playing with a different rendering algorithm than the artists had in mind when they made the artwork. It will look different. It will not look like the artist intended, and since it's a global specular function, there will always be places where it will look worse.

 

Thanks Humus!
demo1 1st and 2nd results.
Org:
36.2
42.9

+ 8xAnsio(CP)
29.8
32.7

+ Memx351(Core Untouched)
31.9
34.9

+ 4.9(OGLDriver)
32
35.3

Humus
37.7
43.4

Everything was left on once set so the end result is 8xAnsio,Mem OC to 351Mhz, Cat4.9 + Humus Tweak.
AthlonXP Barton @1.8Ghz System Clock 200mhz
9800SE softmod org 378 Mem 298

Game looks a lot better and is smoother to play

 

Did you read this?

A constant lookup table,being replaced with a constant math algorithm. Seems fair to me...and Carmack doesn't have an argument against it.

 

edit: sorry, I failed to trace the evolution of this thing beyond the Humus's first changes. Anyway my current understanding is the latest hack produces perfect results.

http://www.rage3d.com/board/showpost.php?p=1333082791&postcount=210
http://www.beyond3d.com/forum/viewtopic.php?p=343322&highlight=#343322
http://www.beyond3d.com/forum/viewtopic.php?p=343724&highlight=#343724

 

Latest version on Humus' link has the following:

# perform a dependent table read for the specular falloff
# TEX R1, specular, texture[6], 2D;

#MAD_SAT R1, specular, 5.0, -4.0;
MAD_SAT R1.w, specular.w, 4.0, -3.0;
MUL R1.w, R1.w, R1.w;

 

This is an issue, since when you take John Carmacks comments about this and other things you can't really benchmark comparatively benchmark Doom3 knowing there is a level playing field. From John's comments we know NVIDIA has shader replacements going on, and this tweak is a pretty good indicator that ATI doesn't. The question is - what do the shader replacements that NVIDIA are doing by default actually doing? Do we know that they aren't making similar alterations for the boards their boards that cope with this better?

 

Test results

Default settings
UltraHigh 1024x768 2xAA/8xAF 24.5 fps
UltraHigh 1024x768 0xAA/16xAF 27.7 fps


Humus mod
UltraHigh 1024x768 0xAA/16xAF 35.5 fps

High 1024x768 0xAA/8xAF 44.2 fps
High 1024x768 0xAA/16xAF 43.8 fps


NICE increase in performance . Basically free 16xAF. And no artifacts so far.

Athlon 64 3200+
Chaintech VNF-250
2 x 512Mb GEiL Golden Dragon PC3200
3D Prophet 9800 Pro 128Mb (stock speeds)
Catalyst 4.9b


Tried same on

AthlonXP 1800+
Epox 8KHA+
768Mb PC2100
GIGACUBE R9550 ULTRA 128MB DDR 128BIT TVO DVI (stock speeds)
Catalyst 4.9b

Default settings
High 800x600 0xAA/8xAF 23.2 fps

Humus mod
High 800x600 0xAA/8xAF 27.3 fps

 

Doom 3 timedemo only gives average frame rate which is not so informative.

Anyone can say if Humus tweak can actually be slower in some cases than original texture lookups? You get increase in timedemo but that doesn't necessarily mean you get higher frame rate all the time.

 

I saw a graph eariler that showed the whole timedemo and never was the humus tweak slower than the original.

 

Gameplay is a lot smoother with the Humus tweak...that's with 8xAF. I can't think of an easier way to quantify or qualify it except to say the game looks and plays better on my system. By looks, for the ppl that are going to froth at the mouth with indignation, I mean I have been able to enable AF where before I was unable to. That's enough analysis for me.
When this get's incorporated into the next driver release - when in some form, then peeps are going to bench Doom3 out of the box with the latest whql drivers on Ati hardware and benefit. Pretty plain and simple to me. I guess some people will then scope the driver package and find something very similar to the Humus tweak. <shrugs> I don't see any image degradation nor clipping planes nor PP hints nor shenigans nor banding to warrant the call.

 

If the look up method utilized is looking up non-procedurally generated data then creating a procedure to replicate it is going to be an issue. The thing is, that I doubt that such is the case. Seeing as that is true, isn't it possible to analyse the reference data to generate a perfect procedural match, especially considering the basic form of the procedure is known?