Codeplay Responds to NVidia's Cg

This leads to suspicion that NVidia plans to add a by t0qer · 2002-07-27 13:58 · Score: 3, Troll

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!

And we are calling NVidia bad? by SeanTobin · 2002-07-27 14:02 · Score: 4, Funny

Just found this quote funny... especially because of the knock on nvidia for working with our favorite evil empire (emphesis added)...

This approach will be extended to embrace emerging new hardware features without the need of proprietary 'standards'.

I guess the evil empire has gone everywhere they wanted to go today.

--
Karma: SELECT `karma` FROM `users` WHERE `userid`=138474;

It's a shader language... by invispace · 2002-07-27 14:05 · Score: 4, Interesting

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

Re:It's a shader language... by Milinar · 2002-07-27 16:50 · Score: 2, Informative

A couples notes about the above:

- CG came around long before exluna was bought by Nvidia. I overheard Tony Apodaca (the co-author author of Advanced Renderman with Larry Gritz, the founder of exluna, at siggraph this week saying how CG was pioneered by a bunch of renderman users who wanted to bring that technology to real-time hardware. Since renderman is almost 15 years old now, the user base that CG could reach is vast.

- PIxar's lawsuit with exluna over trade secrets was settled, and the company was subsequently bought out by Nvidia. There is no guanantee that any of exluna's work will be continued. It's not uncommon in these situations to never see anything come of it. It's a nice idea that maybe nvidia will make renderman-supported hardware, but don't hold your breath. Nvidia wants to be the next intel, or microsoft, and you don't get there by support other people's software, you get there by eating competitors alive and flushing their work down the toilet.

- Best-case scenario: Larry Gritz re-releases BMRT, his free (as in beer) renderman ray-tracer, and at least we don't have to pay thousands for a production-quality renderman implementation. Or (even better) someone writes and releases another free (as in freedom) renderer that actually works.

Dan

Goto is not a cuss word when used wisely by yerricde · 2002-07-27 14:06 · Score: 2

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?

Re:Goto is not a cuss word when used wisely by norwoodites · 2002-07-27 14:26 · Score: 2

2. label break is more equivalent to goto than 1. try...catch because exceptions have more overhead.
Re:Goto is not a cuss word when used wisely by Broccolist · 2002-07-27 14:37 · Score: 2

I use goto carefully to break out of nested loops
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've found it pays off to do this, because I often end up reusing the new, smaller subfunction. There's really no justification for using goto in human-written C code.
Re:Goto is not a cuss word when used wisely by Broccolist · 2002-07-27 18:00 · Score: 2

Trouble is that even the most talented of us make errors in judgement pretty often (what new code doesn't have bugs?). And a lot of experienced programmers have found that even if it seems like a good idea at first, using goto is one of those things that always seems to turn out to be an error in the long run.
I would make an analogy with multiple inheritance in C++. Now if you've reached the point where you're considering using MI, you've already got some modicum of experience and judgement. I used MI maybe 3 times in my code (all of which seemed eminently reasonable), considering the situation carefully before making the decision. And guess what: one of those 3 times it unexpectedly blew up in my face horribly, just like the anti-MI people always said. (I hit a bug in GCC that left me baffled for 2 days.) Somehow MI seems to be intrinsically evil, although it seems so tempting and useful sometimes.
I've learned my lesson, and now I have a strong anti-MI bias in my coding. Using goto is the same kind of thing for me, although it isn't nearly as serious a problem.
I'm not an "anti-goto fanatic" (I don't really care that much either way), I just like arguing about it :).
Re:Goto is not a cuss word when used wisely by Tony+Hoyle · 2002-07-27 23:50 · Score: 2

MI works well if the only things you inherit are virtual base classes (basically treating them like java interfaces). It's useful for writing event handlers.

Whining about competition... by kbonin · 2002-07-27 14:21 · Score: 5, Insightful

