PDA

View Full Version : Is the Carmack wrong ?


Sazar
05-28-03, 10:01 AM
just reading up on b3d about some details in the carmack spiel on optimizations v/s cheats in games/benches...

"Rewriting shaders behind an application's back in a way that changes the output under non-controlled circumstances is absolutely, positively wrong and indefensible.

Rewriting a shader so that it does exactly the same thing, but in a more efficient way, is generally acceptable compiler optimization, but there is a range of defensibility from completely generic instruction scheduling that helps almost everyone, to exact shader comparisons that only help one specific application. Full shader comparisons are morally grungy, but not deeply evil.

The significant issue that clouds current ATI / Nvidia comparisons is fragment shader precision. Nvidia can work at 12 bit integer, 16 bit float, and 32 bit float. ATI works only at 24 bit float. There isn't actually a mode where they can be exactly compared. DX9 and ARB_fragment_program assume 32 bit float operation, and ATI just converts everything to 24 bit. For just about any given set of operations, the Nvidia card operating at 16 bit float will be faster than the ATI, while the Nvidia operating at 32 bit float will be slower. When DOOM runs the NV30 specific fragment shader, it is faster than the ATI, while if they both run the ARB2 shader, the ATI is faster.

When the output goes to a normal 32 bit framebuffer, as all current tests do, it is possible for Nvidia to analyze data flow from textures, constants, and attributes, and change many 32 bit operations to 16 or even 12 bit operations with absolutely no loss of quality or functionality. This is completely acceptable, and will benefit all applications, but will almost certainly induce hard to find bugs in the shader compiler. You can really go overboard with this -- if you wanted every last possible precision savings, you would need to examine texture dimensions and track vertex buffer data ranges for each shader binding. That would be a really poor architectural decision, but benchmark pressure pushes vendors to such lengths if they avoid outright cheating. If really aggressive compiler optimizations are implemented, I hope they include a hint or pragma for "debug mode" that skips all the optimizations."

per the conversation there... it would appear as though Carmack is assuming dx9 == fp32... instead of the stated fp24 minimum... thats the topic of discussion @ b3d anyways...

anyone care to chime in and explain this ?

digitalwanderer
05-28-03, 10:04 AM
Originally posted by Sazar
it would appear as though Carmack is assuming dx9 == fp32... instead of the stated fp24 minimum...

Me thinks he's been too chummy with nVidia lately and it's where he's been getting his DX9 specs from. :rolleyes:

"No John, really! Microsoft made DX9 fp32 bit for it's standard last week, you must have missed it. Now, about that benchmark we were discussing..."


:rolleyes:

Sazar
05-28-03, 10:08 AM
Originally posted by digitalwanderer
Me thinks he's been too chummy with nVidia lately and it's where he's been getting his DX9 specs from. :rolleyes:

"No John, really! Microsoft made DX9 fp32 bit for it's standard last week, you must have missed it. Now, about that benchmark we were discussing..."


:rolleyes:

well it could very well be that he is just going on and talkin in relation to doom III which... since it is not dx... does not conform to dx9 API specs... ergo fp32 precision makes sense...

as far as the chummy part :) if you read the article... I think you may not think so...

regard this...

"Rewriting shaders behind an application's back in a way that changes the output under non-controlled circumstances is absolutely, positively wrong and indefensible.

I think that is quite obvious init :D

SurfMonkey
05-28-03, 10:31 AM
I think he's got a little confused, DX9 and OGL process everything internally at FP32 but the minimum support is for FP24.

It's annoying because it's not listed in the DX9 SDK but it was posted on the MSDXDEV mailing list.

Sazar
05-28-03, 10:32 AM
Originally posted by SurfMonkey
I think he's got a little confused, DX9 and OGL process everything internally at FP32 but the minimum support is for FP24.

It's annoying because it's not listed in the DX9 SDK but it was posted on the MSDXDEV mailing list.

yes... thats what I have heard...

he is probably a little overwhelmed @ the moment what with doom III taking a decade to create and the pressure to find someone new to do the music...

:)

maybe he just didn't think straight there...

Nv40
05-28-03, 10:48 AM
probably he thinks faster ,than what he types..(heck it happens to me) :)

so what he was probably saying was..

There isn't actually a mode where they can be exactly compared. DX9 and ARB_fragment_program assume 32 bit float operationon Nvidia cards ,since they dont support Fp24, and ATI just converts everything to 24 bit

i think he already knows ,but i dont think he needs to explain *everything*
with detail what is obvious to everyone ,not in a forum of Linux Guys with
some degree of Computer knowledge. :D

Hanners
05-28-03, 10:57 AM
Originally posted by Nv40
i think he already knows ,but i dont think he needs to explain *everything*
with detail what is obvious to everyone ,not in a forum of Linux Guys with
some degree of Computer knowledge. :D

