HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
eyalroz
cuda-api-wrappers
C++2021–2026
eyalroz / cuda-api-wrappers

cuda-api-wrappers

Thin, unified, C++-flavored wrappers for the CUDA APIs

Languages & CompilersSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
2Distinct people
17Mentions
0Explicit recommenders
906GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Thin, unified, C++-flavored wrappers for the CUDA APIs

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2021-09-25 19:52:06 UTC to 2026-06-29 14:12:34 UTC.

0123452021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC303
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC505
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

What Hacker News says

17 sources
einpoklum·Jun 29, 2026
First - nice writeup which goes into a lot of nooks and crannies. That said, a lot of the user-space "voodoo" is gone if you don't go through CUDA's "runtime API". If you use the driver API, take your kernel source as a string and compile it with NVIDIA's run-time compiler, you'll have better visibility into a lot (not all) of what's going on. For the "raw" version of this, look at: https://github.com/NVIDIA/cuda-samples/tree/master/cpp/0_Int... but for a much more readable, and still fully transparent modern-C++ API version of the same, try this: https://github.com/eyalroz/cuda-api-wrappers/blob/master/exa... that's a sample program for my CUDA API wrappers (header-only) library.
In What happens when you run a CUDA kernel?
einpoklum·Jan 19, 2026
In my library [1], wrapping the CUDA APIs in modern C++, I do allocations which are not exactly from an arena, but something in that neighborhood - memory spaces on context on GPU devices. Unlike the GP suggests, and like you suggest, I have indeed embraced RAII in the library - generally, not just w.r.t. memory allocation. I have not, however, replicated that idioms of the standard library. So, for example: * My allocations are never typed. * The allocation 'primitives' return a memory_region type - essentially a pointer and a size; I discourage the user from manipulating raw pointers. * Instead of unique_ptr's, I encourage the use of unique_span's: owning, typed, lightweight-ish containers - like a fusion of std::span<T> and std::unique_ptr<T[]> . I wonder if that might seem less annoying to GP. --- [1] : https://github.com/eyalroz/cuda
Read the rest
-api-wrappers/
In Understanding C++ Ownership System
einpoklum·Nov 20, 2025
> CUDA Runtime: The runtime library (libcudart) that applications link against. That library is actually a rather poor idea. If you're writing a CUDA application, I strongly recommend avoiding the "runtime API". It provides partial access to the actual CUDA driver and its API, which is 'simpler' in the sense that you don't explicitly create "contexts", but: * It hides or limits a lot of the functionality. * Its actual behavior vis-a-vis contexts is not at all simple and is likely to make your life more difficult down the road. * It's not some clean interface that's much more convenient to use. So, either go with the driver, or consider my CUDA API wrappers library [1], which _does_ offer a clean, unified, modern (well, C++11'ish) RAII/CADRe interface. And it covers much more than the runtime API, to boot: JIT compilation of CUDA (nvrtc) a
Read the rest
nd PTX (nvptx_compiler), profiling (nvtx), etc. > Driver API ... provides direct access to GPU functionality. Well, I wouldn't go that far, it's not that direct. Let's call it: "Less indirect"... [1] : https://github.com/eyalroz/cuda-api-wrappers/
In CUDA Ontology
einpoklum·Jan 14, 2025
NVIDIA does have a bunch of FOSS libraries - like CUB and Thrust (now part of CCCL). But - they tend to suffer from "not invented here" syndrome [1] ; so they seem to avoid collaboration on FOSS they don't manage/control by themselves. I have a bit of a chip on my shoulder here, since I've been trying to pitch my Modern C++ API wrappers to them for years, and even though I've gotten some appreciative comments from individuals, they have shown zero interest. https://github.com/eyalroz/cuda-api-wrappers/ There is also their driver, which is supposedly "open source", but actually none of the logic is exposed to you. Their runtime library is closed too, their management utility (nvidia-smi), their LLVM-based compiler, their profilers, their OpenCL stack :-( I must say they do have relatively extensive documentation, even if it doesn't cover e
Read the rest
verything. [1] - https://en.wikipedia.org/wiki/Not_invented_here
In The Missing Nvidia GPU Glossary
einpoklum·Nov 28, 2024
### Statistics ### ninja has ~26 kloc, ~3,100 commits, and only a quarter of them by the original author (although by loc changed their weight is higher). Interesting! https://github.com/ninja-build/ninja/graphs/contributors ### Bunch of other comments ### > users of ninja ... all Meson projects, which appears to increasingly be the build system used in the free software world; So, AFAICT, that hasn't turned out to be the case. > the code ends up being less important than the architecture, and the architecture ends up being less important than social issues. Well... sometimes. Other times, the fact that there's good code that does something goes a very long way, and people live with the architectural faults. And as for the social issues - they rarely stand in opposition to the code itself. > Some pieces of Ninja took struggle to get to an
Read the rest
d then are obvious in retrospect. I think this is true of much of math Yup. And the some of the rest of math becomes obvious when some re-derives it using alternative and more convenient/powerful techniques. > I think the reason so few succeed at this is that it's just too tempting to mix the layers. As an author of a library that also focuses on being a "layer" of sorts (https://github.com/eyalroz/cuda-api-wrappers/), I struggle with this temptation a lot! Especially when, like the author says, the boundaries of the layers are not as clear as one might imagine. > I strongly believe that iteration time has a huge impact on programmer satisfaction I'm pretty certain that the vast majority developers perform 10x more incremental builds than full builds. So, not just satisfaction - it's just most of what we do. It's also those builds which we wait-out rather than possible go look for some distraction: https://xkcd.com/303/ OTOH, the article doesn't mention interaction with build artifact caching schemes, which lessen the difference between building from scratch and building incrementally. > Peter Collingbourne found Ninja and did the work to plug it into the much more popular CMake ... If anyone is responsible for making Ninja succeed out there in the real world, Peter is due the credit. It is so gratifying when a person you didn't know makes your software project that much more impactful! Makes you really feel optimistic again about humanity and socialism and stuff.
In The success and failure of Ninja (2020)
johndough·Sep 20, 2024
Personally, I prefer CuPy over your library. For example, your vectorAdd.cu implementation at https://github.com/eyalroz/cuda-api-wrappers/blob/master/exa... is much longer than a similar CuPy implementation: import cupy as cp vector_add = cp.RawKernel(""" extern "C" __global__ void vector_add(const float *A, const float *B, float *C, int num_elements) { int i = blockDim.x * blockIdx.x + threadIdx.x; if (i < num_elements) { C[i] = A[i] + B[i]; } } """, "vector_add") num_elements = 50_000 block_size = 256 # round up to next multiple of block_size grid_size = (num_elements + block_size - 1) // block_size a = cp.random.rand(num_elements, dtype=cp.float32) b = cp.random.rand(num_elements, dtype=cp.float32) c = cp.zeros(num_elements, dtype=cp.float32) args = (a, b, c
Read the rest
, num_elements) print(f"[Vector addition of {num_elements} elements]") print(f"CUDA kernel launch with {grid_size} blocks of {block_size} threads each") vector_add((grid_size,), (block_size,), args) incorrect = cp.abs(a + b - c) > 1e-5 if cp.any(incorrect): print("Result verification failed at element", cp.argmax(incorrect)) print("Test PASSED") print("SUCCESS") It could be made even shorter with a cp.ElementwiseKernel https://docs.cupy.dev/en/stable/user_guide/kernel.html#basic... Although I have to concede that the automatic grid size computation in cuda-api-wrappers is nice. A few marketing tips for your README: * Put a code example directly at the top. You want to present the selling points of your library to the reader as fast as possible. For reference, look at the CuPy README https://github.com/cupy/cupy?tab=readme-ov-file#cupy--numpy-... which immediately shows reader what it is good for. Your README starts with lots of text, but nobody reads text anymore these days. A link to examples is almost at the end, and then the examples are deeply nested. * The first links in the README should link to your own library, for example to documentation or examples. You do not want to lead the reader away from your GitHub page. * Add syntax highlighting with "cpp" after triple backticks: ```cpp <code here> ```
In CuPy: NumPy and SciPy for GPU
einpoklum·Jul 20, 2024
This is _not_ an alternative to CUDA nor to OpenCL. It has some high-level and opinionated API [1], which covers a part (rather small part) of the API of each of those. It may, _in principle_, have been developed - with much more work than has gone into it - into such an alternative; but I am actually not sure of that since I have poor command of Vulcan. I got suspicious being someone who maintains C++ API wrappers for CUDA myself [2], and know that just doing that is a lot more code and a lot more work. [1] - I assume it is opinionated to cater to CNN simulation for large language models, and basically not much more. [2] - https://github.com/eyalroz/cuda-api-wrappers/
In Kompute – Vulkan Alternative to CUDA
einpoklum·Jul 16, 2024
At my workplace, we were reluctant in making the choice between writing OpenCL and being AMD-compliant, but missing out on CUDA features and tooling; and writing CUDA and being vendor-locked. Our jerry-rigged solution for now is writing kernels that are the same source for both OpenCL and CUDA, with a few macros doing a bit of adaptation (e.g. the syntax for constructing a struct). This requires no special library or complicated runtime work - but it does have the downside of forcing our code to be C'ish rather than C++'ish, which is quite annoying if you want to write anything that's templated. Note that all of this regards device-side, not host-side, code. For the host-side, I would like, at some point, to take the modern-C++ CUDA API wrappers (https://github.com/eyalroz/cuda-api-wrappers/) and derive from them something which supports
Read the rest
CUDA, OpenCL and maybe HIP/ROCm. Unfortunately, I don't have the free time to do this on my own, so if anyone is interested in collaborating on something like that, please drop me a line. ----- You can find the OpenCL-that-is-also-CUDA mechanism at: https://github.com/eyalroz/gpu-kernel-runner/blob/main/kerne... and https://github.com/eyalroz/gpu-kernel-runner/blob/main/kerne... (the files are provided alongside a tool for testing, profiling and debugging individual kernels outside of their respective applications.)
In Run CUDA, unmodified, on AMD GPUs
einpoklum·Jul 1, 2023
1. This implements the clunky C-ish API; there's also the Modern-C++ API wrappers, with automatic error checking, RAII resource control etc.; see: https://github.com/eyalroz/cuda-api-wrappers (due disclosure: I'm the author) 2. Implementing the _runtime_ API is not the right choice; it's important to implement the _driver_ API, otherwise you can't isolate contexts, dynamically add newly-compiled JIT kernels via modules etc. 3. This is less than 3000 lines of code. Wrapping all of the core CUDA APIs (driver, runtime, NVTX, JIT compilation of CUDA-C++ and of PTX) took me > 14,000 LoC.
In VUDA: A Vulkan Implementation of CUDA
einpoklum·Jan 21, 2023
Given your criteria, you might want to consider (modern) C++. * Fast - in many cases faster than Rust, although the difference is inconsequential relative to Python-to-Rust improvement I guess. * _Really_ utilize CUDA, OpenCL, Vulcan etc. Specifically, Rust GPU is limited in its supported features, see: https://github.com/Rust-GPU/Rust-CUDA/blob/master/guide/src/... ... * Host-side use of CUDA is at least as nice, and probably nicer, than what you'll get with Rust. That is, provided you use my own Modern C++ wrappers for the CUDA APIs: https://github.com/eyalroz/cuda-api-wrappers/ :-) ... sorry for the shameless self-plug. * ... which brings me to another point: Richer offering of libraries for various needs than Rust, for you to possibly utilize. * Easier to share than Rust. A target system is less likely to have an appropriate version
Read the rest
of Rust and the surrounding ecosystem. There are downsides, of course, but I was just applying your criteria.
In GNU Octave
einpoklum·Jul 5, 2022
For writing kernels and profiling, yes, it's pretty nice. But the host-side API is rather unapproachable. There are, like, 20 API calls just for different variants of memory allocation, all inconsistently named. Also, the APIs are almost entirely (but not 100%) C'ish. In the API wrappers I've written: https://github.com/eyalroz/cuda-api-wrappers I try to address these and some other issues. We should also remember that NVIDIA artificially prevents its profiling tools from supporting OpenCL kernels - with no good reason.
In How CUDA Programming Works

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.