Sebastian Aaltonen ships NoGraphicsAPI, a Vulkan prototype where shaders use raw GPU pointers, and the repo has 1,319 stars in 11 days

Sebastian Aaltonen has published NoGraphicsAPI, a working prototype of the idea from his "No Graphics API" blog post and SIGGRAPH talk, and the repository has 1,319 stars in 11 days on GitHub. It is a minimal graphics API built on Vulkan 1.4 that removes almost every layer between shader code and GPU memory.

What it removes

The repo's own description sets out the question: "how much of a conventional graphics API disappears when shaders use 64-bit GPU pointers, texture and sampler descriptors live in application-owned GPU memory, and synchronization describes hazards instead of resource state." The answer, as implemented, is: most of it. There are no descriptor sets, no pipeline layouts, and no per-resource state transitions. Shaders read and write buffers through raw GPU pointers, textures and samplers sit in descriptor heaps the application manages itself, and a single root data payload is copied into commands with vkCmdPushDataEXT.

What it keeps

Barriers stay, but they describe execution and memory hazards rather than resource transitions, which is closer to how the GPU actually enforces ordering. Submission is explicit and asynchronous, tied to timeline points rather than fences per queue. The result is a small surface with graphics, mesh, and compute paths, a Win32 presentation backend, and a cube example that renders a Vulkan-Tools test texture. Linux and SteamOS presentation are on the roadmap.

Why the stars

The repo is 11 days old, MIT-licensed, has 35 commits and 37 forks, and its author is the graphics engineer whose past work sits behind Ubisoft and Unity engine code. The audience is small and specific: engine developers, driver writers, and researchers who have been discussing whether the descriptor-set and pipeline-state model of modern APIs is still doing useful work. A prototype that shows a concrete alternative, running on a shipping Vulkan driver, is the artefact that discussion was missing.

For a team maintaining a rendering path, this is not a library to adopt. It is a reference implementation that answers a design argument with running code: how much of the pipeline abstraction is inherent to the hardware, and how much is habit carried forward from OpenGL and DirectX 11. The trade-offs it accepts, the extensions it needs, and the parts of Vulkan it still cannot avoid are more useful than the star count. Engine teams evaluating what the next generation of their renderer looks like now have a small, readable codebase to argue about rather than a slide deck.

Source

Primary source: sebbbi/NoGraphicsAPI on GitHub.