Rightmark3D
- Thread starter Lezmaka
- Start date
Doesn't work properly here.
The synthetic tests have been available for some time, problem is that they load and run FOREVER.. and then when done they run freakking again with one settings changed.
Takes forever to complete the full suite of tests.
I dunno, not really worth much in it's current state and I agree Cg does not seem like a bright idea.
The synthetic tests have been available for some time, problem is that they load and run FOREVER.. and then when done they run freakking again with one settings changed.
Takes forever to complete the full suite of tests.
I dunno, not really worth much in it's current state and I agree Cg does not seem like a bright idea.
But... You people *do* realize many future games are going to use Cg, right? And what's the purpose of a benchmark such as RightMark, hmm?
I think you got my point
Oh, sure, I agree using Cg for every benchmark wouldn't make sense - heck, many games also aren't going to use Cg - but as long as only a few benchmakrs use it, I don't see the problem.
Uttar
I think you got my point
Oh, sure, I agree using Cg for every benchmark wouldn't make sense - heck, many games also aren't going to use Cg - but as long as only a few benchmakrs use it, I don't see the problem.
Uttar
Weeee. Lets start this fight up again.
Uttar said:But... You people *do* realize many future games are going to use Cg, right? And what's the purpose of a benchmark such as RightMark, hmm?
I think you got my point
Oh, sure, I agree using Cg for every benchmark wouldn't make sense - heck, many games also aren't going to use Cg - but as long as only a few benchmakrs use it, I don't see the problem.
Uttar
Fine use Cg for a benchmark but then they shouldn't claim to be so independent, the whole site sorta contradicts tthe fact that they are using a vendor specific compiler which nVidia themselves says outputs nV optimized code.
Xmas said:
Err, for fear of shoving my foot in my mouth here somehow.... If DX9 uses PS 2.0 and all PS 2.0 can do PS 1.4 then Cg should be able to do PS 1.4 correct? A fully complient DX9 HLSL is compatible with PS 1.4 but Cg is not. Does Cg support PS 2.0? If it does then it should as well support PS 1.4. Bah maybe I am getting a few things mixed up.
At this point I will make the same sort of disclaimer that Ratchet made only with the suggestion that I know even less then him..
Well, when I see a vendor specific technology in a benchmark app (or used to create a benchmark app, in this case), then I can only assume that said app is optimized for said vendor. The results will obviously be skewed toward the vendor with the optimizations, therefore, what would be the point of using the benchmark to compare one vendors products to anothers? It just doesn't seem "Right" to me...Xmas said:
I don't know what kind of shaders they're using, but if there is one single shader that requires PS 2.0 and has no fallback in a test, then there is no point in supporting PS 1.4 for it.Ichneumon said:
I don't know how far MS has come, but the first DX9 HLSL compiler didn't support PS1.4, too. And the current version still doesn't fully support it AFAIK.
That's only because eNVIDIous and Micro$oft are in cahoots.
Plain as day.
Plain as day.
Here are some points for discussion on Cg:
The first prevents all R200 and RV2x0 cards from exposing anything but PS 1.3. This precludes expanded dynamic range, flexibility, and shader length. nVidia has said they will deliver this, but to my knowledge they still have not, and I have a more than slight distrust of their intention to actually do so.
The second allows the nv30 to compete. The only problem I have with this, besides where it concerns the other two factors noted, is that it can cause development decisions to be made for performance on the nv3x that are not pertinent at all the R300 and future cards...basically independently forcing a non standardized least common denominator instead of the PS 2.0/ARB_fragment_program the industry agreed upon and we were expecting. Now, the real problem is not when this is done in addition (why screw over nVidia card owners if you don't have to?), but when this is done instead of implementing to PS 2.0 specifications. EDIT: this is also depending on the final outcome of WHQL certification on how Cg interacts with the drivers when executing "PS 2.0", or when using OpenGL and considering ARB_fragment equivalent to "PS 2.0" and the nv30 extension "integer PS 2.0"
The third is a pervasive problem. For instance, the R300 performance is optimized for scalar/3 component vector execution with texture ops simultaneously dispatched, while this emphasis absolutely chokes the nv30, especially if floating point is needed. Under DX 9 HLSL, the output is optimized to the spec, which the IHVs can then anticipate and optimize for, but for Cg, the output is optimized to the nv30's special demands, and this can, and has, resulted in "LLSL" that is distinct. They say they aren't bypassing the API, but they do exactly that with regards to DX 9 HLSL.
It might be a simple matter for nVidia to effectively optimize for this resulting code (and they of course have a vested interest in doing so and control what the code looks like), but other IHVs would have to do new work to either optimize with the different Cg "standardized" profile output's high level optimizations (or lack of them) in mind, repeat the work that Microsoft already did and come up with their own optimized DX 9 "equivalent" HLSL compiler (if they've already optimized for DX 9 HLSL output, this doesn't make much sense unless you want to spend time and effort to specifically hand over control to your direct competitor
), and trust in nVidia's good intentions with regards to the future work for this they'd have to do. Seems a bit silly for nVidia to expect other IHVs to do that work for them as it suits their goals.
None of those options make sense to me, and I suspect to any IHV with an architecture dissimilar to the nv30's (which I'd guess is all other vendors, but it is conceivable that someone could have made similar choices) with nVidia's level of control over language evolution, so it seems to me that the burden for Cg to be useful as other than as a tool to impede other IHVs, while easing things for nVidia, falls to nVidia themself. That is to say, they need to settle with benefiting themself instead of both benefiting themself and simultaneously maintaining a level of control that disadvantages other IHVs, as it is their own hardware that requires deviation from the standard (downwards) to perform well.
What could they do? Well, they could make the Cg standard output identical to DX 9 HLSL shader output and support all its targets (i.e., effectively be the DX 9 HLSL compiler for anything except the nv3x cards within the Cg development environment), or they could encourage developers to code to DX 9 standard HLSL, and then promote Cg as the "nVidia specific" DX 9 HLSL to code to in addition (this still seems a possible outcome, and hopefully they'll be forced to settle for this at most by the market without too many deviations in the interim).
Now, this is what they imply they are encouraging when Cg is challenged as undesirable, and what I hope market realities will force developers to do, but this does not fit what I see them as doing in actuality (lip service is cheap)...avenues of Cg promotion appear to be to foster it as replacement environment for developing instead of using DX 9 HLSL and its compiler, and I don't see any indication (yet) that they have plans to facilitate the use of the DX 9 HLSL compiler on their "identical" code from within their Cg development toolset. Seems trivial to implement (if they're really committed to maintaining the specification compatibility to DX 9 HLSL), so I'm concerned as to why I see only nVidia's compiler output mentioned when discussing DX targets from Cg.
There are options developers can use that aren't negative to everyone besides nVidia...like the option mentioned above for coding for DX 9 HLSL (the standard), and then supporting Cg (even though it doesn't seem identical, adjustment should be trivial, though getting similar performance might be difficult sometimes for the current nv3x cards) for nVidia cards afterwards. If nVidia devrel is assisting in time used for the last part, I don't see any significant disadvantage to this. I do think it is incompatible with how I perceive developers are "supposed" to utilize Cg tools and interact with nVidia developer relation initiatives as actually implemented...for instance, a developer who decides on Cg based on proported equivalence to DX 9 HLSL is strongly dissuaded from exploring the possibilities of PS 1.4 shaders as an option, and will continue to be until nVidia provides an effective PS 1.4 solution (including recognizing competitors capabilities for it) or coerces other IHVs to provide one by their refusal to do so after success in gaining developer adoptation of Cg, and thereby facilitating the disadvantages for IHVs other than nVidia that situation entails
Also, there are other options (that benefit nVidia, but not exclusively them) open to nVidia from their standpoint, like designing future hardware to offer performance when following API specifications (I've considered that the nv30 had broken floating point support in register combiners and thus might be fixed quickly, but this doesn't seem as likely at present), or actually achieving the things I propose above and meaning the things that they imply about Cg's "open" intent. This seems likely to me only if nVidia is forced to by the marketplace (with the R300 lead time, I hope this is the only avenue of success for Cg) or if Cg is still around when their hardware has improved to be able to compete well in standard API paths, which, unless the nv35 is "nv30 with the fix of floating point register combiners", I don't think is remotely possible any time soon.
- Does not output PS 1.4
- Does output an "integer PS 2.0"
- Outputs code suited for nVidia's own low level shader/"assembly" optimizer
The first prevents all R200 and RV2x0 cards from exposing anything but PS 1.3. This precludes expanded dynamic range, flexibility, and shader length. nVidia has said they will deliver this, but to my knowledge they still have not, and I have a more than slight distrust of their intention to actually do so.
The second allows the nv30 to compete. The only problem I have with this, besides where it concerns the other two factors noted, is that it can cause development decisions to be made for performance on the nv3x that are not pertinent at all the R300 and future cards...basically independently forcing a non standardized least common denominator instead of the PS 2.0/ARB_fragment_program the industry agreed upon and we were expecting. Now, the real problem is not when this is done in addition (why screw over nVidia card owners if you don't have to?), but when this is done instead of implementing to PS 2.0 specifications. EDIT: this is also depending on the final outcome of WHQL certification on how Cg interacts with the drivers when executing "PS 2.0", or when using OpenGL and considering ARB_fragment equivalent to "PS 2.0" and the nv30 extension "integer PS 2.0"
The third is a pervasive problem. For instance, the R300 performance is optimized for scalar/3 component vector execution with texture ops simultaneously dispatched, while this emphasis absolutely chokes the nv30, especially if floating point is needed. Under DX 9 HLSL, the output is optimized to the spec, which the IHVs can then anticipate and optimize for, but for Cg, the output is optimized to the nv30's special demands, and this can, and has, resulted in "LLSL" that is distinct. They say they aren't bypassing the API, but they do exactly that with regards to DX 9 HLSL.
It might be a simple matter for nVidia to effectively optimize for this resulting code (and they of course have a vested interest in doing so and control what the code looks like), but other IHVs would have to do new work to either optimize with the different Cg "standardized" profile output's high level optimizations (or lack of them) in mind, repeat the work that Microsoft already did and come up with their own optimized DX 9 "equivalent" HLSL compiler (if they've already optimized for DX 9 HLSL output, this doesn't make much sense unless you want to spend time and effort to specifically hand over control to your direct competitor
), and trust in nVidia's good intentions with regards to the future work for this they'd have to do. Seems a bit silly for nVidia to expect other IHVs to do that work for them as it suits their goals.None of those options make sense to me, and I suspect to any IHV with an architecture dissimilar to the nv30's (which I'd guess is all other vendors, but it is conceivable that someone could have made similar choices) with nVidia's level of control over language evolution, so it seems to me that the burden for Cg to be useful as other than as a tool to impede other IHVs, while easing things for nVidia, falls to nVidia themself. That is to say, they need to settle with benefiting themself instead of both benefiting themself and simultaneously maintaining a level of control that disadvantages other IHVs, as it is their own hardware that requires deviation from the standard (downwards) to perform well.
What could they do? Well, they could make the Cg standard output identical to DX 9 HLSL shader output and support all its targets (i.e., effectively be the DX 9 HLSL compiler for anything except the nv3x cards within the Cg development environment), or they could encourage developers to code to DX 9 standard HLSL, and then promote Cg as the "nVidia specific" DX 9 HLSL to code to in addition (this still seems a possible outcome, and hopefully they'll be forced to settle for this at most by the market without too many deviations in the interim).
Now, this is what they imply they are encouraging when Cg is challenged as undesirable, and what I hope market realities will force developers to do, but this does not fit what I see them as doing in actuality (lip service is cheap)...avenues of Cg promotion appear to be to foster it as replacement environment for developing instead of using DX 9 HLSL and its compiler, and I don't see any indication (yet) that they have plans to facilitate the use of the DX 9 HLSL compiler on their "identical" code from within their Cg development toolset. Seems trivial to implement (if they're really committed to maintaining the specification compatibility to DX 9 HLSL), so I'm concerned as to why I see only nVidia's compiler output mentioned when discussing DX targets from Cg.
There are options developers can use that aren't negative to everyone besides nVidia...like the option mentioned above for coding for DX 9 HLSL (the standard), and then supporting Cg (even though it doesn't seem identical, adjustment should be trivial, though getting similar performance might be difficult sometimes for the current nv3x cards) for nVidia cards afterwards. If nVidia devrel is assisting in time used for the last part, I don't see any significant disadvantage to this. I do think it is incompatible with how I perceive developers are "supposed" to utilize Cg tools and interact with nVidia developer relation initiatives as actually implemented...for instance, a developer who decides on Cg based on proported equivalence to DX 9 HLSL is strongly dissuaded from exploring the possibilities of PS 1.4 shaders as an option, and will continue to be until nVidia provides an effective PS 1.4 solution (including recognizing competitors capabilities for it) or coerces other IHVs to provide one by their refusal to do so after success in gaining developer adoptation of Cg, and thereby facilitating the disadvantages for IHVs other than nVidia that situation entails
Also, there are other options (that benefit nVidia, but not exclusively them) open to nVidia from their standpoint, like designing future hardware to offer performance when following API specifications (I've considered that the nv30 had broken floating point support in register combiners and thus might be fixed quickly, but this doesn't seem as likely at present), or actually achieving the things I propose above and meaning the things that they imply about Cg's "open" intent. This seems likely to me only if nVidia is forced to by the marketplace (with the R300 lead time, I hope this is the only avenue of success for Cg) or if Cg is still around when their hardware has improved to be able to compete well in standard API paths, which, unless the nv35 is "nv30 with the fix of floating point register combiners", I don't think is remotely possible any time soon.
Xmas said:
That's self fulfilling...if there is no fallback, it is by definition not using PS 1.4. The developers have absolute control over the shader selection at this time.
If it is a Cg benchmark, it is a Cg benchmark, but that's what it should be called because that really is not representative of DX 9's tools for achieving the same thing at this time. If it is a DX 9 HLSL and Cg benchmark, that's even a good thing I think. I actually think this is quite possible, since I seem to remember PS 1.4 support in the prior releases.
However, what I'm concerned about is a "DX 9 and Cg" (note the significance of the absent HLSL, which nVidia seems to try and imply even when the actual DX 9 HLSL is replaced by Cg) benchmark, which is just a way of saying it supplants the HLSL for other vendors already implemented and being evolved, with the one nVidia provides now and demands that other vendors re-implement to be on a level playing field. That's just making others adapt to their standard instead of them adapting to the existing one that already recognizes other interests besides nVidia's. Note, that I'm not necessarily applying this label to Rightmark since I haven't checked for myself, but to address some comments being made.
Well, this is Microsoft's stated intent, and I don't have reason to doubt it at this time. Perhaps someone with experience with the latest SDK can answer your specific question.
You can have HDR in PS1.1, too. Additionally, the compiler doesn't even have to support it explicitly. Constants are limited to [-1, 1] in PS 1.x, and all other calculations' precision or range does not affect the compiler.demalion said:
But it's not an issue here because it only works in OpenGL.
What is "optimized to the spec"? There is no defined "best" way to write an assembly shader, the only obvious optimization being using as few instructions as possible (which may sometimes not be the best case for certain hardware). The drivers have to make the best out of the assembly shaders by reordering and pairing instructions, regardless of whether the shader was written in assembly, HLSL or Cg.
If Cg is used in a benchmark, it is considered "not right". What if a shader programmer came up with the same assembly code as the Cg compiler. The program would run executing the same shader code, in how far would that be better?
If Cg outputs better code than DX9 HLSL compiler, meaning it is faster on any hardware, should a benchmark still use DX9 HLSL to be more comparable?
As you can read here:Xmas said:
http://www.beyond3d.com/forum/viewtopic.php?t=5150
The NV30 is very sensitive, e.g. the more registers are used the slower it gets and profits from mixing the shaders with integer stuff. The R300 has a totally different behaviour. It's in my opinion absolutely obvious that if you want to have a fair comparison you need to either write a shader without having any special hardware in mind. Or you have to adjust the shader so that it runs as fast as possible on both NV30 (by using as few registers as possible and mixing with integer stuff etc) and R300. If you write a shader with NV30 in mind it's still interesting to test it on R300 and vice versa. But it can't be used as a fair benchmark!
Maybe. But that doesn't mean that the driver can turn a NV30 optimized shader around and make it perform exactly as good as a R300 optimized shader would perform. Otherwise it would not make any sense that ATI was/is working hard on their own DX9 HLSL profile, or would it?Xmas said:
Correct. Because Cg is guaranteed to optimize the shader for best NV30 performance, while ignoring R300. How can that be fair? Again: It can be interesting to look at, but not fair as a benchmark.Xmas said:
That's highly unlikely, if you look at how careful you have to be to get halfway good performance out of the DX9 NV30 shaders.Xmas said:
*If*. Do you really believe that!?Xmas said:
As Xmas said: the only good guideline is: use as few instructions as possible. Rightmark is a DirectX 9.0 application, which comes with a completly standard ps_2_0 path, and this path does not include integer calculations. Cg absolutly CAN'T sneak ANY integer code into it! The same goes for ARB_fragment_program in OpenGL. The only place where Cg CAN sneak integer calculations is when you specify NVIDIA specifc target profile using NV_fragment_program in OpenGL (and it's output code doesn't work in ARB_fragment_program or pixel shaders 2.0 in DirectX).madshi said:
Also both DX9 HLSL and Cg do actually NEAD to use as few registers as possible. What will happen when they hit an upper limit for register count? Ok, we wasted one register there so we'll remove it now? Not that simple.
Both DX9 HLSL and Cg will use data type programmer tells them. If you are using float, they will output float. If you use half, they'll output half float instructions. If you use int they'll use int if it is availible on the platform (and it is not unless you go to NV_fragment_program).
There is ATI profile in DX9 HLSL? Where have you seen it?madshi said:Maybe. But that doesn't mean that the driver can turn a NV30 optimized shader around and make it perform exactly as good as a R300 optimized shader would perform. Otherwise it would not make any sense that ATI was/is working hard on their own DX9 HLSL profile, or would it?
The only one working on DX9 HLSL is Microsoft, all that IHVs do is tell them what kind of code they wish from DX9 HLSL.
I tend to think you CAN'T get good performance out of the DX9 NV30 shaders OK? And Cg can't help NVIDIA here.madshi said:
Now I haven't done much of extensive testing and all but from what I have seen CURRENT Cg and CURRENT DX9 HLSL are on par when it comes to shaders of usefull lengths for current hardware. I have also done a Cg shader for that Cg contest back last year that actually uses LOTS of instructions. When targeting ps_2_x DX9 HLSL compiles to about 350 instructions, while Cg runs out of registers. If I compile it for NV_fragment_program it is about 450 instructions long. But I'm sure next releases of Cg an DX 9 HLSL will still do better then this.madshi said:*If*. Do you really believe that!?Xmas said:
But most people dislike Cg because it's from NVIDIA. They haven't seen it, they haven't tried it, they haven't done extensive testing with both DX9 HLSL and Cg to determine which one outputs better code. How can you just claim that Cg outputs sucky code if you haven't seen what kind of code it outputs?
All in all Microsoft has an advantage as it has one of the best compiler writing teams in the world, but for OpenGL 2.0 every IHV will have to write their own compiler. With or without Cg...
