GPU.NET is a managed solution integrated with Visual Studio 2010 for .NET developers and aimed at creating calculation intensive applications for GPU.
GPU.NET is a managed solution for creating HPC .NET applications running on the GPU. GPU.NET offers intellisense support for writing C# or VB.NET applications in Visual Studio 2010. The resulting assemblies are pre-processed with an Assembly Processor which injects references to the GPU.NET runtime which in turns compiles the assemblies into native code and manages its execution on existing GPU devices. If not GPU device is found in a system then the execution falls back on the CPU. Any GPU device has a device driver, so targeting it makes more sense than generating CUDA or OpenCL code which would require from users to install other SDKs.
GPU.NET has a plug-in architecture in order to support other devices, according to Jack Pappas, CEO and Co-Founder of TidePowerd, the company behind GPU.NET:
Our runtime uses a plugin architecture for its hardware support. At the release of the beta, we’ll only have a plugin for nVidia CUDA-capable hardware, but we’re collaborating with AMD on a plugin to support their hardware as well (which we’ll make available sometime towards the end of our beta period, but before the release of v1.0). With this plugin-based design, we can easily add support for existing hardware-based accelerator cards (e.g., IBM Cell, or an FPGA-based card) or for new hardware when it becomes available (e.g., Intel’s “Knight’s Corner”).
Another important implication of this design for the runtime is that we can make your [hardware-accelerated] code faster after you’ve deployed it to your end-users, simply by making updates to the plugins; such updates might include bug fixes, new device code JIT compiler optimizations, or support for new APIs available in a certain release of a hardware driver. Note that this update process is totally transparent to both the developer and the end-user.
GPU.NET currently runs on Windows, but it will also run Mac and Linux via Mono. Regarding the API, Pappas commented:
There is a limited API that developers using GPU.NET will need to learn in order to use the system. A few CUDA/OpenCL-like abstractions remain, but we’ve designed the API to have a “native” .NET look-and-feel so that .NET developers without GPGPU development experience can quickly get up to speed and start writing GPU-accelerated code.
For example, in CUDA:
int tid = blockDim.x * blockIdx.x + threadIdx.x;
In C#, using GPU.NET:
int ThreadId = BlockDimension.X * BlockIndex.X + ThreadIndex.X;
The API which exposes higher-level functionality such as parallel primitives (similar to Thrust) hasn’t been finalized yet; we’ll freeze it at some point during the beta period, after we’ve received some user feedback on it.
Read more: InfoQ
Read more: GPU.NET
GPU.NET is a managed solution for creating HPC .NET applications running on the GPU. GPU.NET offers intellisense support for writing C# or VB.NET applications in Visual Studio 2010. The resulting assemblies are pre-processed with an Assembly Processor which injects references to the GPU.NET runtime which in turns compiles the assemblies into native code and manages its execution on existing GPU devices. If not GPU device is found in a system then the execution falls back on the CPU. Any GPU device has a device driver, so targeting it makes more sense than generating CUDA or OpenCL code which would require from users to install other SDKs.
GPU.NET has a plug-in architecture in order to support other devices, according to Jack Pappas, CEO and Co-Founder of TidePowerd, the company behind GPU.NET:
Our runtime uses a plugin architecture for its hardware support. At the release of the beta, we’ll only have a plugin for nVidia CUDA-capable hardware, but we’re collaborating with AMD on a plugin to support their hardware as well (which we’ll make available sometime towards the end of our beta period, but before the release of v1.0). With this plugin-based design, we can easily add support for existing hardware-based accelerator cards (e.g., IBM Cell, or an FPGA-based card) or for new hardware when it becomes available (e.g., Intel’s “Knight’s Corner”).
Another important implication of this design for the runtime is that we can make your [hardware-accelerated] code faster after you’ve deployed it to your end-users, simply by making updates to the plugins; such updates might include bug fixes, new device code JIT compiler optimizations, or support for new APIs available in a certain release of a hardware driver. Note that this update process is totally transparent to both the developer and the end-user.
GPU.NET currently runs on Windows, but it will also run Mac and Linux via Mono. Regarding the API, Pappas commented:
There is a limited API that developers using GPU.NET will need to learn in order to use the system. A few CUDA/OpenCL-like abstractions remain, but we’ve designed the API to have a “native” .NET look-and-feel so that .NET developers without GPGPU development experience can quickly get up to speed and start writing GPU-accelerated code.
For example, in CUDA:
int tid = blockDim.x * blockIdx.x + threadIdx.x;
In C#, using GPU.NET:
int ThreadId = BlockDimension.X * BlockIndex.X + ThreadIndex.X;
The API which exposes higher-level functionality such as parallel primitives (similar to Thrust) hasn’t been finalized yet; we’ll freeze it at some point during the beta period, after we’ve received some user feedback on it.
Read more: InfoQ
Read more: GPU.NET