How Cg favors NVIDIA products (at the expense of others)

[Gollum]

I think we continue jumping ahead of the game too much, most of the concerns about things that might happen in the future make sense of course, but I think it's just not yet possible to predict any of what will happen accurately enough, not in a way that justifies the scepticism towards the whole Cg move based on such vague speculation. It's good to question Nvidia's motives, but the stories about how they could use their leverage to take over the developers and industry are unrealistic IMO.

The CG language is currently still controled by Nvidia alone, yes, but I don't agree that this automatically implies Nvidia will only adopt what is within their own interest, or rather that they will be able to do so. They might not do this out of their own free will, but will be forced to do so! After all if Nvidia wants Cg to have any success watsoever, they will need to please the developers, I think that is forgotten too often.

It's not just about Nvidia, ATi or some other company. Developers themselves are a huge crowd and what this is all about after all. Developers however are certainly not going to sit idle while Cg only supports Nvidia features, or neglect other features Nvidia might not have, at least not for long! They want their games to run on as much hardware as possible, as fast as possible (exclude the occasional developer that is paid off to produce IHV specific demos).

Lets say the new S3 graphics core in spring has some incredibly cool and flexible PS pipeline that could be taken advantage off through DX9.1b, and this new core finds wide adoption due to its 75$ retail price. Developers will demand of Nvidia to add support for that to Cg (if it can't be directly adressed without changing the language specs slightly) or include the optimizations in the compiler (if S3 is unable to, IMO it would be their job in this case). If Nvidia continues to ignore such requests, or is generally unresponsive to concerns, then developers will drop Cg as a development platform faster than a Rockstar drops his girlfriend!

Yes, Nvidia might try to slow down adoption of competitor-specific extensions, or tweak produced code through their compiler more for their own hardware, but the language itself is generic enough to make it hard for Nvidia to throw huge rocks in the way of anybody. With much of Cg open source (plus documentation, plus maybe even more will be open sourced in the future) it now mainly is a question wether IHVs will invest the resources to write their own Cg compilers. In the end its still the developers that count most, if Nvidia doesn't look after them properly (although in the past they showed that they actually do care about developers) and try to make them happy, Cg will fail, its ultimately them who have the control.

All IMO of course...

Russ, sorry that this is not so much technical...

edit: corrected some typos, changed a sentence that said something I meant differently and added one

 

[RussSchultz]

My point is that it seems clear other HLSLs have a clear road of evolution to adapt to this

Where is that clear? Do we have any real clue as to what other HLSL are out there and how they will handle graceful degradation of support?

 

[Hellbinder]

I have decided to try one last time...

Here is the crux of the issue. 99% of development platforms are based on Nvidia products. We have already seen many games come out that are codded to use special Nvidia features Like Dronzmark etc. Features that do exsist on other cards but the developer only supported the specific Nvidia extension Etc Etc...

Fast forward.. Many of the effects that were accomplished this way in the past will now be sccomplished by various shader programs. Programs developed on Nvidia hardware with Nvidia Cg. Nv30 can execute 1024 instructions in a single cycle. R300 can do 160 instructions in a single cycle, however their shader can "loop" back through the shader pipeline once doubbleing to 360. to do this though you sacrifice speed.

This is what I was getting at. SIS, ATi all the rest FOLLOWED the OpenGL 2.0 and DX9 specs just as every card from every company has going all the way back several years. However this has all changed now. the Nv30 went far beyond the DX9 spec. Thus you can Write a shader routine that runns FASTER on the Nv30 than the R300 even though the game says DX9 on the box.. You guys all need to step back and look at the big picture. Corperations and Businesses do not do charity work for their competitors. Who will end up getting blamed for the poor performance? thats right all the other companies.... so go buy and Nvidia card or suffer lower performance etc... These things are all linked together you cannot seperate them. When was the last time you saw a game company say anything other than "this game optomized for Nvidia" Or gone to a dev forum and not saw poor performance blamed on everything else other than the fact that they coded the game on an NVIDAI board using Nvidia extensions etc.. Tribes 2 is a prime example of this.

Chalnoth himself said this more than once recently.. The R300 has not gone far enough... Etc etc etc.. Even though it follows the DX9 spec to the letter.. suddenly it became... the _minimum_ Dx9 spec.. Even to the point he stated that it was not a *true* dx9 card....

I totally agree than the short term aspect of this does not look like it has any bad side to it. I just think that most of you are forgetting (because you are technical people) to step back and look at the big picture.. Why would any competative hardware company release something that benefited its competitors in the long run.. Bottom line? this is america fellas, this is big buisness.. survival of the fittest.. They wouldn't.

Like I said its about the pairing of Cg with the hardware, Both having Nvidia name, with Nvidia sending out little *PDF* docs they are famous for.. talks on the phone with the tech support people.. Its an entire package. Anyone who loves Nvidia will not see any problem with this.. as they shouldn't.. its a brilliant plan.

 

[DemoCoder]

HellBinder, when will you realize that "ATI and all the rest" did not follow the DX9 spec when designing their card. The DX9 spec followed their design. If they had waited until DX9 had been finalized (it has changed alot over the past year), the R300 would have been shipping in 2004.

Secondly, you still don't seem to "get it" That Cg is high level and not attached to a particular card, and thirdly, no game developer is going to write shaders that are > 160 instructions long, or probably > 32 instructions for that matter!

Length = performance. The fact that the NV30 can execute 1024 pixel shader instructions is frankly, irrelevent. Multipass or no multipass, IT WILL BE SLOW.

Don't you remember how Carmack used PS1.4 with Doom3 to render in less passes than the GF4, but the GF4 still beat the 8500 using multipass?


You are speculating in total and utter absense of information. You have zero information on the difference between DX9 HLSL and NVidia Cg, and you have zero information on how fast NVidia's pixel shader unit can execute such programs.

 

[pascal]

Little conspiracy theory:

If I were nVidia I would first make everybody use Cg because I am a nice guy

and Cg is so cool.

After that I would release a hell fast, advanced and optimized Cg to the metal compiler for my chips in the windows environment. My boards vendors will be able to use the Cg logo in the 3Dcard Box. The games optimized/compiled with Cg will be able to use the logo too in the games Box (remenber Glide). It can take some time but is a nice try

I dont care about Cg, RenderMonkey, M$ HLSL. Again and again I wish we have an open standard HLSL and basic tools/formats.

The internet TCP/IP is a good example of what can an open standard do and its potential impact in the world (where is Decnet, SNA, IPX, Vines, etc..?).

 

[RussSchultz]

All except decnet were lan protocols (I think, anyways)

 

[pascal]

SNA is IBM long distance but is not routable. Many banks use it for ATMs.
DECnet was the best but...

 

[DemoCoder]

Although I have nothing against "tools" such as Cg, someone wanted a technical answer, so I'll give a technical example-

The following Cg code:
----------------------

#pragma bind appin.Position = ATTR0
#pragma bind appin.Normal = ATTR2

struct appin : application2vertex  {
      float4 Position;
      float4 Normal;
};

#pragma bind vertout.HPosition = HPOS
#pragma bind vertout.Color0 = COL0

struct vertout : vertex2fragment  {
    float4 HPosition;
    float4 Color0;
};

#pragma bind main.ModelViewProj = C 0
#pragma bind main.ModelViewIT = C 4

vertout main( appin In,
                     uniform float4x4 ModelViewProj,
                     uniform float4x4 ModelViewIT,
                     uniform float4 LightVec)  {
     vertout Out;
     Out.HPosition = mul(ModelViewProj, In.Position);
     float4 normal = normalize(mul(ModelViewIT,In.Normal).xyzz);
     float4 light = normalize(LightVec);
}

---------------

Compiled and linked... will only run on NVxx chipsets. As developers are handed the compiler and back-ends and told to "go to town"- the end result cannot be used on ATI, Matrox, P10 or any other chipset except NVIDIA's.

Pretty simple.

Also, pretty wrong. I doubt your example will compile AT ALL. NVidia's current generic backend could easily produce DirectX8 vertex shader code for this or ARB_vertex_program. The translation would look something like (non optimal, by hand)

// Out.HPosition = mul(ModelViewProj, In.Position);
dp4 oPos.x, c0, v0
dp4 oPos.y, c1, v0
dp4 oPos, c2, v0
dp4 oPos.w, c3, v0

//mul(ModelViewIT,In.Normal)
dp4 r1.x, c4, v2
dp4 r1.y, c5, v2
dp4 r1.z, c6, v2
dp4 r1.w, c7, v2

//normalize xyzz
dp4 r2, r1.xyzz, r1.xyzz
rsq r2.x, r2
mul r1, r2.x, r1.xyzz

//light = normalize(lightvec)
dp4 r2, v3, v3
rsq r2.x, r2
mul r3, r2.x, v3

// now I assume you want to do something with the light vec, like calculate diffuse and specular, or pass to pixel shader, otherwise this shader wastes the calculation

This shader could basically run DX7 hardware as well, since it is very close to fixed function capability.


Still waiting for a Cg shader that can't be expressed as DX9/OGL2.0 or can't run on other hardware.

 

[Basic]

How Cg favors ...

I hope a small set of people (from both "sides") will get banned, and until then I will avoid to give amunition that can be used by anyone of them.

I can however say to you that:

There are differences between NV30 and R300 PS, some are:

It seems as NV30 doesn't have the offset and scale modifiers any more. (At least scale modifiers are less usefull after going from fixed to floating point.)

NV30 can do swizzles in PS. (Something I've actually missed.)

So a Cg PS shader with swizzles would be, if not impossible, at least MUCH more difficult for R300. (I have no doubt that it will be possible to use swizzles in PS in some version of DX9.)

 

[DemoCoder]

Re: How Cg favors ...

I can however say to you that:

There are differences between NV30 and R300 PS, some are:

It seems as NV30 doesn't have the offset and scale modifiers any more. (At least scale modifiers are less usefull after going from fixed to floating point.)

NV30 can do swizzles in PS. (Something I've actually missed.)

So a Cg PS shader with swizzles would be, if not impossible, at least MUCH more difficult for R300. (I have no doubt that it will be possible to use swizzles in PS in some version of DX9.)

This is a DirectX9 requirement, not an NV30 requirement. As per the last DX9 pixel shader docs:

1) complement, bias, and shifting removed
2) arbitrary swizzle added
3) can still negate
4) output saturation still available


