Reverend at The Pulpit #12
- Thread starter Reverend
- Start date
- Status
My apologies, I will desist.Reverend said:
Reverend said:
new ? when did you discover computer graphics ?
it has been used since early days of Geforce 3
(and some games on XBox also like splinter cell).
The fact that 3dmark discover it now (and they have been criticized for their use of stencil shadows also in the previous one), is not relevant. I don't quite understand the fuss about that.
Moreover, it is the original way to do it. 3dmark probably didn't want to do that before because their baseline (pre-ps2.0 boards) didn't support the "emulation" in the shader. Now that minimal spec support it in a way or the other, it is the way to go.
This issue for the site relates to the fact that they have their name stamped on this program as beta members of the benchmarks development. If they dont agree with what is implemented in it (and they obviously werent consulted with the final release), they dont need to be associated with it.
I dont agree that there should be any short-cuts/or alternate paths to render a benchmark which will be used through-out the industry for determining future 3d-graphics performance. Every card should follow the same path, and render the same image to give a comparitive result or fair score.
I think they have done the right thing with the shaders however, allowing the program to compile down the more advanced shaders in fewer passes (if possible) with the more advanced shader models supported by the newer cards (at least with a runtime-compilation engine). I also believe its ok to reduce precision for simple shaders, which have no effect on the output, and will be used to speed up dx9 games on slower, mixed-precision cards. Lets hope the newer drivers dont start overriding the benchmark requests in 3dmark.
Both of the above seem fair for all groups, even though they may specifically favour only one. The use of 3Dc in 3Dmark05 could only help one company, as does DST usage (which is actually on by default). The same would apply to game-tests that would have unusually-high overdraw and render back-to-front to slow the optimisations of IMR architectures & score more favourably on an alternative TBDR (if one emerged for PC) - what would people say then???
Scali, Im sure you (as well as DeanoC & many others) may have more experience and 3D-knowledge, than DaveB & Co, but you should show a little more respect for the guys on their own site. They have created and maintained and informative & edu-taining place here where people can learn about the world of 3D. The other developers arent out here picking through the little misconceptions that they may have made, so maybe you should reserve your opinions on such matters for other places. This place has never been the "be-all-and-end-all" of 3D, but it does seem to be one of the fairest and honest sites around.
I dont agree that there should be any short-cuts/or alternate paths to render a benchmark which will be used through-out the industry for determining future 3d-graphics performance. Every card should follow the same path, and render the same image to give a comparitive result or fair score.
I think they have done the right thing with the shaders however, allowing the program to compile down the more advanced shaders in fewer passes (if possible) with the more advanced shader models supported by the newer cards (at least with a runtime-compilation engine). I also believe its ok to reduce precision for simple shaders, which have no effect on the output, and will be used to speed up dx9 games on slower, mixed-precision cards. Lets hope the newer drivers dont start overriding the benchmark requests in 3dmark.
Both of the above seem fair for all groups, even though they may specifically favour only one. The use of 3Dc in 3Dmark05 could only help one company, as does DST usage (which is actually on by default). The same would apply to game-tests that would have unusually-high overdraw and render back-to-front to slow the optimisations of IMR architectures & score more favourably on an alternative TBDR (if one emerged for PC) - what would people say then???
Scali, Im sure you (as well as DeanoC & many others) may have more experience and 3D-knowledge, than DaveB & Co, but you should show a little more respect for the guys on their own site. They have created and maintained and informative & edu-taining place here where people can learn about the world of 3D. The other developers arent out here picking through the little misconceptions that they may have made, so maybe you should reserve your opinions on such matters for other places. This place has never been the "be-all-and-end-all" of 3D, but it does seem to be one of the fairest and honest sites around.
tEd said:
Looking at my screenshots on a GFFX with FW66.51 and 'Quality' there is quite a lot of blurring and/or anti-aliasing on the edges of them 2k-Shadowmaps.
Obviously, the degree of edge calculations varies depending on the position of light source and shadowed surface.
I tried frame 240 (just a wild guess at first try, but worked) on GT3 in quite a high resolution. The back fins of the airship do shadow the airtank of the ship quite blurry whereas the shadows of the emergency jets are only mildly AA'ed on the hull.
Mmmm,
Something changed between July and September.
[url=http://www.beyond3d.com/interviews/fm04/index.php?p=4 said:
Something changed between July and September.
In a NDA doc, Futuremark states the following as one of the "Principle Guidelines" behind the formation of 3DMark05 :
I read that to mean that the "default setting" plays an important part in FM's attempt to produce "identical rendering on all hardware" in 3DMark05.
Futuremark said:
I read that to mean that the "default setting" plays an important part in FM's attempt to produce "identical rendering on all hardware" in 3DMark05.
DaveBaumann said:
Sounds like things have really changed a lot the last few months. :?Reverend said:
Reverend said:
I don't think it specifically says that, to be honest. To be fair, DST is not part of the *required* feature set of 3DMark05, since it can run without.
I think this statement merely says that without any *optional* features, you get identical, reliable and comparable rendering.
I can understand the confusion though, since it doesn't say that there are optional features, or how those relate to this. Then again, perhaps that was mentioned elsewhere in the document, or was thought to be implicit in this statement.
If you purchase it, if you run the free version you don't have the option to disable DST.Scali said:
No, DST+PCF is not a require feature but PSM is.
DST+PCF has to do with PSM that FM implemented. Hence, PSM is itself a "required feature set" (and not necessarily the addition of DST+PCF) -- both ATI's and NV's DX9.0 parts support PSM. Heck ALL DX9 parts announced/available support PSM. Again, PSM is a "required feature set". It is the basic feature wrt shadows in 3DMark05.
DST+PCF is not an "optional feature" to a lot of folks -- it is enabled by default and in the free version, which the majority of folks use, you have no way to disable it.
1) Read what FM said a year+ ago regarding the principle guidelines that I provided, which I'll repeat again in this post :
2) See what is the default for shadow rendering in 3DMark05 as released (i.e. DST+PCF is on by default).
3) All can see that with DST+PCF enabled, you WILL NOT GET (to quote FM's own "principle guidelines" for 3DMark05) "AN IDENTICAL RENDERING ON ALL HARDWARE WITH THE REQUIRED FEATURE SET. THIS IS TO ENSURE THAT THE PERFORMANCE MEASUREMENT IS RELIABLE AND COMPARABLE."
4) Note again the importance of what the "Default Settings" means.
Scali, you remind me a lot of Derek Smart when you post (you can take that as either a compliment or a jab) but I'll leave that aside for this one : Do you now see why me/Dave/Beyond3D is pissed about this especially when we agreed to participate in the BDP based on such "principle guidelines" set by Futuremark themselves?
Do you understand the importance of the "Default Settings" in 3DMark05? It is this that I/Dave/B3D is pissed about, not whether DST+PCF is an implemented feature (which I have said that if you want PSM, then it is a good thing).
DST+PCF has to do with PSM that FM implemented. Hence, PSM is itself a "required feature set" (and not necessarily the addition of DST+PCF) -- both ATI's and NV's DX9.0 parts support PSM. Heck ALL DX9 parts announced/available support PSM. Again, PSM is a "required feature set". It is the basic feature wrt shadows in 3DMark05.
DST+PCF is not an "optional feature" to a lot of folks -- it is enabled by default and in the free version, which the majority of folks use, you have no way to disable it.
1) Read what FM said a year+ ago regarding the principle guidelines that I provided, which I'll repeat again in this post :
Futuremark said:
2) See what is the default for shadow rendering in 3DMark05 as released (i.e. DST+PCF is on by default).
3) All can see that with DST+PCF enabled, you WILL NOT GET (to quote FM's own "principle guidelines" for 3DMark05) "AN IDENTICAL RENDERING ON ALL HARDWARE WITH THE REQUIRED FEATURE SET. THIS IS TO ENSURE THAT THE PERFORMANCE MEASUREMENT IS RELIABLE AND COMPARABLE."
4) Note again the importance of what the "Default Settings" means.
Scali, you remind me a lot of Derek Smart when you post (you can take that as either a compliment or a jab) but I'll leave that aside for this one : Do you now see why me/Dave/Beyond3D is pissed about this especially when we agreed to participate in the BDP based on such "principle guidelines" set by Futuremark themselves?
Do you understand the importance of the "Default Settings" in 3DMark05? It is this that I/Dave/B3D is pissed about, not whether DST+PCF is an implemented feature (which I have said that if you want PSM, then it is a good thing).
Reverend said:
I believe we are talking about hardware features here. PSM is a rendering method, not a hardware feature. DST+PCF are hardware features, which can be applied to the PSM rendering method. But they are not required for the PSM rendering method.
They are optional hardware features, in the way that they are not required to make 3DMark05 run, unlike for example SM2.0 support.
Which depends on how 'required featureset' is to be interpreted.
I have seen why you are pissed all along. But as I say, I am not sure if your interpretation is the one that FM meant. With the alternative interpretation that I presented, your statements would be in an entirely different light (not saying that my interpretation is the right one, you'll have to ask FM).
Yes, and as I said before, 3DMark's game tests are not about apples-to-apples testing, but about predicting in-game performance. The feature tests are apples-to-apples (why haven't you made any fuss about the fact that some cards use SM3.0 while others use SM2.0 in the same game tests?).
This goes for 3DMark03 aswell, where game tests could run either a ps1.1 or ps1.4 path, on hardware from the same generation, but from different IHVs.
And for 3DMark2000/2001 where non T&L hardware had to run CPU-based T&L where T&L hardware used a hardware T&L path by default, but could be forced to run software T&L if required.
And there are probably other examples of how game tests weren't apples-to-apples, but feature tests generally were (with the exception of T&L vs non-T&L I suppose).
Of course it was. Especially in light of the post a few posts above, where most people will only be able to run the default modes.
- Status
