View Full Version : Will 3DMark03 ever become popular?
gokickrocks
02-26-03, 03:41 PM
2k3 = 2k3, lets just leave it at that, people get the idea
as for 2k3 being a shortcut, thats just absurd and plain laziness for not typing 1 more number
aw it is not lazyness it is just consiceness. als 2k3c would be 2300, at least in my part of the world, but that would be pointless for sure. ;)
Originally posted by jbirney
Its been show that currently CG only supports features found in NV hardware (no support for Turform or PS1.4). If a developer has all the tools he needs to write HLSL which is a standard for all hardware, why not write just in HLSL?
Truform has nothing to do with either CG or HLSL.
If ATI wants PS1.4 support they can alway make their own compiler.
Originally posted by DaveBaumann
But this is still a DirectX benchmark - what is the point of using a non-Microsoft/DirectX specific HLSL when DirectX9 comes with its own? DX9 HLSL is optimised - its optimised for DirectX, which is exactly what Futuremark are looking for.
Again, Futuremark didn't use HLSL. So your argument is not valid.
By the way HLSL won't produce ATI optimized code either. So why develop in HLSL when using Cg will deliver faster nvidia performance and same ATI performance as HLSL?
DaveBaumann
02-26-03, 10:23 PM
Originally posted by Cotita
Again, Futuremark didn't use HLSL. So your argument is not valid.
Eh? I know, I asked, and I documentented that! I'm merely pointing out that if they were to have used a HLSL then it would make no sense for them to use Cg given they are making a DirectX benchmark and DirectX ships with its own native HLSL.
By the way HLSL won't produce ATI optimized code either. So why develop in HLSL when using Cg will deliver faster nvidia performance and same ATI performance as HLSL?
And thats exactly what Futuremark do not want - they have created optimised code, but not opimised for any particular vendors product its optimised to DirectX.
Futuremark are already being called 'biased' for sticking to what DirectX offers - if they started using HLSL's produced by a vendor, that produces optimised code for that vendor, DESPITE the API they are working on providing a perfectly functional and neutral HLSL, what credibility would they have then?
well i am sure nvidia would put them up on a white horse again Dave. :lol:
jbirney
02-26-03, 10:49 PM
Originally posted by Cotita
If ATI wants PS1.4 support they can alway make their own compiler.
Ummm PS1.4 is already supported by HLSL so why should ATI spend time and money to write a back end for CG to support PS1.4 again?
Chalnoth
02-26-03, 11:39 PM
I think that Futuremark's "sticking with the standards to remain neutral" is flawed. They should optimize for all video cards, not the standards.
As a side note, I had thought that I read 3DMark03 did use DX9 HLSL to aid in writing the shaders (I believe DX9 HLSL, however, has no option to do runtime compiling, which makes for a serious flaw).
gokickrocks
02-27-03, 12:04 AM
since this 2k3 has not been solved, here is my take on it...
in engineering notation and scientific for that matter...
k = e^3
you dont have numbers after the notation unless its the order of the power, so you would have to take the 3 as a multiplication
it would be...
2(e^3)3 = 6000
for 2003, you would have to put...
2.003k or 2k+3
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.
exactly, scew standards, lets make this all much harder on programs because it is too easy for them to make good games any other way! :lol:
Chalnoth
02-27-03, 12:27 AM
You might have a point if we didn't have an HLSL that can compile to specific hardware.
gravioli
02-27-03, 12:58 AM
Originally posted by gokickrocks
since this 2k3 has not been solved, here is my take on it...
in engineering notation and scientific for that matter...
k = e^3
you dont have numbers after the notation unless its the order of the power, so you would have to take the 3 as a multiplication
it would be...
2(e^3)3 = 6000
for 2003, you would have to put...
2.003k or 2k+3
Talk about beating dead horse. :) Anyway, if you type in "2k3" as a google search, the most common references that pop up refer to the abbreviation of 2003. Therefore, I think it is safe to conclude that a reference to "2k3" clearly communicates "2003" to the majority of people.
Okay, back on topic. Maybe we can have the 2k3 debate in the Off-Topic forum. :)
Originally posted by gokickrocks
since this 2k3 has not been solved, here is my take on it...
in engineering notation and scientific for that matter...
k = e^3
you dont have numbers after the notation unless its the order of the power, so you would have to take the 3 as a multiplication
it would be...
2(e^3)3 = 6000
for 2003, you would have to put...
2.003k or 2k+3
That's what I have been trying to say. You adding 3 to 2k that will give you 2003. 2k3 would be 2300.
Shinri Hikari
02-27-03, 03:59 AM
Originally posted by kyleb
k = 1000
2k = 2000
2k3 =2003
thats math on my part of the planet :D
No matter where I am, I agree.:D :cool:
DaveBaumann
02-27-03, 04:34 AM
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.
Errr, its a benchmark that will be used by several generations of boards by several manufacturers - they could only optimise to the ones that are available now, so how on earth could it be a fair an impartial benchmark for those that come out six month down the line? How would it be fair on S3, SiS and perhaps the next 3Dlabs part?
Again, the only route to take to make it an impartial benchmark is to optimise to the API, not vendors boards.
Originally posted by Shinri Hikari
No matter where I am, I agree.:D :cool:
Come down to Australia and say that. My physics, maths and electrical teachers would spank your buttox. :) :D
Chalnoth
02-27-03, 07:32 AM
And yet, with support for PS 1.4, they manage not to use any VS/PS 2.0 extended (this would probably give benefits for skinning, for one).
DaveBaumann
02-27-03, 07:37 AM
And yet, with support for PS 1.4, they manage not to use any VS/PS 2.0 extended (this would probably give benefits for skinning, for one).
Those that require skinning are DX8 compliant tests, and PS1.4 is part of DX8.
Chalnoth
02-27-03, 07:41 AM
And VS/PS 2.0 extended is part of DX9. If this is supposed to be a DX9 benchmark, where are the VS/PS 2.0 extended tests?
From what I've read about the performance characteristics of the R300 (specifically, that it's faster running PS 1.4-level shaders than PS 2.0-level), the choices that Futuremark made to "optimize for the API" seem to conspicuously look like they optimized for the R300. Whether this is intentional or not is of little consequence. Any decisions made will always favor one architecture over another, so it is better to just attempt to optimize for all architectures.
DaveBaumann
02-27-03, 08:02 AM
Its supposed to be a test for new boards - the majority of gaming titles DX9 board will operate on will be using DX8 features, and that is what they are representing. However, I even documented that I would have preferred to have seen a more far reaching DX9 benchmark generated via HLSL instead of the rather pointles DX7 benchmark - even if that were the case I doubt that they would have used extended PS2.0 as most games are not likely to go that far either - performance on that number of instructions is poor, and the majority target for DX9 support is R300. As with previous revisions you are likely to see most game developers (I'm sure there will be some that use the extended support) target to withing the lowest common demoninator of the API in order to hit the widest range of boards.
And, so what if R300 does have support for PS1.4 - thats immaterial to Futuremark since PS1.4 is just a part of the API. Everyone is free to add dedicated support if they wish. If you really want to winge at someone, winge at MS for including PS1.4.
Originally posted by DaveBaumann
Its supposed to be a test for new boards - the majority of gaming titles DX9 board will operate on will be using DX8 features, and that is what they are representing. However, I even documented that I would have preferred to have seen a more far reaching DX9 benchmark generated via HLSL instead of the rather pointles DX7 benchmark - even if that were the case I doubt that they would have used extended PS2.0 as most games are not likely to go that far either - performance on that number of instructions is poor, and the majority target for DX9 support is R300. As with previous revisions you are likely to see most game developers (I'm sure there will be some that use the extended support) target to withing the lowest common demoninator of the API in order to hit the widest range of boards.
And, so what if R300 does have support for PS1.4 - thats immaterial to Futuremark since PS1.4 is just a part of the API. Everyone is free to add dedicated support if they wish. If you really want to winge at someone, winge at MS for including PS1.4.
Very well said. I agree 100%.
Chalnoth
02-27-03, 10:41 AM
Originally posted by DaveBaumann
I doubt that they would have used extended PS2.0 as most games are not likely to go that far either - performance on that number of instructions is poor, and the majority target for DX9 support is R300.
There are more benefits than just the number of instructions.
there are more benefits than just the number of instructions, but none that can be done without visual diffferences; which would destroy the whole point of 3dmark!
Chalnoth
02-27-03, 11:37 AM
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?
StealthHawk
02-27-03, 07:38 PM
Originally posted by Chalnoth
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?
i guess in that case you'll have to wait for 3dmark03SE :p ;) :D
vBulletin® v3.7.1, Copyright ©2000-2012, Jelsoft Enterprises Ltd.