Can Numbast be used without a CUDA installation?

[dbs4261]

Simple question really, if I am binding a library for host usage only, can I generate bindings (static or dynamic) without the user's environment requiring the CUDA runtime?

[isVoid]

Numbast started with a focused goal: generating bindings for device libraries, where the outputs are callable from device kernels. For host-side bindings, there are already more mature options available, such as pybind11, nanobind, ctypes, SWIG, and others.

For anyone interested in a deeper rabbit hole: the parser side, ast_canopy, includes machinery for finding a CUDA environment that keeps the Clang toolchain happy. Most of that is about satisfying header requirements rather than anything runtime-related.

As a side note, there is also a cuda-header-mode flag that puts the parser into a no-CUDA-injection mode, which may relax some of the header requirements. That said, this is parser-level support only, not end-to-end binding generation.

[dbs4261]

Would you be open to PRs related to this?

[isVoid]

Thanks for your interest in contributing to Numbast! We welcome meaningful open source contributions. Could you share more about your intended use case, especially whether you plan to use Numbast in an ongoing project or workflow? Understanding the motivation will help us make sure the contribution aligns well with the project’s direction and is useful to the broader community.

[dbs4261]

I am specifically looking at generating bindings for Embree. I think it is a particularly compelling case, firstly because it integrates tightly with TBB which Numba uses for CPU parallelism. Additionally, I think it would open up an interesting opportunity for jitting the same kerenel from python into either a CPU ray tracing kernel with Embree or GPU Kernel with Optix. (Out of scope) More than that, there is no equivalent piece of software that can generate Numba bindings from an AST on the CPU side. And it makes more sense to generate Numba bindings, instead of JAX bindings, for CPU code as JAX doesn't truly support CPU parallelism.

I've been able to get AST Canopy to work without CUDA. The harder part of making CUDA optional are the includes in the generated bindings which I haven't dug into in depth. It would also require adding another dependency group that doesn't require the numba-cuda package.

Additionally AST Canopy and Numbast don't support some aspects of C/C++ yet that the Embree API uses. The issues I have found so far:

1. Structs that contain other structs. This one is easy to fix, types just need to be registered in Numbast before their bindings are rendered. Just split the loop into two passes.
2. Opaque Pointers as records. I get these aren't going to be super common, but it is handy to be able to hide implementation. Most Embree types like devices, scenes, geometries etc. are handled like this. Additionally some structs contain these types.
3. Qualified typedefs. This ties into the Opaque Pointer binding. Right now, typedefs only work as a way to provide an alternate name to a struct. In Embree the scene type RTCScene is defined as typedef struct RTCSceneTy* RTCScene. So I would want the generated binding to be a typedef to a pointer to an opaque type, but right now, the typedef just disappears, and (with some patching) I end up with RTCSceneTy being bound.
4. Function Pointer typedefs as records. Some structs work as a function table. So AST Canopy would need to parse these typedefs, and Numbast would need to be able to search the typedefs when rendering the struct.

[isVoid]

Thanks for raising these points. After discussing this internally, our guiding principle is that Numbast is a CUDA device-library-focused binding generator. Because of that scope, we would not be able to accept changes whose primary purpose is to make the parser work independently of CUDA, or to otherwise move Numbast away from its CUDA-focused design.

That said, we view improvements to the core parser and binding-generation functionality as generally neutral and welcome. The examples you mentioned above seem to fall into this category: they make the parser more robust and help support more Numba functionality. We would be happy to consider contributions in that direction.