Eskiu GPU: How Our Own Language Cut Scan Processing From 15 Minutes to 6

In short: Eskiu GPU is the GPU layer for Eskiu, the MIT-licensed systems language built in ReactVision Labs. It runs on wgpu-native, so one API targets Metal, Vulkan and DirectX 12. Moving the Advanced VPS pipeline onto it cut a typical medium-quality room scan, with a full mesh and object detection, from about 15 minutes to 6.

A month ago, processing a medium-quality room scan on our backend took around 15 minutes. Today the same job takes around 6. We didn't buy bigger GPUs to get there. We wrote our own GPU layer, in our own language.

That layer is Eskiu GPU, and this post is a look at what it is, why we built it, and what it means for Advanced VPS, the next generation of spatial understanding we're bringing to ReactVision developers.

The Eskiu work was led by Eduardo Dorantes.

First, what is Eskiu?

Eskiu is a systems language we build in ReactVision Labs. It's self-hosting, compiles through LLVM, has no garbage collector, and speaks the C ABI, so it slots in next to the C++ and native code that already runs our stack. It isn't an experiment sitting on a shelf: Eskiu already runs in production inside ViroCore, the native engine behind ViroReact. The memory-sensitive modules we've migrated to it use around 85% less memory than before.

Eskiu is MIT licensed, like ViroReact. And to be clear up front: you don't need to learn Eskiu to build with ViroReact or the ReactVision Editor. It's the engine room, not the steering wheel.

What does Eskiu GPU do?

Eskiu GPU is the package that gives Eskiu direct access to the graphics card. It's built on wgpu-native, so one API targets Metal on macOS and iOS, Vulkan on Linux and Android, and DirectX 12 on Windows. Shaders are written in WGSL.

It covers three jobs:

• Compute: storage buffers, WGSL kernels, dispatches, and reading results straight back into Eskiu memory.
• Rendering: textures, depth buffers, render passes, and a model loader for glTF 2.0 (.gltf and .glb) and OBJ, drawn with physically based shading, normal maps, skinning, and animation. PNG and JPEG decoding is written in pure Eskiu.
• Machine learning: transformer inference from GGUF, safetensors, and llama2.c files, with f32, f16, Q8_0, and Q4_0 kernels, plus training with automatic differentiation and an Adam optimiser. Trained weights save as safetensors that PyTorch can load.

Errors come back as typed results with the actual WebGPU validation message, and WGSL errors point to the line and column. If you need to go lower, the full webgpu.h API is exposed through <gpu/raw>.

How fast is Eskiu GPU?

We hold ourselves to published benchmarks. These are from the repository README, measured on an Apple M4 Pro with greedy decoding:

We're not claiming to beat llama.cpp, which has years of hand-tuned Metal kernels behind it. What matters to us is that a young package, written in our own language, already lands within reach of it on quantised models, and that the output is right: Llama 2 output matches llama2.c byte for byte, and matches llama.cpp and Hugging Face transformers token for token on the prompts we've tested. On the training side, the MNIST example trains a small network to 97% test accuracy in three epochs, at roughly 0.4 seconds per epoch.

How did Eskiu GPU speed up Advanced VPS scan processing?

Benchmarks are useful. Shipping is better. The first place Eskiu GPU is earning its keep is the processing pipeline behind Advanced VPS.

Advanced VPS takes a phone capture of a space and turns it into something your app can understand: a full mesh, measurements, and a breakdown of what's in the room. Every one of those steps leans on the GPU, from building the mesh to running object detection across it.

Moving that work onto Eskiu GPU has cut processing times across the board. The headline: a typical medium-quality scan with a full mesh and object detection used to take around 15 minutes to process. It now takes around 6. Bigger spaces and higher-quality settings still take longer, but every scan size we run has got faster.

On the left, a kitchen processed by Advanced VPS, with its detected objects labelled in place. On the right, the processed mesh itself, which you can explore in 3D.

Advanced VPS kitchen meshClick to load the interactive 3D model (3.6 MB), rendered by ViroReact in your browser.

Why build our own language and GPU layer?

People sometimes ask why a small team would write its own language, let alone its own GPU layer. The short answer is that spatial computing lives or dies on performance, and you can't tune what you don't own.

When your pipeline is a stack of other people's runtimes, you inherit every one of their trade-offs: their memory model, their platform gaps, their release cadence. Each layer you own is a layer you can make faster, smaller, and more portable. Eskiu in ViroCore gave us the 85% memory saving. Eskiu GPU has more than halved scan processing time. Those are the results that tell us this is the right bet.

It's also why glTF and GLB sit at the centre of everything. The same formats move between ViroReact, the Editor, ReactVision Spatial, and Eskiu GPU, so improvements in one place show up everywhere.

What's next for Eskiu GPU?

This is the start. Eskiu GPU is at v0.2.0 and moving quickly. Today the GPU modules run on macOS, Linux, Windows, iOS, and Android. WebAssembly runs the pure Eskiu modules now (glTF, OBJ, images, GGUF, safetensors, maths), with the GPU modules to follow.

For ReactVision developers, the payoff is Advanced VPS: faster processing now, and more on-device computer vision as Eskiu GPU reaches more of the pipeline. Better scans, quicker turnaround, and apps that understand the space around them.

If you want to dig in:

• Eskiu GPU docs: eskiu-lang.org/gpu.html
• Source, tests, and examples: github.com/eskiu-lang/gpu
• ReactVision Labs: reactvision.xyz/labs/eskiu-gpu

And if you're building something that needs to understand physical space, we'd love to hear about it.