I love the line regarding Codeplay's own product: "This approach will be extended to embrace emerging new hardware features without the need of proprietary 'standards'." So, the point is: 'Don't waste your time on that competitors product, wait for us to finish ours!' Where have I heard this marketing approach before? :)

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...)

Re:Whining about competition... by AltaMannen · 2002-07-27 15:31 · Score: 2, Informative

I'd say most Playstation 2 developers use custom graphics code for each game, whereas most PC developers use custom translators for high level graphics libraries (because low level libraries would require too much per card customization).

But that's just my opinion. And Vector C fits pretty well in with the PS2 VUs but almost every developer has at least one person doing mainly VU asm anyway so they may not be so eager to switch.
Re:Whining about competition... by Keith+Russell · 2002-07-27 17:05 · Score: 2

All good points. My tuppence:

FYI, the current version is 1.01. Maybe that's why whole bunches of features aren't available? Has Microsoft's influence made us so paranoid that we feel compelled to seek Evil Empires around every corner?

--
This sig intentionally left blank.
Re:Whining about competition... by kbonin · 2002-07-27 18:00 · Score: 2

Dunno... the OpenGL support has been sufficient to date, I'm using Cg a few hours a day, and you can generate OpenGL fragment shaders by compiling to a D3D target and passing the output through their D3D to GL shader translator, which while a pain has allowed our shader prototyping to continue.

I'm more hoping that nVidia can leverage Cg to keep the pressure up on the OpenGL ARB to move to v2 faster, despite the intra-vendor infighting, patent pressure from M$, and the dilema r/e multipass strategies.

To do this, nVidia must make Cg usable for bleeding edge ATI products as well, and the divergence w/r/t pixel shader functionality is considerable. I'm hoping they won't do anything to preclude ATI supporting Cg, should ATI really choose to do so. At the same time, I don't expect ATI to do anything to damage their role reversal w/ nVidia w/r/t being M$'s favored vendor (and candidate for XBox2 chip supplier), so I'm not expecting ATI to step forward anytime soon onto the Cg front, or even GL 2...

This means nVidia needs to take some initiative to demonstrate they will not preclude support for next gen pixel shaders, especially features that cannot be trivially abstracted unrolled from a high-level language, like 3 and 4 levels of dereferencing of textures instead of one. Unfortunately, I have not had any favorable impressions on this topic when I talk to developer relations at nVidia.

Other than that, for a v1.01, they've done their usual damn fine job of providing stable code, and I'm enjoying the advantages of C over ASM for most of the grunt level shaders we need...

NVidia has it right by Animats · 2002-07-27 14:48 · Score: 5, Informative

I'll have to go with NVidia on this one. A shader language should be limited and highly parallelizable. Ideally, you'd like to be able to run the per-pixel shaders simultaneously for all the pixels. In practice, you're going to be running more and more shaders simultaneously as the hardware transistor count goes up. So you don't want these little programs interacting with outside data too much.

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.

Cg isn't supposed to be a general-purpose language by andycat · 2002-07-27 14:53 · Score: 5, Informative

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:

Cg limits shaders to single-pass rendering. This is a design limitation: there are lots of interesting multipass effects, and it's not all that difficult to get the compiler to virtualize the shader to do multipass on its own. The Stanford Real-Time Shading Project people wrote a compiler that does precisely that: it uses Cg as an intermediate language. The advantage of that design decision is that you-the-programmer have fuller control over what's happening on the hardware, which is the entire point of the exercise.
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. Again, this gives you control over the details of the pipeline at the cost of some added complexity. This can be changed by changing the semantics of the language.

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.

Linux on GeForge 6... by stikves · 2002-07-27 15:11 · Score: 2

I would like to see Linux ported to GeForge 6 (or whatever) shader language.

Than we'll have "portable" software!

Just kidding... :)

Re:Linux on GeForge 6... by Cryptnotic · 2002-07-27 16:44 · Score: 2

It is possible to compile Linux with a compiler other than gcc. However, either you would need that compiler to support the weird gcc extensions or you would need to change the source code. It's not something people usually do.

