[SYCL][Doc][RTC] Add device global queries

[jopperm]

Adds three new methods on kernel_bundle to interact with device globals defined in runtime-compiled code:

bool ext_oneapi_has_device_global(const std::string &name);
void *ext_oneapi_get_device_global_address(const std::string &name, const device &dev); // return a device USM pointer suitable for queue::memcpy etc.
size_t ext_oneapi_get_device_global_size(const std::string &name);

[gmlueck]

Why is dev a parameter of this function? It doesn't seem to serve any purpose.

[jopperm]

I took the signature straight from the presentation you gave a while back 😇 But I agree, checking the device only makes sense if we also test if the device supports device globals. Playing around with the E2E tests for DGs, such a check does not seem to happen for code compiled with the normal pipeline.

I'll drop the parameter.

[gmlueck]

Is this really true? Can you handle cases like:

• The device global is defined in a namespace, and name includes the namespace qualifier like mynamespace::var?
• The device global is defined in a namespace, the application defines a namespace alias, and name uses the namespace alias like myalias::var?
• The device global is defined as a static member of a struct, and name includes the name of the struct like mystruct::var?

I suspect these would be hard to implement for the same reasons we cannot just pass an arbitrary C++ expression for the address of a kernel function to ext_oneapi_get_kernel, It seems like we would want to use registered_kernel_names also for the names of device globals. (Maybe we should rename the property to registered_names instead.) In this case, registered_names would accept either:

• A C++ expression for a pointer to a kernel function, or
• A C++ expression for a pointer to a device global variable.

In both cases, the expression is conceptually compiled at the bottom of the source code.

Then, the name parameter to ext_oneapi_has_device_global could be either:

• The name of the device global if it was declared in the global namespace (i.e. the top-level namespace), or
• The name of a device global that was registered via registered_names.

[jopperm]

I think there's a reasonable set of (scoped) names that we could mangle on the fly, but I didn't consider aliases, inline namespaces etc.. I agree that to do this right, we should extend registered_kernel_names to also support DG names.

[jopperm]

As this would be quite a heavy-weight change, I'm proposing to limit device globals to be declared on global scope only in 83d2898. Happy to revert if you think that's too constrained.

[gmlueck]

Implementing it in phases is OK, but I think we need to lift the restriction before we consider this extension "finished". Note that NVRTC allows global variables to be defined in namespaces, etc., and their nvrtcAddNameExpression API allows registration of either kernel or global variable names. Therefore allowing device global names in registered_names would be equivalent to what NVRTC has now.

If we plan to rename registered_kernel_names to registered_names, we should do that sooner rather than later. Better to do this before people start using the extension in ernest.

[gmlueck]

This seems like a detail of our implementation. It would also be valid to allocate the device memory earlier (e.g. when the kernel bundle is compiled), or allocate it later (e.g. when the host first reads or writes to the address). Maybe we could instead add a Remarks: section like:

Remarks: The contents of the device global may be read or written from the host by reading from or writing to this address. If the address is read before any kernel writes to the device global, the read operation returns the device global's initial value.

[gmlueck]

We should say that this is a "device USM" pointer. That way application's know they cannot directly access it from the host.

The formatting is messed up here because of the "'s". I generally avoid pluralizing identifiers for stylistic reasons. I'd rewrite the sentence like:

Returns: A device USM pointer to the storage for the device global name on device dev.

[gmlueck]

Kind of a nit, but the size is the size of the device global's storage, which is not the same as sizeof(name). I'd say:

Returns: The size in bytes of the USM storage for device global name.

(BTW, notice that we do not repeat the word "Returns" in the description of the return value.)

[gmlueck]

Do we need the dev parameter? Is the size different on different devices?

[jopperm]

No, see discussion on ext_oneapi_has_device_global. I'll drop the parameter.

[jopperm]

Superseded by intel#17401.