Will 3DMark03 ever become popular?

[Hellbinder]

I think the primary benefits would be seen by moving to VS 2.0 extended (while keeping the visuals the same), for 3DMark03. That is, it has been shown that per-vertex branching can help with skinning.

As for visual differences, 3DMark01 had an "advanced pixel shader test," didn't it?

It makes NO SENSE to move or support PS 2.0 *extended*. Becuase its not any kind of an industry standard. Its just some extra junk Nvidia tossed on their card for marketing purposes.

PS 2.0 *extended* is not a recognized and accepted DX9 Standard. Its a hybrid bastard child of Nvidias own creation. You cannot make comparrisons to PS 1.4 with this, because PS 1.4 *IS* a recocnized Standard and *included* within the DX8.1 and DX9 spec.

What there is iincluded is PS 2.0 and PS 3.0

You want 3dmark03 to add support for more DX9 shader features? Then it needs to be PS 3.0 not some half backed shader support that *ONE* IHV dreamed up trying to do their own thing.

I am all for adding more PS DX9 features to 3dmark03. But lets make them Conform to Microsoft and the rest of the industries *RECOGNIZED* Standards. Like more diverse PS 2.0 tests, or even better PS 3.0 tests. After all the R400 is a PS 3.0 card. The Nv35 might be as well.

It is pretty obvious that the Nv30 is only going to be released in limited quantities before they move to the Nv35. Why Screw up an industry standard benchmark for the sake of one Ill Concieved, poorly executed, limited release product??

[Kruno]

Originally posted by Hellbinder
It makes NO SENSE to move or support PS 2.0 *extended*. Becuase its not any kind of an industry standard. Its just some extra junk Nvidia tossed on their card for marketing purposes.

PS 2.0 *extended* is not a recognized and accepted DX9 Standard. Its a hybrid bastard child of Nvidias own creation. You cannot make comparrisons to PS 1.4 with this, because PS 1.4 *IS* a recocnized Standard and *included* within the DX8.1 and DX9 spec.

What there is iincluded is PS 2.0 and PS 3.0

You want 3dmark03 to add support for more DX9 shader features? Then it needs to be PS 3.0 not some half backed shader support that *ONE* IHV dreamed up trying to do their own thing.

I am all for adding more PS DX9 features to 3dmark03. But lets make them Conform to Microsoft and the rest of the industries *RECOGNIZED* Standards. Like more diverse PS 2.0 tests, or even better PS 3.0 tests. After all the R400 is a PS 3.0 card. The Nv35 might be as well.

It is pretty obvious that the Nv30 is only going to be released in limited quantities before they move to the Nv35. Why Screw up an industry standard benchmark for the sake of one Ill Concieved, poorly executed, limited release product??

Any chance of you backing up everything you have said?

[Chalnoth]

Originally posted by Hellbinder
It makes NO SENSE to move or support PS 2.0 *extended*. Becuase its not any kind of an industry standard. Its just some extra junk Nvidia tossed on their card for marketing purposes.
BS. Look at the specs. "PS 2.0 extended" also supports other functionality that nVidia does not support.

And how in the world can you make the distinction that PS 1.4 is a standard while PS 2.0 extended is not? They're both posted quite clearly on the MSDN website.

You want 3dmark03 to add support for more DX9 shader features? Then it needs to be PS 3.0 not some half backed shader support that *ONE* IHV dreamed up trying to do their own thing.
Again, the parallels to PS 1.4 are just too obvious here.

[tamattack]

Originally posted by Chalnoth
Again, the parallels to PS 1.4 are just too obvious here.

So why do you sound like you support one (PS2.0 Extended) but not the other (PS1.4)?

[kyleb]

espesaly sence 1.4 was adopted by microsoft well after the release of dx8 while 2.0+ poped up right along side dx9 which is the obvious reason not backed by microsoft yet. it seems to me that microsoft is being very reasonable in this situation, however i can't see how you could claim the same Chalnoth.

[Sazar]

Originally posted by kyleb
espesaly sence 1.4 was adopted by microsoft well after the release of dx8 while 2.0+ poped up right along side dx9 which is the obvious reason not backed by microsoft yet. it seems to me that microsoft is being very reasonable in this situation, however i can't see how you could claim the same Chalnoth.

damn now I need to do more reading :(

I was just about caught up on pixel shaders when you lot went off on this stuff..

/me heads back to the library to bury his sorrows in old fashioned/dust covered books...

[kyleb]

and man i need to start working harder to fight my dyslectia, i swear i proof-read that but now that i read it again it looks really bad. :banghead:


anyway, i am glad you at least could read my comments well enough to find them of interest Sazar. :)

[Chalnoth]

Originally posted by tamattack
So why do you sound like you support one (PS2.0 Extended) but not the other (PS1.4)?
It's more that I don't support the fact that 3DMark03 uses PS 1.4 more often than any other shader on DX9 hardware.