--
My other first post is car post.

I don't get it by g4dget · 2002-07-27 15:26 · Score: 2

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.

Re:I don't get it by zenyu · 2002-07-27 16:22 · Score: 3, Interesting

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?

The PS2 has two almost identical MIPS chips souped up with fast SIMD math instructions. One runs the OS/AI/etc, as a pretty standard processor. The other is dedicated to process vertex arrays and the like. This is the "GPU" But really it is a full fledged processor that simply used in a streaming fashion.

The talk this year at SIGGRAPH was all about how the GPU's are all becoming streaming processors that can handle almost anything thrown at them. Using them effectively is all about never asking for any data not already fetched, that is no random access to memory. A huge portion of the die on a modern CPU is dedicated to caching, GPU's get faster at a greater rate because they use most of their die for logic gates and what is left is used for the very specialized texture memory access, with little or no caching of random access.

As for the integer arguement, I think nVidia heard that loud and clear, and it's almost certainly going to be in OpenGL 2 shader language (which is C like and has branching and loops even in the fragment shader.) 3D Labs and ATI promise drivers weeks after ratification. Except for integers nVidia should be able to do this in their driver with extra passes. For integers they can just suggest 'safe' texture sizes for data as a work around.

OpenGL2 also asks for effectively unlimited program size, which no one will have initially. This of course can be simulated with more passes, but you'll be reponsible for any such splitting since it tells you whether the shader compiled and 'out of program space' is one of the acceptable errors.

ATI is known for not so great drivers and 3D Labs has an external company writing their linux drivers, so I'm not sure they will be any more stable than the nVidia ones. Both booths told me the linux drivers would be closed source, but I didn't ask so I guess they are hearing people asking for easier to fix drivers.

C-style pointers by g4dget · 2002-07-27 15:43 · Score: 2

No pointers. This is Cg's most serious omission. Pointers are necessary for storing scene graphs, so this will quickly become a serious omission for vector processors that can store and process the entire scene or even sections of it.

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.

Re:C-style pointers by g4dget · 2002-07-27 19:17 · Score: 2

If you use references in C++, you're using pointers. [...] Lots of neat affects are very easy to do with pointers, but a pain to do with arrays. Function pointers come to mind.
C and C++ use the term "pointer" for a lot of things. It is the totality of those things, and the fact that they are all the same datatype, that presents problems.
"Not using pointers" means not using the stuff that is specific to pointers in C/C++: pointers into the middle of arrays, pointer arithmetic, pointers to local variables. Things would be a lot less problematic if "pointer into the middle of an array", "pointer to local variable", "pointer to heap-allocated object", etc., all had different types.
References are not "pointers": you can't do arithmetic on them, you can't store them in data structures, etc., many of the things that cause problems. But even unrestricted use of references is problematic and error prone in C++, and it is best to limit oneself mostly to references to variables passed as function arguments.
You're not particularly creative with pointers, if you honestly believe they can be replaced by arrays.
I am decidedly not creative with pointers. I used to be very creative with pointers, but I found that hand-crafted pointer code that looked "efficient" didn't run any faster on modern hardware and was a lot harder to debug.
Re:C-style pointers by g4dget · 2002-07-27 19:21 · Score: 2

"References are not "pointers": you can't do arithmetic on them, you can't store them in data structures, etc.,"
Just to be clear: you can, of course, initialize a reference in an object. That is as problematic as pointers, and I avoid it.
Re:C-style pointers by rossz · 2002-07-27 19:35 · Score: 2

