No Graphics API

Original Article ↗ Hacker News Discussion ↗

Overall reaction and motivation

  • Many commenters praise the post as a clear, deeply informed argument that modern DX12/Vulkan expose far more complexity than current GPUs actually require.
  • The core appeal: drop legacy features, assume a “2020s GPU baseline,” and design something closer to CUDA-style compute plus a few fixed‑function blocks.
  • Several note that most real work already happens in engine‑specific RHIs; a simpler common API would align better with how engines are written in practice.

Hardware baseline, legacy, and mobile

  • There’s tension between targeting recent desktop GPUs (with bindless, buffer pointers, mesh shaders, HW RT) and supporting older or mobile hardware.
  • Some see the proposal as viable only for GPUs from roughly the ray‑tracing era onward; others stress that Vulkan’s “unified desktop/mobile” story already breaks down due to extensions and driver quality.
  • Android’s stagnant GPU drivers are called out as a major blocker, even when vendors technically support advanced Vulkan features.

Comparisons to existing APIs (Vulkan, DX12, SDL3 GPU, WebGPU)

  • The proposed API is viewed as conceptually similar to SDL3 GPU or NVRHI but:
    • Leans heavily on raw GPU addresses and bindless resources instead of buffer/descriptor objects.
    • Exposes modern features (mesh shading, etc.) more directly.
  • SDL3 GPU is described as “lowest common denominator” across DX12/Vulkan/Metal, whereas this design intentionally drops 2010s‑era hardware.
  • WebGPU is criticized for inheriting too much “legacy Vulkan” structure (pipelines, bindings), missing a chance for a leaner launch model.

Benefits and tradeoffs

  • Primary gains are seen as:
    • Far simpler mental model, fewer barriers and resource‑state footguns.
    • Less driver state tracking, smaller driver memory footprint.
    • Reduced PSO/shader permutation explosion and fewer shader‑compile hitches.
  • Some expect per‑draw overhead to drop to nanoseconds and CPU submission costs to approach zero with bindless + indirect.
  • Others argue that “removing cruft” must be justified beyond aesthetics: performance wins may be modest if you already use a modern Vulkan/D3D12 subset.
  • Big tradeoff: deliberate abandonment of older GPUs and some mobile architectures.

Software-style rendering, fixed function, and future directions

  • There’s active interest in moving more of the pipeline into “software on GPU” (compute‑driven rasterizers, meshlets, raytracers) similar to how CUDA/AI frameworks work.
  • Counterpoint: throwing away fixed‑function blocks (rasterization, RT cores, TMUs) would be a massive performance regression; the goal is to better integrate them, not bypass them entirely.
  • Some speculate longer‑term about AI‑assisted or “hallucinated” rendering, but others note current inference budgets (a few ms per frame) make that mostly aspirational.

Complexity, documentation, and accessibility

  • Several note the irony that arguing for simplicity required a huge, dense article, and criticize aspects of its presentation and self‑promotion.
  • Others highlight how bad documentation and lack of shader language ecosystems make modern GPU programming inaccessible; they see a simpler, more uniform API as one necessary step but not sufficient on its own.