One of the practical problems I ran into while learning CUDA was simply having the right computer with me. The machines I used had CUDA-capable GPUs, but they also tended to be bulky or heavy. They were fine at a desk, but inconvenient to carry around just to try a small kernel.
For a while, my workaround was to leave my GPU machine running at home and connect to it remotely. It worked, but it was not a great routine. Leaving it on all day felt wasteful, and more than once I went out only to realize that I had forgotten to turn it on.
That made me wish there were a simple CUDA playground I could open anywhere. I wanted a place to write a small CUDA C++ or Python program, run it on a real GPU, and see the result without setting up a remote machine first.
Remote access was only part of the problem. Whenever I wanted to understand a run, I had to profile it separately. If I wanted to remember which version of the code produced a particular profile, I had to keep my own notes. It was easy for the code, output, and profiling data to become disconnected.
GPUFlight Workbench grew out of those frustrations. I wanted one place where a saved version of the code, its output, and the GPU trace could stay together.
I also wanted Workbench to be a good first experience with GPUFlight. Instead of asking people to understand the whole product upfront, they could start with a small program and see the connection between their code and what happened on the GPU. That felt like a more useful introduction than a feature list or a product tour.
A Small CUDA Workspace in the Browser
Workbench starts with a few deliberately small templates:
- Hello, GPU in CUDA C++
- Vector addition in CUDA C++
- Python vector addition with Numba CUDA
The templates are not meant to hide CUDA. They give you a working project so you can get to the useful part sooner.
The CUDA C++ projects use regular .cu source files. The Python template uses Numba and @cuda.jit. In both cases, the code runs on a managed NVIDIA GPU instead of pretending to run CUDA in the browser.
The First Run
The project adds two arrays with a Numba CUDA kernel. It copies the inputs to the device, launches the kernel, copies the result back, and checks the output on the CPU.
The editor, project files, execution settings, and run history stay on the same page. There is no local CUDA setup involved.
I clicked Run, and Workbench sent the saved revision to a real GPU. The program processed 1,048,576 elements and reported zero verification errors.
That is the basic edit and run loop. It is useful on its own, but the trace is the part I care about more.
From "It Worked" to "What Happened?"
The completed run produced a GPU trace. In this example, the trace found one launch of the Numba vector_add kernel.
Opening the timeline shows the whole sequence on one wall-clock axis:
- host-to-device transfers
- the CUDA kernel launch
- the device-to-host transfer
- kernel launch details and occupancy-related values
- GPU power and memory samples from the run
This is the difference between seeing Verification errors: 0 and understanding how the program reached that result.
For a tiny vector addition, the timeline is simple. That is good. It gives someone learning CUDA a clean picture of the relationship between memory transfers and kernel execution. Once that makes sense, the same workflow can be used for multiple kernels, streams, shared memory experiments, or a small reproduction of a performance problem.
Python and C++ Are Both Part of the Story
Python with Numba is an approachable way to write a first CUDA kernel, especially if Python is already familiar. CUDA C++ gives you direct control over the native CUDA programming model and is still the main path for many performance-sensitive applications.
Workbench supports both because I do not think learning GPU programming needs a single required entry point.
The syntax changes, but the questions are the same:
- What did I launch?
- How many blocks and threads ran?
- When did memory move?
- How long did the kernel take?
- What should I change next?
Those questions are easier to answer when the code, output, and profile are kept together.
What Workbench Is For
Workbench is built around short CUDA experiments and profiling runs. Each run is currently limited to 30 seconds, which is enough for learning, testing kernels, and investigating small performance problems. It is not a general-purpose cloud GPU or a place for long-running training jobs.
That boundary is intentional. The goal is to keep the feedback loop short:
- Start from CUDA C++ or Python with Numba.
- Make one change.
- Run the saved revision on a real GPU.
- Check the output.
- Inspect the kernels, transfers, and timeline.
Then change something and run it again.
I am building GPUFlight, so this is not an independent review. It is the workflow I want the product to make straightforward: start with a browser, write a kernel, and look at what the GPU actually did.
Top comments (0)