The last time I worked on a commercial game (it's been a few years), we avoided pointers like the plauge. We also avoided dynamically allocating and deallocating memory. Everything was kept in big honkin' arrays because it was FAST. Accessing into an array with a constant index is a very simple operation because the details are taken care of at compile time. Using pointers, however, took a huge amount of overhead. In real time games, performance is everything.

Another benefit of this system was reduced bugs. Eliminate pointers and you automatically eliminate a good portion of your potential bugs.

--
-- Will program for bandwidth

Re:My bone with Cg by h2odragon · 2002-07-27 15:46 · Score: 3, Funny

Didn't you post this same rant on the last nvidia article? What, are you a bitter ex-3dfx employee?

Re:what? by whizzter · 2002-07-27 15:56 · Score: 2, Interesting

In the case of supporting the ps2 vu's, goto is a gift from (insert the god you worship).
And i think the same would apply for other vertex/pixel shading units.
Why?
Because the VUs has a very small amount of memory and to get the most of it you should almost count cycles aswell.
I haven't tried vectorC but considering the VU i think it's the only sane option apart from the stuff in asm(that i think might be preferable anyhow).
As for Cg i think i have to agree with the points Codeplay makes about Cg being too simple and aimed at the current NVidia implementations, but the statement itself is to be considered FUD.

I have been working with 3d for some years now and spent the last two years coding professionally for the PS2 and Dreamcast.

IMHO most stuff defining appearance(bumpmap,etc) should when it comes to supporting 3d hardware be translated from a really high level(renderman?).
Cg feels too lowlevel and specific for this, especially if you plan on supporting consoles.
vectorC could possibly(though questionable in reality?) get away in this case because the most of the code will be C/C++ anyhow and thus the specific code could be taken out and recompiled with vectorC when aiming for performance.

/ Jonas Lund

Re:Bias?! What bias?! by zapfie · 2002-07-27 16:08 · Score: 2

Are they an actual evil company? You may disagree with them, and they may have broken the law, and you may find some of their practices unethical... but does that make them evil?

Yes?

--
slashdot!=valid HTML

Re:wow! by rizawbone · 2002-07-27 16:24 · Score: 2, Interesting

However, calling nVidia a 'almost-monopoly' because they have the most market share is ridiculous.

One entry found for monopoly.

Main Entry: monopoly
Pronunciation: m&-'nä-p(&-)lE
Function: noun
Inflected Form(s): plural -lies
Etymology: Latin monopolium, from Greek monopOlion, from mon- + pOlein to sell
Date: 1534
1 : exclusive ownership through legal privilege, command of supply, or concerted action

they have almost all of the market share. they are almost a monopoly. i don't see what's so hard about this point. ati is making a valiant effort, but they aren't shipping the kind of units/chips that nvidia is. sis, matrox, 3dlabs and trident do not have a 3d architecture even comparable to the latest nvidia offerings.

if tomorrow nvidia released detonator drivers with a special feature or program, it would become a standard. big companies make games for nvidia chips. people speak about games in nvidia terms (that game's a geforce2 featureset game).

face it kiddo, nvidia is *the* video card maker right now when it comes to consumer desktop 3d.

They can program in Logo for all I care by dr_canak · 2002-07-27 16:47 · Score: 2, Insightful

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.

Re:what? by XMunkki · 2002-07-27 17:17 · Score: 2, Informative

I'd simply say, that without "goto" (the functionality, not the language contruct), many tasks of programming woul be nearly impossible. The trick is, many high level languages discourage or lack goto, and that's a completely different matter when compared to a low-level "assembly like" programming like the PS2 VUs or (I assume) CG.

So even if you never use gotos in c/c++, they still are compile in as unconditional jumps at assembly level. The same should happen with pixel/vertex programming.

Not a universal graphics language. by KewlPC · 2002-07-27 17:18 · Score: 2, Informative

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.

The hardware in those cards has certain limitations (dunno 'bout the integers, but I've heard (from John Carmack's .plan file) that the hardware itself lacks support for conditional jumps i.e. if...else) when it comes to custom pixel and vertex shaders.

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.

Competitor X Hates Competitor Y's Product... by istartedi · 2002-07-27 17:49 · Score: 2

...film at 11. If NVidia Cg can be used without diseasing your code, it makes VectorC's product irrelevant along with Intel's SIMD hack. It takes all of that and moves it onto dedicated hardware. The key word here is *IF* you can use Cg without mucking up your code. Just looking at VectorC's source for their benchmarks, I saw some things that were nonconforming for ANSI/ISO C. Pot. Kettle. Black. Also, maybe I missed it, but I didn't see what switches they used on the other compilers (grin).

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"?

Re:My bone with Cg by zulux · 2002-07-27 19:33 · Score: 2

What, are you a bitter ex-3dfx employee?

Or possibly a bitter ex-BitBoys employee?

--

Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.

What about NV30? by Emil+Brink · 2002-07-27 20:52 · Score: 2

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);}

Re:wow! by be-fan · 2002-07-28 02:11 · Score: 2

1) make money
2) once 1 is done, gain a monopoly
>>>>>>
I suppose you'll now tell us that you learned this at Harvard business school. Exactly where do you get off making up your own economic theories? Ford is profitable, are they a monopoly? Dell is profitable, are they a monopoly?

