Related articles

• Tell me about CUDA, the "architecture," versus the "CUDA for C" compiler.CUDA is the name of Nvidia’s parallel computing hardware architecture. Nvidia provides a complete toolkit for programming the CUDA architecture that includes the compiler, debugger, profiler, libraries, and other information developers need to deliver production-quality products that use the CUDA architecture. The CUDA architecture also supports standard languages (C with CUDA extensions and Fortran with CUDA extensions) and APIs for GPU computing, such as OpenCL and DirectX Compute. This diagram may help: With OpenCL, you gain the advantage of cross-platform support, but lose automated tools, such as memory management, that are found with CUDA. It seems that as a scientist, you'd want to decrease your startup development costs, but at the same time, you'd want support for multiple platforms. What's the best way to reconcile this challenge? There are certainly compromises that have to be made to provide a cross vendor/platform solution. Nvidia has worked from the beginning with Apple and the OpenCL working group to make sure OpenCL provides a great driver-level API layer for GPU computing, especially for Nvidia hardware. Furthermore, we will certainly provide extensions to further enable Nvidia GPU’s with OpenCL. Nvidia is also constantly improving our C compiler and development environment for Nvidia GPUs. We have a few simple extensions to C in order to enable our GPUs. If Fortran is more your preference, there is a Fortran compiler also available. With the introduction of Microsoft’s Windows 7 this fall, users and developers will have access to the DirectCompute API, which shares many concepts with our C extensions. Nvidia seeded a DirectCompute driver to key developers last December. These are the added advantages to choosing Nvidia hardware; we support all major languages and API’s. Your work with GPUs started in the GeForce 5 era, and we're now several generations later. Obviously, the newer stuff is faster, but what new capabilities have been introduced over this time period (i.e. IEEE-754 compliance)? What can we do now that we couldn't do before? Early programmable GPUs were basic floating point-only programmable processors. No integer or bit operations, no general access to GPU memory, no communication between neighboring processors. The first main innovation was to provide the hardware needed for supporting C, which includes full pointer support and native data types. Another key innovation was the addition of dedicated, on-chip shared memory, which allows processors to intercommunicate and share results, greatly improving the efficiency of the algorithms. In addition, it offered programmers a place to temporarily store and process data close to the processor, rather than going all the way out to off-chip DRAMs. Shared memory improved our signal processing library by 20x over a similar OpenGL implementation. Finally the addition of double-precision floating point hardware also signified a key step toward GPUs as a true high performance computing product, enabling applications that required extended precision numerics. It should also be noted that memory speed and on-board memory size improvements (up to 4GB per processor and 16GB for our Tesla 1U server) has increased the scale of problems an Nvidia GPU can tackle. What about the compiler? What kind of optimizations and innovations have been added over time? Very early on, we recognized that we needed to build a world-class compiler solution. GPU computing programs tend to be much larger, more complex, and benefit from more complex optimization. Our competition (the CPU) had almost 40 years to get it right. Our C compiler is based on technologies from the Edison Design Group, who has been making C compilers for 20 years, and the Open64 compiler core, which was originally designed for the Itanium processor. Our compiler technology, combined with the world-class compiler team we’ve assembled, is a key part of Nvidia’s success. Currently, most GPUs are very fast with single precision math, but less quick with double precision math. Will GPUs still provide "better than CPU" cost/performance if it weren't for the economies of scale? That is, could you make a special double precision-optimized GPU while still keeping costs low? As the market for GPU computing clearly continues to grow, I think you will see more areas invested in double precision arithmetic. Our double precision hardware released last year was only the starting point for what I imagine will be a growing investment in GPU computing from both the industry and Nvidia. What is your impression of Intel's Larabee? AMD's Stream Architecture? Cell? Zii? My view of Larabee is that it is a great validation of what the GPU has achieved and an acceptance of the limitations the CPU. Where CPUs have tried to take a legacy sequential programming model and squeeze out every last bit of parallelism, GPUs were created for 3D rendering, an embarrassingly parallel application. Massive parallelism is a part of the GPU’s core programming model.  In the end, it is the accessibility and productivity of a programming model that will take an architecture from a novelty to a success. We are all competing against a mountain of legacy code. We’ve focused on making Nvidia GPUs extremely easy to obtain orders of magnitude speedups with a familiar and simple programming model.

