Campy version 0.0.8 has been released. The changes to Campy since release 0.0.7 have centered around the integration of the GPU BCL (i.e., the “Dot Net Anywhere” runtime that is being used on the GPU after porting to CUDA C) into the compiler. Unfortunately, the effort has set into motion a large number of changes. Some of those changes I expected, but many were not.
- Up to now, C# objects on the GPU were allocated using a “malloc” of pinned memory. This memory was allocated in C# on the host CPU using Cuda.cuMemHostAlloc(), and is accessible on the CPU and GPU. But, C# objects are managed, meaning that the BCL should know the type of the object when a pointer is passed to it. With the recent changes to Campy, C# objects accessible on the GPU are now allocated using the GPU BCL. (987209c and others).
- The GPU BCL needs to be accessible on both the GPU and CPU because the memory allocation on the CPU needs to be recorded by the GPU BCL. Considerable time was devoted to figure out how to write C# code to call unmanaged C code in a DLL that contains the GPU BCL (example). For the GPU, a static .LIB file is generated that contains pre-linked code (via nvcc -dlink). For the CPU, an unmanaged layer written in C/C++ is provided in a DLL. C# code calls the DLL API using P/Invoke.
- The assembly containing the kernel needs to be loaded by the GPU BCL. Campy “worked” before but used the meta only on the CPU side (using Mono.Cecil). The GPU BCL now reads the meta for any assemblies referenced.
- Even though Campy is supposed to be Net Standard 2.0 code, “dotnet build” of Campy wouldn’t build. As it turned out, Swigged.LLVM and Swigged.CUDA contained references to native libraries which prevented building Campy via Dotnet.exe. Those packages have been updated so that the native libraries are now in the proper sub-directory (Swigged.LLVM 6.0.5; Swigged.CUDA 9.185.5).
- The pre-build code in the .TARGETS file of Swigged.LLVM and Swigged.CUDA don’t work with “dotnet build” because Dotnet does not create output directories before the running the pre-build steps. The build now performs a copy using a completely different Msbuild mechanism.
- This release fixes line-oriented debugging of kernel code (11). Due to quirkiness of Mono Cecil (2116ef7), method references in CIL call instructions would not have debugging symbols loaded. A problem in instruction discovery (IMPORTER) existed with CIL call rewrite: the offset of the instruction was not set. These problems are now fixed.
- Many compiler warnings were cleaned up. A Dotnet build of Campy is completely error and warning free.
- Note, Dotnet works in a different directory from the application that you build. In order to find all dependent dlls and libs, you will need to change directory to the application, or “publish -r win10-x64” the application. Finding dlls is still a mess, but Campy with Net Core and Net Framework does work.
- Nsight does not work with Net Core apps. I have no idea why Nsight is so messed up. Build the application as a Net Framework app, and it’ll all work as expected. Make sure it’s a 64-bit app you are building; Campy only works with 64-bit apps.
The release is in Nuget.org. You will need Net Core 2.0 and have CUDA GPU Toolkit 9.1.45 installed on Windows. To take full advantage of Campy, e.g., debugging with Nsight, you will need Visual Studio 15. You should be able to use the latest version of Visual Studio, although I haven’t tried because the GPU toolkit compiles C++ with VS version 15.4. Dotnet published Net Core 2.0 apps should run with only the GPU Toolkit installed.