NoGraphicsAPI: A Bindless GPU Programming Library for Metal 4 and Vulkan 1.4

What NoGraphicsAPI Is and the Problem It Addresses

Conventional graphics APIs require a renderer to declare vertex attribute layouts, create descriptor set layouts describing which resources each shader stage can access, and bind those descriptor sets before every draw or dispatch call. These declarations duplicate information: the shader knows what data it needs, and the CPU knows what data it is providing, but the API forces both sides to independently describe the same binding contract.

Sebastian Aaltonen's blog post, referenced in the README, asks how much of this binding machinery modern GPU hardware still requires. Recent hardware supports 64-bit GPU virtual addresses and application-managed descriptor heaps, which means resources can be addressed directly without the binding layer.

NoGraphicsAPI implements the alternative design as a C++20 library with backends for Metal 4 (macOS, iOS, iPadOS) and Vulkan 1.4 (Windows, Linux). The README states: "The goal is to make GPU programming feel more like working with ordinary memory and data structures: GPU pointers for data, heap indices for textures, and one GPU pointer to the arguments of each draw or dispatch."

Both backends use the same C++ API and the same Slang shader sources. CMake selects the backend based on the target platform.

The Core Model: Memory, Pointers, and Descriptor Heaps

NoGraphicsAPI introduces six changes from the conventional rendering model, all documented in the README.

First, allocation without buffer objects. The library provides GPU heaps that the application partitions with an allocator. Mapped heaps give both CPU and GPU addresses. Vertex data, constants, and arbitrary structures are allocations in these heaps, not named buffer objects with separate binding points.

Second, typed GPU pointers. Shaders follow 64-bit pointers stored in shared C++/Slang structures. Arrays, pointer arithmetic, and nested structures work without buffer descriptors. A vertex shader fetches its own vertices by following a pointer; there is no vertex layout declaration.

Third, bindless textures. The application owns descriptor heaps and assigns indices. Materials carry those indices as data. Changing materials does not require constructing or rebinding descriptor sets.

Fourth, root arguments instead of binding tables. Each draw or dispatch receives a single GPU pointer to a structure containing all its inputs. The CPU and shader share the structure declaration, so there is no separate descriptor-set layout or pipeline layout to maintain.

Fifth, less pipeline-state coupling. Resource binding and vertex layouts are absent from pipeline creation. Viewport, scissor, and depth/stencil state can be set independently.

Sixth, barriers without resource lists. Synchronization describes which work produces and consumes data, not a list of per-resource transitions. The application does not track image layout transitions.

Root Arguments: A Concrete Draw Call Example

The README demonstrates the root arguments model with a minimal rendering example. First, declare the argument structure once in a shared C++/Slang header:

struct RootArguments
{
    Vertex* vertices;
    Material* material;
    float4x4 transform;
    uint32 texture_index;
};

Then, on the CPU, allocate a root from application-owned mapped storage and fill it:

const gpu::GpuCpuRange<RootArguments> root = frame_data.allocate<RootArguments>();
*root.cpu = {
    .vertices = vertex_memory.gpu,
    .material = material_memory.gpu,
    .transform = transform,
    .texture_index = texture_index,
};
gpu::draw(commands, root.gpu, vertex_count);

In the shader, the same structure is accessed by following the pointer:

GPU_ROOT(RootArguments, root);
Vertex vertex = root.vertices[vertex_id];
Material material = *root.material;
Texture2D<float4> texture = gpu_texture<Texture2D<float4>>(root.texture_index);

The structure definition is shared: any change to `RootArguments` is automatically visible to both the C++ allocation code and the Slang shader. There is no separate binding layout to update when the structure changes.

Hardware Requirements: Metal 4 and Vulkan Extension Surface

Metal 4 support requires macOS, iOS, or iPadOS 26 or newer with Apple GPU family 7 or newer. The README lists M1 and newer Macs, iPhone 12 and newer (A14 and newer), iPad Pro from 2021, iPad Air from 2020, iPad mini from 2021, and iPad from 2022. Intel Macs, Simulator, tvOS, and visionOS are explicitly not supported.

