John Carmack Post Doom3 Release Technology Interview

[Dave Baumann]

http://www.beyond3d.com/siteimages/b3dsmall.gif (http://www.beyond3d.com/interviews/carmack04/)Following the release of Doom3 it’s seen many a discussions such as gameplay, graphics, benchmarking and tweaking. In this short interview we talk to id’s John Carmack about various elements of the title that are pertinent to benchmarking, as well as some of the queries that have arisen following some of the choices made within the games shader code.<blockquote>"[/i]What's the situation with regards to depth bounds test implementation in the game? Doesn't appear to have any effect on a NV35 or NV40 using the cvar.
Nvidia claims some improvement, but it might require unreleased drivers. It's not a big deal one way or another.[/i]"</blockquote>Read the full interview here (http://www.beyond3d.com/interviews/carmack04/).

[jvd]

very interesting dave. It explains a little bit better what humus actually changed

[Anonymous]

What I would find interesting, would be a benchmark like:

normal path vs humus optimization vs specular disabled.

[Solr_Flare]

Very interesting read, and it pretty much confirms what most of us figured, it was simply a design choice based on the hardware when the engine was designed and to give the best "overall" effeciency to the widest range of cards.

As the humus code showed, changing from a lookup does benefit later generation ATI hardware since it can handle the math more effeciently, thus giving it a bit more headroom. Which, either nets you a few extra frames and/or lets you use the ATI AF implementation that will net you slightly better overall image quality but without any significant cost.

In the case of Nvidia's latest hardware, however, where it seems to be more effecient at handling table lookups, switching to the humus code seems to have a reverse effect on performance.

If I were to make a guess, I'd say specular disabled would should the best performance, with humus and the original code flip flopping based on the hardware design and generation.

A bigger question I would ask then is, based on this response, is it reasonable to assume that with the proper work, the table lookup could be replaced in a way that would net significant gains to all current generation video hardware, or are table lookups going to remain the defacto best choice for all Nvidia and some older generation ati cards simply based on design, leaving math alternatives really only benefiting R3x0 ATI cards and higher?

In other words, how much further can we go without breaking image quality to the point where it isn't worth or finding the gains not significant enough to warant a change.

[Anonymous]

Could this become a problem in future that games will favour the texture access over the straight math in shaders.

The way its meant to be programmed :D

[Anonymous]

Could this become a problem in future that games will favour the texture access over the straight math in shaders.

My understanding (and it is extraordinarily limited) is that shader computation/math power is increasing at a much faster rate than available bandwidth, so wherever possible, future engines and games will favour mathematical shader operations over texture lookups where possible.

Obviously, if it's a choice between a 4,000 step multipassed shader or a texture lookup, I'd guess that engine designers would take the texture lookup option, at least for the reasonably forseeable future ;)

[DarN]

He actually has a cvar to help calculate driver overhead. That's pretty cool. :) Has anyone tried this yet?

[Gubbi]

Could this become a problem in future that games will favour the texture access over the straight math in shaders.

My understanding (and it is extraordinarily limited) is that shader computation/math power is increasing at a much faster rate than available bandwidth, so wherever possible, future engines and games will favour mathematical shader operations over texture lookups where possible.

Obviously, if it's a choice between a 4,000 step multipassed shader or a texture lookup, I'd guess that engine designers would take the texture lookup option, at least for the reasonably forseeable future ;)

I think It'll take some time before that's the case.

The reason why ATI's GPUs sees a big speed up is because they do maximum anisotropic filtering on the texture lookup, ie. instead of taking 1 (bilinear) sample it takes 8 for every tex lookup, hence a big drop in performance when 8xAF is applied.

The patched shader remedies this by not doing a tex lookup at all.

AF on tex lookups is of course a good thing when your actually using a real graphical texture. However in this case texture lookup is used as a discrete function ( f[x]=>y ), and one can argue that AF on 1D textures makes no sense at all (at least when doing magnification). If you'd want interpolated values, bilinear would do just as well as anisotropic filtering (again only in the case of 1D textures).