If the R300 doesn't do arbitrary swizzles in the pixel shaders, it is not DX9 PS2.0 compliant. OpenGL 2.0.3DLabs also allows arbitrary swizzle. If R300 doesn't support this, they are in trouble.

In any case, it can be accomplished in DX8 via the following sort of hacks
(this one demos .bgra)

use texreg2ar to lookup A,R into a 2D tmap and return 0,0,R,A
use texreg2gb to lookup G,B into a 2D tmap and return B,G,0,0
add together to get B,G,R,A

(Edit)
I just thought of another hack to do it with color ops and no textures. Assume color is in r0

mov r1.b, r0.a (alpha replicate)
mov r1.g, r0.r (red replicate)
mov r1.r, r0.g (green replicate)
mov r1.a, r0.b (blue replicate)

Of course, it's debatable whether burning 2 texture stages or 4 color stages is better.

 

[pascal]

Re: How Cg favors ...

So a Cg PS shader with swizzles would be, if not impossible, at least MUCH more difficult for R300. (I have no doubt that it will be possible to use swizzles in PS in some version of DX9.)

Do you have a link for it?
What could be the possible impacts and how?
Thanks

 

[Gollum]

Sorry to interrupt the ongoing programming/feature discussion.
For starters I will repeat my previous post's point, in regard to Hellbinder's post:

