Example of CUDA and MATLAB and nothing else (for Windows)

A simple example that creates a MEX file which calls CUDA to add two length-5 vectors

This is a "Hello World"-style example that shows a simple way to directly work with CUDA (Nvidia's supercomputing-on-your-gpu toolkit) from MATLAB. There is very little information online about how to do this sort of thing (other than proprietary and/or intricate examples) so this example was written with simplicity as its goal.

To run: first compile it with 'my_compile test.cpp' and then run your new MEX file on two length-5 vectors of your choice, as in 'test([1 2 3 4 5],[10 20 30 40 50])'

Requirements:
1) This example was written for the Nvidia GTX 260 or 280, which are the only gpus to support double-precision arithmetic. This is reflected as follows: in my_compile.m, nvcc is run with the '-arch compute_13' switch, which produces code for the GTX 260 and above. If you want to run this example on older hardware, remove this switch, replace all the doubles with singles in test.cu, and rewrite test.cpp to pass arrays of singles to gpuAdd, instead of doubles.

2) This example was written for Visual Studio 2008 (9.0). If you have Visual Studio 2005 (8.0) you should be able to run the example by changing the 6th character in the body of my_compile from a '9' to an '8'.

3) This example was written in Windows XP64. It probably works in other versions of Windows, but changes to my_compile.m might be needed to get the right paths from the environment variables.

4) This example was written on CUDA 2.1 (beta)

Files:
1) test.cpp is a very standard MEX file that expects to be linked with a function gpuAdd that takes three pointers to double arrays of length 5 and stores the sum of the first two arrays in the third array. (This is indicated by 'extern "C" gpuAdd...').

2) test.cu is a very simple CUDA file. gpuADD creates three length-5 arrays in the gpu's memory, fills the first two of them with doubles from the cpu's memory, spawns 5 threads to compute each of the 5 sums, copies the result back to the cpu's memory, and cleans up.

3) my_compile.m has some goofiness in it, primarily because nvcc has some sloppiness in it. The first line is an operating system command that runs a Visual Studio batch file which sets up temporary environment variables that specify include and library directories; the '&' character separates this command from the nvcc compile command (which has to be run in the same command as the batch file or else the temporary variables will disappear). The '-c' switch says to compile but not link test.cu. The next line tries to get the path to the CUDA libraries. It strips out quotes if they're there (side note: on XP64 CUDA neglects to put quotes when defining the environment variable, but won't compile unless they're added; we strip them out again for MATLAB.) The final line uses mex to compile the mex file and link it against test.obj, as produces in the first line by nvcc.

Quirk: Yes this will produce valid 64-bit code when run on a properly-configured 64-bit system. The 32-bit batch file we run is just something nvcc insists on for their own reasons.

Caution: code run on gpus has none of the protections that 40+ years of experience of coding for cpus have given us. Don't be surprised if your system crashes when playing around with gpu code.