I don't know if the application of AF in ATI hardware is a consequence of their texture cache design, or if it is simply a driver "bug". Considering they use an adaptive AF approach, I would think that they could indicate the degree of anisotropicity (is that a real word?) and just set it to 1. In that case the next set of Catalyst drivers is going to give a big boosts to performance, especially in high quality.

Cheers
Gubbi

[BetrayerX]

I know this might be controversial, but I believe he should have been asked if he recognizes the shader replacement as a legit one....

He indirectly acknowledges it but anyway, a straight answer, specially since many believe that the fix is actually better than the original line of code in the case of the ARB2 path, would silence some voices out there (I know it smells like flame fuel, but that's not the intended purpose).

I'll put it another way, will Beyond3D use the "Humus Hack" ;) when they benchmark Doom3?

[Tokelil]

The reason why ATI's GPUs sees a big speed up is because they do maximum anisotropic filtering on the texture lookup, ie. instead of taking 1 (bilinear) sample it takes 8 for every tex lookup, hence a big drop in performance when 8xAF is applied.My knowledge is very limitted where to 3d programming, so sorry if this a stupid question.

When AF is forced through the CP does the driver know that some of the textures shouldn't have AF applied?
If not shouldn't the performance on Nvidias hardware when AF is forced descrease just like Ati's? (Dont know whether it do or doesn't)

[Rolphus]

Could this become a problem in future that games will favour the texture access over the straight math in shaders.

My understanding (and it is extraordinarily limited) is that shader computation/math power is increasing at a much faster rate than available bandwidth, so wherever possible, future engines and games will favour mathematical shader operations over texture lookups where possible.

Obviously, if it's a choice between a 4,000 step multipassed shader or a texture lookup, I'd guess that engine designers would take the texture lookup option, at least for the reasonably forseeable future ;)

I think It'll take some time before that's the case.

The reason why ATI's GPUs sees a big speed up is because they do maximum anisotropic filtering on the texture lookup, ie. instead of taking 1 (bilinear) sample it takes 8 for every tex lookup, hence a big drop in performance when 8xAF is applied.

The patched shader remedies this by not doing a tex lookup at all.

AF on tex lookups is of course a good thing when your actually using a real graphical texture. However in this case texture lookup is used as a discrete function ( f[x]=>y ), and one can argue that AF on 1D textures makes no sense at all (at least when doing magnification). If you'd want interpolated values, bilinear would do just as well as anisotropic filtering (again only in the case of 1D textures).

I don't know if the application of AF in ATI hardware is a consequence of their texture cache design, or if it is simply a driver "bug". Considering they use an adaptive AF approach, I would think that they could indicate the degree of anisotropicity (is that a real word?) and just set it to 1. In that case the next set of Catalyst drivers is going to give a big boosts to performance, especially in high quality.

Cheers
Gubbi

You're probably right - after all, all I know about this stuff is what I've picked up from various websites.

My point about shader power increasing a lot faster than bandwidth is a fairly direct quote from one or other developer interview - I think Tim Sweeney, but I couldn't swear to it. I know that things are pretty much in the balance at the moment, and complex math operations are still a lot slower than texture access (as far as instruction cost goes), but something that was raised in the Humus' tweak thread might be relevant here: fetching textures has a large latency compared to math ops, and can cause pipeline stalls.

You're absolutely right about the anisotropic filtering point though, I can see why that would cause a lot of problems, especially if you have to fetch 8 samples into the texture cache. Obviously, the higher the degree of anisotropy (I think that's the right word) applied, the more this will cause problems. I'm guessing that using app-controlled AF avoids this situation to an extent, which is why the performance boost isn't that big when using app AF. It's still tangible though on an R420 from what I've seen on my X800 Pro. That leads me to believe that the MAD_SAT and POW operations are less "expensive" overall than the texture lookup. This, as you've pointed out, only gets worse when AF is forced in the driver.

Of course, I could be entirely wrong, as I'm a graphics technology newb :)

[nggalai]

1) When AF is forced through the CP does the driver know that some of the textures shouldn't have AF applied?

2) If not shouldn't the performance on Nvidias hardware when AF is forced descrease just like Ati's? (Dont know whether it do or doesn't)
1) That's for later drivers. Right now, forcing AF in the control panel equals to AF on ALL texture data. At least for DooM3. ;)