Developers HAVE to make money, they HAVE to make sure their stuff runs well on as much hardware as possible, that's not gonna change overnight, and not in the long run either as far as I can see. What some here suggest might happen [horrible future of all games running worse on any non-Nvidia platform], can frankly, NEVER happen, at least not as a result of the current market situation. This is a whole complex market with an incredible amount of players, variables and constants, don't make it simpler than it is. Cg is only an insignificant small part of this market, for some reason blown way out of proportion, mostly by its opponents. No matter what Nvidia might try to pull off with Cg, at the time DX9 even becomes a standard target platform, we will have seen new generations of hardware, APIs, HLSLs, whatever, the situation will be so different that e.g. those few additional NV30 features will not matter at all anymore! If for some unimaginable reason we end up with Nvidia monopoly down the road, it will be because the other IHVs have screwed up, not because of Nvidia playing dirty tricks with Cg, its too insignificant an influence for that. Let the market regulate itself I say, it's done just fine till now without people jumping to its rescue, spamming forums along the way...

Those constantly arguing how incredibly good or bad Cg can be should just take back a step and relax. Some people are being overly pessimistic and paranoid, others (though fewer) are too enthusiastic. Overestimating Nvidia and most importantly underestimating developers and consumers is not helping anyone either.

All IMHO of course, feel free to disagree or correct me.
Now making room again for one of the few technically interesting discussions today that just started going on here...

 

[demalion]

My point is that it seems clear other HLSLs have a clear road of evolution to adapt to this

Where is that clear? Do we have any real clue as to what other HLSL are out there and how they will handle graceful degradation of support?

Hmm, within the syntax of the REST of my post it seems pretty clear to me what that statement means. I could requote it here for clarity but, you know where to find it since you snipped that bit out of it. In short, the answer is provided in the rest of my text that expands upon that statement, and your point wasn't just about degradation, but about degradation in a scenario where a more advanced hardware implementation required a new "high" target for the HLSL.

