No Graphics API
Modern GPUs are capable of far more flexible, pointer-based access patterns than traditional graphics APIs like DirectX 12 and Vulkan expose, leading some developers to argue for a radically simplified, CUDA-like interface for rendering. Commenters weigh the benefits of such a “no graphics API” model—less legacy cruft, higher developer productivity, fewer shader compilation hitches, and lower driver overhead—against its costs, chiefly dropping support for older or mobile hardware and diverging from today’s cross-platform standards. The exchange highlights a broader tension between low-level, hardware-centric APIs that demand complex resource management and a desire to move back up the abstraction ladder while still exploiting modern GPU features such as bindless resources, mesh shaders, and hardware ray tracing.
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.