NVIDIA's Pixel & Vertex Shading Language

Barkhausen Criterion writes "NVIDIA have announced a high-level Pixel and Vertex Shading language developed in conjunction with Microsoft. According to this initial look, the "Cg Compiler" compiles high level Pixel and Vertex Shader language into low-level DirectX and OpenGL code. While the press releases are going amok, CG Channel (Computer Graphics Channel) has the most comprehensive look at the technology. The article writes, "Putting on my speculative hat, the motivation is to drive hardware sales by increasing the prevalence of Pixel and Vertex Shader-enabled applications and gaming titles. This would be accomplished by creating a forward-compatible tool for developers to fully utilize the advanced features of current GPUs, and future GPUs/VPUs." "

Comments

3dfx/Glide part 2?

[PackMan97]

Hopefully NVidia will be able to avoid the proprietary pitfall that ultimately doomed 3dfx and Glide.

From the story it sounds like NVidia will allow other cards to support Cg so maybe they can. However I wonder if ATI will be willing to support a standard which NVidia controls. It's like wrestling with a crocodile if you ask me!~

Re:3dfx/Glide part 2?

[Jucius Maximus]

"Hopefully NVidia will be able to avoid the proprietary pitfall that ultimately doomed 3dfx and Glide."

NVidia is avoiding at least one 3dfx pitfall ... their product is not simply a beefier version of the previous product (which in itself was a beefier version of the previous product (which in itself was a beefier version of the previous product (which in itself was a beefier version ... )))

Re:3dfx/Glide part 2?

[BWJones]

Hopefully NVidia will be able to avoid the proprietary pitfall that ultimately doomed 3dfx and Glide.

Given that it was nVidia that purchased 3dfx and brought along many of the employees, I should hope that there would be some internal discussion of this.

Re:3dfx/Glide part 2?

[SirSlud]

> like NVidia will allow other cards to support Cg so maybe they can

Um, well, Cg gets compiled to DirectX or OpenGL, so it follows that any card that can do DirectX or OpenGL (read: all of them?) will benifit Cg. I guess different cards to different levels of support, but if they want this to fly, itd be in their best interest to generate multi-card compatible code. Or at least allow you to specify what extentions your generated code will support, to tailer to specific card feature sets? Correct me if I'm confused, if anyone is really in the know.

I think the idea here is that you could use this language to write new shaders for cards on the market _now_ ... the gain is that it supports two targets (DX and OpenGL) and seems a significantly easier way of incorperating new shaders into games than current methods?

Re:3dfx/Glide part 2?

[Dark Nexus]

Well, they're quoted in this article on ZDNet (the quote is near the bottom) as saying that they're going to release the language base so other chip makers can write their own compilers for their products.

That was the first thing that popped into my head when I read this article, but it sounds like they're going to give open access to the standards, just not to the interface with their chips.

Re:3dfx/Glide part 2?

[dextr0us]

IF you would have read the article instead of just posting first, YOU WOULD READ THAT IT IS CROSS PLATFORM!

THE FIRST PARAGRAPH!

Graphics giant NVIDIA today announced Cg, an initiative with participation from Microsoft to create a cross-platform, hardware-independent, high-level Pixel and Vertex Shader programming language.

Re:3dfx/Glide part 2?

[JebusIsLord]

Argh this is such a common misconception. This is NOT A NEW, PROPRIETARY API like glide was, it is simply a high-level programming language that generates direct3d and opengl code so the programmer doesnt have to worry about it. This is fantastic! It also apparently will work fine with other chip architectures. Everyone wins!

Re:3dfx/Glide part 2?

[RAMMS EIN]

Compiling to OpenGL is about as hardware-independent as it gets. Compiling to both OpenGL and Direct3D shows the true power of a high-level language like Cg. This looks like a Good Thing to me.

Re:3dfx/Glide part 2?

[bokketies]

good for the open sorce OpenGL! NVIDIA is the nice companee launches the open sorce programing. I understend mane companees make mone from new Vertex Shader. Open sorce also?

Will compaled code faster then macheen code? NVIDIA has no expereens with compaler making. Right?

Excoos for speling. Thanks friends

Radjif.

Re:3dfx/Glide part 2?

[Anonymous Coward]

Sorry for the fact that I burst out in laughter after I read your post. Obviously you mean well, but should really improve your spelling capabilities :-)

But to answer your questions. Well... here at slashdot not everyone will be jumping with joy about the open source mindedness of Nvidia, but this seems a step in the good direction.

Furthermore, the compiled code will probably not be as fast as native code. But perhaps in time, when this gains momentum it will be close enough. Just like the fact that nowadays you have to be a real cowboy to outperform a C compiler.

Re:3dfx/Glide part 2?

[Salden]

How do you figure that Glide is what doomed 3dfx? 3dfx supported everything that nvidia supported PLUS glide. The only technical trouble they had was getting their windows 2000 drivers out the door. What doomed them was nVidia's rapid rollout cycle. They just couldn't keep up.

Re:3dfx/Glide part 2?

[super-flex-o-matic]

yeah but they are in the great position to prescribe the standards, aren't they?????????????????????

Re:3dfx/Glide part 2?

[supermoose]

The article claims it will be platform and hardware-independent, and that most of the compiler will be open-source. The NVIDIA folk also make the specific claim that stuff written for the Geforce chips should run on an ATI Radeon 8500.

Re:3dfx/Glide part 2?

[Rothron the Wise]

I don't see how this compares to Glide in any way.
Glide was irreversably linked to the hardware, as it was a paper thin API just consisting of some header files with function declarations that plugged straight into the hardware registers of the Voodoo-part.

You basically can't get any more low level, a design choice that made sense at the time where there was no 3D-API to speak of on the Windows platform, and CPUs were too slow to do fancy things in software.

Cg is almost the exact opposite. A generic language that compiles into hardware specific code. As more GPUs are supported by other compilers, it becomes easier for developers to write shaders that work everywhere. It's much like a C-compiler in the way that it lets you ignore some, but not all, of the HW-spesific issues.

Cg-compilation is fast and the compiler is small, so one could imagine pixel-shader source code being included in the product/game/whatever and
compiled for the specific hardware just before
runtime.

Re:3dfx/Glide part 2?

[cyborch]

with participation from Microsoft to create a cross-platform, hardware-independent,