[Chalnoth]

Originally posted by kyleb
espesaly sence 1.4 was adopted by microsoft well after the release of dx8 while 2.0+ poped up right along side dx9 which is the obvious reason not backed by microsoft yet. it seems to me that microsoft is being very reasonable in this situation, however i can't see how you could claim the same Chalnoth.
:banghead:
PS 2.0 extended is included in DirectX 9. How in the world can it possibly not be "backed by Microsoft"?

[kyleb]

hu fair enough, i was given the impression that it was only avalable in opengl at this point. funny though, i did a seach google for "ps 2.0 extended" and only came up with one result, that being an nvidia pdf. :D

[Chalnoth]

There's absolutely no such thing as "Pixel Shader 2.0" in OpenGL.

[digitalwanderer]

I was pretty sure it was just "ps 2.0" in DX9 without any "extended" mentioned in there...could you back that up please?

[Chalnoth]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/Shaders/Shaders.asp

[kyleb]

Originally posted by Chalnoth
There's absolutely no such thing as "Pixel Shader 2.0" in OpenGL.

i was speaking about the availability of such functions, not nomenclature. regadless, now that you present that link i do remeber hearing the small contrivcy over the disssion to include 2.0 extended and 3.0 in dx9. ;)

[tamattack]

Originally posted by Chalnoth
It's more that I don't support the fact that 3DMark03 uses PS 1.4 more often than any other shader on DX9 hardware.

As a consumer, would you care if Doom III is compiled from C vs. C++ source? No, you just care if the game runs as promised. What's the difference here?

Put another way: Why do you care if I use 5 words to describe something which takes you 15? :confused:

[digitalwanderer]

Originally posted by Chalnoth
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/directx/graphics/reference/Shaders/Shaders.asp

Thank you Chalnoth. I was wrong, there are indeed "ps 2.0 extended" listed in the DX9 specs. You are correct. :)

[hithere]

Originally posted by Chalnoth
I think that Futuremark's "sticking with the standards to remain neutral" is flawed. They should optimize for all video cards, not the standards.

"All video cards" have not been produced yet, just as all games have not yet been produced. Nvidia's and ATi's offerings may differ greatly over the next year and a half...how good would their benchmark do if it were running code optimized for a certain make of card, then a future card received no such optimized code and performed poorly, even though it was more than capable of handling the challenge of future games? As far as I can tell, using a proprietary HLSL only colors the results in favor of one company, and at that, only the current generation of card offerings from said company. How the heck are they supposed to help people make a decision about a card purchase in 2004 using a benchmark that favors cards manufactured in November of 2002? Would they offer "updates" to the benchmark, as if all the games that were produced in the interim would have been cg-patched every time nvidia decided to release a new card?
And what do they say about the lower precision modes the FX favors? Is it a valid comparison between cards that aren't producing the same visual effects?


Regardless of whether or not it were true, Futuremark would risk
being regarded as favoritizing nvidia if it were to use cg to develop their benchmark...and for what? Optimization for a card that isn't out yet, and hasn't shown its true colors (FX), or would you rather it showed your Ti4600 in a better light (as if it can compete with the 9700)? What disservice are they doing consumers here?

And your suggestion about having it be "the lowest shader version possible" seems outdated...isn't this supposed to be a forward-looking benchmark? We have benchmarks for all lower versions, do we need another one?

[kyleb]

i also have to wonder how many games are writen is straight directx and run well across the range of current hardware so no effort is put into optimizing for various cards. i don't think you can call those games flawed for that can you?

[Kruno]

Originally posted by tamattack
As a consumer, would you care if Doom III is compiled from C vs. C++ source? No, you just care if the game runs as promised. What's the difference here?

Put another way: Why do you care if I use 5 words to describe something which takes you 15? :confused:

A\ I am a consumer and I deeply care if the source was compiled from C or C++.

B\ Using 15 words instead of 5 to say the same thing is usually done to confuse people.

[Cotita]

Originally posted by K.I.L.E.R
A\ I am a consumer and I deeply care if the source was compiled from C or C++.

B\ Using 15 words instead of 5 to say the same thing is usually done to confuse people.

Really?, can you tell if a game was develped in C or C++?

[legion88]

Originally posted by Chalnoth
I think that Futuremark's "sticking with the standards to remain neutral" is flawed. They should optimize for all video cards, not the standards.



You make it so obvous that you want coders to write their applications to give NVIDIA an advantage. We all know that you are trying to hide your PR by including such general terms like "all" but we know better.

You as a programmer would already know that the purpose of using an API is to make programming for a particular type of hardware (i.e. video cards) a whole lot easier. The purpose of an API is to allow programmers to code for these variety of hardware without having to test every single possible variety (e.g. "all video cards").