• Tom's Hardware: What makes Dynamic Pictures unique when compared to other generative art forms? San Base: The Dynamic Paintings I'm designing are examples of generative art - an art that has been generated algorithmically by a computer system. There have been many attempts at producing generative art; the history of it goes back to the early days of computer development. Many of these works have used fractals (geometric shapes that at different scales repeat themselves, at least to some degree) and pretty much none of them accounted for more than just basic artistic principles. This is not the case for my Dynamic Paintings. I'm a strong believer that innovation is often born when several drastically different disciplines come together, and I think that being an experienced programmer and an artist gives me an edge. Another big challenge with dynamic pictures has been the inadequate computing power of personal computers to handle advanced algorithms that describe artistic principles of a computer generated painting. My technology uses powerful video cards to generate real-time images that rival most of the conventional contemporary paintings that cost thousands of dollars. This is not something that has been attempted before. Also, being able to generate images in real time enables me to set paintings in motion and create a new experience never seen before. Courtesy: San Base Tom's Hardware: You use graphics cards in your work. Can you tell us what cards you utilize and why? San Base: Many of the modern CPUs are still not powerful enough to generate these images in real time; only the latest developments in programmable video cards (GPUs) have made this technology possible. Instead of using video cards for rendering 3D images like video games do, my technology taps into the video card's raw computing power. Painting algorithms, translated into pixel shaders - programs used by GPUs - painstakingly construct paintings pixel by pixel at any desired resolution with an unprecedented level of detail. This is an example of using video cards for what is called general purpose computing on GPU (GPGPU). The rendering engine is constructed in such a way that we are not limited by the video card's native resolution, so I am able to produce images as big as 80 to 100 Mpixels for printing on a real canvas. Tom's Hardware: What graphics API are you using, and why did you choose to ship screensavers on your website with the DirectX 9 version of the engine? San Base: Currently I use DirectX 9 for the screensavers, but I try to stay API agnostic. In fact, my Dynamic Picture engine supports OpenGL as well. I originally developed an engine using OpenGL and planned to ship it in the screensavers, however I encountered several compatibility problems with it over a wide range of video cards. First of all, OpenGL shading language (GLSL) is slightly differently implemented on Nvidia and ATI (AMD) cards, which caused me some amount of grief to get shaders working equally well on cards from both vendors. The bigger problem was trying to get shaders to run on slightly older shader model 2.x cards. In many cases OpenGL would just switch to software rendering instead of complaining about supported shader capabilities. This wasn't the case for DirectX 9 - it has fairly tight shader specifications and allows you to see shader assembly, which is helpful when you're trying to squeeze every bit of performance and functionality out of shader model 2.x and some lower-end 3.0 cards. In the end, DirectX 9 turned out to be the better choice in terms of broad compatibility and ease of shader development for my screensavers. However, we still keep the OpenGL version around for future cross-platform developments. I use standard C/C++ for the engine and HLSL or GLSL for shader development. Tom's Hardware: You mentioned a GPGPU approach is at the heart of your technology. Are you using any special GPGPU languages, like Brook or CUDA, or some other software developer kit (SDK)? San Base: No, I don't use anything specific to GPGPU implementations in my paintings. The GPGPU is a trend to use GPUs for all kinds of computations and it can be implemented on top of any graphics API that exposes shaders, not just using special GPGPU toolkits. Because my problem is somewhat unique, none of the GPGPU solutions provided a 100% match, which is exactly the reason I decided to write my own engine.

• TH: As I understand it, Adobe is OpenGL-accelerated. I’ve heard nothing from them about Stream. Yet your initial launch info shows Acrobat Reader, Photoshop CS4, After Effects CS4, and Flash 10 all being “Stream-enabled titles.” Can you elaborate on this? AMD: As I mentioned previously, ATI Stream refers to a framework (or environment) for both hardware and software that provides acceleration of tasks outside the usual game rendering or regular video playback acceleration. In the case of the Adobe apps you mentioned, they are enabling the hardware capabilities to accelerate their processing workflow. TH: Hardware acceleration, yes. But that’s not the same thing as Stream acceleration. AMD: Anything that uses GPU acceleration is ATI Stream, be it DirectX, OpenGL, or ATI Stream component. TH: Anything? Isn’t that getting a little too broad and vague? AMD: It is critical for a parallel compute language to be closely integrated with a graphics API. OpenCL will integrate tightly with OpenGL. Another example is DirectX 11, where the compute shaders are closely coupled with the rendering pipeline. In both cases, the rendering API is complimentary to the compute language in either OpenCL or DirectX 11. As parallel compute gets more standardized (with the ratification and release of OpenCL and DirectX Compute Shaders) “ATI Stream” is not defined by what underlying mechanisms are specifically tied to it, but more by what types of activities are being accelerated by the GPU. We tend to look at Stream as the GPU accelerating workloads that are beyond traditional 3D rendering that has previously been associated with GPU processing. Some productivity applications already use more traditional 3D API’s acceleration of certain tasks, hence we view this as an example of Stream processing.