It's funny how a language which only has a windows compiler (some .exe) can ever be called cross-platform!?!? It seems very much to me like this is NOT cross platform. I haven't actually run the Cg compiler (I couldn't afford a windows license just to try this compiler out...) so I cannot tell if the OpenGL code it generates is so full of nVidia extensions to be all but useless to anyone who wants to make an application that works for more cards than the ones from nVidia. But since the cross-platform statement is an obvious lie how can I trust that it will generate hardware independent OpenGL code?

Re:3dfx/Glide part 2?

[Anonymous Coward]

They've released a linux toolkit on the cg developer website.

News.com beat ya.

[aetherspoon]

News.com had this story for awhile.

My biggest question - from reading this, this would actually work correctly on other competing VCards... why did nVidia create it?

Re:News.com beat ya.

[brejc8]

If they didn't ATI would

Re:News.com beat ya.

[Merlin42]

'Cause 3Dlabs already created it ... see their OpenGL 2.0 proposal. My fear is this is _only_ a preemptive strike against the "full programability" of the 3dlabs P10 which will sooner or later have a consumer version. High level interoperating programability is very much needed to access the power of current and more complicated future cards.

Re:News.com beat ya.

[Anguirel]

"My biggest question - from reading this, this would actually work correctly on other competing VCards... why did nVidia create it?"

Simple - they want applications written to support vertex and pixel shaders... At this point, they're interested in market saturation. They need apps (mostly games) that use this technology in order to cause people to buy the cards (increasing the number of apps that will use it and so on).

Now... if they created a language that would never work with other cards, most programmers wouldn't bother using it. What was needed was a generic high-level language that could compile to low-level shader code. This is just the high-level portion... If ATI wanted to tap into this, they'd need to write their own compiler (for efficiency purposes, anyways).

Re:News.com beat ya.

[VoiceOfRaisin]

Usage Note: Awhile, an adverb, is never preceded by a preposition such as for, but the two-word form a while may be preceded by a preposition. In writing, each of the following is acceptable: stay awhile; stay for a while; stay a while (but not stay for awhile).

Not only that, the date on the news.com article is TODAYS date. How exactly is that "awhile"?

Re:News.com beat ya.

[Anonymous Coward]

That's like asking why did SGI create OpenGL, and then actually publish an open specification for it?

Or why did Intel create the PCI spec, and allow open access to it (to competitors like Motorola and AMD?)

Or why did Sun create Java, then publish open specifications for how it works? (Which IBM, BEA, and Oracle are happily implementing and trying to beat Sun at)

("Why did MS make C sharp" is *NOT* analogous -- that was purely an overt attack against Sun's Java)

nVidia wants people to adopt Cg, but have ultimate control/arbitration rights over compliance with it. It would put them into the default leadership, direction setting position as far as shaders are concerned.

Its the same reason why 3DLabs is pushing so hard with their ideas for the next generation of OpenGL.

Re:News.com beat ya.

[Anonymous Coward]

OpenGL is an API; Cg is a programming language.

NVidia != compatibility?

[FueledByRamen]

Remember 3dfx's GLIDE libraries? This could end up like those... an "industry standard" supported only by one manufacturer's chipsets, used by all major games. At least 3dfx made good, cheap cards before they died, though.

If it doesn't work with my RADEON, it must be evil!

Re:NVidia != compatibility?

[neo8750]

I remember Glide as being incompatible with anything without a 3dfx chip set. But in return for the incompatibility we got great performance enhancements.

Re:NVidia != compatibility?

[rainwalker]

Did you read the artcle?? The FIRST paragraph contains, "Graphics giant NVIDIA today announced Cg, an initiative with participation from Microsoft to create a cross-platform, hardware-independent, high-level Pixel and Vertex Shader programming language."

If you happened to read the rest of the article, it notes that this will work fine on Radeons, in particular.

Re:NVidia != compatibility?

[Anonymous Coward]

Fuck the radeon's. ATI barely even supports Linux. In order to get some 3D support, you will either have to wait for Tungsten Gfx to implement part of the Radeon 8500's capabilities, or you can use the FireGL 8800 drivers -- which work for now but who knows if sometime in the future they will stop working.

NV has the best support and is a better 3D card. If you want a good VIVO card, then Radeons are your pick -- mainly under Windows though.

Re:NVidia != compatibility?

[GutBomb]

if you are worried about future driver revisions not working, don't install them. if you are happy with how your drivers work now, keep them that way.

Re:NVidia != compatibility?

[cyborch]

with participation from Microsoft to create a cross-platform, hardware-independent

It's funny how a language which only has a windows compiler (some .exe) can ever be called cross-platform!?!? It seems very much to me like this is NOT cross platform. I haven't actually run the Cg compiler (I couldn't afford a windows license just to try this compiler out...) so I cannot tell if the OpenGL code it generates is so full of nVidia extensions to be all but useless to anyone who wants to make an application that works for more cards than the ones from nVidia. But since the cross-platform statement is an obvious lie how can I trust that it will generate hardware independent OpenGL code?

If you happened to read the rest of the article, it notes that this will work fine on Radeons, in particular.

So it says. If I had a windows box I would try this cross-platform tool which requires windows in order to run and see if it was really true. Then I might compile the OpenGL code it generated and see if that actually worked on my Radeon card. I haven't tried it yet, but since they start out lying why should I believe them now?

Pixels & Hardware sales

[NickRob]

If we wanted cutting edge Pixels, we'd go back and play Wolfenstein. Man, I remember those days, the people with sharp features and a whole four frames of animation. And we were glad to have it, too.

Hype or innovation?

[moonbender]

You've got to wonder, is this yet another load of Nvidia corporate hype (a la "HW TnL will revolutionise gaming"), or is this useful technology? I wouldn't trust any of the current articles on answering that, judging by the previous Nvidia hypes, it takes a few months till anyone really knows if this is good or bad.

Re:Hype or innovation?

[array_one]

ummm.... T&L DID revolutionize the game industry. We are at a point where companies dont have to worry about pushing polygons. Now they are finally moving on to actually improving visual quality, as opposed to geometric complexity.Have you seen what ID has been up to lately?

Re:Hype or innovation?

[UnknownSoldier]

> You've got to wonder, is this yet another load of Nvidia corporate hype (a la "HW TnL will revolutionise gaming")

Have you *even* done *any* 3d graphics programming?? HW TnL *offloads* work from the CPU to the GPU. The CPU is then free to spend on other things, such as AI. Work smarter, not harder.

I'm not sure what type of revolution you were expecting. Maybe you were expecting a much higher poly count with HW TnL, like 10x. The point is, we did get faster processing. Software TnL just isn't going to get the same high poly count that we're starting to see in today's games with HW TnL.

> it takes a few months till anyone really knows if this is good or bad.

If it means you don't have to waste your time writing *two* shaders (one for DX, and other for OpenGL) then that is a GOOD THING.

Re:Hype or innovation?

[Pulzar]

Have you seen what ID has been up to lately?

Have you read about how much effort JC has put into pushing polygons in Doom 3? We're hardly at a point where companies don't have to worry about speed issues..

If anything, companies have to put in even more effort into producing some stunning results, because everybody has been spoiled by recent titles.

Re:Hype or innovation?

[friedmud]

"If it means you don't have to waste your time writing *two* shaders (one for DX, and other for OpenGL) then that is a GOOD THING."

Even better then that! It means you don't have to waste your time writing *4* shaders:

Nvidia/DirectX
Nvidia/OpenGL
ATI/DirectX
ATI/ OpenGL

That is of course, pending a compiler for ATI cards - but I don't think it will be long... Unless ATI holds out for OpenGL2 - but in between now and when OGL2 comes out there is a lot of time to lose maket share to Nvidia because people are writing all of their shaders in Cg - and ATI is getting left out in the rain....

So I would expect ATI to jump on this bandwagon - and quick!

Derek

Re:Hype or innovation?

[blink3478]

This isn't hype, it's a natural progression in computer graphics.

What you've been able to do in 3d animation software for ten years now (bump mapping, specular mapping, displacement, self-illumination, glossiness maps etc), you're finally able to do in real-time using the lastest video cards.

In another few years, cards will probably be able to do real-time shadow effects (Doom 3), normal mapping, and eventually raytracing in real-time, for those nice reflection and refraction effects.

In the future, the 'top of the line' rendering effects that 3d Studio Max Softimage and Maya are just getting into (global illumination, caustics, hair, deep shadows) will eventually be able to be processed in real time as well... when processing power and video cards catch up.

D

Re:Hype or innovation?

[Paolomania]

The thing that the original poster didn't *see* is that offloading TnL onto the GPU does not neccesarily improve the *visual* quality of the game. Rather it frees up system resources for the important parts of a game that unfortunatly don't go into making good *screenshots*.

Re:Hype or innovation?

[ThrasherTT]

It's neither. This is simply the natural next step in the 3D graphics world. Once a standard high-level GPU programming language is adopted, programmers can spend a LOT more time doing stuff that makes for better games, while keeping the eye candy at a very high level (across any decent piece of hardware and 3D API). When I saw this PR, I wept with joy at the thought of being able to forget all the ASM-level tuning that needs to be done currently to get high performance from this generation of 3D HW. And I don't even have to wait 10 years for OpenGL 2.0!

Re:Hype or innovation?

[MisterBlister]

He isn't putting very much effort at all into pushing polygons..Its going into handling the multipass texture effects.

HW T&L (or, rather HW T, since the L part is of dubious usage because who does simple vertex lighting anyway?) *IS* a huge boon to gaming. Programmers don't need to sweat the details of polygon culling as they did before, with elaborate PVS/BSP setups.. Once GF3 and above are the norm, in almost all cases you can get away with just a very loose frustum cull as long as you render most objects front to back (to take advantage of built in z occluding, guard band clipping..)

Yes, there's always going to be more work to fill up the savings in work from other areas but as that happens the visual quality of the games is rapidly improving because more and more stuff is being properly solved for general cases.

In a couple more iterations, good enough global illumination and shadowing will be 'solved' as well, and then the programmers will move on to something else as the primary focus.

Of course none of this particularly revolutionizes GAMING, as the game industry is free to keep making the same games with better graphics (and this seems to be their general game plan), but you can't hold NVidia, ATI, etc responsible for that.

Re:Hype or innovation?

[Merlin42]

I agree with you on most points ... except for the real-time rayracing. One important thing to consider when building a 'real-time' system is that the innermost loop that is time sensitive should be effectively O(1). You want to avoid algorithms that can blow up under certain circumstances(Think two mirrors with a glass ball in between :), which makes recursive algorithms very dangerous. This is why reflections are generally handled by doing different environment maps. Also having each peice of geometry (triangle) be able to be rendered independently is important to a low latency real-time system. If you need to evaluate the entire scene as a whole (to figure out what a reflected/refracted ray hits) then you are pretty much guarenteed to increase latency which has a very poor effect on playability/interactivity.

Re:Hype or innovation?

[GutBomb]

he said the future. i wholeheartedly believe computers will advance enough to do this in the future without adversely affecting playability.

Re:Hype or innovation?

[Anonymous Coward]

Perhaps one should stop for a second and think of al the several hundreds of millions of machines, and at least a couple of tens of millions of users, that won't get the new fancy $500+ GPU cards. When a high-end card was $1500-200 I actually bought one too (at $100). But a five freakin' hundred bucks?! For that amount of money I could almost buy a P3-Xeon (that whips the crap out of any P4 any day)!

Re:Hype or innovation?

[Anonymous Coward]

Why are GPU instruction just not incorperated into the likes of SSE2 ? They are not that far off it, surely. The AGP .. arghh I doneyno.

Ten!? Are you trying to insult me? Me? With a poor dying grandmother ... Ten!?!

Fat Cats I guess at least someone like john has a bit of a say...

Re:Hype or innovation?

[Anonymous Coward]

HW TnL has barely even gotten off the ground. Game developers, until recently, were still programming for the TNT2 crowd. Things like Unreal2 and Doom3 should start really showing us what these cards can do.

Re:Hype or innovation?

[Anonymous Coward]

WTF are you talking about?

A GeForce4 MX440 cost less than a $100

Proprietary standards?

[Lord Fren]

While I this is a great move by NVIDIA to increase the use of Pixel and Vertex Shader in games, is this wholly proprietary? I mean wouldn't it be better for ATI to have a hand in it as well, to work out a standard to make it easier for game developers? I just hope this doesn't turn out like 3dfx..

Re:Proprietary standards?

[startled]

"While I this is a great move by NVIDIA to increase the use of Pixel and Vertex Shader in games, is this wholly proprietary?"

Cg compiles down to OpenGL and DirectX statements, which are not proprietary. Some of the statements are recent extensions to support the kind of stuff they want to do. So, yes, other companies can support these as well. However, they might be following a target being moved around at will by Nvidia. "Oh, you don't support DirectX 9.001's new pixel puking extensions?"

It remains to be seen how it's used. Obviously, Nvidia wants to use this to sell their cards. But MS doesn't have to listen to them when designing DirectX, either. It seems to me that at the very least, it'll be faster than writing separate old-school (last week) vertex and pixel shader code for each different brand.

zerg

[Lord Omlette]

The article writes, "Putting on my speculative hat, the motivation is to drive hardware sales by increasing the prevalence of Pixel and Vertex Shader-enabled applications and gaming titles. This would be accomplished by creating a forward-compatible tool for developers to fully utilize the advanced features of current GPUs, and future GPUs/VPUs."

Putting on my speculative hat, the motivation is to, um, make better looking graphics?

The real test will be how well the crosscompiler outputs OpenGL 2 & DX 9 shaders in practic, not theory.

But let's be serious: cel shading is the only shading anyone really needs. ^^

Good times

[Procrasturbator]

I'm buying one right away, and praying that they become industry standard. The next "Amy men" game will be all the sweeter, along with Pac-man 3D!

Re:Good times

[Score Whore]

The next "Amy men" game will be all the sweeter...

Yes, I agree! We all like a good cross-dressing game for the early morning hours at lan parties!

Bloated code?

[creative_name]

But will this result in the bloated code so prevailant in other Microsoft applications? Anyone who has ever seen the source of Billy Joe's webpage that he made using FrontPage can attest to the fact that the Redmond crew love to throw in all sorts of extra nonsense. In an area that is already so resource intensive, can we really afford the bloated code? Hopefully it will be a non-issue.

feh

[Anonymous Coward]

This means nothing to me until John Carmack gives the seal of approval. Until then it might as well be BitBoys "Oy! Cg!"

More Cross-Platform Games?

[Anonymous Coward]

Now, it should be easier to port code to non-MS platforms because the compiler outputs both DirectX and OpenGL.

Re:Linux Support

[friedmud]

What are you talking about?? Nvidia makes great linux drivers - and from looking through the pages it looks to me like Cg just outputs regular OpenGL (Well - Nvidia-OpenGL anyway) so I would venture a guess that any of these will run just fine on the nvidia linux drivers.

My only problem is that the toolkit itself is only for windows :-(

Anyone try it with Wine/Winex yet?? I might when I get home.

Derek

This could be really good.

[Steveftoth]

According to the web site, they are working to implement this on top of both OpenGL and DirectX. On linux and Mac as well.
Basically this is a wrapper for the assembly that you would have to write if you were going to write a shader program. It compiles a C-like (as in look a like ) language into either the DirectX shader program or the OpenGL shader program. So you'll need a compiler for each and every API that you want to support. Which means that you'll need a different compiler for OpenGL/Nvidia and OpenGL/ATI until they standardize it.

On a more technical note, the lack of branching in vertex/pixel shaders really needs to be fixed, it's really the only feature that they need to add to them. Which is why the Cg code looks so strange, it's C, but there's no loops.

Re:This could be really good.

[Anonymous Coward]

Cg does support loops and branching -- check the language spec.

Depending on the targeted hardware platform for a given shader (e.g., requesting the shader be compiled to DX8 vertex shaders), certain limitations may be imposed, like requiring all loops be unrollable at compile time, to make programming and readability easier, but not really improve the programmability of the GPUs. Other profiles may have these restrictions removed, so that general loops and branching are fully supported.

Re:This could be really good.

[91degrees]

You just need a standard high level language. The compiler will most likely be supplied by the chip manufacturers as a library for each card.

Branching in a pixel shader is a little tricky. Current designs work on a large number of pixels at the same time. Branches have to be performed using conditional execution, which means that both paths must be taken.

Assembly vs. High-level? hmmm....

[rob-fu]

That's like asking which of the following would I rather do...

a) have a 3-way with two hot chicks
b) clean the floor behind my refrigerator

I wonder.

Re:Assembly vs. High-level? hmmm....

[Anonymous Coward]

somewhat rough was of putting it ;). But it cuts to the heart of the issue.

Most of the great games we play today are totally reliant on DirectX. Developer middleware is very very important. Programming is hard. especially at the device level...so high level SDK's are always a good thing for game players and builders.

Re:Assembly vs. High-level? hmmm....

[prockcore]

Ironically, you won't have A until you do B.. your fridge stinks!

Pixel and Vertex Shading and OpenGL2.0?

[Ace Rimmer]

Has OpenGL 2.0 a chance now? Is anyone capable to compare those?

Re:Pixel and Vertex Shading and OpenGL2.0?

[alriddoch]

It seems to me that this is probably an attempt to kill OpenGL 2.0, and secure Direct X as the dominant 3D API. OpenGL 2.0 has as far as I can tell been well thought out, and most of the feedback to it has been very positive. The frontend to its shader language is Free Software, and the work done seems to have been done with the best of intentions. I am very cynical about an offering from NVIDIA, especially when you consider their behavoir towards the rest of the 3D card market, and the fact that Microsoft are involved.

Re:Pixel and Vertex Shading and OpenGL2.0?

[afidel]

Since NVidia sits on the OpenGL 3.0 steering commitee and was the first to offer pixel shader extensions to their 2.0 drivers I think you are being a little reactionary to M$'s presence. For one thing the high end of Nvidia's line where they make about 8X the margins is in CAD and the like which will likely never be ruled by D3D. BTW, the interface to NVidia's pixel shader pipline exposed by the OpenGL extensions is much cleaner and better thoughtout then DX8's. See the recent John Carmack .plan update where he ranted about this fact.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Anonymous Coward]

>>It seems to me that this is probably an attempt >>to kill OpenGL 2.0, and secure Direct X as the >>dominant 3D API.

Yeah..... it would be easier to assume that than read the damn article.

If you hadn't noticed, the Cg compiler can generate shaders for DirectX AND OpenGL.

FUD FUD FUD. Welcome to Linux Land.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

Cg compiler can generate shaders for OpenGL 1.4. Not 2.0. BIG difference.

It would be easier to read the damned article.

OpenGL 1.4 is a completely different beast than OpenGL 2.0. Cg is a direct competitor (and attempt to kill) OpenGL 2.0, and secure NVidia as the dominant provider of 3D APIs.

Tell me, Anonymous Coward, why you think that NVidia made Cg instead of supporting OpenGL 2.0 on their hardware? Try not to use words like "monopoly", "closed standard", and "platform specific."

Re:Pixel and Vertex Shading and OpenGL2.0?

[ThrasherTT]

"why you think that NVidia made Cg instead of supporting OpenGL 2.0 on their hardware?" Maybe because OpenGL 2.0 is vaporware? If it wasn't, Doom 3 would be using it :)

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

It's not vaporware.

How do you know Doom 3 isn't going to OpenGL 2.0? Carmak has repeatedly said that he's under NDA's, and can only talk about what hardware is currently available.

You'll notice that Carmak's name is not listed as an endorser of Cg.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Arakonfap]

Did -you- read the article?

Did you miss the point about it having cross-platform support, and being hardware independant?

AKA OTHER video card manufacturers can write there own compilers..!

Can you tell me how this locks anyone into Nvidia?
Is it because they didn't do ATI's job for them? Or because they want there technology (vertex and pixel shaders) used now, instead of whenever opengl 2.0 comes along?

And can you also tell me why this compiler language will be unable to compile Opengl 2.0 compliant code? This may be a good forward-looking tool/initiative.

Re:Pixel and Vertex Shading and OpenGL2.0?

[mallan]

How the #U&^ do you come up with this stuff?

Saying Cg is a competitor to OpenGL 2.0 is like saying that a muffler is a competitor to a BMW M3. Cg IS ONLY FOR SHADERS. It's offers a high level language which translates to shader assembly. When OpenGL 2.0 comes out, all that is required is a new back end for the compiler, and you can REUSE your existing Cg shader code on OpenGL 2.0. Heck, you can reuse your Cg shader code on DirectX if you want. Does that mean that it's a competitor to DirectX? Geez.

And why aren't they supporting OpenGL 2.0 on their hardware? Because OpenGL 2.0 DOESN'T EXIST. It is a PROPOSAL at the current time - it is not a STANDARD yet. You can't make hardware support a standard until a standard exists. Get a clue, dude.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

Yes, I have read the article.

It does not have cross-platform support. It is not hardware independant. They say that other vendors will be able to support it, they don't say that it's a free or open standard.

Think about the compiler part of it, for a second. So what if the compiler supports multiple targets? Each compiled program will only be able to run on that one platform! Does that sound like OpenGL to you? Even if they allow a mechanism where the code can be targeted to multiple platforms in one executable, they're still making that decision at compile time. As opposed to at runtime, like OpenGL 2.0. That means that an executable today will be able to run on future hardware. Not true with Cg. Also, the compiler they talk about in Cg is an NVidia product. They're giving it away like free beer, not like free speach. In order for any given company to have Cg targeted to their platform, they'll need to go through NVidia to make it happen. Doesn't this scare you?

Other video card manufacturers can not write their own compilers. The intended method is for other manufacturers to provide new "profiles" (eg fp20, vp20, dx8vs, dx8ps) which will be integrated into the one and only Cg compiler, which NVidia controls.

That's how it locks people in to NVidia.

I'm not talking about ATI. I'm talking about 3dlabs, the people who created the OpenGL 2.0 standard.

I agree that it's to NVidia's advantage to release their hardware sooner rather than later, and that the OpenGL 2.0 standard won't be a standard for some time to come. But NVidia could put their weight behind it, or they could write their own thing. They chose to abandon OpenGL 2.0. Entirely. And they're hoping everyone else will, too.

The Cg language is different from the OpenGL 2.0 shader and vertex language. They're different, but they do the same thing, essentially. To rephrase your question, perhaps someone will be able to provide a translator from Cg to OpenGL 2.0 and vice-versa. Just as people have created a layer that makes DirectX work on top of OpenGL.

Is there really a question in your mind about whether OpenGL is a better standard that we can all live with than DirectX?

The possible objections are the fact that DirectX has more features than OpenGL. Well, that's why OpenGL 2.0 is a good thing.

Throwing Cg into the mix doesn't make OpenGL 2.0 any less of a good thing.

I'm pissed at NVidia for deciding to go with a closed standard, rather than an open standard. What else is new?

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

"Cg is only for shaders." What do you think OpenGL 2.0 is? Have you read the OpenGL 2.0 specs? It provides an exact competitor to the language that NVidia has proposed. Vertex and fragment shaders. It's the same thing, in two different ways - one open and free, one propietary.

I agree it might be possible to write code for the NVidia platform which can be redirected to the proposed standard of OpenGL 2.0. But in a year from now, I hope everyone's using OpenGL 2.0 instead of Cg.

