데이빗 커크(NVIDIA의 메인 개발자(Chief Scientist))과 Cg와 이것이 그래픽 프로그래밍 커뮤니티에 어떤 의미가 있는지에 대해서 약간 대화할 기회가 있었다. 우리의 질문에 대해서 답변할 시간을 마련해 준 데이빗에게 감사한다.

Cg는 그래픽스를 위한 C 언어입니다. 아이디어는 과거에 요구되었던 GPU의 프로그래밍에 있어서 저레벨 어셈블리 코딩을 사용하기보다는 상위 레벨의 언어를 사용하자고 하는 것이었습니다. 어셈블리 언어 프로그래밍은 짧은 코딩에는 적합하나, GPU가 점점 더 고수준으로 프로그래밍 가능하게 진화되고 더 길고 융통성있는 프로그램을 지원함에 따라 어셈블리를 사용하는 것은 사용하기 까다롭게 되었습니다. 상위 레벨 언어 프로그래밍은 개발자로 하여금 그다지 많은 하드웨어 명령을 습득하지 않고서도, 더욱 직접적으로 작업을 할수 있도록 해줍니다. 개발자는 보다 쉽게 프로그램들을 생성하고 수정할 수 있게 되며, 그 프로그램은 어떤 하드웨어에서도 잘 실행되도록 컴파일 될 것입니다. (역주 : 카드에 관계없이 한번의 컴파일로 활용이 가능하다라는 것을 의미하는 듯함.)

아닙니다. 몇몇 우주적이거나 종교적인 뜻으로 물어보는 것이 아니라면 말이죠. (역주 : DX나 GL 한쪽만을 좋아하지 않는다는 의미인 듯...) Cg가 표준 OpenGL의 최상층의 레이어에 놓여있으며, 또한 directX8과 directX9에서도 최상층의 레이어에 놓여있기 때문에, Cg 프로그램은 독립적인 API 기반하에 작성될 수 있으며 변경 없이 양쪽 API상에서 실행될 수 있습니다.

One of the important things you can do with Cg that's a pain with the assembly interface is to build your shader incrementally, out of several different pieces. Say one of your shader writers creates a cool per-pixel lighting solution, while another one figures out a neat procedural effect such as marble. With Cg, you can easily create each of these as functions, and combine them together however you think makes sense (perhaps, just multiplying the two values together). With the assembly interface, you would probably need to rewrite one of the shaders, since the two pieces of the shader need to agree on which registers get used to hold various pieces of data. You can't do this at all in a fixed-function pipeline, since there is currently not support for procedural surfaces, or for per-pixel lighting. Also, the standard library provides you with a ton of useful & tested functions that would take a lot work to replicate for each shader in assembly. For example, calculating the sin() of a value is just one function call in the standard library, but would easily consist of more than a dozen assembly instructions for GeForce 3 and GeForce 4.

Cg 프로그램 길이의 한계는 당신이 컴파일하고 있는 타겟에 따라 운용됩니다. 예를 들면, Directx 8 정점 셰이더는 128 개의 어셈블리 명령으로 제한됩니다. 그러므로 만약 당신이 128 보다 더 많은 수의 명령을 컴파일하고 있는 Cg 프로그램을 작성한다면, 당신은 당신의 코드를 재작성할 필요가 있습니다. NVIDIA's Cg Compiler doesn't do any magical multipass behind your back to break those strict limits, as our feedback from developers was clearly telling us they wanted to handle that part of the code. 그것은 차후 살펴볼 것입니다.

Cg vertex programs and Cg fragment programs are specifically targeted at vertex shaders and pixel shaders, respectively. Given a particular target piece of hardware, the Cg program for vertex operations will be compiled at runtime into the API interface of choice (OpenGL or Direct3D) with the correct instruction set for the vertex processor for that hardware. Likewise, a Cg program for fragments (pixels) will be compiled at runtime for the pixel shader. The instruction sets for these processors differ, so the expression of the Cg program for vertex and pixel programs may differ accordingly. For each of these programs, the data results and inputs must match, so that the information produced per vertex is the correct information that is called for per pixel.

But from a syntax point of view, Cg programs for Vertex and Pixel are more or less the same, whether they're targeted at the vertex or fragment (pixel in Direct3D terminology) level. Texturing is not possible in a program targeted at the vertex level, and so texture functions, as well as functions to compute derivatives (often used in texturing) will not compile if targeted at a vertex profile. But one of the key ideas of Cg is that you can use the same language to represent programs that run on the vertex engine, fragment engine, or any other programmable engines that might be dreamed up for future architectures.

