6

Specifically, my issue is that I have CUDA code that needs <curand_kernel.h> to run. This isn't included by default in NVRTC. Presumably then when creating the program context (i.e. the call to nvrtcCreateProgram), I have to send in the name of the file (curand_kernel.h) and also the source code of curand_kernel.h? I feel like I shouldn't have to do that.

It's hard to tell; I haven't managed to find an example from NVIDIA of someone needing standard CUDA files like this as a source, so I really don't understand what the syntax is. Some issues: curand_kernel.h also has includes... Do I have to do the same for each of these? I am not even sure the NVRTC compiler will even run correctly on curand_kernel.h, because there are some language features it doesn't support, aren't there?

Next: if you've sent in the source code of a header file to nvrtcCreateProgram, do I still have to #include it in the code to be executed / will it cause an error if I do so?

A link to example code that does this or something like it would be appreciated much more than a straightforward answer; I really haven't managed to find any.

Billy Smith
  • 273
  • 1
  • 5

2 Answers2

5

You have to send the "filename" and the source of each header separately.

When the preprocessor does its thing, it'll use any #include filenames as a key to find the source for the header, based on the collection that you provide.

I suspect that, in this case, the compiler (driver) doesn't have file system access, so you have to give it the source in much the same way that you would for shader includes in OpenGL.

So:

  • Include your header's name when calling nvrtcCreateProgram. The compiler will, internally, generate the equivalent of a std::map<string,string> containing the source of each header indexed by the given name.

  • In your kernel source, use #include "foo.cuh" as usual.

  • The compiler will use foo.cuh as an index or key into its internal map (created when you called nvrtcCreateProgram), and will retrieve the header source from that collection

  • Compilation proceeds as normal.

One of the reasons that nvrtc provides only a "subset" of features is that the compiler plays in a somewhat sandboxed environment, without necessarily having all of the supporting tools and utilities lying around that you have with offline compilation. So, you have to manually handle a lot of the stuff that the normal nvcc + (gcc | MSVC| clang) combination provides.

A possible, but non-ideal, solution would be to preprocess the file that you need in your IDE, save the result and then #include that. However, I bet there is a better way to do that. if you just want curand, consider diving into the library and extracting the part you need (blech) or using another GPU-friendly rand implementation. On older CUDA versions, I just generated a big array of random floats on the host, uploaded it to the GPU, and sampled it in the kernels.

This related link may be helpful.

3Dave
  • 28,657
  • 18
  • 88
  • 151
  • Hmmm. So I have some thinking to do about how I accomplish this. Pre-compiling the code that uses curand into PTX isn't feasible... Pre-generating floats on the CPU isn't feasible because there would need to be way too many... So I am left with working through the curand library to get the parts that I need to compile using NVRTC, and finding another implementation of rand. As all I really need from curand is the standard uniform PRNG from 0 to 1, I think the solution is to find another PRNG that is easier to compile using NVRTC, thanks! – Billy Smith Oct 17 '16 at 20:58
  • Hmm. GPU implementations of PRNGs are hard to come by. Maybe I will have to adapt CURAND somehow... – Billy Smith Oct 17 '16 at 21:39
  • @BillySmith The most direct solution is to build a big buffer and populate it with rand() or similar CPU-side, then upload it to the host. Keep an index variable indicating what value is "next" in the buffer. When you hit the end of the buffer, rinse and repeat. – 3Dave Oct 18 '16 at 12:49
0

You do not need to load curand_kernel.h yourself and add it to the include "aliases" mechanism.

Instead, you can simply add the CUDA include directory to your (set of) include paths, e.g. by adding --include-path=/usr/local/cuda/include to your NVRTC compiler options.

(I do this in my GPU-kernel-runner test harness, by default, to be on the safe side.)

einpoklum
  • 118,144
  • 57
  • 340
  • 684