Yes, you can make hardware support a proposed standard. How do you think hardware gets designed in the first place?

By the way - that's a silly argument - "don't make hardware until the standard exists," and "don't make the standard until hardware exists." I'm hearing both of those arguments at the same time in here, which is pretty amazing.

Don't be rude, dude.

Re:Pixel and Vertex Shading and OpenGL2.0?

[ThrasherTT]

OK, so 3DLabs is on the ball. But what ball is that? A ball of an as-of-yet "unapproved" specification (see an approved spec here?). How many hardware vendors are going to support OpenGL 2.0 with 110% effort when the spec is still being reviewed? Does that mean hardware vendors aren't allowed to try to gain market/mind share in the meantime?

I did note that Carmack hasn't seemed to say anything about Cg yet. As I'm sure most of us are, I am very interested in what he has to say. I suspect that he will be highly unimpressed.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Arakonfap]

Hm.

A few small things:

I can see why you would be weary of it, but I think you're jumping to conclusions too quickly.

Anyway, with that said:
Cg itself not being crossplatform is a completely different topic then the OUTPUT. The compiled shaders should work on any platform that has Opengl with nvidia extensions (linux, windows, etc). I see nothing wrong with that. It's a development issue, not a runtime issue. Cg is used at the design development stage, not on the end-users' machine.

Again, I see nothing wrong with NVidia controling the compiler. I can't seem to see any information on licensing fees for other vendors to make the profiles for Cg. It may be cheap, it may not be. The market will decide. Just because there a company does not mean they have evil intentions for everything.

Either way, this is NOT a lockin solution (like Glide was). Developers can still write shaders by hand for whichever card they choose - this tool just makes it easier to make them for nvidia chipsets, or directx in general. Again, I see nothing wrong with that.

As far as the directx vs opengl debate goes.. opengl moves way too slow to keep up with the hardware. 2.0 will be nice, if it ever happens. Until then, as long as OpenGL extensions (Nvidia's, or ATI's) are available, I see no problem. It may add a little more to development cost, but it's not all that complicated really. A game can quite easilly support shaders for Nvidia or ATI, or whatever. Most already have tools for handling the conversion using a generic subset.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

I don't fault NVidia's marketing department, and I don't fault their technology guys. As far as NVidia is concerned, this is the best way to sell products in the best manner, right now.

It doesn't help the rest of the industry, though. I wish OpenGL 2.0 were already ratified. That's the problem with standards like that, though - they don't like to ratify them until the hardware exists to test out the theories on. Well, no hardware that's shipping today can support OpenGL 2.0. Chicken and the egg.

I just with NVidia were being more supportive of OpenGL 2.0. Because it's the better of the two standards, in respect to its effects on the industry as a whole.

Same way that I wish Microsoft had never developed DirectX. Sure, it has more features today, but in the long run OpenGL is a better alternative.

Re:Pixel and Vertex Shading and OpenGL2.0?

[mallan]

OpenGL 2.0 covers a *LOT* more ground than shaders. The OpenGL 2.0 proposal has not been ratified, and there is no time estimate as to when it will be come a standard. And as to when we'll have robust, compliant implementations, that's anyone's guess.

Cg is available *today*, as a TOOL for developers. If you'd prefer to write different assembly code for every card that supports shader functionality right now, hey, go for it. If you'd rather sit around and stare at the opengl.org website until GL2.0 is released instead of writing code, that's another option.

And why do you have to throw around words like "monopoly", "closed standard", etc.? NVIDIA provides excellent drivers for Linux, Mac and Windows. They don't dominate the graphics card industry because of dirty business practices, they dominate because they are leading the industry in feature implementation. They are taking an extremely active role in the development of OpenGL 2.0, and you can bet that a lot of what they learned from writing Cg will make it into the final standard. Honestly, who do you think has more experience with programmable pipelines, 3DLabs or NVIDIA?

And as for the "silly argument" - I never said "don't make hardware until the standard exists", what I said was that you can't support OpenGL 2.0 implementations until the standard exists. Duh. Whether the hardware is *capable* of supporting the standard is irrelevent. You can't ship a standard until it's a standard.

Direct3D 9 has a high level shader language. So maybe they're out to kill Direct3D 9 as well! Just think about it for a sec before coming up with absurd conspiracy theories. Do you really think Microsoft is happy that Cg supports OpenGL at all? Come on.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

If OpenGL 2.0 covers a lot more ground than shaders, and if you agree that some of that is good - then you think that companies will need to reinvent a lot of OpenGL 2.0 if they want to support Cg at the same time. See what I mean? In essence, nVidia is re-inventing the wheel, just so that they can control exactly what's on their GPU. And you know what, I'd probably do the same thing in their position - if, as you assert, they can't ship OpenGL 2.0 until it's fully ratified.