2) Performance does decrease quite considerably on NV if you force AF through the control panel (10-30% for GFFX). Humus' / Demirug's tweaks are mostly counter-productive for NV as the driver's shader replacement gets negated.

93,
-Sascha.rb

[WaltC]

I know this might be controversial, but I believe he should have been asked if he recognizes the shader replacement as a legit one....

He indirectly acknowledges it but anyway, a straight answer, specially since many believe that the fix is actually better than the original line of code in the case of the ARB2 path, would silence some voices out there (I know it smells like flame fuel, but that's not the intended purpose).

I'll put it another way, will Beyond3D use the "Humus Hack" ;) when they benchmark Doom3?

I see nothing unclear, vague, or equivocal about his statement:

The lookup table is constant in Doom, so there isn't any real strong argument against replacing it with code. The lookup table was faster than doing the exact sequence of math ops that the table encodes, but I can certainly believe that a single power function is faster than the table lookup.

Indeed, he also says that had he known in advance the abundance of time he'd have prior to shipping D3, he might well have done things differently than he did:

The specular function in Doom isn't a power function, it is a series of clamped biases and squares that looks something like a power function, which is all that could be done on earlier hardware without fragment programs. Because all the artwork and levels had been done with that particular function, we thought it best to mimic it exactly when we got fragment program capable hardware. If I had known how much longer Doom was going to take to ship from that time, I might have considered differently.

I think JC's as clear as he can be as to there being no doubt about as to both the efficacy and the desirability of the power function approach as applied to newer hardware, and in providing his reasons as to why he didn't take that route. In short, I think this is as close to him saying "Yea, I should have done that," as you are ever likely to see...;)

Edit: Hard to say for sure, of course, but this sentence, "Because all the artwork and levels had been done with that particular function, we thought it best to mimic it exactly when we got fragment program capable hardware," sounds very much as if he's saying that the artwork and levels for D3 were all finished prior to them laying hands on an R300--which is a long time ago, but certainly fits perfectly with his next sentence, as it was nearly two years after R300 shipped to D3. Anyone else with a different take on that?

[Anonymous]

AAAAAAAAAAAAAAh why didn't you asked about the 3Dc and which rendering path apply to ATi cards and get better performance? =[

[Sxotty]

Humus eh adubo LOOOO¬ CASCA DE LARANJA AZEDA.

