Built with Eskiu

Programs that run today: ReactVision's rendering modules and web AR in production, a language model on the GPU, a 3D model viewer and the compiler itself. Labs has the experiments, such as an AR demo on a handheld console.

ReactVision

ReactVision builds ViroCore, the native AR/VR rendering engine behind @reactvision/react-viro on iOS, Android, Meta Quest and visionOS. The team replaces memory-sensitive C++ components with Eskiu modules that link in over the C ABI, one module at a time, while the rest of the engine stays as it is. The rendering modules moved so far use about 85% less memory.

The object detection core of react-viro-onnx, written twice in Objective-C++ and Java, is now one Eskiu module for both platforms in production, with its Android JNI layer written in Eskiu through the jni package.

Read the ReactVision case study →

tinyvio: AR tracking in the browser

tinyvio is the visual-inertial tracker behind ViroReact's AR on the web: corners, optical flow, pose solving, bundle adjustment, planes and anchors, compiled to WebAssembly. Its whole engine, about 9,000 lines of C++, was ported to about 7,400 lines of Eskiu that implement the same C API, and the Eskiu engine is the one in production. It computes the same bits as the C++, frame after frame, at the same speed:

Its computer vision core is also an Eskiu package, vision, checked bit for bit against tinyvio's C++ on every commit.

How it was checked →

Llama 2 on Metal

examples/llama2.esk in the gpu package is Llama 2 inference after Andrej Karpathy's llama2.c. It reads llama2.c checkpoints, llama GGUF files (Q4_0 and Q8_0 run quantized on the GPU) and Hugging Face model directories with safetensors, and runs on the GPU through WebGPU, which is Metal on a Mac:

eskiuc build && ./build/llama2 llama-2-7b.Q4_0.gguf -t 0 -i "The capital of France is"

Measured on an Apple M4 Pro with greedy decoding. The outputs match llama2.c byte for byte, and llama.cpp and Hugging Face transformers token for token, on the prompts tested. The forward pass is a program of <gpu/nn> operations recorded once and replayed as one compute pass per token.

The same package trains networks: examples/mnist.esk trains a two-layer network on MNIST with <gpu/train> to 97% test accuracy in three epochs, and saves the weights as safetensors, which PyTorch loads with the same accuracy.

A glTF and OBJ viewer with PBR

examples/model.esk in the gpu package opens glTF 2.0 (.gltf and .glb) and Wavefront OBJ files in a window: drag to orbit, scroll to zoom, and space pauses the animation. <gpu/model> shades with glTF's metallic-roughness model under one directional light and a hemisphere ambient term, with normal maps, alpha modes, skinning and animation. The same code runs on Metal, Vulkan and DirectX 12.

github.com/eskiu-lang/gpu →

The compiler, written in Eskiu

Eskiu has two implementations of its compiler. The released eskiuc is written in C++ and links LLVM. The second, under selfhost/, is written in Eskiu: it covers the same pipeline and command line, writes LLVM IR as text and calls clang to assemble and link it. CMake builds it as eskiuc-esk, and CI checks that both compilers agree on every runnable program in the test suite.

preprocessor → lexer → parser → sema → async lowering → codegen (LLVM IR text) → clang

It is also checked against itself. The C++ eskiuc builds cc0, cc0 builds cc1, and cc1 builds cc2; the bootstrap reaches a fixpoint when cc1 and cc2 produce identical IR for the compiler's own source.

How self-hosting is checked →

Labs

Experiments made to see how far Eskiu goes. They work, and they are not products.

An AR demo on the Nintendo 3DS

A camera and gyroscope AR demo holds a 3D model steady over the live camera feed. Its logic is written in Eskiu, compiled for the console's 32-bit ARM11, and its rendering goes through ViroCore on citro3d. It was verified on real 3DS hardware.

Read the 3DS case study →