Slashdot Mirror
Codeplay Responds to NVidia's Cg
Da Masta writes "Codeplay Director Andrew Richards has some interesting things to say about NVidia's Cg graphics language. Just to refresh, Codeplay is the company that publishes Vector C, the badassed, high performance C compiler. In brief, it seems as though Cg isn't the universal, standard graphics language some pass it off to be. Certain design considerations in the language, such as the lack of integers, break/continue/goto/case/switch structures, and pointers suggest a general lack of universal usefulness. This leads to suspicion that NVidia plans to add and tailor the language in the future according to its own hardware and their respective features. Of course, this is all old news to those of us who noticed NVidia co-developed the language with the Evil Empire."
Evil Empire
No bias here at all!
Who uses goto statements? I'd count that as a feature.
Mmmm... I'd love to see Gnome and KDE compiled with VectorC or intel's compiler...
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
've been coding in Cg for some time, there have been a number of problems I've faced so far:
1. The vertex engine calls are not logical. Sometimes you call passing a referenced pointer, other time you have to pass a referenced strucute, some form of standarization to calls would have made it easier for developers to write function calls (more insane than POSIX threads).
2. The lanugae is not truely Turning complete. Which could have been fixed by taking some more time and making the language more complete.
3. The compiled bytecode is giving a security mask that disables it's use on chips that do not carry a compliment decoder (To keep competetors away?).
4. Confusing definitions of pointer/references. They could have made this easier by removing the entire pointer usage.
5. Class calls outside of friend functions can at certain times reach memory outside of parent definitions (Bad language design?! I think this is one of the most debated feature/bug, since you can piggyback this to implement vertex calls within lighmaps).
6. No SMP support in current implmentation and no thoughts to future support (What about threading?!).
7. Inlining support is bad and possibly unusable outside the scope of inling cg within c.
an almost-monopoly and a true monopoly combine like voltron to create yet another monopoly on graphics languages.
who gets to be the battleship?
"such as the lack of ... pointers"
Well, Nvidia sure knows how to make a C guru cry!
Buying a Dell computer is equivalent to dropping the soap in a prison shower.
GNU is not U!
j00 s3rve the dev1l!
"During times of universal deceit, telling the truth becomes a revolutionary act" -- George Orwell
This leads to suspicion that NVidia plans to add and tailor the language in the future according to its own hardware and their respective features.
Smells like glide!
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;
1. It's not C.
2. Exluna was bought by nVidia.
3. Exluna makes 2 renderman compliant renderers.
4. Shaders are used by renderman.
5. nVidia is touting CG as a compiled shader... just like one has to compile shaders for renderman.
6. Fill in the next 2 years here of having look development tools for major graphics studios that look close enough to the final renders that it speeds up FX work to near realtime for shading and lighting.
-- -- A truly great man never puts away the simplicity of a child
Who uses goto statements? I'd count that as a feature.
Some CS people hear "go to hell" and are more offended by the "go to" than by the "hell", but in my C code, I use goto carefully to break out of nested loops and to bail on exceptions. Even though the Java language has goto bound to nothing, it has nearly equivalent structures: 1. try...catch; 2. labeled break.
Will I retire or break 10K?
This guys got some good points, espically with regard to pipelines with more progammibility such as the PlayStation 2 gpu. 3Dlabs is also developing highly progammible pipelines
3DLabs press release
Having better control structures and pointers will be important down the line.
"Never cuss a man until you've walked a mile in his shoes. Then if he gets mad, you'll have a headstart and he'll be barefoot."
When all else fails, run.
Codeplay's VectorC is optimized around Playstation2 centric vector graphics hardware and scene graph libraries, whereas nVidia's Cg is optimized for most current PC accelerators. Most playstation developers use licensed scene graph libraries, whereas most PC game developers use custom or licensed engines over low level libraries, so both approaches are appropriate for their current customer base...
I think its reasonable to assume Cg will evolve with its target hardware, and I'd rather nVidia do a good job with the current version than waste time hypothetical future features. I'm using Cg now, and its a great step in the right direction - a high level shader language not owned by M$ and/or tied to D3D.
I think the biggest issue w/ Cg is how nVidia is going to address the divergence in silicon budgets between themselves and ATI - nVidia is pushing for more, faster vertex shaders, while ATI (w/ M$'s backing) is pushing for more powerful pixel shaders, i.e. D3D pixel shaders v1.4, exposed in D3D 8.1, are supported in ATI Radeon 8*, but no publically announced nVidia cards support the nicely expanded instruction set and associated capabilities. nVidia also needs to complete fragment[pixel] shader support for OpenGL (and release source or a multithreaded version of the GL runtimes...)
When the revolution comes, your heads will be the first to roll.
This is the second article in a row with the word "badass" in it :)
What did you think they were doing?
Someone needs a beating with the clue stick.
...if that's the target market for your compiler...
If you put a general-purpose execution engine in the graphics engine, you need an OS, context switching, protection mechanisms, and all the usual system stuff. If pixel shaders aren't allowed to do much or run for long, managing them is much simpler. Bear in mind that all this stuff has to work in multiwindow environments - one app does not own the graphics engine, except on game consoles.
I think what Richards is overlooking in his commentary is that Cg is not *supposed* to be a general-purpose graphics programming language. Its design goal was precisely what he said later in the article -- to expose the capabilities of current (and presumably future) NVIDIA hardware without requiring programmers to write assembly code. Likewise, conditionals like if, case, and switch aren't in there right now because the profiles the compiler is aimed at -- DirectX and OpenGL extensions -- don't yet support them. I expect this to change.
Also, Cg programs run at the level of vertices and pixels. This is the wrong place to be thinking about a scene graph: that happens at a much higher level of abstraction. Dealing with scene graphs in a fragment shader is a little bit like making L1 cache aware of the memory-management policy of whatever OS happens to be running.
After reading the article a few times, I think it's meant more as a "here's why our product is better than theirs" release than an honest criticism of the design of Cg. If he was interested in the latter, there are a few obvious issues. I won't go into them all, but here are two I ran into last week at a Cg workshop:
One final note: Cg is not the be-all and end-all of real-time shading languages. Nor is DirectX 8.1, 9, or whatever. Nor is the SGI shading language. Real-time shading on commodity hardware is still a new enough field that the languages and the hardware are evolving. DirectX 9 and OpenGL 2.0 both incorporate shading languages that will by nature be less tightly coupled to one vendor's hardware. Watch those over the next year or so.
Quote from the article :
"Overall, Cg is not a generic language for graphics programming; it is a language for NVIDIA's current generation of graphics card."
Well, what does anyone expect! Cg is a tool to help developers take advantage of pixel and vertex shaders *today*. And which pixel and vertex shaders do they know best? NVidia stated in their original press announcement that it would work across DirectX and OpenGL, as well as with other pixel and vertex shaders that comply with the specifications and even mentioned that other chip makers would be able to optimise the compiler for their particular hardware.
The games industry moves along at a rocket pace, it's all about performance and getting the most out of the hardware right now. I applaud NVidia for actually doing something for today, rather than just talking about how great things are going to be tomorrow, and fail to see why leaving features unimplemented is a cardinal sin when they're not available in their current generation of chips.
Reading their press release, I don't know what the hell Codeplay want. Some attention maybe.
If I was a gaming corporation, and I knew that an 800 dollar tool could make my game faster for my end users, I'd do it in a heart beat.
Lastly, you failed to mention that there is an 80 dollar version of the same software. It may not have the same features as its 800 version, but it comes close enough.
Sunny
Than we'll have "portable" software!
Just kidding... :)
In that case, I will be screwed again, that is if cg has the same effect on the market as glide did, then I will not be able to play games, seeming as I cannot currently afford a graphics board that can be used with this type of language. So I would hope that people will really create the games in opengl first, and then if they want to crank up the detail levels for the games, then they can use cg. Kind of what is in some games now, although they kind of don't have a choice with the way this language is looking to be designed, with no , ints and such.
Cg limits shaders to single-pass rendering.
Cg doesn't limit you to single-pass rendering at all. It just doesn't do it for you automatically, which would require some sort of scene graph or driver level support. You can still do multipass in the same manner its always been done.
The Stanford Real-Time Shading Project [stanford.edu] people wrote a compiler that does precisely that: it uses Cg as an intermediate language.
The Stanford language doesn't use Cg.
Cg requires that you write separate vertex and fragment shaders. You can't do things like texture lookups inside a vertex shader; you can't change the position of your vertices inside a fragment shader
Current hardware/drivers don't expose any way of doing this so the only way to do it would be some sort of slow readback to CPU memory, which would be to slow to be of much use. Cg is designed to work with current and future hardware in the least intrusive way possible so it wouldn't make sense to implement some high level abstraction like what was done with the Stanford language.
This Codeplay "article" was done about 2 days after the Cg launch, which came out in June...
What does a vectorizing compiler for a C-like language for the x86/PS2 have to do with a C-like shader language for nVIDIA graphics processors? It seems to me they are different languages for different purposes, even running on different parts of the same system.
The deal here is that we currently have GPU's that simply cannot implement anything like a full-up C compiler. There is no point in wishing for something that the hardware simply cannot support.
/. crowd is whether we should embrace Cg now - or wait a year (or more) for the hardware to catch up with something like the OpenGL 2.0 shader language (which is very similar to Cg - but isn't implementable on most hardware...yet).
Cg doesn't have integers because GeForce chips don't implement integer math operations. There are no pointers because the hardware doesn't implement them.
So, the choice here is either to put up with a C subset that will grow with the hardware until it's not a subset anymore (and live with the consequent lack of compatibility between versions of the hardware and Cg compilers) -- OR you carry on writing GPU-based shaders in machine-code (which *also* changes with hardware versions).
We are at the very beginning of a revolution here and as such, we have to put up with some initial inconveniences.
A better debate for the
At the OpenGL Birds-of-a-Feather session at SigGraph last week, nVidia clearly expressed an interest in working with ATI and 3Dlabs on the OpenGL 2.0 standard - but those of us who need to use realtime shader languages simply cannot wait another year. I think we should expect to use Cg until something better shows up - probably in the form of the OpenGL 2.0 shader language.
One should note that the Direct3D DX-9 shader language (called HLSL by Microsoft) is basically the same thing as Cg.
www.sjbaker.org
You do not need (C-style) pointers for high performance graphics. You do not need pointers even for representing relational structures. People have been implementing graph algorithms in languages without pointers since before most of us were born. You can even do it in a language as tedious as Fortran 66. C pointers are a bizarre aberration in language design and play havoc with high performance computing and optimization. You have to jump through hoops in order to even optimize siple uses, and then add lost of special purpose declarations to make them work. Any use of C pointers can be replaced with the use of arrays and integers (but the logic of your program may change dramatically).
Another reason pointers are generally not such a good idea in graphics or high performance is that they have to be large enough to address all of memory. An index into a array can be 1, 2, 3, or 4 bytes long depending on how much data it actually needs to address. That can lead to saving a lot of space.
When dedicated C hackers make such statements, it is understandable. But a company in the business of writing high performance compilers ought to be familiar with the work, programming styles, and languages that people in high performance computing adopt, and those often don't include pointers. C programmers want pointers becaues they are used to them, and CodePlay is in the business of satisfying this desire, but that doesn't make it a good engineering choice.
Incidentally, I program in C++, including numerical and graphics code. It is quite easy to eliminate most uses of pointers from C++ code, and the result is code that is a lot easier to debug and often run faster, too.
You tards, cg is compiled into OpenGL/DirectX shaders.
Why would he mention the $80 version when it doesn't support the P4 optimizations?
When I clicked the "some" in "it seems as though Cg isn't the universal, standard graphics language __some__ pass it off to be", I thought I was going to get a meanful link to an article stating Cg was a universal, standard graphics language, or at least something to that effect.
Instead I'm brought to Nvidia's homepage.
Why the pointless links that don't really pertain to the article?
Codeplay is probably just upset because Nvidia is setting some precendece for graphics companies providing stuff like this free of charge to whoever wants it. It's got to be hurting Codeplay's business. It's obviously in Codeplay's favor if companies like Nvidia stay away from this stuff and leave it up to Codeplay so Codeplay can sell their proprietary commercial products to fill the gap. Other than dissent from Codeplay itself, Cg seems to be fairly well accepted by developers.
Codeplay was probably planning on making a DX9 backend for their commercial product, so Nvidia is just raining on their picnic. We'll see what happens to Codeplay over the next year or so.
In fact, it's unfortunate they named the thing after C. The entire reason Nvidia made Cg was to make it easy to use what their (and eventually their competitors) hardware supports instead of having to learn a (relatively) unmaintainable assembly language. Cg doesn't support integers and break/continue/goto/case/switch structures is because current graphics hardware doesn't support it. This is hardly news to any of us who've shipped 3D graphics engines. Cg is meant to be shorthand for what we'd otherwise have to implement in pixel/vertex shader assembly.
Vector C is, tangentially, a competitor to Nvidia in their Cg effort. Both aim to reduce the pain in making 3d graphics engines, except that Vector C doesn't have the advantage of running on Nvidia's GPU. Therefore, they resort to FUD like this.
This is like saying that Stroustrup is at the center of a conspiracy to suppress the use of defining common data operations in terms of functions that return functions, simply because you can do it in lisp but you can't in C++. Speaking of which, why can't Cg also have functions that return functions? I mean, come on!
At a SIGGRAPH course on real-time shading last week, Eric Chan described a version of the Stanford compiler that broke a shader down into its component passes and used Cg as an intermediate language when aiming at NVIDIA cards. (Eric -- or anyone else who was at that course -- if you're reading this, I'd welcome corrections. I know it was the Stanford project and Cg as an intermediate language but I'm hazy on the details.)
Current hardware/drivers don't expose any way of [texture lookups in vertex shaders / position change in fragment shaders] so the only way to do it would be some sort of slow readback to CPU memory, which would be to slow to be of much use.
Exactly. This goes back to the Richards' claim that the Right Solution is to program everything in C/C++ and make the compiler smart enough to figure out how to partition it all into vertex shaders, fragment shaders, multiple passes, scene graph management, vector processing... I don't want a fully general language down in the fragment shaders. I want to know about what the hardware there can and can't do so I can make things run fast.
i, for one will laugh when M$/Nvidia lose the race to ATI/Linux
*crosses fingers*
Base 2 yields only ARTIFICIAL Intelligence
[X] Microsoft
[ ] Sony
[ ] NVidia
[ ] CowboyNeal
Microsoft is EVIL Linus Turdballs is GOD!!!!!
"NVIDIA is touting the NV30 as a Cinematic Shading GPU".
Java is completely platform independent. It also would make a good graphics language. Maybe a compromise: Cgava.
lmb is SO horribly, wonderfully good looking!!
In Soviet Russia you dant have to put up with these crappy jokes
Anyone who's played games in the last two years knows that an NVidia chip is the way to go. They update their drivers on an almost weekly basis, and make all their beta's available for download as well. The On-line support is excellent, and just about every driver update seems to add a boost in performance. Add to this that their drivers are backwards compatible to at least the TNT2 chips, and I say I don't really care if they want to tout their own language, and make it propriatary to their chips. This is a company that actually survived the dotcom burst, and is continuing to thrive because they make a damn good product.
C/C++ is not a language of choice for vector applications, hpf (High Performance FORTRAN) is, although a crockish hack on f90 it's quite usable, we really need some more vectorable languages. I have made an early atempt at a vector unit (GPL now, disregard copyright) Ganymede but that is far from completion and will never se the light of day. Still we need vector processors though. For a good free hpf compiler check out this: Adaptor
Ordo Militum Unix.
you will be left behind.
I say this, not out of some great experience in programming, though I will admit that the stuff I churn out in Perl is much different than what I do in C++.
Anyway, I recently took up Java. Now, I always thought Java was some trend-o-matic language that was overhyped and underpowered. I mean, just by using the JVM, "Hello World" takes as much memory and startup time as StarOffice? WTF? Not to mention the factor of 2 slowdown in plain old integer arithmetic.
Point is, I have all kinds of reasons to hate Java. But look at the apps! Not many of them, for sure, but fucking NetBeans alone is better than the top dozen GTK+ apps put together. Who the hell programs these Java apps that they are so consistently feature-rich and well done? And why are these Linux fags still programming window managers and mp3 players?
Only thing I can come up with is that it's the language itself. Maybe C/C++ just isn't conducive to writing worthwhile apps. Since learning Java, I have written a totally l337 badass multithreaded SQL-backend swing-GUI 3d Hello World that smokes anything in KDE or Gnome. I'll bet I could do better than Doom 3 if I learned Cg next.
I thought that Cg didn't support if...else (etc.) because the pixel and vertex shader hardware itself doesn't support that sort of thing. If the hardware doesn't support it, why should Cg?
.plan file how the lack of support for conditional jumps and suchsort in the shader hardware really annoyed him.
I distinctly remember John Carmack saying in his
I doubt there is some evil conspiracy going on here. nVidia may add if...else to Cg in the future, not due to some underhanded plot, but because once the shader hardware supports conditional jumping it only makes sense that Cg would as well.
you will be left behind.
Cg isn't a universal, all-purpose graphics language. It is specifically tailored for writing custom pixel and vertex shaders for newer 3D cards like the GeForce3 & 4 and newer ATI cards.
.plan file) that the hardware itself lacks support for conditional jumps i.e. if...else) when it comes to custom pixel and vertex shaders.
The hardware in those cards has certain limitations (dunno 'bout the integers, but I've heard (from John Carmack's
It seems like there's rampant misunderstanding when it comes to Cg, so I'll try to clear things up:
1)It is *ONLY* for writing custom pixel and vertex shaders for 3D cards that support custom pixel and vertex shaders.
2)The alternative to Cg is to write your pixel/vertex shader(s) in an assembly-like language. This is assembly language for the 3D hardware, not the CPU or anything else. Again, this isn't x86 assembly.
3)The shaders produced are only used by the 3D hardware, and only for the purpose of allowing developers more control over how objects look (i.e. the developer can write a shader that mathematically simulates the way light bounces off human skin, then tell the 3D hardware to use that shader for all polygons that are supposed to be human skin), and have absolutely nothing to do with speeding up graphics operations or other speed optimizations.
I may not love you, but I love weekend Slashdot.
I suspect that disciplined programmers can use either tool without making their code proprietary. Use MACROS for compiler dependant stuff! Wrap proprietary functions!!! Of course, when you are shoving games out the door, how many stop to think about coding discipline? So, then it becomes a question of who you would rather risk getting locked into...
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Use Nvidia for games if you like. For some of us, open source - which Nvidia drivers are not - matters more than video gaming frame rate.
Nvidia => no BSD support, no support if your Linux kernel strays too far from the snapshots they use.
Is it just me or are break, continue and goto all considered to be evil programming practices (with the exception of break in a switch structure)? And switch isn't at all necessary if you have if and else (you can make a switch structure out of those). Lack of pointers and integers may or may not be a problem, I don't really know much about the language.
----
All of whose base are belong to the what-now?
> Are they an actual evil company?
m l
Of course they are. But don't take my word for it. You can see it in Microsoft's own words...
Microsoft sabotages new technologies:
> The "strategic objective" is to "kill cross-platform Java by grow[ing] the polluted Java market." http://java.sun.com/lawsuit/051498.unfair.html
Microsoft commits fraud against their customers:
> "At this point its [sic] not good to create MORE noise around our win32 java classes. Instead we should just quietly grow j++ share and assume that people will take advantage of our classes without ever realizing they are building win32-only java apps." (same link)
Microsoft uses extortion:
> "Apple let us down on the browser by making Netscape the standard install." Gates then reported that he had already called Apple's CEO [Gil Amelio] to ask "how we should announce the cancellation of Mac Office...."
> "Though the language of the agreement uses the word "encourage," I think that the spirit is that Apple should be using [IE] everywhere and if they don't do it, then we can use Office as a club." http://www.usdoj.gov/atr/cases/f3800/msjudgex.htm
In order to get what they want, Microsoft is even willing to destroy things that are of great value to the whole world, such as the openness and compatibility of the Internet:
> "OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market." http://www.opensource.org/halloween/halloween1.ht
But those are only a few examples. Microsoft's entire history has been one of sabotage and fraud. Plus, Microsoft has never produced a new idea, preferring to copy others.
As a result of Microsoft's acts of destruction, PC technology is ten years behind where it should be.
Um, I see a lot of comments along the lines of "NVIDIA aren't including loops in the language because GPUs just can't do loops". It seems NVIDIA aren't aware of that, the next-generation "NV3x" hardware supports loops up to 64 levels of nesting... They've also grown the maximum pixel shader program size by a nice little factor of 512 (65,536 rather than 128 instructions per program). Also, it says "dynamic flow control" in the chart, which sounds like maybe arbitrary branching (there's your GOTO right there) could be supported.
;^)
That said, it does seem a bit weird not to make Cg strong enough to include features that are obviously needed for their own next-generation of hardware... But all the conspiracy theories have already been used up, I'll just settle for introducing some facts in the discussion.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
80$ version do support automatic array prefetching, vectorizing of loops, best alignment etc. on P4 what it doesn't do is just SSE2.
Funny, I use return to break out of nested loops. If your functions are so huge you feel the need to use goto, that's a sign they need to be split up.
I write video drivers for soft real-time applications. If I split up a function into an inner function and an outer function wherever I need to break out of something, performance drops 30% because now I have to pass a dozen arguments to a function call in a loop, and on some architectures, function calls are very expensive.
Will I retire or break 10K?
one should never NEED to break ... out of a ... for loop
Then what do you do when you get a "Virtual memory exhausted" error on a widely deployed machine with extremely limited but non-upgradable RAM? Surely you don't switch to C++ exceptions, because that will take up even more RAM for the exception handling code, right?
USE A ... WHILE OR DO WHILE LOOP
I've considered this, but I'm not sure GCC's optimizer will know what to do with putting complicated expressions in a while loop's condition. I don't want my profiler to report a 30% performance hit from inefficient control structures.
Will I retire or break 10K?
I haven't read too deeply into it, but I got the impression that it was supposed to be more of a markup language than a procedural language, much like VRML was a markup language.
You're supposed to be able to specify a scene in a procedure neutral way. Then the hardware will decide how best to optimize it in-terms of its capabilities.
ATI's new chip doesn't use ints anymore, only floats, as mandated by Direct X9.
It's a shader language, not an all-purpose programming language. It's more like DSP-style programming, for those few people who are familiar with that sort of thing.
You don't need integers, for example, because NVidia's hardware works entirely in floating point. It's not like you could use Cg to parse text files, nor would you want to.
I'd rather put my eggs in the "works right now"-basket then gamble on how the future will be. It is too early to standardize on something that doesn't even exist (or only exists for the PS2), so "Vector C" will not replace Cg anytime soon. Give it 5-10 years, and we will see what happens. In the meantime, if Cg is useful to you, go ahead and make use of it.
And please don't worry about standardization just yet. Before we can standardize, we need to find out which features are useful, and that will take several years of experimentation and competition in the marketplace. In the meantime, Cg could come in handy.
Twice, I have been swimming in pools with flooded 120V lights. Both were at hotels. Each time, I had been swimming for awhile, when I noticed an operating underwater light with a water line on the lens. A brief inspection verified that it was, indeed, mostly full of water -- well above the socket. These were large 120V fixtures. The lights worked, and I didn't feel anything, but I got the heck out of the pool!
When we moved into a new house a few years ago, none of the pool equipment was on a GFI. The wiring was old (70's) and terribly dangerous. The outdoor junction boxes for the pump and light wiring were regular indoor boxes with open knockouts on tops, and regular romex (NM, not UF) was run all over without conduit -- completely exposed to the elements and frequently in standing water. A 500W 120V light was in the deep end of the pool. I immediately set about rewiring with proper outdoor boxes and watertight conduit, and installed GFI breakers on everything.
They all tripped instantly. Three GFIs, three major ground faults which had gone undetected for who knows how long. The pool heater (gas, with electric control) had a hot wire touching the chassis. It was poorly grounded through a concrete slab, and had been running with the huge metal case hot for an unknown length of time. It was probably passing fault current through the water in the PVC pipes connected to it. The pool pump motor was going, and the case was hot. Again, a bad ground kept it from blowing the breaker. Again, probably passing fault current through the pool water.
Finally, and scariest, was the light. It had a ground fault, too. When I disconnected the leads at the box nearest the light, I measured 15 ohms from hot to ground, with no bulb installed. That would be through the pool. Yep.
-- Don
One of the most significant points made by the author of this article is the lack of pointers in Cg. While his reason for including pointers seems to be focussed on higher-level constructs such as scene description mechanisms (scene graphs, etc.) which are handled in the rendering pipeline entirely outside the likes of Cg (and very efficiently, I might add), this point is fundamentally untrue to begin with:
Dependent texture operations ARE pointer operations, and they have been in Cg from the start.