And Carmack is a cheater =(

It ressembles me of Gabe Newell :lol:

Is all I can say to that

I do not think walt they had the artwork done, I think his point was to make it look the same on all cards. No he may be saying if I realized how long it would take to do the artwork and levels I might have tried a different strategy on newer cards.

[Anonymous]

I think all this sounds strange i mean by choosing the option Carmack did he knew it would lower ATI's performance and then not to say anything about it.... talk about cheating for Nvidias favor or whatever you would like to call it.

Many of us took for granted that the latest ID Software engine would come optimized for all cards. But i guess that is not the case.
Also claiming time limits as the reason to not fix this for ATI cards is just BS.

Doom 3 must be the most overrated game by long time.
Gamespot has a decent review but still 8.5 is to much more like 7.5
Most Doom 3 review websites are just a good laugh.

Comparing Doom 3 to Far Cry is like comparing Skoda to BMW.
(The Hell lvl was nice but thats it.)

ID havent been honest with us and this makes me wonder what more is to come. Talk about hyping up Nvidia cards and then the hard truth comes straight back in your face.

I hope game developers choose other engines for their games since this engine is obviously not optimized for 50 % of the computer gaming market.

[BetrayerX]

I see nothing unclear, vague, or equivocal about his statement:

Oh, wait until Ruined give his interpretation of Carmack's comments and come back to tell me the same again. :wink: :lol:

[Fox5]

I think all this sounds strange i mean by choosing the option Carmack did he knew it would lower ATI's performance and then not to say anything about it.... talk about cheating for Nvidias favor or whatever you would like to call it.

Many of us took for granted that the latest ID Software engine would come optimized for all cards. But i guess that is not the case.
Also claiming time limits as the reason to not fix this for ATI cards is just BS.

Doom 3 must be the most overrated game by long time.
Gamespot has a decent review but still 8.5 is to much more like 7.5
Most Doom 3 review websites are just a good laugh.

Comparing Doom 3 to Far Cry is like comparing Skoda to BMW.
(The Hell lvl was nice but thats it.)

ID havent been honest with us and this makes me wonder what more is to come. Talk about hyping up Nvidia cards and then the hard truth comes straight back in your face.

I hope game developers choose other engines for their games since this engine is obviously not optimized for 50 % of the computer gaming market.

I far prefer doom 3 to farcry. Farcry may be better in many different aspects, but I feel doom 3 is more fun. It's more fun to shoot and run around in it than it was in farcry. Farcry is more ambitious, doom 3 is more polished.

[Anonymous]

lol who had to recall a 1.2 patch (with ATI optimizations) five months after the game wasd released ??? it's not id software .

it has been shown that the humus trick brings around 1 fps .. oh dear big deal .


I think all this sounds strange i mean by choosing the option Carmack did he knew it would lower ATI's performance and then not to say anything about it.... talk about cheating for Nvidias favor or whatever you would like to call it.

Many of us took for granted that the latest ID Software engine would come optimized for all cards. But i guess that is not the case.
Also claiming time limits as the reason to not fix this for ATI cards is just BS.

Doom 3 must be the most overrated game by long time.
Gamespot has a decent review but still 8.5 is to much more like 7.5
Most Doom 3 review websites are just a good laugh.

Comparing Doom 3 to Far Cry is like comparing Skoda to BMW.
(The Hell lvl was nice but thats it.)

ID havent been honest with us and this makes me wonder what more is to come. Talk about hyping up Nvidia cards and then the hard truth comes straight back in your face.

I hope game developers choose other engines for their games since this engine is obviously not optimized for 50 % of the computer gaming market.

[Anonymous]

Im not defending Crytek for releasing the non working 1.2 patch regarding ATI hardware. They mezzed up but set the record straight by recalling the patch.

Regarding the FPS gain on Humus trick, depending on what card you use and your other spec you can gain alot more than 1 fps. It seems to work best for the X800 series.

[karlotta]

I far prefer doom 3 to farcry. Farcry may be better in many different aspects, but I feel doom 3 is more fun. It's more fun to shoot and run around in it than it was in farcry. Farcry is more ambitious, doom 3 is more polished.

[Anonymous]

I would not compare Far Cry with Doom 3, because those are two different games. If I have to, I would say that shaders looks much better in Far Cry. Shadows, lighting, special effects Doom 3 owns it.

Overall, those are two great games. I think HL2 is going to blow both games. HL2 is a pure DX9.0 game with intensive use of shaders, we haven't seen so far.

[Reverend]

I was looking for sites that plugged this interview and came across a comment in the Voodooextreme forums (horrors!) that had the following :

Skinning on the CPU is done so that shadow volumes can be calculated on the CPU. Early in development of Doom3, Carmack stated that all shadow volume calculations were to be done on the CPU. The reason for this was to be fair to the people who didn't have vertex shader support on their systems (his code for shadow volumes on the CPU was faster than vertex shaders running on the CPU). Also, he didn't want to support both options. Had he realized how late Doom 3 was going to be, he may have standardized on the vertex shader model - in which case skinning could be done on the GPU as well (assuming he could fix up the tangent vectors for the normal maps on the GPU, too).

Perhaps the full vertex shader model will be available for engine licensees.

It's been 4 years since Carmack mentioned they decided to make Doom3 and while I have been following his .plan updates like a religion, I must've missed the above part (or, well... 4 years... I forget!). Is the above true, and can anyone point me to a link (or his specific .plan file, if he did disclse the above in a .plan file)?

Don't wanna bother John about this, so help by you guys is appreciated.

[Saem]

Holding the ultra high poly models and the low poly models and other associated process data would likely be TOO much of a burden on the on board RAM of vid cards.

[Anonymous]

Reverend,

Even though I am an anonymous poster, I have been following these threads for a long time now and have been following the technical aspects of Doom III since their release to the public. I do remember a time when he did say that all the shadow volumes would be done on the CPU. It was a long while ago, and I don't remember exactly where I saw it (I want to say VE actually), but I do remember discussing this on some forums. There was a slight controversy over this because a lot of people were saying that doing shadows on the CPU would add too much overhead and hurt performance on higher-end cards that would be able to handle the full vertex model.

As for another anonymous poster (I am not the same person) who is calling John Carmack fool - you sir, need to get some facts straight before you go calling people favoring one hardware over another. Firstly, this is john carmack, he doesn't care which hardware runs faster he just codes things as best he can. He has more integrity and dignity than that. Secondly, he even said that it uses the ARB2 path, which he has been saying for a while, that he liked best because it made all cards render everything the same - john carmack has stated time and time again that he does not like specialized rendering paths. The ARB2 path is an industry standard for OpenGL - it favors no hardware but the best hardware, simple as that. Please educate yourself before passing off your assumption as fact.

[Tokelil]

The ARB2 path is an industry standard for OpenGL - it favors no hardware but the best hardware, simple as that.The way the shaders are written can favor different hardware though. (Which is quite apparent from the tweak Humus did a few days ago)

[NeARAZ]

Holding the ultra high poly models and the low poly models and other associated process data would likely be TOO much of a burden on the on board RAM of vid cards.
This isn't needed for GPU skinning/shadows. All that's needed for "correct" shadows is inserting degenerate quads at the edges. Certainly, this produces much more unique vertices, but then, DoomIII models aren't very high poly...

[Anonymous]

I'm not well versed in graphics API's and the development of either OpenGL or DirectX, but it seems like all of these optimization issues are only going to get worse as every video card will probably have a different number of pipelines/texture units/math units. Is there any facility on modern graphics cards or through the programming API to monitor utilization of the different 'units' on the graphics cards? i.e. if Card X can do 3 texture lookups and a math op per cycle, can you tell on average how many its doing in a realtime fashion? It seems to me like Carmack knew that he was using memory bandwidth in place of more math capabilities. It seems like as shader compilers get more advanced, it would be possible to annotate segments of code as equivalent (or even automatically convert math ops to precomputer texture lookups for older cards) and then choose between them based on pipeline utilization on the graphics card.

[Anonymous]

I think all this sounds strange i mean by choosing the option Carmack did he knew it would lower ATI's performance and then not to say anything about it.... talk about cheating for Nvidias favor or whatever you would like to call it.


In the interview Carmack clearly stated that performing the same calculations that the lookup table encodes would be slower. Humus' patch substitutes a very similar but much simpler calculation and gives faster results.

Note that even on the ATI cards the patch only has significant effects when anisotropic filtering is forced on for all textures (which therefore includes the lookup table, where it's not wanted). If filtering is left up to the application to control it's easy to see ID concluding that there isn't enough of a performance difference to justify two different code paths. It's also worth noting that the only reason for using the control panel to override the filter settings in the first place (and thereby incurring the performance penalty in the unpatched code) is because the ATI driver appears to be ignoring the application's requests regarding filtering, which is where the real fix lies.

[Saem]

This isn't needed for GPU skinning/shadows. All that's needed for "correct" shadows is inserting degenerate quads at the edges. Certainly, this produces much more unique vertices, but then, DoomIII models aren't very high poly...

So basically one could use the 3-5k poly models that Doom3 uses, modify them and then you're set?

AFAIK, you need higher poly models from which you generated the shadows than the models you applied them too, otherwise it'd look poor.

[SteveHill]

Don't wanna bother John about this, so help by you guys is appreciated.
Extrusion is performed on the GPU (shadow.vp) for vertex-shader-capable hardware, if r_useShadowVertexProgram is enabled (default for nv20/r200/arb2 I imagine). Unless I'm very much mistaken, [potential] silhouette edge loops are determined on the CPU, so this isn't brute-force GPU extrusion.

[Anonymous]

AFAIK, you need higher poly models from which you generated the shadows than the models you applied them too, otherwise it'd look poor.

No, one of the nasty problems of stencil shadows is that you need EXACTLY the model for casting the shadow volume that you're actually drawing, otherwise the self shadowing would be royally screwed up.

Of course low-polygon stencil shadows don't look too good, but that's perfectly compensated by Doom3's dark, high-contrast level design which simply keeps the eye away from the hard borders ;)

[Anonymous]

plz someone ask him why id engines wont use 3dnow :evil:

[AlStrong]

Would that really give a significant boost in performance :?:

[Anonymous]

Q3 dlls prove it. D3 would be better, if sse is working (but how about early k7 then?). I think Id with their "influence on industry" should use the best.

[Anonymous]

Q3 dlls got the AMD people a nice ~15% boost, the nice thing is: it was the same as the P4 people got by default, but Intel could scream out : LOOK there's a game that runs faster on our CPU !

today we know Intel has just a not-so-good game performer and they had luck Carmack wrote an engine which sorted the data well.. something the intel arch likes a lot, but many engine devs don't waste time on doing..

very OT, sorry..

[Anonymous]

I think all this sounds strange i mean by choosing the option Carmack did he knew it would lower ATI's performance and then not to say anything about it.... talk about cheating for Nvidias favor or whatever you would like to call it.

Many of us took for granted that the latest ID Software engine would come optimized for all cards. But i guess that is not the case.
Also claiming time limits as the reason to not fix this for ATI cards is just BS.

Doom 3 must be the most overrated game by long time.
Gamespot has a decent review but still 8.5 is to much more like 7.5
Most Doom 3 review websites are just a good laugh.

Comparing Doom 3 to Far Cry is like comparing Skoda to BMW.
(The Hell lvl was nice but thats it.)

ID havent been honest with us and this makes me wonder what more is to come. Talk about hyping up Nvidia cards and then the hard truth comes straight back in your face.

I hope game developers choose other engines for their games since this engine is obviously not optimized for 50 % of the computer gaming market.


Actually saying Far Cry is better than Doom 3 is like saying a Skoda is better than a BMW.

Doom 3 is a masterpiece which was brilliantly designed and was loads of fun to play.

[Tim]

Q3 dlls got the AMD people a nice ~15% boost, the nice thing is: it was the same as the P4 people got by default, but Intel could scream out : LOOK there's a game that runs faster on our CPU !

today we know Intel has just a not-so-good game performer and they had luck Carmack wrote an engine which sorted the data well.. something the intel arch likes a lot, but many engine devs don't waste time on doing..

very OT, sorry..

And wrong, the Q3 dll give almost as large a boost on P4s as on Athlons/A64s the reason they outperform stock Q3 is that precompiled dll simply is faster than using the Q3 virtual machine it has nothing to do with SSE etc.

[Nick]

Did some of you forget that Carmack presented the first Doom III demos on R300 hardware? Now that it runs better on NV40 it's called cheating? He picks whatever hardware he likes best at the moment.

[Reverend]

Not sure what you mean by "demo" but IIRC the first public showing of the Doom3 engine was on a GeForce3 in a Mac presentation.

[Richard]

Not sure what you mean by "demo" but IIRC the first public showing of the Doom3 engine was on a GeForce3 in a Mac presentation.

You are both right. The D3 _engine_ was first demonstrated on a GF3 (it wasn't even referred to as "DOOM" only "upcoming game") and the D3 _game_ was first demonstrated on the R300.

[Anonymous]

I think all this sounds strange i mean by choosing the option Carmack did he knew it would lower ATI's performance and then not to say anything about it.... talk about cheating for Nvidias favor or whatever you would like to call it.

Many of us took for granted that the latest ID Software engine would come optimized for all cards. But i guess that is not the case.
Also claiming time limits as the reason to not fix this for ATI cards is just BS.

Doom 3 must be the most overrated game by long time.
Gamespot has a decent review but still 8.5 is to much more like 7.5
Most Doom 3 review websites are just a good laugh.

Comparing Doom 3 to Far Cry is like comparing Skoda to BMW.
(The Hell lvl was nice but thats it.)

ID havent been honest with us and this makes me wonder what more is to come. Talk about hyping up Nvidia cards and then the hard truth comes straight back in your face.

I hope game developers choose other engines for their games since this engine is obviously not optimized for 50 % of the computer gaming market.
That's just Carmak's "reward" for ATi leaking the Doom3 demo (He did say there would be repercussions for the IHV responsible)...