Slashdot Mirror


NVidia announces Cg: "C" for Graphics

mr_sheel writes: "Thresh's FiringSquad has an article about Cg, a new language developed by NVidia in collaboration with Microsoft. 'Up until now,' Brandon Bell writes, 'game developers have had to use complex assembly language to create the lifelike graphics gamers experience in today's latest games.' Cg eases the process of bringing graphics to the screen and compiles for DirectX 8,9 and OpenGL 1.4. Many companies, including 3D Studio Max, Blizzard, and over 100 game developers, have already jumped onto the Cg bandwagon. Will this replace assembly graphics coding once and for all?"

11 of 176 comments (clear)

  1. MS Mistrust by feldsteins · · Score: 3, Interesting

    "...in collaboration with Microsoft..."

    I just hope that phrase doesn't mean non-DirectX operating systems (Linux, Mac OS X) aren't about to get the short end of the grahics stick. I can visualize features not being implimented for OpenGL, or worse, support for OpenGL discontinued at some strategic point in the future "because our customers strongly prefer DirectX" [says Microsoft].

    Ok maybe I'm paranoid. Maybe this is basically nVidia's baby and MS is only involved a little bit. Let's all hope. Can someone reasure me?

    --
    You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
    1. Re:MS Mistrust by fferreres · · Score: 3, Interesting

      Nvidia = Microsoft since the begining. I can say that because I know them since the NV1 (1995 i think), which I own.

      They where virtually killed by 3Dfx many times yet someone kept pumping money from "somewhere" for them. The only change in focus after their failure this: target for Direct3D.

      They kept pumping money and money and selling at a loss until they bough 3Dfx. Most other players where dead already (rendition and many others) dead by then. Now they control the market with Microsoft by their side. Microsoft was always against 3Dfx, they direct3D was never "friendly" with 3Dfx cards (though it worked fine, features where really targeted for Nvidia cards).

      It's like Nvidia and Microsoft developed direct3D. It's not a coincidence. Microsoft would never enjoy a monopolistic provider in a key market unless they own/control it somehow (and no, you don't need Microsoft puting money directly to own it. There are a thouthand ways to own something in an unnoticed fashion).

      Remark: i know Nvidia cards are the best and excelent ones! This has nothing to do with it :) The 3D market history is full of "black holes" which you just can't understand well without some conspiracy.

      --
      unfinished: (adj.)
  2. Why it won't work (link) by Space+Coyote · · Score: 4, Interesting
    There's an interesting editorial at The Register pointing out some of the flaws in Cg, and speculating about NVidia's intention for future development of the language as it relates to their core graphics hardware busines.

    From the article:

    • No break, continue, goto, switch, case, default. These are useful features that can be used without penalty on other vector processors.
    • 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.
    • No integers. This may be appropriate to NVIDIA, but is not a universal design decision.
    • Arrays use float indices. This is an odd design decision, relevant to DirectX 8 and Nvidia only.

    It may be possible that NVidia is holding back support for such rudimentary language features until such time as they are supported in their own hardware. I don't think this is a formula for a widely-adopted language at all, and smells a little of 3dfx's efforts with Glide.

    --
    ___
    Cogito cogito, ergo cogito sum.
  3. I wonder what John Carmack thinks of this by levik · · Score: 3, Interesting
    This looks like a very smart move on NVIDIA's part. Remember GLIDE? Everyone loved it, and it arguably contributed a lot to 3Dfx's success in late 90s. The only problem with GLIDE was that it completely didn't work on any other cards.

    Which was fine while the market was 90% Voodoo, but once other players got more or less established, the benefit of easily developing stuff with GLIDE was overshadowed by the loss of a chunk of your target audience, and the developers moved away from it.

    Now imagine, if GLIDE worked on all the competitors' cards, but worked just *slightly* worse than on a Voodoo card. Not enough to be unplayable or anything, but worse nontheless. Then, there's a good chance developers would still use GLIDE, and 3Dfx could claim supperiority on all those products.

    However "open" Cg will be, NVIDIA will definitely get the edge on any software written with it, if only because they will have had a head start.

    I wonder though if this language is at all similar to GLIDE, which they acquired together with 3Dfx. I also wonder what someone who is very good at low-level graphics programming (like John Carmack) thinks of the idea of this language.

    --
    Ñ'
  4. cgshaders.org and Linux Toolkit by Screaming+Lunatic · · Score: 5, Interesting

    The official community site is at cgshaders.org. There's a Linux Toolkit out now. There's a interview with CEO David Kirk. Along with articles, a shader repository, and forums for help.

  5. Re:Complex assemly language? by Milalwi · · Score: 3, Interesting

    Please grab a clue, high performance 3d graphics aren't done in assember. Its done in C with OpenGL calls. The OGL calls are quite high level, nothing as simple as 'put a point at x,y on the screen'. Why do I know? Because I know OpenGL perhaps?


    Perhaps you should look at this before you comment further?

    "Writing code for existing Pixel and Vertex Shaders is akin to writing assembly code. Eventually it'll work but it's a laborious, low-level exercise with almost no comprehensibility if someone else works on the code."

    Maybe you "know" OpenGL, but have you ever written a pixel or vertex shader?

    Milalwi
  6. OpenGL 2.0 Shader Language by RoninM · · Score: 5, Interesting
    Cg looked awfully familiar to me (and not just because we had this article, before). You might want to compare it to the OpenGL 2.0 Shader Language defined here (PDF) and implemented here.

    All of this leaves me a little bit confused. I'm not sure why we need two (or, perhaps, more) C-based shader languages, at least one of which (Cg) is hardware-specific, but API neutral.

    --
    If a corporation is a personhood, is owning stock slavery?
  7. Re:Float for array indices? by WNight · · Score: 3, Interesting

    I doubt it's for interpolation. It's easy to average two numbers and pick the midpoint but proper interpolation is a *very* complex subject. To get really good interpolation you need to graph both sides of the data set and extrapolate over the area you're interested in, from both sides. Then where (if) those meet, that's the new value. The farther away you graph from, the smoother the interpolated area.

    This is something it might be nice to have a function to do, but if this was done on every array access it's going to be hella-slow.

    Not to mention, sometimes you store arrays of things you don't want interpolated. You could interpolate between shades in a pallette, but perhaps you're holding three colors in an array for three effects. Effect one (blood) is red, effect two (slime) is green, etc... If you use floats for integers either you round them to get ints, or you have something that's never exact. So in this case you'd have 1.000003, for instance, and it'd interpolate between the red and green, even though you didn't want that behaviour.

    So, for the reason that automatic interpolation between array values is hard to do, and hard to do in a way that you'd want, I don't think they're doing it.

    Most likely they're dealing in floats simply because they've got hardware that can deal with floats very quickly, and they trunc or round to get the desired value when using them in an integer context.

  8. Re:What Are You Talking About? by fferreres · · Score: 4, Interesting

    Do you even read articles? How did you get modded insightful? Do moderators read articles?

    Yes, I think they do read them. There's nothing in the article that contradicts what he says. Actually, Nvidia IS IN BED with Microsoft. 3Dfx was not and got killed. 3DLabs was not and suffered.

    If it werent't for Id, i'd say OpenGL will be dead right now and you would not be able to play any 3D games but loading Windows.

    Now, all this can sound unsound, but if you really followed what happened in the 3D world since 1995 you will notice it's not a crazy idea.

    Microsoft needs the games to run under Windows and XBox, and to NOT run on any other plataform. This is as true as the sky is blue. So the original poster does have a valid point with I'd mod as Insightfull any day.

    --
    unfinished: (adj.)
  9. Re:This wouldn't happen... by johnathan · · Score: 3, Interesting

    Full-text queries can only be done on four or more letter words.

    You're just making that up, jackass. There is no limit to how short the text is that you query for.

    Not so, it turns out. From that very page:
    MySQL uses a very simple parser to split text into words. A ``word'' is any sequence of characters consisting of letters, numbers, `'', and `_'. Any ``word'' that is present in the stopword list or is just too short (3 characters or less) is ignored.
    --
    You don't need a weatherman to know which way the wind blows.
  10. Re:C'mon by Anonymous Coward · · Score: 1, Interesting

    > It's why most compiled languages have a way to include in-line assmbly code.

    That isn't why. In-line assembly was brought into 'C' to access hardware features. Like "bit set and test interlocked", MMX, "INT xx", etc., etc., all which can't be expressed in 'C' and are too "light" to justify a function call's overhead.

    For most "i++" style code, the compiler can do a fine job of getting it right. Not that all do, but their own failures aren't the assumption built into in-line assembly.