Show HN: OctoFlow – A GPU-native programming language I built a general-purpose programming language where the GPU is the primary execution target, not an afterthought. |
Show HN: OctoFlow – A GPU-native programming language I built a general-purpose programming language where the GPU is the primary execution target, not an afterthought. |
Interesting project! I haven't really worked with Vulkan myself yet. Hence my question: how is the code compiled and then loaded into the cores?
Or is the entire code always compiled in the REPL and then uploaded, with only the existing data addresses being updated?
Each gpu_* call emits SPIR-V and dispatches via Vulkan compute. Data stays resident in VRAM between calls — no round-trips to CPU unless you need the result.
No thread_id exposed. The runtime handles thread indexing internally — gpu_add(a, b) means "one thread per element, each does a[i] + b[i]." Workgroup sizing and dispatch dimensions are automatic.
The tradeoff: you can't write custom kernels with shared memory or warp-level ops. OctoFlow targets the 80% of GPU work that's embarrassingly parallel. For the other 20% you still want CUDA/Vulkan directly.
Cheers
Because I think there is no way to avoid concepts like thread_id.
I'm curious how GPU programming can be made (a lot) simpler than CUDA.
So instead of writing a kernel with thread_id:
let c = gpu_add(a, b)
let total = gpu_sum(c)
The thread indexing is still there — just handled
by the runtime, like how Python hides pointer math.