물론, 이것은 Cg 프로그램을 작성하는 사람에게 많은 부분이 달려있습니다. 확실히 사람들이 Cg상에서 재사용가능한 많은 유용한 함수들이 존재합니다. 예를 들면, Cg 프로그램들내에 넘겨지는 매개변수들은 실행시 털의 색상같은 요소나 털이 얼마나 길어질 것인가, 얼마나 굵게 할 것인가등등을 변경하기 위해 미세하게 조정될 수 있습니다.

그래서 보다 넓은 느낌으로 본다면, 어셈블리와 반대로 재사용성과 이식성은 Cg을 사용하는 핵심적인 장점이라고 볼 수 있습니다. 하나의 프로젝트를 위해 작성된 코드는 프로젝트에 걸쳐서, 그리고 개발자 사이에서 까지도 공유될 수 있습니다. 나는 우리가 커뮤니티 웹사이트상에서 늘어나고 있는 저장된 셰이더 코드들을 볼 수 있을 것을 확신합니다.

The Cg Standard Library was designed to provide many of the often-used math functions from the standard C library, and also some shading-specific routines that are commonly used in shading languages. Routines ranging from sin(), exp(), and cross(), to refract(), distance(), and noise(), are all included in the Cg Standard Library.

Cg is different from, say, C, in that it is designed to work on a stream of data. An example would be a stream of vertices that represent a 3D model. There are points in the pipeline where one stream of data is converted into a different stream of data, such as taking a stream of vertices, and rasterizing the triangles represented by those vertices. The data in are vertices, the data out are fragments (or pixels, in Direct3D terminology). Connectors are a way of representing this change in the data stream. A connector mostly looks like a C struct, but some of the fields in the connector change when moving between, say, the vertex and fragment sides of the connector.

The Cg Runtime Library provides several useful functions. First, it allows a program to compile their Cg programs on-the-fly, very quickly. Cg programs can also be pre-compiled, and the output of those programs can be saved off in a game or other application. But the advantage of compiling on-the-fly is that the Cg program, which is not chip-specific, can be optimized by the compiler for each piece of hardware upon which the program is run. So, if someone writes a Cg program to, say, bumpmap a surface, the bumpmapping technique can be compiled down optimally for each different GPU on which the application runs. The other big function of the Cg Runtime Library is to let the application tweak parameters of the shader at runtime. If an app precompiles the bumpmap without using the Cg Runtime Library, and then at application runtime, the app decides that the bumpmaps need to change in depth, for example, the application would need to have pre-built a separate shader that knows how to draw deeper bumpmaps. By using the Cg Runtime, the application can instead just change a parameter passed in to the Cg program, re-compile on-the-fly, and render using that Cg program's output automatically.

Because Direct3D and OpenGL differ in their APIs, the Cg Runtime interface is different for Direct3D versus OpenGL. The same functionality is available, but we have tried to make the Cg Runtime for Direct3D look consistent with the rest of Direct3D, while the Cg Runtime for OpenGL looks more familiar to OpenGL programmers.

Cg은 GPU상에서의 그래픽의 상위 레벨 언어 프로그래밍에 대한 기본틀이라고 할 수 있습니다. 이것은 단지 시작일 뿐입니다. 왜냐하면 우리는 단지 programmable한 GPU를 생산하는 것을 시작했을 뿐이니까요. 차세대 GPU는 더 유연하고 보다더 프로그래밍이 가능하게 될 것이며, 훨씬 더 강력해 질 것입니다. 마법과 같은 실시간 컴파일에 의해서, 이 새로운 GPU들은 여전히 Cg을 사용하여 프로그래밍이 가능하게 될 것입니다. 그리고 또한 오늘날의 Cg 프로그램은 미래의 GPU에도 수정없이 실행될 수 있을 것입니다. 이것이 바로 Cg의 아름다움이죠 : Cg는 Cg가 동작하는데 있어서 API 독립적이며, 플렛폼 독립적이고 새로운 GPU의 생산에 대해서도 독립적입니다. 그러므로, Cg 프로그래밍의 앞에는 길고 흥미진진한 미래가 펼쳐져 있다고 말할 수 있습니다.