No, I think what SurfMonkey said is closer to what he actually meant.

digitalwanderer
05-28-03, 11:02 AM
Originally posted by Nv40
i think he already knows ,but i dont think he needs to explain *everything*
with detail what is obvious to everyone ,not in a forum of Linux Guys with
some degree of Computer knowledge. :D

Yeah, I think it's safe for JC to assume that the folks at /. will be able to fill in a few of the blanks. ;) :lol:

eagle17
05-28-03, 11:39 PM
Originally posted by Sazar
yes... thats what I have heard...

he is probably a little overwhelmed @ the moment what with doom III taking a decade to create and the pressure to find someone new to do the music...

:)

maybe he just didn't think straight there...

Well I think he is burnt on Doom3 and is spending more and more of his time trying to get to space. After all that is more of a race...

GlowStick
05-29-03, 12:20 AM
Hm, actually there is a way to clear things up.

JC dosent really care about DirectX, for some reason on alot of boards people keep saying "dude, no Doom 3 is DX9".

His statement only protains to OpenGL and Doom3, pretend DirectX dosent exist, like we all should : P *shameless openGl plug*

StealthHawk
05-29-03, 12:55 AM
Originally posted by GlowStick
Hm, actually there is a way to clear things up.

JC dosent really care about DirectX, for some reason on alot of boards people keep saying "dude, no Doom 3 is DX9".

His statement only protains to OpenGL and Doom3, pretend DirectX dosent exist, like we all should : P *shameless openGl plug*

His statement explicitly, and incorrectly, mentions DX9DX9 and ARB_fragment_program assume 32 bit float operation, and ATI just converts everything to 24 bit.

GlowStick
05-29-03, 01:02 AM
Originally posted by StealthHawk
His statement explicitly, and incorrectly, mentions DX9
whoa

ok i retract that im sorry.

aapo
05-30-03, 09:25 AM
Originally posted by Sazar

per the conversation there... it would appear as though Carmack is assuming dx9 == fp32... instead of the stated fp24 minimum... thats the topic of discussion @ b3d anyways...


Read more carefully:



DX9 and ARB_fragment_program assume 32 bit float operation, and ATI just converts everything to 24 bit.



JC doesn't say that the accuracy is 32 bits. He just states that DX9 and ARB assume the length of the data type (used in the GL/DX9 program) to be 32 bits. Then, inside ATI's drivers the results are calculated using an accuracy of 24 bits. Which is of course completely legal in both GL and DX9, btw.

Similar situation exists for example in gcc and i386 arch: Long doubles with a length of 128 bits are only calculated with 80-bits accuracy.

Sazar
05-30-03, 09:36 AM
Originally posted by aapo
Read more carefully:



JC doesn't say that the accuracy is 32 bits. He just states that DX9 and ARB assume the length of the data type (used in the GL/DX9 program) to be 32 bits. Then, inside ATI's drivers the results are calculated using an accuracy of 24 bits. Which is of course completely legal in both GL and DX9, btw.

Similar situation exists for example in gcc and i386 arch: Long doubles with a length of 128 bits are only calculated with 80-bits accuracy.

ok that would make more sense... since ati's r3x0 cores do convert 32bit to 24bit fp internally..

k... cheers...

Greg
05-31-03, 02:07 AM
I think Carmack is just making two points.

1) Modifying instructions/programs he sends to the video card is cheating in his mind. A valid optimisation, but still cheating.

2) The current situation is brought about by the two manufacturers taking design decisions that are quite different and both have strengths and weaknesses, but are being compared in a) synthetic benches b) a selection of current games. This is an important battle for the mind and wallet.

I think a key DirectX9 feature was 'high precision color'. Any preliminary specification such as minimum 24bit floats etc is not important. What is important is oportunities to get away from 8bit int components (which has happened internally for some time). I personally think it would be great if the user could select a lower internal/external precision to compromise speed or quality for specific games. We could then run Quake 3 at insane frame rates, but also get 60zillion shades of black for Doom 3!

aapo
05-31-03, 04:16 AM
Originally posted by Sazar
ok that would make more sense... since ati's r3x0 cores do convert 32bit to 24bit fp internally..


Yes. I think JC always speaks in application context due to his engine developing (eg. in his famous .plan-files). You and other hardware enthusiasts usually discuss things from the hardware / drivers viewpoint, which is on the other side of the interface. ;) And because JC for some reason uses words rather sparingly, there is a lot of room for misunderstandings. Took me quite a while to understand his statement, too...

(edited a pselling error...)

StealthHawk
05-31-03, 04:56 AM
Originally posted by aapo
(edited a pselling error...)

Ironic :D

Ady
05-31-03, 09:12 PM
Originally posted by StealthHawk
Ironic :D

hehe too funny.