I'm still waiting for a response from DemoCoder concerning the questions I raise and my argument as to why the expectation he/she has that others invent and prove a concept that might not be exposed within Cgs current specs is a fallacy, and why instead it seems more reasonable and necessary to prove why it is NOT possible to have a feature that cannot be exposed in Cg, or that nVidia cannot block the adaptation of Cg to such features. I fear at current I'm relegated to the label "anti-Cg" and my points are being ignored, which would beg the question as to how that is any more productive than "fanboys" ranting and ignoring someone else's points.

 

[Deflection]

This is what I was getting at. SIS, ATi all the rest FOLLOWED the OpenGL 2.0 and DX9 specs just as every card from every company has going all the way back several years. However this has all changed now. the Nv30 went far beyond the DX9 spec. Thus you can Write a shader routine that runns FASTER on the Nv30 than the R300 even though the game says DX9 on the box..

That paragraph is just asinine. Why shouldn't developers have a chance to do so if Nvidia provides it to them?

CG Language is open-sourced.

1) To me it seems clear that the NVIDIA CG COMPILER in the future will be able to optimize to an NVIDIA card. Great, faster game for Nvidia!

2) If developers like coding in CG. What is to prevent ATI from writing their own optimized CG compiler that may link ATI specific libraries or generate optimized towards ATI routines? Great, faster game for ATI!

3) Why shouldn't a company be able to optimize to their card. There will still be a base CG shader code that a developer could write that will work on both platforms and will compile under both compilers. It is the developer's call to choose what to code. In fact the developer could presumably include both optimized versions or none.

4) (Possible reason for CG) Could NVIDIA be promoting CG so that they can create an optimized compiler? Something that they could not do with DX or GL HLSL's? (I.E. there will be 1 and only 1 compiler that Microsoft will make for DX HLSL. MS will not allow other companies to create a compiler to optimize.)

Again the developer will decide to support these optimized compilers if they want to. What is wrong with that? Do you want your gaming experience limited to the lowest common denominator (Which unfortunately the Developers will choose most of the time anyway)?

 

[demalion]

Re: How Cg favors ...

So a Cg PS shader with swizzles would be, if not impossible, at least MUCH more difficult for R300. (I have no doubt that it will be possible to use swizzles in PS in some version of DX9.)

Do you have a link for it?
What could be the possible impacts and how?
Thanks

When does siggraph end? Supposedly Rendermonkey downloads will be available then and exploring this in a preliminary fashion should be a simple matter of implementing a test in...what...Renderman? And then compiling it with Rendermonkey and looking at the output.

 

[Basic]

DemoCoder:
You seem to be right.
I just hadn't seen any mention of swizzles in ATI docs. But since it's in DX9 there's no reason to think that it isn't in R300.

Btw, I knew they could do channel replicate, so it was the 4*color op trick I meant as much more difficult.

So to Pascal:
Well, read above.
The impact if it had been the case would still probably not be that big. When doing color operations the color components usually stay at their place. It's just when you do "strange stuff" that you could need swizzles.

The impact according to the people that would claim X is so superior, or Y is so evil, would of course be enormous.

I personally wanted them for image filtering operations where the four components of a pixel would be treated as a 2x2 matrix. Operations on that would of course need swizzles, but it's not realy the mainstream stuff.


Btw, the post above were meant to be a PM.

 

[Basic]

Demalion:
The simplest way would of course be to test it in Rendermonkey with a DX9 PS2.0 shader. That is if they can release a PS2.0 assembler directly after SIGGRAPH2002. It might only come with DX8 PS interface at the beginning since DX9 isn't released yet. (Just as you can't get NV30 profiles for Cg yet.)

 

[Sharkfood]

Also, pretty wrong. I doubt your example will compile AT ALL. NVidia's current generic backend could easily produce DirectX8 vertex shader code for this or ARB_vertex_program. The translation would look something like (non optimal, by hand)

Everyone, Democoder included, seemed to miss the point of my example.

Developer A downloads the Cg kit and bangs out some code. There is no compilation path for anything outside of an NVxx chipset at this time. There is no ATI compiler back end, no P10, nada.

It's a simple fact that no backends outside the NVxx version exist at this time. So a developer being pressured to use Cg, or deciding to use Cg limits it's usage to only NVxx target platform and nothing more at this time. Unless now you are going to tell me NVIDIA is certifying it's back-end compiler will produce R200/R300 working code...