Direct task and mesh draws work throughout the Metal 4 baseline. Indirect mesh draws require A17 Pro or M3 or newer hardware.

The Vulkan backend requires more than just Vulkan 1.4. Four extensions are mandatory: `VK_EXT_descriptor_heap` for application-owned descriptor heaps, `VK_KHR_device_address_commands` for commands that operate on GPU addresses, `VK_EXT_mesh_shader` for task and mesh shaders, and `VK_KHR_shader_untyped_pointers` for descriptor-heap shader support. A fifth, `VK_KHR_unified_image_layouts`, is optional but makes the common image layout efficient.

The Vulkan utility math library requires AVX2 and FMA, limiting it to x86-64. The README includes a driver compatibility table checked on 5 September 2026; missing required extensions are the primary reason for unsupported GPUs.

Slang Shaders and the Shared Type System

NoGraphicsAPI uses the Slang shading language for GPU code rather than GLSL or HLSL directly. Slang compiles to SPIR-V for Vulkan and to Metal Shading Language for Metal. The README's stated advantage is that shader types defined in Slang can be shared with C++ host code, so the `RootArguments` structure above compiles on both the CPU (as C++) and the GPU (as Slang).

The library includes a `NoGraphicsAPIUtility` component that provides shared shader types, math libraries, allocators, upload queues, and deferred deletion. These utilities are optional: the core API does not depend on them, and applications can replace any utility component.

The `docs/slang.md` file in the repository contains the complete shader guide with additional examples. The `docs/no-graphics-api-comparison.md` documents the remaining differences between this design and conventional binding table approaches.

NoGraphicsAPI vs Conventional Vulkan Binding Tables

Standard Vulkan uses descriptor sets to bind resources to shader stages. Before drawing, you create a descriptor set layout that declares each binding point (buffer, texture, sampler), allocate a descriptor set, write resource handles into it, and bind it to the command buffer before each draw. Vertex input state declares the format and stride of each vertex attribute.

NoGraphicsAPI removes both of these constructs. There are no descriptor sets, no descriptor set layouts, no vertex input declarations, and no pipeline layout objects. Resources are referenced by GPU address (for buffers) or by descriptor heap index (for textures and samplers).

The trade-off is hardware scope. Standard Vulkan works on any Vulkan-capable GPU from roughly the past decade. NoGraphicsAPI requires `VK_EXT_descriptor_heap`, which is a very recent extension. The README compatibility table documents which GPUs and drivers pass the extension check as of its collection date.

The approach is not unique: the PlayStation 5's GNM API uses a similar pointer-based model, and DirectX 12 with work graphs moves in a related direction. NoGraphicsAPI makes this model available on the hardware that supports it through an open-source C++ library.

Repository Layout and Maintenance

The repository is organized into `include/` (the public API headers), `src/` (implementation), `utility/` (the optional NoGraphicsAPIUtility library), `examples/` (triangle, cube, and deferred renderer examples), `tests/`, and `docs/` (metal-support.md, vulkan-support.md, slang.md, and the comparison document).

Build uses CMake with presets defined in `CMakePresets.json`. The `.clang-format` file indicates the project enforces code style through clang-format. The `THIRD_PARTY_NOTICES.md` documents the external libraries bundled with the project.

The project is licensed under the MIT licence. The last push to the repository was on 2026-09-23. There are no published GitHub releases. The repository includes an `AGENTS.md` file providing instructions for automated coding agents, indicating the project is actively developed with AI assistance.

Editorial conclusion

NoGraphicsAPI is a useful starting point for graphics engineers who want to explore the bindless GPU programming model described in Sebastian Aaltonen's blog post, without implementing the infrastructure from scratch. It is not a production-ready renderer or a cross-platform graphics layer: it requires very recent hardware (Metal 4 or Vulkan 1.4 with specific extensions) and has no published releases. Before evaluating it for production use, check the Vulkan driver compatibility table in `docs/vulkan-support.md` against your target hardware, and verify that `VK_EXT_descriptor_heap` is supported: as of the driver checks documented in the repository on 5 September 2026, this extension is the main reason for unsupported GPUs.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. sebbbi/NoGraphicsAPI on GitHub