CUDA ("Compute Unified Device Architecture"), is a GPGPU technology that allows a programmer to use the C programming language to code algorithms for execution on the GPU. CUDA has been developed by NVIDIA and to use this architecture requires an NVIDIA GPU and special stream processing drivers. CUDA only works with the new GeForce 8 Series, featuring G8X GPUs; NVIDIA guarantees that programs developed for the GeForce 8 series will also work without modification on all future NVIDIA video cards. CUDA gives developers unfettered access to the native instruction set and memory of the massively parallel computational elements in CUDA GPUs. Using CUDA, NVIDIA GeForce-based GPUs effectively become powerful, programmable open architectures like today’s CPUs (Central Processing Units). By opening up the architecture, CUDA provides developers both with the low-level, deterministic, and for repeatable access to hardware that is necessary API to develop essential high-level programming tools such as compilers, debuggers, math libraries, and application platforms.
The initial CUDA SDK was made public 15th February 2007.[1]
NVIDIA 8-Series GeForce-based GPU
The 8-Series (G8X) GeForce-based GPU from NVIDIA is the first series of GPU to support the CUDA SDK. The 8-Series (G8X) GPUs features hardware support for 32-bit (single precision) floating point vector processors, using the CUDA SDK as API. (CUDA supports the C "double" data type, However on G8X series GPUs these types will get demoted to 32-bit floats.). Due to the highly parallel nature of vector processors, GPU assisted hardware stream processing can have a huge impact in specific data processing applications. It is anticipated in the computer gaming industry that graphics cards may be used in future game physics calculations (physical effects like debris, smoke, fire, fluids).
Advantages
CUDA has several advantages over traditional general purpose computation on GPUs (GPGPU) using graphics APIs.
- It uses the standard C language, with some simple extensions.
- Scattered writes - code can write to arbitrary addresses in memory.
- Shared memory - CUDA exposes a fast shared memory region (16KB in size) that can be shared amongst threads. This can be used as a user-managed cache, enabling higher bandwidth than is possible using texture lookups.
- Faster downloads and readbacks to and from the GPU
Limitations
- Compared, for example, to traditional floating point accelerators such as the 64-bit floating point (FP64) CSX600 boards from Clearspeed that is used in today's supercomputers, the current GPUs from NVIDIA (and AMD/ATI) are only running on 32-bit, providing only single-precision data capability[1] – instead of double-precision (64-bit) capability of supercomputers.[2] NVIDIA stated in the CUDA Release Notes Version 0.8 file that NVIDIA GPUs supporting (64-bit) Double Precision Floating Point arithmetic in hardware will become available in late 2007.[3]
- Only bilinear filtering is exposed in the CUDA API at this time, most likely because anisotropic and trilinear filtering would require access to derivatives and mipmap chains in CUDA, (and it could also be argued that it would needlessly complicate the API for those using CUDA for non-rendering workloads, which really is the vast majority of CUDA's target audience), but it would be nice with anisotropic and trilinear filtering functionality, for example to accelerate deferred rendering passes.
- Recursive functions are not supported, at all. This is a scheduler limitation, as there currently are no real "functions" on the hardware side of things, and even if there was, there is no stack to push/pop arguments from either, unless you want to use uncached global memory for that - which is unlikely to be super-fast.
- There is no efficient way to do "global synchronisation" on the GPU, which likely forces you to divide the kernel and do synchronisation on the CPU. Given the variable number of multiprocessors and other factors, there may not even be a perfect solution to this problem.
- Various deviations from the IEEE-754 standard even if the precision level is identical. For example, neither denormals nor signaling NaNs are supported. The rounding mode also cannot be changed, and division/square root are not implemented in a fully standard way.
- Functions cannot have a variable number of arguments. Same problem as for recursion.
- Conversion of floating point numbers to integers is done differently than on x86 CPUs.
- The bus bandwidth and latency between the CPU and the GPU may be a bottleneck. (Hopefully the uppcoming PCI Express 2.0 standard might lessen this issue).
See also
- NVIDIA Corporation
- CTM (Close To Metal), AMD/ATI's competing GPGPU technology for ATI Radeon-based GPUs
- Graphics Processing Unit (GPU)
- Stream Processor
- Shader
- HLSL2GLSL
- Sh, a GPGPU library for C++
- Stream programming
- GPGPU (General-Purpose Computing on Graphics Processing Units)
- Graphics processing unit
- Physics Processing Unit (PPU)
- Audio Processing Unit (APU) (GPGPU technology can be used to emulate DSP for audio processing)
References
- ^ Double precision on GPUs (Proceedings of ASIM 2005): Dominik Goddeke, Robert Strzodka, and Stefan Turek. Accelerating Double Precision (FEM) Simulations with (GPUs). Proceedings of ASIM 2005 - 18th Symposium on Simulation Technique, 2005.
External links
- NVIDIA CUDA Homepage
- NVIDIA CUDA GPU Computing developer forums
- NVIDIA CUDA developer registration for professional developers and researchers
- Beyond3D - Introducing CUDA NVIDIA's Vision for GPU Computing (16th February 2007)