We also know that optimizing for "all video cards" is 100% dependent on how good the programmer is. As already mentioned to you, just because Joe Cool Programmer (JCP) knows how to program NVIDIA cards very efficiently, it does not follow that he can do the same with other cards from ATI, SiS, Matrox, or S3. It does not even follow that a current NVIDIA efficient code would even work efficiently with future NVIDIA products.

As already mention, you are no longer just benching video cards, you are also gauging how well JCP knows how to efficiently program different current video cards. And every programmers' skill level are different. Why do we want to measure their skill level? What's the purpose of 3DMark2003?

We, including you, also know that the relationship that JCP has with NVIDIA, ATi, and others will also influence how efficient to code is. A better relationship increases the likelihood that the code would be as efficient as possible. So, now we are also gauging how good JCP's relationship is with the various video card companies. We all know that the assumption here is that NVIDIA has an advantage with this.

And what is the purpose of benchmark programs like 3DMark2003? I noticed that a certain someone keeps making these general comments (that don't even work for general cases, either) while completing ignoring the purpose of 3DMark2003.

The purpose of 3DMark2003 was never to gauge how well FutureMark can optimize their code for NVIDIA versus ATI versus S3, etc. The purpose of 3DMark2003 was to gauge how well various video cards can perform (referring to the graphics portion of the suite of tests, of course) on an even playing field.

Your use of "flawed" is in itself flawed. It is like saying that bus drivers are "flawed" because all they do is drive buses. If you refuse to accept the purpose of benchmarks, then don't call it "flawed". It is only flawed if it does not live up to its purpose.

[legion88]

Originally posted by hithere

(snip...)

And your suggestion about having it be "the lowest shader version possible" seems outdated...isn't this supposed to be a forward-looking benchmark? We have benchmarks for all lower versions, do we need another one?

It isn't about need. It is about 'what do you want to hide until the next best thing comes out'.

Here are some scores with a fillrate tester from the Quadro FX 2000 (400Mhz core).

Fillrate Tester
--------------------------
Display adapter: NVIDIA Quadro FX 2000
Driver version: 6.14.1.4290
Display mode: 1024x768x32bpp
--------------------------

Color writes enabled, z-writes disabled:
FFP - Pure fillrate - 1512.724487M pixels/sec
FFP - Single texture - 1217.574219M pixels/sec
FFP - Dual texture - 975.951599M pixels/sec
FFP - Triple texture - 570.073181M pixels/sec
FFP - Quad texture - 542.109619M pixels/sec
PS_2_0 - Per pixel lighting - 58.340889M pixels/sec
PS_2_0 PP - Per pixel lighting - 58.350346M pixels/sec
PS_1_1 - Simple - 766.042053M pixels/sec
PS_1_4 - Simple - 480.761139M pixels/sec
PS_2_0 - Simple - 483.617737M pixels/sec
http://www.beyond3d.com/forum/viewtopic.php?t=4535&postdays=0&postorder=asc&start=40

I note the signficant drop in performance from PS_1_1 to PS_1_4. The performance of PS2_0 is quite similar to PS_1_4.

Now here are the scores for a Radeon 8500.

Fillrate Tester
--------------------------
Display adapter: ALL-IN-WONDER RADEON 8500
Driver version: 4.14.1.3659
Display mode: 1024x768x32bpp
--------------------------

Color writes enabled, z-writes disabled:
FFP - Pure fillrate - 1249.172607M pixels/sec
FFP - Single texture - 1034.936646M pixels/sec
FFP - Dual texture - 563.419495M pixels/sec
FFP - Triple texture - 255.208725M pixels/sec
FFP - Quad texture - 168.004639M pixels/sec
PS_2_0 - Per pixel lighting - Failed!
PS_2_0 PP - Per pixel lighting - Failed!
PS_1_1 - Simple - 1233.932617M pixels/sec
PS_1_4 - Simple - 642.095886M pixels/sec
PS_2_0 - Simple - Failed!


Similar result. Large drop in performance from PS_1_1 to PS_1_4. Of course, the 8500 is not a DX9 card so PS_2_0 tests all failed.

Now here are scores for the Radeon 9700Pro.
Fillrate Tester
--------------------------
Display adapter: RADEON 9700 SERIES 325/310
Driver version: 6.14.1.6292
Display mode: 1024x768x32bpp
--------------------------

Color writes enabled, z-writes disabled:
FFP - Pure fillrate - 1786.334229M pixels/sec
FFP - Single texture - 1962.872559M pixels/sec
FFP - Dual texture - 1028.006592M pixels/sec
FFP - Triple texture - 680.939575M pixels/sec
FFP - Quad texture - 498.430298M pixels/sec
PS_2_0 - Per pixel lighting - 188.913147M pixels/sec
PS_2_0 PP - Per pixel lighting - 188.947739M pixels/sec
PS_1_1 - Simple - 1230.885376M pixels/sec
PS_1_4 - Simple - 1223.748901M pixels/sec
PS_2_0 - Simple - 1223.748047M pixels/sec


Notice that the scores for PS_1_1, PS_1_4, and PS_2_0 are virtually the same. When it comes to performance, it does not make much of a difference which pixel shader was used on a Radeon 9700Pro. It does make a difference on the FX, a big difference. So you can see why there's a push to use PS_1_1 even with NVIDIA's latest and greatest because of the current performance issue.

[John Reynolds]

One theory I've read is that the FX architecture is running PS1.4 over its floating point hardware (DX9 compliancy requires PS2.0 to be run on floating point precision) while its legacy shader support (1.1) is using integer functionality from its predecessors (GF3/4). Therefore the FX architecture could very well be faster running PS1.1 over its integer operators than PS1.4, though the former requires more passes.

And, Roscoe, this is getting scary. I'm starting to agree with almost everything I see you post these days. :hug:

[legion88]

How many pixel pipelines do these cards have?

Radeon 9700Pro
Core: 466MHz, memory: 405MHz (http://service.futuremark.com/compare?2k3=330527)
Fillrate (single): 2020.5 mtexels/sec

# of pipes: 2020.5/466 = 4.33

Core: 324MHz, memory: 351MHz (
http://service.futuremark.com/compare?2k3=299936)

Fillrate (single): 1588.3 mtexels/sec

# of pipes: 1588.3/324 = 4.9


GeForce FX series

Core: 500Mhz, memory: 500MHz (http://service.futuremark.com/compare?2k3=305614)

Fillrate (single): 1314.1 mtexels

# of pipes = 1314.1/500 = 2.6

Core: 400Mhz, memory: 400MHz (http://service.futuremark.com/compare?2k3=270840)

fillrate (single): 1022.9 mtexels/sec

# of pipes = 1022.9/400 = 2.56

GeForce TI 4600

Core: 361Mhz, memory: 376Mhz (
http://service.futuremark.com/compare?2k3=237799)

fillrate (single): 1003.5 mtexels/sec

# of pipes = 1003.5 mtexels/361 = 2.77

Core: 315Mhz, memory: 375Mhz (http://service.futuremark.com/compare?2k3=312725)

fillrate (single): 1046.5 mtexels/sec

# of pipes = 1046.5/315 = 3.32

Radeon 8500

Core: 275MHz, memory: 275Mhz (
http://service.futuremark.com/compare?2k3=120189)

fillrate (single): 656.3 mtexels/sec

# of pipes = 656.3/275 = 2.39

Core: 319MHz, memory: 370MHz (http://service.futuremark.com/compare?2k3=239614)

fillrate (single): 1024.3 mtexels/sec

# of pipes = 1024.3/319 = 3.2

Quick notes to convert to pixel fillrate.
For FX/9700Pro, divide the single-texture fillrate scores(mtexels/sec) by one then multiply by the # of TMUs used in each pipeline (which is one). Thus, they are numerically the same.

For the 4600/8500, the # of TMUs is also one since the second TMU of each pipe in single-textured cases isn't being used.

For FX/9700Pro, divide the multi-texture fillrate scores (mtexels/sec, not shown) by four then multiply by the # of TMUs used in each pipeline (which is one).

For the 4600/8500, the # of TMUs is two.

If FutureMark didn't waste their time listening to 3dfx and used this marketing term we call "texel", then this stupid conversion equation would not have been needed.

Quick observations:

1) bandwidth is the #1 influence. Comparing the 370+ Mhz memory 8500s, TI 4600s and the 400MHz FX shows similar scores, regardless of theoretical maximum fillrate.

2) the FX multi-texture scores in mtexels (not shown) are typically more than 2X greater than single-texture scores. In pixels/sec--remember to convert, this means that the single-texture fillrate is only 61% faster when it should be around around 100% faster than the multi-texture case. Strongly suggests that the single-texture FX scores are lower than it should be, possibly related to #1--bandwidth.

3) double the available bandwidth, you double the calculated # of pipes (notice the 9700Pro scores). Again, this suggests that bandwidth is the issue here. Even with the Pro, the # of pipes don't add up to 8. Where's the noise?

4) the 9700Pro's multi-texture scores in mtexels (not shown) are typically just 50% greater. In pixels/sec, this means that the single-texture fillrate is a whopping 165% faster than multi-texture instead of 100%. This suggest that the multi-texture scores are lower than it should be for unknown reason.

[Kruno]

Originally posted by Cotita
Really?, can you tell if a game was develped in C or C++?

C++. :)
Because it's an extension to C. :D
Makes it easier and quicker to do some things.

You can tell by ripping the source code. ;)