Automatic Kernel Embeddings

[badnikhil]

Currently, DCompute requires a "side-car" workflow where .ptx (CUDA) or .spv (OpenCL) files are generated as separate files. Developers must manually manage these paths and use Program.fromFile("path/to/kernel.ptx")at runtime. This has several drawbacks.

[badnikhil]

1. We define a small header to identify our data related to kernel binary (SASS)inside the section.
2. We create a tiny helper tool that takes .ptx files and bundles them with that header.
3. In DCompute , we add a shared static this() constructor.

so during dub build:
everything happens like it does.. after compilation , the tiny helper utility puts the SASS into our binary. during runtime the constructor registers the kernel..

in the D code user can directly write something like

import dcompute.driver.cuda;

void main() {
    auto res = UnifiedBuffer!float(1024);
    auto x   = UnifiedBuffer!float(1024);
    auto y   = UnifiedBuffer!float(1024);
    saxpy.launch([32, 1, 1], [32, 1, 1], res, 5.0f, x, y, 1024);
}

i think my explaination is simple and approach is accurate enough @thewilsonator

[thewilsonator]

so it is possible to use the -J flag to then include the files into the binary and it would also be possible to make the compiler or dub (with postBuildCommands) invoke the PTX assembler on the resulting file.

That still leaves dealing with devices and queues.

[badnikhil]

@thewilsonator --J and postBuildCommands simplifies the embedding side significantly.

For the "devices and queues" part, I'm thinking we can follow what the CUDA Runtime API does:

Default to device 0 -> a shared static this() constructor initializes the platform, picks the first available device, and creates a default context + queue. This covers the common single-GPU case.
Expose some APIs -> something like Device.select(n) for users who need multi-GPU or want a specific device. The default path requires zero boilerplate, but control is always available.
I'll start working on the default constructors and lazy initialization. This way saxpy.launch(...) can "just work" without the user having to manually set up Platform, Context, Queue, or Program.