I'm not arguing that people shouldn't use shading languages. They're fantastic. They're the best thing ever to hit the PC graphics marketplace. It's unfortunate that a closed-source, non-free implementation is available before the open-source, free implementation. Companies can move faster than comittees. (Especially when the companies are on the comittees, too.) It's almost as though a bi-law of the OpenGL review board should be that memebers can not publish competing standards. (It's like a conflict of interests.) That would encourage them to play nice with eachother. I don't know, I'm just venting steam.

I have to throw words like "closed standard" around because this is a closed standard. As to throwing around "monopoly", the reason I do it is because nVidia could either play with the proposed open standard, or invent their own closed standard. I'm not saying that they're abusing their monopoly. I'm just saying that they're trying to establish one. There's nothing illegal about having a monopoly - it's illegal to abuse it. Everyone in their right mind wants their company to have a monopoly.

I disagree strongly with your assesment that they are taking "an extremely active role in the development of OpenGL 2.0." Based on that disagreement, you can imagine why I'm frustrated at their behavior. If you are correct, then I agree, they can potentially dramatically improve the OpenGL 2.0 standard. (And I hope they do!) When 2.0 is ratified, we'll see how quickly they come out with an implementation. I hope for everyone's sakes that they do it quickly, and that it's good.

You can ship a proposed standard. People do it all the time. C++ compilers come to mind.

If they're out to "kill Direct3D 9", I'm happy. Granted, they'd only be trying to "kill" the shader language part - but that's fine by me. I just hope, hope, hope, hope, hope that they don't kill OpenGL 2.0 before it's born.

I don't think I'm saying there are conspiracies. And I don't think my standpoint is "absurd." Maybe you disagree with my conclusions, and some of my assumptions - but do you honestly think I'm acting in an "absurd" manner? You think that I'm "manifesting the view that there is no order or value in human life or in the universe"? =)

Yes, I think Microsoft is happy that Cg supports OpenGL. Because I think you'll find that Cg works much better on DirectX than it does on OpenGL 1.4 (which, by the way, has not yet been ratified - which proves my side of the argument, not yours). That's just my guess, but it's what I think will happen. And I think that developers will tend to chose the platform that supports it better. (Other than Carmack, who always seems to chose the standard he thinks is better in the long run.) It's embrace and extend all over again.

Honestly, I wish there was only one shading language : RenderMan Shading Language. Not that it couldn't use some improving, but wouldn't it be cool if you could literally use the exact same code on every platform? Offline renderers, included?

Re:Pixel and Vertex Shading and OpenGL2.0?

[mallan]

How can they be "reinventing the wheel" when their implementation is out before OpenGL 2.0? There are already several real-time shading languages, e.g.
http://graphics.stanford.edu/projects/shadin g/
http://www.sgi.com/software/shader/overview.ht ml

Trying to create a standard without prototype implementations is fraught with problems (witness CORBA, for example). I suspect that NVIDIA's Cg began as some employee's thesis work and has been in internal development for some time. The proposed GL 2.0 language (proposed by a competitor, I might add) only hit the streets a couple of months ago. Why should NVIDIA drop everything they've been working on simply because 3DLabs thinks they know how to write an API? In case you weren't aware, the ARB didn't come up with the proposal, it came directly from 3DLabs.

You can ship a proposed standard. People do it all the time. C++ compilers come to mind.

Heh. Yeah, and how wonderful is that? I just love putting #pragmas and #ifdefs all though my code. You don't do much cross-platform development, do you? And you can't call anything OpenGL unless you license the name from the ARB.

NVIDIA has a strong investment in OpenGL - I don't know why you believe otherwise. They stand to gain nothing by killing OpenGL 2.0 - without OpenGL, they're not going to be selling 3D cards to Linux or Apple users. AFAIK, NVIDIA was the first vendor to ship OpenGL 1.3 certified drivers. Go to any conference session on advanced OpenGL, and you'll find an NVIDIA employee giving the lecture.

Honestly, I wish there was only one shading language : RenderMan Shading Language.

As elegant as the RM Shading language is, it doesn't map well to current hardware - it would be way too slow, unfortunately. But wait - that's a proprietary API, controlled by a single company. Isn't that what you're upset about? A de facto standard is not a true standard.

I doubt Cg will last more than a few years, at the most - hardware shading is still very, very young, and people are trying out the best way to do it. Personally, I think it's excellent that NVIDIA have put forth a high profile, cross platform, cross API shading language. Glide proved that developers won't accept a solution which locks them into a specific vendor. If NVIDIA is too tight with Cg, it will fade away - and they know that.

Re:Pixel and Vertex Shading and OpenGL2.0?

[Viking Coder]

According to what you said (and I agree with), Cg is an alternate implementation of the shading language component of OpenGL 2.0. In which case, the OTHER components of OpenGL 2.0 will need to be re-implemented with a different API, to be viable with the Cg platform. I stand by this assertion, because I don't think that OpenGL 2.0 and Cg will play nicely with eachother. Cg proclaims to run "on top" of OpenGL 1.4, but I suspect that it will have so many platform specific hooks that the OpenGL 1.4 code it produces will only work on the nVidia platform. OpenGL 1.4 merely allows nVidia to expose the necessary API for them to make Cg work on top of it.

What makes you think there isn't a prototype implementation of OpenGL 2.0?

nVidia had the opportunity, ALL ALONG to drive the development of the next generation of OpenGL so that it could be capable of supporting the features that nVidia wants. I'm pissed off that everyone forgets this fact. They chose not to. They went off in isolation, and developed their own propietary API, which is incompatible with the OpenGL 2.0 specification (the shading language part.) It's not as though OpenGL 2.0 happened all of a sudden, without nVidia's involvement. They had every chance to steer the proposed standard to their liking. Instead, they abandoned the proposals, and they're releasing a closed solution. And you like them for this behavior? This is Microsoft and DirectX all over again.

Would you agree that SGI did a pretty good job in producing OpenGL? I think they did an amazing job. I've also read the OpenGL 2.0 specification. It's just as stunning as the original OpenGL specification. And nVidia had every opportunity to make it work the way that they wanted to, or to make it even better. Don't try to defend their actions as though this is 3dlabs forcing their closed solution on everyone. 3dlabs is playing nice with others, nVidia is not. I suppose it's pointless for us to continue discussing the matter, if you disagree on that simple point.

I do cross-platform development all of the time, thank you. And I happen to do OpenGL things all of the time, as commercial products, and I've never once licensed the name from the ARB. Oh, you meant preparing an OpenGL implementation. So, you're saying that licensing the name from the steering committee is a bad thing? I suppose you think that Microsoft's Java implementation was good, too.

I do not believe that nVidia has a strong investment in OpenGL 2.0. Why would they spend their money twice, and implement Cg? It doesn't make any sense. Why not implement the OpenGL 2.0 shading language, as defined in the proposal, and start shipping it as a provisional implementation? *shrug* I don't blame them for the behavior, and I don't think it's horrible - but I don't like it, and I don't think it's a good thing.

"A de facto standard is not a true standard." So, you don't use Ethernet? Or GIF? PostScript?

Same way as you have to license the OpenGL name, you have to license the RenderMan name. It's the same thing. And I don't disagree with either tactic. I do disagree when one company hopes to control the only implementation.

I hope you're right with your Glide prediction. Then again, DirectX is still shockingly popular. Help me kill DirectX. =)

Re:Pixel and Vertex Shading and OpenGL2.0?

[LinuxParanoid]

nVidia had the opportunity, ALL ALONG to drive the development of the next generation of OpenGL so that it could be capable of supporting the features that nVidia wants.

A lot of key nVidia personnel came from SGI. They know this. They also know that OpenGL's openness, while useful versus other workstation vendors, didn't help them (SGI) combat Microsoft very much, given Microsoft's OS + programming tools monopoly. There's no reason that shoving their key vertex shader technology interfaces into OpenGL would substantially help them sell more units or compete more effectively versus ATI or forestall Microsoft market power. In contrast, getting their interfaces into DirectX potentially helps them sell more units (by lowering the barriers for the largest set of developers using shaders, a key upgrade-driving feature), compete more effectively versus ATI (whose vertex shaders no doubt work a bit differently from nVidia), and forestall Microsoft's market power (since, by offering such technological gems, they can get various concessions on other issues or IP licensing fees from Microsoft).

3Dlabs deserves major kudos for delivering the OpenGL spec. Given that 80+% of their CAD/workstation base predominately uses OpenGL, it makes sense that they'd push programmer interfaces to their IP through OpenGL. And for a similar reason, it makes sense for nVidia to insure interfaces to their hardware are in DirectX. IMHO.

--LP

Re:Pixel and Vertex Shading and OpenGL2.0?

[GoDoEr]

3Dlabs has been totally open with their ideas for OpenGL 2.0 from the start. The first presentation to the ARB was the September ARB meeting last year. Right after that the white papers appeared and were publicly available. Since then they have told the ARB at every meeting what they were thinking OpenGL 2.0 should look like, and have asked for feedback from ARB members, and people like us, developers. They wrote white papers, openly discussed their ideas, took feedback from developers and others and used that to improve the quality of their white papers. They also published a prototype compiler. It is pretty clear that a lot of developers like the direction OpenGL 2.0 is going. BTW, the next ARB meeting is next week, it'll be interesting to see what will happen there. Usually the meeting notes are available on opengl.org a week later. In the mean time nvidia, who is a member of the ARB, listened to all this, and decided to put their formidable resources behind their own competing proposal for a high level shading language. That is just simply lame. Nvidia is part of the OpenGL ARB standard body, but didn't put any effort into helping OpenGL 2.0 along, just decided to do their own thing. That is not behavior that is acceptable as a member of any standard body, including the ARB. If, on the other hand, they had actively worked together with 3Dlabs and the rest of the ARB, imagine how much good that could have done for OpenGL 2.0, and resultingly in what we get to play with. (Before anyone argues that OpenGL 2.0 is more than Cg, that is correct. But let's face it, the key part of the OpenGL 2.0 proposal is the high level shading language.) Cg is exactly what nvidia wants. It compiles to either OpenGL 1.3 / 1.4, or DirectX. Well, what targets do we have for a compiled version of a Cg shader? NV_vertex_program, and hopefully soon ARB_vertex_program (which is pretty close to NV_vertex_program). Guess what, those are invented by nvidia as well. NV_vertex_program does not support loops, function calls, or if statements. So how is a high-level Cg shader that has those constructs going to run on NV_vertex_program? How is a high-level Cg shader going to be run on someone elses hardware, that does have loops or function calls? It is not, since nvidia dictates the compiler, and what target it compiles to. OpenGL 1.3 / 1.4 does not define fragment shading capabilities, other than NV_register_combiner. Yes, another nvidia extension. I hardly would call NV_register_combiner a fragment shader, but I digress. What if an OpenGL fragment shader extension surfaces and gets proposed to the ARB that nvidia doesn't like? How do I get my Cg shader compiled to that new extension? In other words, nvidia effectively dictates the pace of innovation. That is *not* an open standard. Nvidia is afraid of OpenGL 2.0, because it does not fit their hardware roadmap.

Am I Deformed!?

[Metrollica]

Hi.

I'm twenty five years old, and up until two weeks ago, I was a virgin. Too many celibacy had worn my self-esteem down to the point where I was finally willing to pay for sex. I'll spare you the details of the event, as this is not what I am writing about.

After having completed the act, the prostitute whose services I had rented immediately exclaimed that something had felt weird. With no particular ceremony, she grabbed my now-flaccid member and subjected it to an intense examination, while biting her thumbnail in consternation.

After a brief period, she informed me that my penis was deformed, in her professional opinion. I had spent my entire life without ever seeing another man urinate, so I was not aware that the output usually emits from the end of the head, not the underside, where mine does.

I'd like to know if I should seek the advice of a doctor or plastic surgeon? Is this the sort of thing that can, or even should be corrected? I've lived with it for twenty five years, and it hasn't bothered me. Is there really any reason to worry about this?

Re:Am I Deformed!?

[Anonymous Coward]

you might want to use the

 tag

No compiler is as good as human

[Anonymous Coward]

No matter how good the compiler is, it will never be as efficient as a person writing in solid OpenGL and DirectX.

Also, OpenGL and DirectX are most commonly used with C++, which is a 3rd level language.

I sincerely doubt this new language is LISP-like (a higher level language than C++), it seems that this new "language" is little more than some scripting.

Re:No compiler is as good as human

[91degrees]

It isn't about converting to standard OpenGL and D3D operations. It's an extension to support increasing programmability of the graphics cards. You'll still need to use the standard API to set up the basic geometry, and send all the data.

The vertex shader simply executes a series of instructions on a vertex when it is sent to the card, and the pixel shader simply executes a series of operations on each pixel.

Existing shader designs are essentially scripting languages (although you could also argue that the same is true of assembly language). The idea of Cg is to make it a little less directly related to the hardware, and a little easier to follow than an assembly language based concept. Essentially it involves using variable names, and standard mathematical notation.

Re:No compiler is as good as human

[ThrasherTT]

"No matter how good the compiler is, it will never be as efficient as a person writing in solid OpenGL and DirectX."

I'd agree with you if GPUs weren't changing every 6 months. By the time you've tweaked your hand-made GPU ASM, another GPU is out and it with its Cg compiler will outperform your hand-written code!

"it seems that this new "language" is little more than some scripting."

Exactly what makes a language a "little more than some scripting"? This isn't a troll...

Re:No compiler is as good as human

[shokk]

I am convinced that since we see tons of crappy games written by these "professional human coders" with a great grasp of DirectX and OpenGL, this will simply open the floodgates to more poorly implemented games that will just aggravate us even closer to the point of smashing our keyboards through our screens. If we aren't already there.

Re:No compiler is as good as human

[Anonymous Coward]

Wow, you really had a lot of trouble reading that article didn't you?

That or your a bit dim.

Is what Cg really means that hard to grasp? Think of it as a helping hand for all those artists who want to make use of the advanced features promised by pixel and vertex shaders.

Re:No compiler is as good as human

[Anonymous Coward]

That's nonsense. Games are poor because of gameplay, not graphics programming.

Damnit

[sheepab]

I just bought my GeForce 4 TI4600. *sigh* Looks like Ill have to give my other ARM and LEG to pay for the upcoming GeForce 5.

Re:Damnit

[SirSlud]

This technology is compatible with your current card, is it not? My impression is that cG simply makes it easier to generate the same OpenGL and DirectX code games are feeding your GF4 with now. Its to ease the work for the programmer and allow folks to concetrate more on the design of the shaders then their in-code implementation.

Re:Damnit

[Phosphor3k]

Did you expect any different?

And instead of shelling out 300$ for your GF4 TI4600, you should have gotten a Gainward GF4 TI4200 for 150$(shipped, check pricewatch.com). Especially considering they easily overclock to TI4600 speeds with no problem.

Re:Damnit

[sheepab]

I got the Gainward GF4 TI4600....extremely overclockable *nerd smile face*

Re:Damnit

[Phosphor3k]

.....you have my approval.

Is this happenning because of Xbox on Nvidia?

[t0qer]

One has to wonder if this allience is from the current relationship Nvidia and MS has with the Xbox.

Re:Is this happenning because of Xbox on Nvidia?

[PissingInTheWind]

Probably somewhat, to help developers make better looking graphics (or at least make them more easily) on the XBox.

The article claim "cross platform compatibility" on Windows, Linux, Mac and the XBox.

Re:Is this happenning because of Xbox on Nvidia?

[brejc8]

What will happen is that Nvidia only develops the standard DirectX compilers and leaves it open for anyone else to do the others.

This keeps Micro$oft happy as they will get the best drivers at the same time as not insulting the OpenGL community.

They do NOT want every one else to turn their back on Nvidia.

Although most of the customers use M$ most of the poeple that advise them dont. I advised tons of people as to what they want in their PC and I base the advice on how "nice" the company is.

Re:Is this happenning because of Xbox on Nvidia?

[ThrasherTT]

One of the figures in a .pdf on nVidia's site says, "PS2" as well. I believe it was their Cg white paper here.

Re:Render the truth!

[sheepab]

Pluralists would have us to believe that Christianity is just as good as Islam, but I'm here to tell you, sisters and brothers, that Christianity is not just as good as Islam ...Christianity was founded by Jehovah, a demon-possessed incestuous pedophile who had 1 wife -- and she was his 13-year-old mother. And I will tell you Jehovah is not Allah either. Allah's not going to turn you into a terrorist nation that'll try to bomb people for their oil and drop atomic bombs on surrendering nations and take the lives of thousands and thousands of non-Christian people at the whim of your multinational corporations.

Funny how you post that as "Anonymous Coward". Just makes me laugh. Stay on topic with the article, and mods....please dont mark me down for this.

It supports other cards sub-optimally

[Anonymous Coward]

They control what the backend supports, and it suppports only the baseline DX shaders ... since thats all their hardware supports but their competition has a larger feature set and more advanced DX shader versions you can see where the advantage is for them ...

They control the backend, and the backend will always be optimal for their hardware. It only supports their competitors hardware because that increases use by developers ... thats a win win situation, appear to have a cross platform standard but at the same time stack the deck in your favour.

Re:It supports other cards sub-optimally

[ThrasherTT]

They are letting other vendors build their own backend. Think gcc for GPUs...

In Fact......

[friedmud]

From Nvidia's Homepage you can check out the press releases and find this:

"NVIDIA's Cg Compiler is also cross platform, supporting programs written for Windows®, OS X, Linux, Mac and Xbox®."

So maybe even though the tools aren't cross platform - the compiler is. I think this is a Great step forward towards OpenGL 2.0 - this is showing that Windows doesn't have to be the only platform to write graphically intensive applications for.

Derek

good for mac games

[paradesign]

this is good because now it will be easier to create cross platform games. which means more games for linux/mac. that is assuming i read it correctly.

Re:good for mac games

[TheTrunkDr.]

um... you don't read correctly, this really won't make much difference to mac gaming... All this does is make a 3d graphics programmer life a little easier. If he's making windows or mac games it's pretty irrelevent they both get easier, this isn't any incentive to start making a mac game instead of a windows (or whatever) one.

Re:good for mac games

[Anonymous Coward]

Yup! It'll finally remove the one obstacle that's stopping Mac and Linux getting all the best Windows games immediately!

The fact that the Mac market is small and no one in the Linux community thinks they should have to pay for anything.

No, wait, it won't help after all.

Programming language != API

[Anonymous Coward]

Read a Slashdot's description: ""Cg Compiler" compiles high level Pixel and Vertex Shader language into low-level DirectX and OpenGL code"

Cg doesn't need ANY support from the video card.

This is no different from other programming languages. If someone would create new programming language and x86-assemebler for it, then code written in this language would run on ANY x86 CPU. Similary, code written in Cg would run on ANY video card which has Pixel and Vertex Shaders.

There is a great interview with David Kirk (Chief Scientist at NVIDIA) which talks about other Cg's features like on-the-fly compilation of Cg programs.

Re:Linux Support

[jra101]

There will be a linux compiler.

proprietary--scrap it

[Anonymous Coward]

it's not GPL so screw it.

somebody write a nice GPL'd compiler for OpenGL quick and end this BS before it gets too far.

what a waste of effort to keep something nice like this closed.

Re:proprietary--scrap it

[ThrasherTT]

I love comments like this one: "It's not OPEN, it must be a load of CRAP!!!" Raving lunacy, if you ask me (but then again, you didn't).
Aside from the fact that if it WAS open (Mesa's OpenGL 2.0 implementation?), we wouldn't have a stable, well-supported, ubiquitous, working product until 2010.
BTW, game companies need to make money. It's hard to make money selling support services for an open game. Just like its hard to make a quality game without funding of some sort. Just like its hard to live in America without a paying job.

sorta...

[Steveftoth]

There's directX and there's directX 8.1 oh and DirectX 8.1a.
Remember when the Radeon first came out? Well they had to release a special directX just to support it's pixel shaders as opposed to just nvidias.
So as a game developer you'll probably have to compile your Cg code with the Nvidia one and the ATI one just to make it work (better).
This tool will really help those XBox developers.
Same thing with OpenGL, since the spec isn't nailed down yet and with Nvidia 'leading the pack' of development. It wouldn't surprise me if they decided to not support any other cards with the OpenGL compiler (which they haven't even released yet).
So hopefully this will NOT turn into a Glide type issue. Since this is actually a level above glide. Glide was very low level, all the Glide functions mostly mapped directly onto the 3dfx hardware, while this is a little bit more abstract.

One must wonder

[miffo.swe]

I dont think that it should be such a good idea if one wendor would control the backends to the cards. I do dislike directx. Not because it is a vorse standard than open gl but because its not avaliable on every platform. If microsoft has a finger in the game it sure smells funny, that finger is up someones butt if you ask me. Sure it can generate opengl but i would almost presume that the day it gets really widely used it stops or does that in a less efficient way.

Microsoft have never done anything without a hidden agenda (microsoft bob not included).

Re:One must wonder

[Anonymous Coward]

Thank goodness NVidia have decided to team up with Microsoft. At least now we know this language will be done properly.

Sample Code

[JanusFury]

[BEGIN]
SET_PIXELFORMAT(SHINY)
ADD_BUMP_MAPS
BL END_REFLECTION
SET_TRANSPARENCY(0.5)
SET_TEXTURE ("WALL")
[END]

[BEGIN]
SET_PIXELFORMAT(WET)
ADD_BUMP_MAPS
BL END_REFLECTION
SET_TRANSPARENCY(0.3)
SET_COLOR(B LUE)
ADD_FISHIES(YELLOW)
[END]

Just what are shaders?

[Anonymous Coward]

I see things on shaders all the time, but I don't really undersand the difference between pixel and vertex shading...does opengl impliment pixel/vertex shading now? Do things really look a lot better using shaders instead of just using phong and texture mapping? What games that are out using pixel and vertex shaders?

Confused....links would be appreciated.

Re:Just what are shaders?

[91degrees]

Okay - a basic OpenGL or D3d command will send a set of vertices to the card. The vertex will contain position, colour information, a normal vector, and other bits and pieces. The card will transform these vertices, convert to triangles, apply colour and several textures, and output to screen.

A vertex shader will take the vertices before they are transformed, and apply a series of operations on the data inside these vertices. This allows certain clever lighting effects, and nice ripple patterns to be described algorithmically.

The vertices are then converted to triangles as before.

Then the pixel shader is used. Modern applications use several layers of textures. Often, we'll see a texture for the colour, another one giving a bumpmap, andother giving a reflection map. These can be combined in a number of different ways. A pixel shader determines how these textures are applied and combined. A good pixel shader will allow a texture to be defined algorithmically. This looks better than a normal texture map at very large zoom levels. Ken Perlin has done a lot of work on this. Look at his site to see what results you can get. Pixel shaders are getting there, but haven't quite made it.

In practice, all vertex shader operations can be done by the CPU, but this tends to be a bit slower. Pixel shader operations are still at an early stage on current graphics chips, but are getting better. The early Nvidia pixel shaders were no better than the normal texture combiners, but pixel shaders in general are getting more flexible.

Inefficiencies

[Have Blue]

One of these days, nVidia will ship a GPU whose functionality is a proper superset of that of a traditional CPU and then we can ditch the CPU entirely. Just like MMX, but backwards. This is a a recognized law of engineering. At that point, Cg will have to become a "real" compiler. Let's hope nVidia is up to the task...

Re:Inefficiencies

[Arandir]

Damn straight! That CPU just gets in the way. CPUs are for people wanting to use spreadsheets, word processors, accounting, and parsing XML data. Real people just want to play games.

When the GPU can compile its own code, then the computer will finally be freed from those tyrants who want to do use computers for productivity.

Re:Inefficiencies

[Have Blue]

I am being completely serious. A modern computer is an asymmetric dual-processor system. GPUs are already at least as complex as CPUs, and when the shader language becomes Turing-complete (when jumps, conditionals, and some other things are added) the GPU will be a CPU and it will be pointless to ship a computer with 2 unequal general-purpose CPUs.

Re:Inefficiencies

[doop]

They're already heading that way; the Register had an article describing some work being done to do general raycasting in hardware. I guess it's heading towards turning graphics cards into boards full of many highly parallel mini-CPUs, since vertex and/or pixel shading are rather parallelizable in comparison to other things the main CPU might be doing. Of course, OpenGL is already a sufficiently versatile system that one can implement Conway's Life using the stencil buffer, so for a sufficiently large buffer, you could implement a Turing machine; I don't know how much (if any) acceleration you'd get out of the hardware, though.

Re:Inefficiencies

[ceswiedler]

If your logic were correct then a dual-CPU system with a VGA card would run Quake3 as fast as a single-CPU system with a GeForce3.

A GPU is specialized, and (should) have faster access to the system bus. Just because it's as powerful as a CPU, doesn't mean it should be one.

Re:Inefficiencies

[verloren]

The same law applies to IT departments. First IT is centralised to get all the experts synergizing. Then they go out to the business units to be closer to the customer. Then back to a core expert group, out to the customer...

I think of it as a huge pulsating blob that exists only to let successive IT managers justify their existence.

Re:Inefficiencies

[Drunken Coward]

Wired also has a very interesting article this month on Jen-Hsun Huang's (CEO of Nvidia) plans to obsolete the CPU.

Re:Inefficiencies

[Junks Jerzey]

A modern computer is an asymmetric dual-processor system. GPUs are already at least as complex as CPUs

Actually, they're not. An Athlon, for example, has to support hundreds of instructions, branch prediction, integer and floating point operations, SIMD, multiple levels of caches, etc. A GPU, for the most part, supports one basic pipeline, but with lots of parallelism (e.g. 16 pixel units). Now that's an oversimplification, but the principle is there. A GPU does one thing well, while a CPU has to do quite a bit more

Re:Inefficiencies

[juggleme]

Good call. I think they do recognize that though, it was probably a motivating factor in getting involved in the chipset business...

Re:Inefficiencies

[John Miles]

If your logic were correct then a dual-CPU system with a VGA card would run Quake3 as fast as a single-CPU system with a GeForce3.

You're closer to the truth than you think. It pretty much would run just as fast; it's just that the rendering quality wouldn't be competitive. Yet.

The GPU's specialization has more to do with vectorized math and optimized memory access than anything else. Those are both engineering topics that Intel and AMD take very seriously.

Re:Inefficiencies

[krogoth]

Actually, they're more likely to focus on graphics, which gives game developers a sort of dual-processor system. If any other areas of game development were standardized and needed this kind of power (I can think of a few that could use it) they might get accelerators too...

Re:Inefficiencies

[nameinuse2]

The same thought occurred to me when i was contemplating my (very overdue) new 'puter ... turned out the graphics card, a geforce 3, was exactly twice as powerful in clock speed and RAM as my last CPU/mobo ... 266 mhz/64 Meg vs 133 mhz/ 32 Meg ... by the time i upgrade again, i'm wondering if it'd be possible to use the 1.4 Ghz/256 Meg athlon box as the GPU ... (maybe via a really long IDE-like cable from the AGP bus or the like)

Re:Inefficiencies

[Arandir]

And I'll be just as serious. If the GPU becomes a CPU, won't it still be a CPU? Somehow, I think the CPU I already have is more efficient doing spreadsheets, word processor, compiling KDE, playing MP3s and browsing the Slashdot than a GPU-turned-CPU would be.

If you're building a game box, then a general-purpose GPU would make sense. But if I ever see someone running NetBSD on a GeForceXXII as a webserver, I'll puke.

Re:Inefficiencies

[Anonymous Coward]

My friend, the word "efficient" should never be used to describe an x86 processor.

More likely ....

[Anonymous Coward]

they're trying to push something that gives them a leg up on ATI - perhaps making it easier to use the things their chip does well than the ones that ATI does .... these days PC-3D is a VERY cut-throat world

Interesting Comparison

[NitsujTPU]

Did everybody read the comparison between writing in CG and writing hand-optimized assembly code?

Thank GOD they wrote CG, because now I won't have to write all of my programs in assembly anymore.

What is this "compiler" technology that they keep talking about? This might revolutionize computer science!

Re:Interesting Comparison

[grammar fascist]

I'm not sure if you're acting like a moron for the sake of a joke (I do that myself a lot :)) - but just in case you aren't:

It's for programming vertex and pixel shaders. Up until now, all you had was this nearly-evil assembly code to program them with.

It's not as if they've discovered something new, because they haven't. It's that they've applied it to an area that will give more people access to the new cards' powerful new features - which would otherwise go underused because so many people shy away from assembly of any kind.

I was skeptical myself until I saw how they've put it together. I can't wait until I have enough dough to buy one of these cards now...

Re:Interesting Comparison

[NitsujTPU]

Yes... My humor seems to have escaped some.

Not another one of those program-your-gpu lingos

[AltaMannen]

I probably shouldn't be programming 3D videogames since I hate touching hardware chips and much prefer the solutions of Nintendo ("OpenGL-like is the only rendering interface") to the solutions of Sony and Microsoft, but why actually making this shit high-level? Ok for the purpose of writing some sort of optimizer but not for the rendering stuff as I will eventually have to suffer through using something like this.

No, I don't think this language will kill off all the other graphics-wannabe-languages but I think it will join them. Why can't consumers start buying games based on the physics, behaviours, AI, collision and all the other things that are fun to work with instead of basing their purchases purely on graphics?

Besides from my ranting, what does it actually do apart from setting up the material settings before you do the rendering? And isn't that just stuffing parameters into some registers anyway?

Analogy

[Viking Coder]

Cg is to OpenGL 2.0
as DirectX is to OpenGL

It's a closed ("partially open") standard, for a subset of hardware, which is not as forward looking as a proposed competing standard.

Support OpenGL 2.0!

Re:Analogy

[WinterSolstice]

I couldn't agree more. Did that article actually say "low-level Direct X and OpenGL"?

I've written in OpenGL for a long time (first OpenGL game was about when 3dFX came out...) and it is not hard. Freakin' whiners. First assembler is too hard (though I think they do have a point), then C is too hard, then OpenGL is too hard, now DirectX is too hard?

Here's an idea... if you can't write code that is fast, useable, and maintainable GO GET ANOTHER JOB. Stop writing additional layers of abstraction to hog up the CPU and disk.

-WS

Re:Analogy

[Anonymous Coward]

I hardly think thats fair. Cg lets you take advantage of the particular abilities afforded to you by pixed shaders without having to deal with the peculiarities of NvidiavsATIvsParhelion, etc.

-B12

Re:Analogy

[ThrasherTT]

You missed the main point of Cg:

Vertex Shader ASM is hard(er than Cg)
Pixel Shader ASM is hard(er than Cg)

My understanding of Cg is that it'll be used as a shader replacement, NOT an OpenGL replacement. You'll still have to write tons and tons of OGL. Now you can just simplify the SHADER part.

Re:Analogy

[Viking Coder]

OpenGL 2.0 is "the SHADER part."

Cg is attempting to be a replacement for OpenGL 2.0. In that effort, I hope it fails.

Re:Analogy

[ThrasherTT]

That brings up an interesting question: is it better to wait for an Open implementation of something than use a Closed implementation of a similar thing that is available now?

Even if Cg fails, at least it exists *now* and helps developers *now*. How long do we have to wait for OpenGL 2.0? Does it make sense to struggle with multiple implementations of GPU hardware and their ASM's when 95-99% of the experience gained will be useless in 6 months anyway? Why not use the best tool for the task, instead of worrying about whether it is Open or not? If an Open standard of something like Cg (OpenGL 2.0) arrives, and is better, then the market will choose it, right? Just like the market chose to keep OpenGL around when DX hit the scene...

Re:Analogy

[Viking Coder]

I find your points interesting.

What disturbs me though, is NVidia's behavior in the matter.

They could either push to ratify OpenGL 2.0 early, and do everything they can to help the process... Which helps the industry a lot, and helps them, too!

OR, they could create their own closed standard, not help OpenGL 2.0, do everything they can to hurt the process... Which helps them a lot, and makes their competitors in the industry license their technology...

*sigh*

I'd be a lot more comfortable if NVidia were saying things like, "and it provides for the direct and easy translation of Cg code into the proposed OpenGL 2.0 standard, so that code written today can be easily migrated to the OpenGL 2.0 standard, once it's ratified."

Re:Analogy

[ThrasherTT]

I agree, nVidia should make it clearer that this will help in the OpenGL 1.x to 2.0 transition easier. Perhaps they have interesting ideas that the ARB doesn't like, so they put them out anyway as Cg, to test the market's response. IMHO, Cg will make the world a better place, either by becoming a standard, or by forcing another standard to improve. nVidia has smart people, they make good hardware, and excellent drivers. They support (to a degree) Linux. I'm definitely biased toward them because of their products' performance, but I agree that open standards are better than closed ones.

Re:Analogy

[be-fan]

Try reading the article. OpenGL 2.0 is the next version of OpenGL. Most of it is about making OpenGL object-oriented, programmble, etc. One small part of it is a high-level shader language. Cg is another high level shader language. Both can be compiled to any particular hardware. An analogy is C and Pascal. Both ultimately compile down to x86 or MIPS or whatever, so they're actually not competing with each other or replacing each other.

Re:Analogy

[Viking Coder]

I'm intimately familiar with the details of OpenGL 2.0. I would disagree with your assesment that "most of it is about making OpenGL object-oriented, programmable, etc. One small part of it is a high-level shader language." I disagree entirely with your assesment that it's a small part.

C and Pascal are most definately competing with each other and replacing eachother. I've been programming in Pascal for 21 years and C (and C++) for 14 or so. I never get to code in both languages at the same time. It's possible to mix code from each, but it doesn't happen that often (other than in the form of pre-compiled libraries.) It's simply not efficient to ask all of the developers on one project to understand the intracacies of both programming languages and be effective at programming in both at the same time.

The same argument holds for Cg and the shading language component of OpenGL 2.0. I doubt that people will be succesful at mixing Cg in with OpenGL 2.0 code.

Re:Analogy

[be-fan]

I'm not claiming that the shader language for OpenGL 2.0 is not important. But it is still a relatively small part of a much bigger overhaul. They key idea in OpenGL 2.0 is that GPUs should be programmable. What language is used to do it is really not relevent, since it will all get compiled down to GPU-specific code anyway. As for how you feel about multiple languages, you're entitled to your opinion. But I'd argue that you're in the minority on this point. Most people feel that choice in languages is a good thing. The fact that there are many active, popular languages today (C++, C, Perl, Java) is an indication that the market is large enough for multiple choices. As long as Cg is relatively open (ie: anyone can write back-end compilers for it) then I don't see the harm in it existing alongside OpenGL 2.0. And remember, while people might not like proprietory APIs like Direct3D, they have ultimately helped OpenGL in the end. I'd venture that if it wasn't for DirectX 7.0 and up being really good, there would not have been a push for OpenGL 2.0 to even exist. The sole fact that Microsoft and NVIDIA are pushing the limits of consumer 3D hardware is forcing OpenGL to become better instead of simply stagnating as it was previously.

Re:Analogy

[Viking Coder]

You've made some excellent points, but I don't think you're correct in a fundemental assumption.

I don't think people are free to write a back-end compiler for Cg. I don't think nVidia has released the Cg language into the public domain, and I don't think they intend to license the language for reasonable terms. I think they intend to control the language, with the option of other vendors supplying profiles to the one and only Cg compiler (e.g. fp20, vp20, dx8vs, dx8ps).

You are absolutely correct that competition has ultimately helped the graphics industry. I just wish that the competition of shading languages was between competing open standards. Not one open standard, and one closed standard.

Re:Analogy

[be-fan]

That's a lot of assumptions to make. I guess we will have to see what NVIDIA does. However, the article did point out explicitly that NVIDIA intended to keep parts of the compiler open and allow other vendors to write customized backends optimizing for their hardware. The main issue here is that NVIDIA has almost zero control over what Cg has the capability to do. Cg has to map fairly strictly the underlying capabilities of the DirectX and OpenGL shader languages. If it doesn't, NVIDIA risks producing a language which nobody will use. In addition, NVIDIA has been pretty good to the community in the past. They've release a lot of their programming tools for free, they've made drivers for Linux, and they were instrumental (with the Riva TNT-1, back in the day of Glide and MiniGL drivers) in getting full OpenGL ICDs onto consumer level platforms. So I would give them the benifet of the doubt and see what they do before expecting the worst...

Yeah, but...

[NetRanger]

There are some issues that I think nobody seems to be addressing, as in:

* Realistic fog/smoke -- not that 2-D fog which looks like a giant translucent grey pancake. Microsoft comes closer with Flight Sim 2002, but it's not quite there yet.

* Fire/flame -- again, nobody has created more realistic acceleration for this kind of effect. It's very important for many games.

Furthermore I would like to see fractal acceleration techniques for organic-looking trees, shrubs, and other scenery. Right now they look like something from a Lego box. In fact, fractals could probably help with fire/smoke effects as well, to add thicker & thinner areas which take on a "semi-random", but not an obvious pattern, effect.

Perhaps I'm just too picky...

Re:Yeah, but...

[Anonymous Coward]

"Fire/flame "

Return to Castle Wolfenstein flamethrower is as realistic as the real one.

Re:Yeah, but...

[Anonymous Coward]

I suggested this when I worked in 3Dfx...sigh

Re:Yeah, but...

[Anonymous Coward]

What you're talking about is volumetric fog/smoke and volumetric fire/flame. RTCW has volumetric fire/flame I believe. Volumetric effects are nothing new, but most cards can't handle all of those effects and keep the FPS up.
Probably with the newer 3d engines and g3+ cards, we will see more of these types of effects.

Re:Yeah, but...

[ThrasherTT]

And if Cg supports those types of effects NOW, we can code for them NOW, and when the cards that CAN display them without bogging down the framerate, we can play the games with those effects immediately. We won't have to wait until OpenGL 1.4 with NVIDIA_COOL_FLAME_EFFECT_EXT to be widely available.

Re:Yeah, but...

[Doktor Memory]

Actually, the Serious Engine does a pretty impressive job with both fog and flame effects. It's still a few steps away from realistic, but it does a substantially better job than the Unreal or Quake technology at the moment.

The demo versions of both Serious Sam games have a "technology test" level you can walk through in single-player mode that shows off the engine's capabilities pretty well.

hihgly detailed facial features in Cg

[Anonymous Coward]

Does this mean they'll finally be able to make a decent nose-picking routine for Counter-Strike hostage models?

Re:Linux Support

[Mr. McGibby]

Who the hell cares if the toolkit works in Linux? All I need is a compiler, which I'm sure will be released for Linux.

other hardware shading languages

[mysticbob]

there's already lots of other shading stuff out there, nvidia's hardly first. at least two other hardware shading languages exist. these languages allow c-like coding, and convert that into platform-specific stuffs. unfortunately, none of the things being marketed here, or now by nvidia, are really cross-platform. references:

• opengl shader.
• a great paper on the hardware shading problem, and a very generic approach.
• stanford's rtsl.
• the proposed opengl2 also has a hardware shading abstraction language.

of course, the progenitor of all these, conceptually, is renderman's shading language.

hopefully, opengl2's shading will become standard, and mitigate the cross-platform differences. it's seemingly a much better option than this new thing by nvidia, but we'll have to wait and see what does well in the marketplace, and with developers.

Re:other hardware shading languages

[goatee]

You seem to have missed the pretty pictures that show Cg is an abstraction layer above OpenGL and DirectX. Wham, bam, two APIs in one, Sam.

Re:other hardware shading languages

[CityZen]

But you seemed to have missed the point that Cg and OpenGL 2.0 (shading language) are trying to do the same thing. Why try creating yet another new standard? How about just compiling OpenGL 2.0 shader programs into DirectX?

Re:other hardware shading languages

[goatee]

Why try creating yet another new standard?

Huh? Cg is not another API. Cg is a tool that allows programmers to write shaders and other functions in an OpenGL/DirectX independent fashion. Yes, both Cg and OpenGL2 are trying to simplify writing shaders, but Cg is not a new API that card manufacturers have to support. I won't hold my breath for an OpenGL->DirectX converter either; why convert open to proprietary?

(I am not necessarily a supporter of Cg. I'd rather see DirectX dropped on its face, and have OpenGL support in every application. In the mean time, Cg appears to be a viable, work-saving solution for graphics programmers who want to support both APIs.)

Low level?!

[Anonymous Coward]

Since when is DirectX and OpenGL "low-level"?

Re:Low level?!

[kyoko21]

3dlabs's cards of opengl 1.2 implemented on silicon in case you were wondering.

Duke Nukem

[DeadBugs]

If this makes it easier to create high end video games maybe it could boost the Duke Nukem release schedule. I did say maybe

READ THE ARTICLE!

[dextr0us]

I would appreciate it if you would stop spewing your nonsensical dribble on the board. Go and read the article. To all you that have asked the question: Is it cross platform? read the first paragraph of the article at cg channel Graphics giant NVIDIA today announced Cg, an initiative with participation from Microsoft to create a cross-platform, hardware-independent, high-level Pixel and Vertex Shader programming language. can i emphasize CROSS PLATFORM and HARDWARE INDEPENDANT. It ports to DX and (nvidia's) open GL. I really wouldn't worry about its cross compatibilty. All (relevant) cards have drivers for Open GL and Direct X.

Re:READ THE ARTICLE!

[Anonymous Coward]

an initiative with participation from Microsoft to create a cross-platform, hardware-independent, high-level

HAHAHAHAHAHAHA...

oh wait I'm OK now....

BLHAAHAHAHAHAHAH

When pigs fly out of my ass and mutate into fine wine!

Re:READ THE ARTICLE!

[Anonymous Coward]

I don't see a single person asking if it's cross platform, so they're can't be many asking. Why didn't you just reply to that specific person instead of starting an inappropriate, out of place, new thread?

Re:READ THE ARTICLE!

[dextr0us]

I have a tendancy to trust NVidia, since it is their language, but you know, they could be lying.

Re:Linux Support

[Anonymous Coward]

YHBT. YHL. HAND.

In conjunction with Microshit?

[Anonymous Coward]

So, more proprietary antics from Microshit to better exploit the people?

Re:Linux Support

[friedmud]

Did you see the screenshots of the toolkit??? They were previewing effects IN REAL-TIME! That would save anyone a load of time.

What you said is basically like saying - "I don't need a C++ debugger for linux as long as I have my trusty compiler!"

That may be correct for small/medium projects - but we all know that debuggers (like gdb) save us loads of time.

Derek

No loops?

[joeblowme]

I don't code games for a living but I thought I would check out thier toolset and documentation. While reading through the documentation there is a big note that for and while loops are not supported yet. They are eventually planned to be supported they just aren't yet. You'd think when deciding which functions to include in a programming language the ability to do a loop would be essential but I guess not maybe coding games is mostly event driven so you don't need loops very often. I just thought this was strange.

Re:No loops?

[nat5an]

As I understand it, this is because the pixel/vertex shading virtual machine does not, in fact, support branching or conditional branching, so you can't actually do a loop in the low-level language, so you can't do it in the high-level language either.

Re:No loops?

[Anonymous Coward]

The problem is that current GPUs (GF4, Radeon 8500) don't support loops in Vertex/Pixel-shader programs.
This problem will be resolved in next-generation hardware (NV30, R300)

Re:No loops?

[GameMaster]

The actual assembly language used by the present generation of shader supporting video chips has no support for loops and only marginal support for conditional statements (meaning no explicit jmp op). Since this is the code that the cg compiler compiles down to, they can't add those features to the language. It makes some sense because shaders are meant to be short and sweet. Event though they are hardware accelerated, they get run so many times that even a shader that uses only the max number of ops (which is now at 128 ops for NVIDIA chips) is considered pretty slow. If loops were added it would slow the system down even more. When they say those features are "eventually planned to be supported" they mean that they'll be supported by a future generation of hardware (most likely the directX9 compatible chips).

-GameMaster

Re:No loops?

[Anonymous Coward]

This is only for pixel and vertex shaders. It is only used to create things like cool texture affects. It is not used for general game programming. The code you write in Cg is run on the newer graphics cards, and neither ATi or nVidia allow looping in their pixel and vertex shaders

Re:No loops?

[be-fan]

This isn't game programming. Its very low-level, per pixel stuff. A sample pixel shader program (multitexturing) , written in BFSL (be-fan shader language):

temp0=READ texture1[x, y];
temp1=READ texture2[x, y];
output=BLEND temp0, temp1;

The programs are extremely simple, with a few inputs, one output, and a few dozen instructions. More of a function than a program, really. These programs in no way replace any game logic. They just transform the vertex and pixel values passed to the graphics card.

Re:No loops?

[XMunkki]

This is only so that they can support the current hardware now, and add support for the future cards (which will most probably have something other than purely linear shaders) later.

It's only reasonable. Of course they could've made a train with all the bells and whistles, but then, who's gonna use it now? No one.

Good metaphor, poorly executed

[Anonymous Coward]

Indeed but lets take the case of x86 code generated by Intel's compiler ... of course there is no 3DNow! support (the equivalent of PS 1.4) of course code generation is optimal for Intels pipeline etc etc.

So yes code generated by such a compiler can run on anything, but it will run best on whatever the person who controls the compiler wants it to run best on. Which is to say NVIDIA hardware.

Who says?

[Anonymous Coward]

I have seen speculation, but nothing directly attributed to NVIDIA.

Options

[Anonymous Coward]

Which option goes with which answer...

????

Syntax

[Anonymous Coward]

Them _ are sure used sparingly in the second example... expand for us stupid coders...

Microsoft's Participation...

[ackthpt]

Hmm... How long before we have Graphic Card Worms/Subliminal messages...

Segue to someone playing a video game at a high frame rate...

Gee, the more I play this game, the less bad I feel about buying proprietary technology and the angrier I get at those 9 states for disagreeing with the DoJ Settlement. Oh, and I'd like to buy all of Britney Spears CD's and eat every meal at McD's... I'm sure I didn't feel this way yesterday... What's odd, too is that every so many frames seems to flicker something I can't quite make out...

Screen breifly flickers something else

Hmm... I can't remember what I was just thinking about, but I do have the strangest desire to email all of my personal information and credit card numbers to mlm5767848@hotmail.com...

Comment removed

[account_deleted]

Comment removed based on user account deletion

Oh Boy, Another Layer.

[Quixadhal]

Yeah, just what the world of Bloated Sac Hardware needs... another layer of GOOP to get between the programmer and the hardware.

Are all you people out there really so damn LAZY that you can't just program efficiently anymore? Has C++ and Microsoft managed to turn ALL your neurons to mush?

Anyone remember the games we had on the Commodore 64? Don't whine about how they weren't realistic, or how they didn't have UberMondoSurroundSound... they were fun! In fact, they were a hell of a lot MORE fun that 90% of the crap that takes up 3 cds and requires a Gigahertz CPU to run these days.

Yeah, go use your high level languages for writing database queries, and doing year-end financial reports... but for God's sake, don't use it for things where speed matters!

Oh yeah, to all the modern programmers out there... for every malloc(), there should be a free().

Re:Render the ghostse!

[Anonymous Coward]

Dude, get with the program, everyone knows that the Neo-Goatse is the real deal these days. That other goatse guy is passe.

It's a "High-Level Language"!

[dmarsh]

Here's my understanding:

Cg is to vertex shader assembly as C++ is to x86 assembly.

It's a proprietary high-level language, sure, but the assembly code it emits is 100% standard and will run on any GPU that supports DirectX 8.x and up.

Oh now i understand...

[KlomDark]

So you use cc for normal CPU code, and gcc for Graphics (GPU) code. Makes sense. I'd been wondering about that...

j/k :)

Hard to see what that means

[Anonymous Coward]

If they can add their own profiles thats nice, but it seems unlikely that things like software pipelining can be specified in them ... so that would basically still mean competitors would have to write their own compiler if they want a level playing field.

They can keep their secret sauce, the question is ... is their framework open enough to allow competitors to put in their own secret sauce.

Re:Hard to see what that means

[Dark Nexus]

Well, it flat out says that they would have to write their own compiler.

But you're right about the framework being open enough, though I think it's more a matter of it being worth it to put in their own secret sauce, and not if they can.

I guess time will tell.

What Cg means

[Effugas]

Seems like a decent number of people have absolutely no clue what Cg is all about, so I'll see if I can clear up some of the confusion:

Modern NVidia(and ATI) GPU's can execute decently complex instruction sets on the polygons they're set to render, as well as the actual pixels rendered either direct to screen or on the texture placed on a particular poly. The idea is to run your code as close to the actual rendering as possible -- you've got massive logic being deployed to quickly convert your datasets into some lit scene from a given perspective; might as well run a few custom instructions while we're in there.

There's a shit-ton of flexibility lost -- you can't throw a P4 into the middle of a rendering pipeline -- but in return, you get to stream the massive amounts of data that the GPU has computed in hardware through your own custom-designed "software" filter, all within the video card.

For practical applications, some of the best work I've seen with realtime hair uses vertex shaders to smoothly deform straight lines into flowing, flexible segments. From pixel shaders, we're starting to see volume rendering of actual MRI data that used to take quite some time to calculate instead happening *in realtime*.

It's a bit creepy to see a person's head, hit C, and immediately a clip plane slices the top of guy's scalp off and you're lookin' at a brain.

Now, these shaders are powerful, but by nature of where they're deployed, they're quite limited. You've got maybe a couple dozen assembly instructions that implement "useful" features -- dot products, reciprocal square roots, adds, multiplies, all in the register domain. It's not a general purpose instruction set, and you can't use it all you like: There's a fixed limit as to how many instructions you may use within a given shader, and though it varies between the two types, you've only got space for a couple dozen.

If you know anything about compilers, you know that they're not particularly well known for packing the most power per instruction. Though there's been some support for a while for dynamically adjusting shaders according to required features, they've been more assembly-packing toolkits than true compilers.

Cg appears different. If you didn't notice, Cg bears more than a passing resemblance to Renderman, the industry standard language for expressing how a material should react to being hit with a light source. (I'm oversimplifying horrifically, but heh.) Renderman surfaces are historically done in software *very, very* slowly -- this is a language optimized for the transformation of useful mathematical algorithms into something you can texture your polys with...speed isn't the concern, quality above all else is.

Last year, NVidia demonstrated rendering the Final Fantasy movie, in realtime, on their highest end card at the time. They hadn't just taken the scene data, reduced the density by an order of magnitude, and spit the polys on screen. They actually managed to compile a number of the Renderman shaders into the assembly language their cards could understand, and ran them for the realtime render.

To be honest, it was a bit underwhelming -- they really overhyped it; it did not look like the movie by any stretch of the imagination. But clearly they learned alot, and Cg is the fruits of that project. Whereas a hell of alot more has been written in Renderman than in strange shader assembly languages (yes, I've been trying to learn these lately, for *really* strange reasons), Cg could have a pretty interesting impact in what we see out of games.

A couple people have talked about Cg on non-nVidia cards. Don't worry. DirectX shaders are a standard; game authors don't need to worry about what card they're using, they simply declare the shader version they're operating against and the card can implement the rest using the open spec. So something compiled to shader language from Cg will work on all compliant cards.

Hopefully this helps?

Yours Truly,

Dan Kaminsky
DoxPara Research
http://www.doxpara.com

Re:What Cg means

[SanLouBlues]

All one needs for volumetric rendering ("voxels") is 3d texturing capability.

Re:What Cg means

[Effugas]

Depends on your approach. Klaus Engel and company are all sorts of interesting isosurface and direct volume rendering in realtime of really high detail models -- check out:

http://wwwvis.informatik.uni-stuttgart.de/~engel /p re-integrated/

That's being done in realtime. They're doing more than just slapping slices on top of eachother and letting 'em alpha blend. :-)

--Dan

Re:What Cg means

[Anonymous Coward]

Even that I appreciated you writing this most enlightening piece, why did you have to end it like

DirectX shaders are a standard; game authors don't need to worry about what card they're using, they simply declare the shader version they're operating against and the card can implement the rest using the open spec.

Since excaly when has MS ever created anything resembling an "open specification"?! Yes, this might be seen as MS bashing but this is bloody well founded bashing then, isn't it!

Expression: +5:
Ending: -7

Re:What Cg means

[krogoth]

Actually, Cg is "C for graphics" - you can guess what language it comes from.

OpenGL vs DirectX

[Iscariot_]

I'd be interested to see which implementation is faster, OGL, or DX. Seems like they're awfully in bed with MS on this... Does this make anyone else nervious?

Re:OpenGL vs DirectX

[Anonymous Coward]

I don't think NV is exactly "in bed" with MS. But huh, lets see. 98% of all games use DirectX. DirectX is made by MS. NV and MS have a good relationship currently (ala Xbox). NV sells the most 3D cards and 3D cards for gamers. It only makes sense. If ATI/Matrox/3DLabs are so great, why haven't the proposed a cross-platform, hardware independent, semi-OSS, shader language? Cg is compatibile with both DirectX and OpenGL.
How come the OSS/FS communinity, which has spawned a number of languages, haven't come up with and tried to push their own shader language. I wouldn't be suprised if NV released at their Cg compiler for Linux. If not, I'm sure the spec will be available so someone can implement it on their own.

Re:OpenGL vs DirectX

[cREW oNE]

Does it surprise you? Do you *really* think an even remotely significant userbase buys GeForce 4 class cards and then proceeds to run X and Mozilla with it?

nVidia is in the business of selling cards to PC gamers. Most gamers use windows, because that's where most of the games are.

For nVidia, it's a good thing to be in bed with MS. Because that sells cards.

Re:OpenGL vs DirectX

[Anonymous Coward]

no.

What about the OpenGL 2.0 shader language?

[Fnord]

If I remember correctly, one of the major features of OpenGL 2.0 was going to be a high level language and compiler that would compile down to low level pixel and vertex shader assembly. And, if I'm not mistaken, nVidia was one of the biggest contributers to this language. Has nVidia decided to just screw OpenGL altogether? Or is this a temporary equivalent for the time being while we're still using OpenGl 1.2?

Re:What about the OpenGL 2.0 shader language?

[Anonymous Coward]

I believe the intent is to kill OGL2. NVidia, while acknowledging OGL2, has not really warmed up to it or contributed a lot, as it is a threat to their market and API domination of pixel-shader hardware.

They want an API that while being 'cross-platform' and 'vendor-neutral' on the surface, they still control and they can slant in their favor.

While it says it's cross-platofrm and vendor-neutral, they don't have to spend much time designing it to work well on other hardware.

Re:What about the OpenGL 2.0 shader language?

[mallan]

Why do people think that Cg competes with OpenGL 2.0? Cg supports both OpenGL and DirectX. It is an abstraction layer which allows you to write PORTABLE code. This is a GOOD THING. When OpenGL 2.0 comes out, all that is required is a new back end on the compiler, and you can reuse existing Cg shader code. You can't use OpenGL 2.0 shaders on DirectX or OpenGL 1.2, can you?

Re:What about the OpenGL 2.0 shader language?

[Fnord]

That wasn't my point. DirectX shaders and OpenGL (1.2) shaders are done through C function calls that manipulate the GPU's shader assembler. OpenGL 2.0 was going to do away with this by defining a compiled language for shaders that would compile down to OpenGL extensions for whatever video card you're using. Theoretically, the OpenGL 2.0 shader language could be compiled into DirectX calls as well. And I realize that Cg could compile to the same OpenGL calls that the shader language does, what I'm wondering is why nVidia is pushing this in the first place, considering they helped define a large chunk of the OpenGL shader language. Yes it can co-exist, but they're not complementary, they're redundant.

Microsoft's C?

[slagdogg]

An amusing tidbit from the News.com (http://news.com.com/2100-1040-935595.html) coverage:

"The programming language, called Cg, was developed in collaboration with Microsoft and is similar to the software giant's series of C languages for writing Windows code, said Chris Seitz, Nvidia's manager of development tools."

I didn't know that Kerrigan, Ritchie and Stroustrup were all Microsoft employees. Embrace and extend is one thing -- but embrace, extend, and then pretend that you owned it in the first place? Impressive!

standards

[Funk_dat69]

>>However I wonder if ATI will be willing to support a standard which NVidia controls

That never stopped IBM from using and developing Java!

Their website

[Screaming Lunatic]

Their website is at www.cgshaders.com. Their is a coding contest, some articles, and forums to ask questions.

Re:Their website

[Screaming Lunatic]

actually, that was www.cgshaders.org. Yes, I am a dumbass.

Download File Sizes

[Anonymous Coward]

Now, I'm not a math wiz, but sumthin here just don't add up:

NVIDIA Cg Browser 4 MB
NVIDIA Cg Compiler 3 MB
Cg Users Manual 1 MB
Cg Specification 8.2 MB

NVIDIA "Cg Toolkit" (All of the above) 86 MB!!!!

What'd they do, include a game or something?

Enquiring dial-up users wanna to know.

OT - Bandwidth of a 747 filled with CD-ROMS

[brianvan]

This piqued my curiosity.

Assumptions:

Capacity of 1 CD - 650,000,000 bytes
# of CDs that will fit into 1 cu ft comfortably - 400
Cargo space on a 747 - 6,190 cu ft

plus - you'll have enough CD-ROM drives available on either end to write 2.5 million CDs in 1 hour, and read 2.5 million CDs in 1/2 hour (about 125,000 drives - not an impossible number)

plus - the CDs on the shipping end are packed as they are burned, adding little or no time to the process of loading - same goes for receiving end. This assumes you have about 25,000 hard workers.

The flight time from Paris to New York is 6 1/2 hours. Writing/packing is 1 hour. Reading/unloading is 1/2 hour. Total time 8 hours. Total bits transfered is 12,875,200,000,000,000 bits, or 12,875 terabits (1,609 terabytes). Total time for transfer, 8 hours.

Resulting bandwidth: 447 Gb/sec, or 56 GB/sec.

New York to Miami would be 894 Gb/sec, or 112 GB/sec.

Sounds impressive, but you might want to reconsider laying fiber considering the impossible costs and logistics...

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[3prong]

Very cool assessment.

But the sig did say "a 747 filled with CD-ROMs," and not "a 747 whose cargo space is filled with CD-ROMs."

So what happens if you include the passenger cabin, cockpit, and all overhead bins in the calculation?

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[Anonymous Coward]

Well, if you fill the cockpit then you have difficulties taking off and landing and your bandwidth very rapidly approaches zero.

Other questions are at what point do you exceed the weight capacity of the aircraft? Are you including CD cases? If not, how are you protecting the data from scratches during turbulence?

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[CaseyB]

Cargo space on a 747 - 6,190 cu ft

It can only carry the equivalent of one 18' cube? (Oh, I see where you got your numbers. Why are you assuming a plane with passengers? Cargo versions are closer to 25,000)

If you're packing CDs solid, then you'll hit the 113,000 Kg limit long before any volume limit anyway.

One offhand reference suggests 9kg/500 cds, or around 6.3 million discs.

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[Anonymous Coward]

....

you scare me

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[Russ Steffen]

You need to add one more assumption to your assesment: maximum takeoff weight. When I did this thought experiment a long time ago, assuming a 747-400 freightliner full of DAT tapes, it was apparent thet you could only use about 60% of the available cargo space and still have a plane that could get off the ground.

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[GameMaster]

Well, as someone else in this thread mentioned there is no reason you couldn't use the passenger compartment as cargo space which makes your only real limit the plane's max cargo weight. It was also mentioned that the max cargo capacity of a 747 is ~113,000Kg meaning ~6.3 million CDs (9Kg/500CDs). This means that you could carry ~4,095 TB (32,760 Tb) per trip. That comes to ~ 1.1375 Tb/second bandwidth between New York and Paris.

I was thinking about it and I believe it would be more efficient to use hard drives instead of CDs. In particular the largest IDE hard drives listed on pricewatch.com are 160GB Maxtor 5400rpm ATA 133/100 drives selling for ~$235.00. IDE drives are both the largest drives on the market as well as the least expensive per MB. Using the drive's weight off of the Maxtor web site (0.580Kg) you can carry 194,827 drives on a 747. This means a total of ~31,172.41 TB (2,493,793.31 Tb) of data onboard. On the same trip from New York to Paris this would make the bandwidth ~8.659 Tb/second

While it sounds pretty impressive, there is a down side. The hard drives have a per MB cost of ~$0.00146875 while the CDs cost ~$0.000238461 per MB. On the other hand, with the hard drives there would be no need to purchase the ~125,000 CD-ROM drives for the receiving side and the 125,000 CD-RW drives for the sending side (assuming you were only going one way, otherwise its 250,000 CD-RW drives). You would only need to purchase the systems to plug the drives into which would be needed either way. Also, the vastly increased transfer rates for the hard drives would decrease loading and unloading times. In the end, the most expensive part of this whole affair would probably end up being the costs associated with the 747 itself (purchase/rental, fuel, crew, etc.). If you were to add the cost of extra equipment, the plane, labor, etc. to the equation when calculating cost per meg I think you'd end up coming out ahead with the hard drives. Another alternative would be to use DVD-RW disks which, at 4.7 GB per disk, come out costing $0.000382978 per MB.

None of these calculations take into account the sheer number of coasters that are likely to be produced while trying to burn that many CD-Rs. Also, they don't account for the fact that, at these quantities, all this computer equipment could most likely be purchased directly from the respective manufacturers at the same cost retailers pay for it.

I would love to have some information on what it would realistically cost to run an airline that did nothing but this and see if it could be made even close to economical for extremely large file transfers. Unfortunately, I don't really know where to start looking for costs relate to running a 747 or paying for the labor and I don't really have the time to research it. Maybe I'll save it for another day when I get really board. ;-)

BTW - Another nice advantage of using hard drives instead of CD-Rs is that you can re-use the hard drives.

- GameMaster

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[__aawsxp7741]

Awful ping times, though...

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[brianvan]

Nice addition to the original post.

My only concern with the hard drive solution is that if you hit a little bit of turbulence, you just knocked 50,000 drive arms out of place, ruining 25% of your data. DVD-RWs would be less fragile, and are probably the happy medium to all this.

We should save this page, because who knows who might use this kind of transfer someday... after all, the main transoceanic cable laying company (Tyco) is having some problems right now, so who knows what kind of wacky desperate solutions people might come up with in a future bandwidth crunch?

Re:OT - Bandwidth of a 747 filled with CD-ROMS

[GameMaster]

Well, hard drives do have a decent amount of shock resistance. Also, you could put a layer of styrafoam between the hard drives to absorb shock. Also, when you deal with CD-Rs, you may not have to think about shock but you will have to think about scratches. Assuming you planned on storing the CD-Rs on spindles, it would take up a decent amount of space if you tried to place a layer of, even thin, soft material between each CD-R.

As for storing it, I've already stored the .doc file I typed up the original post in though I doubt this will ever be practical concidering the extremely high overhead and the fact that most applications would demand far better latency than a 16+ hour ping. ;-)

-GameMaster

Just a Pre-Compiler

[bigman921]

This seems to be just a pre-compiler to call all of the glVertex() funtions needed to perform accurate shading. It seems to be a tool from the programmers end, not the card's end.

Re:Just a Pre-Compiler

[GameMaster]

Actually, it is lower level than that. Vertex and Pixel shaders are independent of OpenGL or Direct3D. They are short pieces of code compiled down to a special, limited, machine language understood by the video card. The programmer sets a certain shader up as a state change and then uses glVertex() or drawIndexedPimitive() to render the geometry. When each vertex is rendered, the shader code is performed on it.

You are right, however, that cg is a tool on the programmer's end. Like any mid-to-high level programming language, it is designed to make it easier for the developer to write code as opposed to having to write all shaders in difficult to understand/read shader assembly. This will, hopefully, allow a game developer who isn't as big a hardcore coder as someone like John Carmack to create shader effects in a reasonable amount of time. It will also allow coders who are that good to prototype shader ideas faster and figure out if they'll work.

-GameMaster

OpenGL 2.0

[XenonOfArcticus]

IMHO, OpenGL 2.0 is more portable, less NVidia-specific and backed by more manufacturers. Cg is a ripoff of OpenGL 2.0's design, in a cheap attempt to turn it into a NVidia/Microsoft controlled standard.

Remember, NVidia may be good now, but they got where they were by being competitive and overturning old-guard 3D guys (like 3DFX who were themselves trying to lock the industry in to APIs they controlled).

Competition=good.
Single-vendor-controlled APIs=bad.
OpenGL2.0=good.

Now, Ilike my NVidia hardware as much as the next guy, but I fear lock-in. Seems like most of us have already experienced the downsides of lock-in.

Yes, NVidia is talking up the buzzwords "portable" and "vendor-neutral" but if that's what they were after, the wouldn't have created Cg at all, they would have gone with the already-available open standard, OpenGL2.0. This is embrace, extend and extinguish.

Re:OpenGL 2.0

[Merlin42]

You make some good points. Although one could make a reasonable arguemnt for NVidia avoiding OGL2.0.
1) NVidia _needs_ a solution that is "portable" to both OpenGL and Direct3D.
*Many of the current game developers who are driving sales of thier cards have a significant amount of investment (in both LoC and experience/knowledge) in D3D that they will not abandon even if OGL2.0 is far superior.
*They still need good OGL for breaking into the high profit margin profesional sector and for the latest iD engine.
2) Directly bringing the programability aspects of OGL2.0 into DX would not fly. M$ would never admit that someone else has a good idea (at least not until after that idea has been purchased).
3) They need to have competitive buzzwords for use when the P10 is released.

therefore Cg was their solution, and it gave them the operatunity to write some massively forward looking buzzword loaded press releases :)

Like C?

[ruiner13]

Why did they make it like C? You'd think they'd base it on a more object-oriented language like Java. I'm guessing when you are designing 3d worlds (or objects) being able to create objects with their own private methods and properties would be a lot better. Until I actually see the language syntax, I'll pass judgement, but for now... C? Come on... I've used C, Perl, Java, VB, C++ and a few others, and C is the last one I'd choose to base a new language's syntax on, if I had a chance.

Re:Like C?

[GameMaster]

One of the things a lot of people seem to be missing is that this is a special language used only for shader design. Vertex shaders area lot like inline assembly functions in C or C++. They are small pieces of code that do a short string of operations over and over again in hardware.

It makes a lot of sense to base it off of C for a number of reasons. First, most game programmers are familiar with C or C++. Second, and more important, there are extreme limitations on the size of shaders. Vertex shaders have a limit of 128 ops on a geforce card. This is just base ops and can go away real fast when you use macro commands (which are composites of multiple ops) as are most likely available in cg. Future cards will, no doubt, increase the number of ops allowed per shader but it will be a while before we see shaders that are large enough to find any use for OOP features. If we do find a time where some OOP features would be handy then I'm sure they could add basic OOP functionality similar to C++.

-GameMaster

Re:Like C?

[donglekey]

That's a very good question, and the answer is that even very complex shaders don't really get complex enough to require OO. They are all about algorithms and don't benefit a whole lot from design. They are very idependant modules by themselves, so the modularity is inherent.

Right, but it's not in the HW yet.

[Steveftoth]

Cg does because that's the next feature they are planning on adding to the hardware.

Basically, after they do that programming a PC game will be similar to programming for the PS2. You'll have to write multiple programs that are all executing concurrently to use all the power you've got at your disposal.

Re:Right, but it's not in the HW yet.

[Anonymous Coward]

Yes and no.

Developers won't be responsible for managing every memory fetch, quad-buffering data, or any of the truly nasty techniques that are required to obtain passable results from the PS2.

While multiple programs will be running at once, all of the ugly hardware-level things will be abstracted away. Developers are already somewhat accustomed to taking advantage of parallel execution in PCs (the basic DX7/OpenGL multitexture blend operations are very rudimentary shaders). Taking advantage of programmable shading hardware isn't much more difficult than this -- the bottleneck has been the difficulty of writing high-quality (and high-performance) shaders.

Glide didn't doom 3dfx.

[glrotate]

Inferior products did. How could supporting a third API doom the company? How could the parent be modded up as insightful?

If a dual CPU system had the kind

[Steveftoth]

of bandwidth that the average graphics card has then it would.
Also don't forget that a GPU has more transistors then the average cpu these days.
The VGA -> CPU interface was SLOWWWWW. In fact it's still slow, that's why AGP (X8) was invented and that's even slow. The graphics cards have larger buses, and are designed to push data to the DAC.
All you need is more bandwith for the CPU and you're set.

Re:If a dual CPU system had the kind

[Anonymous Coward]

I am ignorant on this topic, but I'll ask anyway. Isn't AMD's new HyperTransport bus supposed to be a big jump in bandwidth? It replaces the PCI bus, correct? Would this help out the CPU and GPU?

Re:If a dual CPU system had the kind

[UranusReallyHertz]

I have been wondering for a while now why the wicked fast DDR RAM and super wide buses that we are seeing on video cards can't be used as the main system ram and bus. I mean, the next generation of video cards are going to be using 750 MHz DDR RAM and a 256 bit bus, resulting in bandwithes of over 20GB/s, while the actual system bandwidth is stuck at well below 5GB/s. I mean, WTF!?!?

Re:If a dual CPU system had the kind

[NovaX]

Hypertransport is mostly for interchip communications. Such as, between the CPU and chipset. It isn't going to be used like a bus and AMD is backing Intel's new bus architecture, 3GIO. 3GIO will support previous PCI cards (for a while) and should replace both PCI and AGP (which is derived from PCI).

3GIO was recently named some new strange PCI name, but I forget it. Using both new standards will vastly improve performance. 3GIO will get it from the I/O cards and HyperTransport will zip it to the CPU.

Re:If a dual CPU system had the kind

[Anonymous Coward]

Oh... 3GIO must be PCI-Express then. I thought HyperTransport and PCI-Express were trying to accomplish the same thing and that both were to be used as local buses. Then there was this Infiniband thing that I still don't really understand where it fits. It seems to be more of a PC to PC communication standard, but I'm not sure what it is supposed to replace exactly.

question

[Anonymous Coward]

Do you know what the words "asymmetric" and "unequal" mean? Do you now realise why it makes absolutely no sense to compare CPU+GPU to 2*CPU? (hint: "unequal" means CPU != GPU).

Beneath the surface

[XenonOfArcticus]

I believe the operations implemented in the Cg compiler are architecturally similar to the hardware found in an NVidia GPU.

What this means is that while you may be able to implement Cg on an ATI or 3DLabs card, it will not run as efficiently as on an NVidia card, even if they are cards of equivalent performance.

Additionally, Cg may not (efficiently) support operations and capabilites that are not implemented by NVidia GPUs.

This is the method by which NVidia plans to freeze out other graphics hardware manufacturers, while appearing to support them.

OpenGL2.0 is designed to be adaptable to all architectures.

Will you guys just READ THE ARTICLE? Cg is imparti

[Mac Degger]

If only you read befor you excreted onto your keyboard. Then you'd understand that this isn't pre-empting OpenGL or promoting DirectX in ANY way. Cg is above that, and outputs to both. Hardware independantly.

Of course, nVidia's compiler is optimised for their cards, but the whole thing is open; everything is specified, so it won't take long for ATI to make their own ATI-optimised compiler.

All this means is that j.random.software company could have to compile their shaders twice, once for ATI, once for nVidia. Hell, some hacker might even make a combined compiler, which includes both optimisations(?).

But the whole thing about Cg is that it's about 12 times more compact than assembly (at least, in the examples I saw). This means:

-it takes less time to write a shader
-because it's simpler (and hardware independant, and C-like) you can get tech-savvy artists to write them, instead of having your valuable programmers do it! And there are not that many manhours available to waste for those who can write assembly shaders :)
-there's an industry standard for real-time shaders!

However, it seems to me that id software have already got their own kind of shader language going. Carmack just didn't hype it like this.

Oh, and on a final note, Cg will even work on gforce 3's, although it doesn't show on their slides (that only mentions geforce 4's). But there's an interview on hothardware.com where nVidia's technical director does say it does :)

Me, I'll have to upgrade though :(

Other Informative Cg Articles

[Totally_Tux]

I'm pleased (and somewhat surprised) that my CGChannel article got onto my favorite tech news site.

For those coders and artists out there who may want to learn more about Cg, these web articles are also worth reading:

Bjorn3D's Cg Article - Programmer's Perspective

Hot Hardware - nVIDIA's "Cg" Language
(Excellent! Includes interview with David Kirk, Chief Scientist - NVIDIA Corp)

ExtremeTech - New Language Revolutionizes 3D Graphics
(includes interview with graphics guru Kurt Akeley)

3DPGU - NVIDIA Cg High-Level Language Preview
(includes short Q&A With Dan Vivoli - Vice President Of Marketing)

nV News - NVIDIA Cg Toolkit Overview
(makes comparisons using COBOL and FOCUS)

Stripes will be Revealed with Time

[ablair]

Maybe I'm a bit paranoid (I probably fit right in on /.) but when I read news subheadlines like "Nvidia, the dominant PC graphics chip maker, has teamed up with Microsoft and developed a new cross-platform graphic language called Cg that it hopes becomes an industry standard" I don't really feel all warm & fuzzy inside. CG Channel states "NVIDIA's compiler toolkit would be more optimized for their own hardware owing to greater understanding of their own technology. ATI would have the option of writing their own backend compiler to support their hardware more optimally, but the exisiting NVIDIA toolkit should generate working code on ATI's part. [...] NVIDIA are hoping that Cg will be the industry's defacto standard simply due to its time on the market [...]" If NVIDIA can't be reasonably criticized for supporting their own chipset more with optimized code (and leaving it open to others with competing chipsets), can co-developer Microsoft be criticized for favouring their own software in this? Couldn't MS solutions (DirectX, XBox-specific tools, etc) be favoured under Cg merely by them investing more in Cg development and (as one of the two developers controlling the standard) updating compilers and shader functions for their software sooner or more completely than for others? If this was the case, Cg could just end up being another "embrace, extend, etc" scenario, this time in the graphics market to push MS & Nvidia techologies.

Nvidia has been fair to good in their cross-platform support so far, but of course MS has not been. To the relief of many CG Channel reports that "Interestingly, key components of NVIDIA's Cg compiler will be open-sourced and will work on Linux, Mac OS X and Xbox platforms. [...] Compiled code for Direct3D will be cross-platform (well, as cross platform as Microsoft might expect). OpenGL code should work much the same as long as the OpenGL extensions are supported on the target. NVIDIA says it will provide compiler binaries for all of the major platforms." The real proof will be in how Nvidia supports Cg on other platforms and OpenGL over the long term. Will these binaries be released at the same time and with the same feature sets? And will this continue to be the case or will full cross-platform support only exist in the beginning until Cg becomes a de facto standard?

I'm skeptical at this point, since we all know there's a world of difference between being merely compatible and being optimized. There's some evidence so far of how Cg is being implemented. For instance, it looks like there isn't an OpenGL fragment program profile for the Cg toolkit while there is one for Direct3D8. Nvidia says that the reason Cg has for no OpenGL ARB vertex_program extension while there are both dx8ps and dx8vs profiles is that OpenGL is dragging it's heels with the standard, perhaps valid but nonetheless the result is Cg is better implemented under DX8 than the OGL side. While it's theoretically possible to program Cg textureShaders and regcombiners in OpenGL, it's not currently supported. Much of the feature set in Cg looks like that announced so far for OpenGL2 - could nVidia just be trying to repeat OpenGL2 functions using their own identical and properitary Cg extentions instead? Finally, Nvidia announced support for Windows, MacOSX and Linux; the first and last platforms should have native Cg compilers (Linux soon apparently) but what about MacOSX?

Re:Stripes will be Revealed with Time

[Rothron the Wise]

Cg looks like that announced so far for OpenGL2 - could nVidia just be trying to repeat OpenGL2 functions using their own identical and properitary Cg extentions instead?

That would be strange indeed, as NVidia is one of
the major reasons why OpenGL is still alive. I'm guessing they are just waiting for OpenGL2 to play
catchup.

This is not how things have happened in the past.

[ralphbecket]

I think you misunderstand the so-called wheel of reincarnation.

Throughout the history of computing, the rule has been that special-purpose co-processing devices have inevitably been retired in favour of doing the work on the main CPU (e.g. some may remember the days when paging and so forth was handled by a separate chip.)

The thing is that vastly more effort goes into improving the general device than the special-purpose device.

More to the point, the special purpose chips are exactly that: they exist because there are currently some things it is currently cheaper to throw hardware at than to do on the main CPU. While we have seen truly stellar improvements in graphics performance, you should not confuse this with generality. The CPU and the GPU are quite different animals.

The RISC philosophy is to include instructions that do the most work for the least cost, hence MMX and friends. On the other hand, I can't see a GPU generalising into a CPU of any merit.

RenderMan and Stanford Real-Time Shading Language

[Anonymous Coward]

You can think of Cg as a real-time shading language. These shading languages have been an active area of research in recent years.

The industry-standard shading language today is RenderMan, designed by Pat Hanrahan while he was at Pixar. As mentioned elsewhere, it is used for movie production-quality shading in software rendering systems.

Consumer graphics chips today such as the nv20 (NVIDIA Geforce 3) and the R200 (ATI Radeon 8500) are programmable, but they expose the programmable features in the form of assembly-like instruction sets. Writing shaders in assembly is ok when the number of supported operations is small for a given rendering pass, but as shaders become longer and more complicated, the process quickly becomes tedious.

In the graphics research community, Marc Peercy and some folks over at SGI first demonstrated how RenderMan shaders could be mapped to multiple rendering passes on simple graphics hardware in their SIGGRAPH 2000 paper.

Then, Kekoa Proudfoot and some folks at Stanford designed a shading language that targets programmable graphics hardware (such as the Geforce 3), and you can read about it here.
Note that a key member of the project is Pat Hanrahan, the designer of RenderMan. The paper associated with this project is in SIGGRAPH 2001.

Both of the above were research efforts to demonstrate that (1) it is possible to compile complex shaders efficiently to commodity graphics hardware, (2) it is desirable to use a higher-level abstraction such as a shading language to program GPUs with instead of low-level assembly code.

Now there are two efforts to bring shading languages to widespread, mainstream use in the industry: the OpenGL 2.0 shading language proposal by 3D Labs, and Cg by NVIDIA.

A nice aspect of having Cg sit on top of DirectX and OpenGL, instead of being integrated into the language (like the OGL2 proposal), is portability. In theory, you can write your uber-shader ONCE, and it would be the compiler's job to map it to the appropriate hardware, etc.

Nup

[Anonymous Coward]

Hi! If you'd read the article, you'd have realised that NVidia are releasing technology to take advantage of the hardware on the card you already own, (and which has been there since the GeForce3) so quit moaning.

21 YEARS?!?!?!

[Supergrass]

I've been programming in Pascal for 21 years

No wonder you're bitter.

Re:21 YEARS?!?!?!

[Viking Coder]

Ayup. I always view new languages through the eyes of Pascal. What I mean is, the Pascal (Delphi) community tends to be more unified than the C/C++ community, at using the same toolkits all of the time, and solving problems in the same way.

I find that's typically the greatest advantage of any new programming language, is that the developers all tend to agree (or at least agree more often), and to make as many of the libraries standard as possible. It's fun to be part of a community that all agrees with each other.

It's much harder to rework an old environment (C++) than it is to design a new one (Python, Perl, Java, etc.) You have to try to get an already existing community to agree to some standard, and they'll all have opinions. But it's important work to do - it helps everyone to try to improve the single environment with the most users, across platforms. That's one of the reasons why I think STL is fantastic. (And scary - I don't love every bit of it, but by and large, I think it's a wonderful tool.) It's good to see the C++ community work together to improve their environment by setting new standards that we can all live with.

Much like the OpenGL community! Which goes back to why I don't like Cg!!! =) (You just knew I had to work that in there, didn't ya?)

In living (blue) color...

[Cheesewhiz]

"NVIDIA have announced a high-level Pixel and Vertex Shading language developed in conjunction with Microsoft"

Oh great, so now we can see the BSOD in nice vertex shading and excellent fill rates.

I can see the marketing scheme now...

"We may crash a lot, but by golly, we're working to make it the most fun you've EVER had whilst watching the smoking wreckage of your kernel burn!"

"El Pantalla azul de MUERTE"

Thank god Glide is dead.

[Rothron the Wise]

I always get annoyed whenever anyone talks about Glide like it's the best 3D API ever made. Claims like this is usually comming from people clinging to their ageing V5 pretending that it's still cutting edge.

In reality it's barely an API at all. It is a set of header files with function declarations that plugs data straight into the HW. It's like calling C64 basics poke and peek functions a machine code api. You have low level access, sure, and thus things are about as fast as they can be, but you have to do EVERYTHING yourself. Glide implementation and hardware was so tightly linked that the one stifled development of the other, holding 3DFX back in the feature department. Even 3DFX said that Glide was on it's way out when the V5 was released because of that fact.

Re:Thank god Glide is dead.

[Anonymous Coward]

UT still runs faster with Glide rendering on my old Voodo2, than it did on a friends system, with a Nvidia card, and the official XFree drivers. At least, with Glide, it was running FPS, where as the Nvidia card was running SPF (seconds per frame).

(Yeah, I know that you can get som unsupported binary-only GPL-breaking kernel module that will make Nvidia-cards go faster, and your computer lock up, but neither of us wanted to try that).

Do we need a custom language?

[Lurks]

Research goes on at the top graphics hardware companies to accelerate more of the graphics pipeline by having more generic programmability. To this end, programmers will be wanting to shift more of their existing graphics pipeline onto hardware. Games programmers in particular, working on multiple platforms, value cross-platform code. So where does a custom language fit in which is tailored to some a particular vendors hardware? I'm not sure it does.

nVidia may offer ATI the ability to get on board this Cg language, but the reality will be different. What disturbs me is that nVidia's chief scientist went on record as saying that ATI's refusal to implement nVidia's shader technology (they did their own, which some consider superior) amounted to destabilising the industry. No, that would be competing dear chap.

Who exactly will need to use Cg and what market ultimate will use it? I have no doubt that PC game developers (and Xbox) will take a look at it but let's not pretend that this is a solution which embraces other vendors. Of course I'll be glad to eat my hat if ATI and Matrox come out in support of this.

It's not an entirely bad idea but writing regular language compilers for exotic hardware is more than feasible. My company has done exactly this for the PS2's vector units with a C/C++ compiler. Those VLIW co-processors are quite similar to the sort of more generically programmable hardware that you'll see in graphics hardware down the line (combined with shaders of course).

There are some good reasons for using a custom language, better control over the implicit parallelism of multiple shaders/vertices etc. However creating a new language for people to use destroys the notion of recyclable code and introduces yet more platform specific issues. And let me tell you, there's quite enough IF/THEN statements in the graphics engines of PC games as it is. Unless your work is being used by multiple developers, in which case any decent authoring tools for specific hardware may be welcomed.

Anyhow, I'm not entirely negative about nVidia's efforts - it's an interesting stab at a problem we had kind of thought everyone (but us) was ignoring. At the very least it's destined to become a more useful shader authoring tool for PC/Xbox game engine/middle ware developers.

I wonder what ATI and Matrox's approach will be. I wonder if they'd like a regular compiler for their shaders? :)

Why do you use Spanish words if you don't speak it

[Anonymous Coward]

GRRR

Hype

[oliverthered]

Take a look at the pixel shader language it ain't that hard really (not if you know what your doing).
All the product seems to do is provide a few functions that would take vertex shader code to write from scratch.