0

The CUDA Runtime API has the functions cudaGetSymbolAddress() and cudaGetSymbolSize() for working with device-side globals from host-side code, using their names (source-code identifiers) as handles.

In the Driver API, we have cuModuleGetGlobal(), which lets us do the same thing... except that it takes a CUmodule which the global symbol is situated in. If you're working with code that you dynamically compiled and loaded/added into a module then you're all set. But what if those globals are part of your program, compiled statically using NVCC rather than loaded dynamically?

I would assume that there's some sort of "primary module" or "default module" for each compiled program, with its baked-in globals and functions. Can I get a handle for it?

einpoklum
  • 118,144
  • 57
  • 340
  • 684
  • 1
    a `.cu` file gets compiled via `nvcc` to either ptx or cubin (for standard driver API usage). Either of these is loaded by the driver API using a `cuModuleLoadXX` function. Not sure what you are asking about. – Robert Crovella Dec 07 '21 at 03:44
  • The runtime API uses fairly fragile private boilerplate to do its magic, there are no APIs which do what you imagine – talonmies Dec 07 '21 at 03:55
  • Are you asking about a module from a runtime API build? Otherwise I don’t understand your question. You literally use the identical code to an nvrtc invocation, except the module is returned from the call where you load the external cubin or ptx from a file name or handle and not the runtime compiler output – talonmies Dec 07 '21 at 08:44
  • @talonmies: I'll try to explain here in the comment and please tell me if I should rephrase the question itself. I'm not loading anything dynamically. I have a .cu file with a global device-side variable and, say, a kernel which uses it. I now want to use `cuModuleGetGlobal()` to get information about that global. – einpoklum Dec 07 '21 at 08:47
  • @RobertCrovella: (answering again to clarify). I'm not asking about a module I load myself, dynamically, but rather about the module that the runtime creates when I compile a `.cu` file into a program and run it. – einpoklum Dec 07 '21 at 08:49
  • Ok, so you are trying to access the static runtime API module from the driver API? If that is the case, you can’t. Use the runtime API, or perform a runtime linking session and access it that way – talonmies Dec 07 '21 at 08:51
  • @talonmies: Ok, that's an answer. It's a bit strange that I can't because, because the driver does allow us access to the primary context for driver-API-interaction purposes, so it would stand to reason that the same would be true for the module with the globals and functions. – einpoklum Dec 07 '21 at 08:57

1 Answers1

0

I would assume that there's some sort of "primary module" or "default module" for each compiled program, with its baked-in globals and functions.

There is, and if you pull apart the runtime API emitted host boilerplate code which makes it work and some runtime traces, you will see it relies on a lot of statically defined symbols and a couple of undocumented runtime API functions which internally maintain the module the runtime API uses.

Can I get a handle for it?

Using the driver API, no. If you need to interact with the runtime API, then use the runtime API.

talonmies
  • 70,661
  • 34
  • 192
  • 269
  • Actually, the reason I want this module is to [avoid having to interact with the runtime API as much as possible](https://github.com/eyalroz/cuda-api-wrappers/issues/279), while still letting my users write code as though they were going to use the runtime API. but I guess it can't be helped, as with `cudaGetFuncBySymbol()`. – einpoklum Dec 07 '21 at 10:08
  • Perhaps you can change the build process by extracting the PTX of your users then. – Sebastian Dec 07 '21 at 15:06