NVRTC standard practice when creating programs & kernels

Hi, I’m doing some stuff with NVRTC and the CUDA driver API, and I’ve been looking into jityfy’s as a way of learning the API, but one thing kinda stuck out to me - it’s the way the programs and kernels get created. As far as I can tell they first compile the program repeatedly, and when they get an error they try to extract a header from it, which they then add to the program and recompile it, this is repeated until the program compiles successfully. After they create the program they then use it to compile a kernel, using the extracted headers - I may have misunderstood something in their source code, but this feels a bit wasteful - isn’t there a ‘better’ way of doing what they are?


jitify has a number of features. I believe you are focusing on just one of them.

With respect to that, you can manually traverse every include chain that is needed in your project, and do something equivalent without using jitify.

My guess would be that the jitify designers chose not to create a parser that could do that work (because its hard) and instead took advantage of the tools that were available to them.

You might try hacking through a complex include process for NVRTC. It’s a lot of fun.

After you do that, you might be more interested in jitify, or maybe you will write your own universal include parser, that handles all situations and corner cases reliably.

Or feel free to suggest something better via the github issues system.

From my own experience with NVRTC, my “standard practice” is to avoid creating kernels that depend on all sorts of headers that I am unfamiliar with, that I didn’t write and include myself. But when the situation demands something more, I think that was the motivation for jitify. It’s obviously not a standard part of CUDA. Merely a convenience library that was written by some NVIDIA developers when they ran into these sorts of struggles.

It’s by no means mandatory.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.