The whole point is, NVIDIA is using a tactic that enforces an additional maintenance cycle upon other IHV's who are competitors. Like I said, I have nothing against tools- tools are great. But to label an exploit such as creating an additional maintenance cycle for other IHV's, which is the same thing as undercutting prices on the hardware itself below profit margin in order to compete, as "same" is ludicrous. Either way is the same as this route costs software maintenance schedules, and NVIDIA can pop in and make small derivations or changes to syntax that requires another maintenance software schedule for those participating if this goes "mainstream." This is the conflict of interest. It would be foolish for other IHVs to leap in and support Cg given this exploit, no matter how "generic" the language syntax itself may be.

I would simply challenge anyone who is going to label Cg as being non-NVIDIA specific to download and use the toolkit and produce code (without translation) to run on R200/R300, P10 or other IHVs products. If it doesnt in all cases, then the point still stands. ATI, 3DLabs, Matrox and anyone else is now stricken with the requirement to add another software maintenance team to not only write/design a back-end for this, but must do so by imposed schedule restrictions defined by NVIDIA.

Language syntax? I don't doubt the language syntax is fairly generic and can be used with multiple platforms but this remains to be seen. It wont be until several hundred Cg programs have been written, and back-end compilers for several chipsets are designed to run on this thing to exploit any possible selectivity of syntax that might exist *in it's current version* and then such an effort will be required with any future version with syntactical changes. The problem is, a very basic concept such as "testing proves the existence of bugs, not their absence" isnt being applied here. There is no 'burden of proof' to provide an example of the latter, at least as there is equal burden to prove the former. As no back-end compilers exist for other platforms, this is a con-man/strawman tactic of FUD.

 

[KimB]

I'd like to explore this further.

How will these HLSL accelerate the useage of new features? Granted, it might make some effects prettier. But how will it allow new features easier and or more widespread?

Obviously, it cannot significantly accelerate the usage of all new features.

But, here are some examples of things that can be accelerated:

1. New programmability function A is implemented in hardware next year. This function is basically an accelerated version of what we had before, or a higher-precision version.

As an example, let's just say, for argument's sake, that the exponential function (e to a power) is implemented by a rudimentary approximation in DX8 hardware that uses a number of instructions to pull off. However, DX9 hardware as an optimized path that quickly and accurately calculates the exponential. You could use the same code in either case, but it would be faster and more accurate on the DX9 hardware, automatically using the new feature.

2. Reduced time to develop new shaders. HLSL's, obviously, make new shaders easier to program. Since artists should probably be the ones doing most of the shaders, it just makes sense that the shaders should be as simple to program as is humanly possible. HLSL's are a step in this direction, and may make it relatively easy for artists to write HLSL shaders that compile to rather long assembly-language shaders.

An example of this might be that Bob, an artist/programmer, wants to use a certain shader for water, but not even DX9 hardware has enough flexibility to do it. Bob can write the shader anyway, put it into the game, and just hope that he can very easily enable it later on a patch, or late in game development. In the meantime, Bob goes ahead and makes some fallback shaders for DX8 and DX9 hardware.

The second one is very hypothetical, and I rather doubt it will come into much use, and if it is used, it will probably result in less-than-optimal performance (Imagine trying to figure out how to program optimally for hardware to be released 1-3 years from now...can't be done...). But the first one is quite likely, and developers may discover pretty quickly that a number of functions in Cg just don't run quickly or produce accurate results in DX8, or perhaps even DX9, hardware. Later hardware may then be able to make up for these shortcomings and produce much better results just by installing the new compiler (which would presumably be included in nVidia's drivers...in an optimal scenario).

Obviously, all of this is just a possibility, not a certainty. And every HLSL should have this same potential.

 

[KimB]

Lets say the new S3 graphics core in spring has some incredibly cool and flexible PS pipeline that could be taken advantage off through DX9.1b, and this new core finds wide adoption due to its 75$ retail price. Developers will demand of Nvidia to add support for that to Cg (if it can't be directly adressed without changing the language specs slightly) or include the optimizations in the compiler (if S3 is unable to, IMO it would be their job in this case). If Nvidia continues to ignore such requests, or is generally unresponsive to concerns, then developers will drop Cg as a development platform faster than a Rockstar drops his girlfriend!

It would be up to S3 to release a backend that would compile to their hardware.

Additionally, if Cg can compile to both DX8 shaders and DX9 shaders, I see no reason why it couldn't compile to any other hardware that at least supports the DX8 spec. Also provided that nVidia has made it relatively easy for anybody else to add their own new functions to their version of the compiler, there is no reason why other IHV's couldn't get optimal usage out of Cg.