--
A deep unwavering belief is a sure sign you're missing something...

Re:drivers still closed source by be-fan · 2002-07-28 02:15 · Score: 2

Nvidia => no BSD support, no support if your Linux kernel strays too far from the snapshots they use.
>>>>
That's crap. Based on some patches for 2.5.17 floating around, I managed to get my set working on 2.5.23. If you take a look at the actual abstraction layer, it is complete. You could port the kernel driver to OS X if you wanted to (oh wait, they already have!)

--
A deep unwavering belief is a sure sign you're missing something...

Re:Yes, Microsoft is Evil by Sj0 · 2002-07-28 04:27 · Score: 2

Being selfish and greedy, being openly malicious and arrogant, stabbing your freinds in the back and treating your customers badly is very evil. Justification doesn't change the bottom line.

But that's just my opinion, I've been proven wrong in the past...

--
It's been a long time.

Who ever said Cg was general purpose? by Junks+Jerzey · 2002-07-28 05:05 · Score: 2

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.

yes it is probably going to happen by joto · 2002-07-28 10:00 · Score: 2

Cg is useful right now. Some people will use it. If graphics hardware evolves into more general purpose CPU's, then people will use "something else". "Vector C" might be that "something else", although it is hard to predict the future.

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.

Re:what? by UncleFluffy · 2002-07-28 10:23 · Score: 2

Who uses goto statements? I'd count that as a feature.

Anyone who wants to efficiently implement a state machine.

--

What would Lemmy do?

Re:what? by Quixadhal · 2002-07-29 01:04 · Score: 2

You do. The only difference is that anyone who has programmed assembly KNOWS that they do. GOTO, JMP, or any of their variants is extremely useful for error handling in languages that don't have the snobbish try/catch mechanism (or have a less than stellar one), and of course it's good for those humans who still produce better code than the compiler.

Re:wow! by be-fan · 2002-07-29 08:34 · Score: 2

Wow. Have a little more faith in corporate America. NVIDIA has proven to be a good company, which is why its users like it. I'm sure most companies want to get to and stay on top, but I doubt that many of them want to do so by becoming an illegal monopoly.

--
A deep unwavering belief is a sure sign you're missing something...

Re:wow! by be-fan · 2002-07-29 08:40 · Score: 2

Yes, they own lots of car companies. They fully own Jaguar, Volvo, and Aston-Martin, among others. They bought these companies so they could compete effectively with the likes of BMW and Diamler-Chrysler at the high-end. I'm sure they want to be more competitive by buying these companies, but do they necessarily want to be an illegal monopoly? Sounds like quite a strech to me.

PS> As for the Mazda thing, its done all the time by car makers. Ford used to make some of Nissan's cars (an SUV and a minivan) from a line parallel to their Mercury brand. A lot of times particular manufacturers do not have a product in a popular market (in the case of Mazda, small trucks) so they make a deal with another company to get in on the action. Volvo, for example did this with its S40 compact, which is actually made by Mitsubishi.

--
A deep unwavering belief is a sure sign you're missing something...

Slashdot Mirror

Codeplay Responds to NVidia's Cg

42 of 163 comments (clear)