3 ms·
It seems like a C API is a much better choice if you want your library to be callable from many different languages. What is a reasonable alternative without gi
by mellinoe 9y ago
It seems like a C API is a much better choice if you want your library to be callable from many different languages. What is a reasonable alternative without giving that up?
- pjmlp 9y agoA bytecode format, like what CUDA, Metal Compute and DirectX Compute use. Which Khronos finally adopted as SPIR, but the drivers aren't there yet. Regarding the other Khronos APIs, a C API is like being stuck in a PDP-11 world. Many mix the idea of C API with OS ABI, it only happens to be the same if the OS APIs are exposed as plain C. There many cases where this isn't like it, e.g. mainframes, mobile OSes, and most userspace on OS X (Obj-C runtime) and Windows (.NET and COM).
- mellinoe 9y agoD3D, Vulkan, OpenGL (optionally) etc. do use a bytecode format, but that only covers shader modules, which are a small part of the overall API. I'm not that familiar with CUDA, but it looks like a large portion of it is delivered as a C API, judging by the bindings I see online.
- nicwilson 9y agohaving a bytecode, and having a C API are completely orthogonal. And thankfully we now have both with SPIR-V, although the C API needs to be wrapped unless you like writing C-like code in higher languages that abstract most of the tedium. Yes driver support is a bit lacking, although I hop that I can convince the OpenCL working group of the need to get a backend (such as https://github.com/thewilsonator/llvm-target-spirv https://github.com/thewilsonator/llvm-target-spirv) into mainline LLVM so that writing drivers becomes easier for vendors.