GPU pointers replace most public buffer and binding objects
NoGraphicsAPI asks renderer developers to treat GPU data more like ordinary allocated memory. Applications reserve GPU heaps, suballocate them, and pass 64-bit GPU pointers through structures shared between C++ and Slang. Textures and samplers live at application-chosen descriptor-heap indices. A draw or dispatch receives one pointer to its root arguments instead of a collection of descriptor sets, layouts, and vertex bindings.
That model removes a lot of visible ceremony, but it does not remove the underlying work. The application still owns allocation policy, object lifetime, and synchronization. Pipeline objects still carry rasterization, blending, and attachment formats. Root allocations must remain stable until GPU work completes. An optional utility library supplies math, allocators, upload queues, and deferred deletion, yet those helpers are deliberately outside the core API. This is an engine-building experiment, not a higher-level scene renderer.
What happened when we ran it
Our sandbox checked commit ae017a2 in an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The repository contained 119 files, about 14,840 lines of source, and occupied 1.2 MB. It had a tests directory, no Dockerfile, and no GitHub Actions workflow. That is a compact checkout, though a small source tree says nothing about whether the host GPU meets the extension contract.
Configuration failed after 9 seconds with exit code 1. CMake's find_package step required Vulkan 1.4.357 or newer and reported Vulkan_LIBRARY-NOTFOUND. Because configuration did not complete, this run never reached compilation or the repository's tests. The log identifies a missing required dependency, not a source defect. It also shows that a generic C++ image is insufficient even for the first build step.
Vulkan 1.4 alone does not meet the feature contract
The Vulkan backend requires descriptor heaps, commands that operate on device addresses, mesh shaders, and untyped shader pointers. It targets little-endian x86-64, while the utility math requires AVX2 and FMA. Mapped heaps also need coherent CPU-visible GPU memory. On a discrete card, Resizable BAR affects how much useful mapped memory the application can expose, even when the required extensions exist.
The project's September 5 compatibility table makes the exclusions concrete. Pascal and the checked Intel Arc report lack required extensions. Checked Windows RDNA 2 configurations are unsupported, while newer RDNA 3 and RDNA 4 reports qualify. Turing can expose the extensions but may be constrained by a 256 MiB fixed BAR. Those are dated driver snapshots, not permanent vendor guarantees, so deployment needs a feature query on the exact driver version you ship.
Metal 4 support also starts with recent devices
Apple support begins at macOS, iOS, or iPadOS 26 with Metal 4 and Apple GPU family 7. That means Apple silicon Macs, iPhone 12 or newer, and the documented recent iPad generations. Intel Macs, Simulator, tvOS, and visionOS are excluded. Direct task and mesh draws work across the baseline, while indirect mesh draws need A17 Pro or M3 hardware or newer.
The two backends share the public C++ API and Slang sources, which is useful when comparing native implementations. They are not broad fallbacks for one another. CMake selects Metal on Apple platforms and Vulkan on Windows or Linux. Linux remains headless, while Windows and macOS have windowed examples. An engine that needs older Apple targets, Linux windows, or a conservative graphics baseline should stop here and choose a wider abstraction.
The examples are small enough to inspect line by line
The repository includes a triangle, a textured cube, and a deferred renderer. The cube demonstrates pointer-based vertex fetch and bindless textures. The deferred example adds compute simulation and mesh-shader rendering. Shared root structures make the central idea visible: CPU code fills an allocation, passes its GPU address, and shader code follows typed pointers from that root. You can trace the model without first understanding a large engine.
Windows setup is still substantial. The documented path uses Visual Studio 2022, CMake 3.24 or newer, Vulkan SDK 1.4.357 or newer, SPIRV-Tools 2026.3 or newer for validation, Slang, and an eligible driver. macOS asks for Xcode 26 plus its Metal compiler and Slang 2026.18.2 or newer. These requirements are reasonable for the extensions being explored, but they exclude casual experimentation on a typical stable toolchain.
September 29 changes show active research, not a stable release line
GitHub showed 1,560 stars and 6 combined open issues and pull requests on September 30, 2026. The repository was pushed on September 29. Open work covered Linux XCB support, device diagnostics, device selection, distributable example assets, and a ray-tracing question. There was no published GitHub release. The project is alive, but consumers do not yet have a tagged series that communicates compatibility across API changes.
For graphics specialists, that is not a disqualifier. The source is readable, the hardware boundaries are explicit, and the code makes a modern API argument testable. Production adopters face a different standard. Pin the commit, query every required extension, run the examples and validation suite on each target, and keep a fallback renderer until the hardware list and release practice fit your support policy.