SDL3 new GPU API merged

Original Article ↗ Hacker News Discussion ↗

Purpose and Scope of the New SDL3 GPU API

  • Provides a cross‑platform GPU abstraction for modern 3D/2D rendering and compute.
  • Aims to let developers write graphics code and shaders once and run across desktops, mobile, and consoles.
  • Meant as a modern replacement/extension for SDL’s old 2D renderer, which was designed for “sprite blitting” era hardware and too limited for modern batching, GUIs, and shaders.

Relationship to Other Graphics APIs/Libraries

  • Positioned between low‑level APIs (Vulkan, D3D11/12, Metal) and engines (Unity, Unreal, Godot).
  • Compared to bgfx/sokol: SDL_gpu is pure C, very portable, lower‑level (explicit command buffers, explicit transfers) and aims to expose asynchronous GPU work clearly.
  • Compared to WebGPU/wgpu: WebGPU is spec‑driven, rigid, web‑safety‑focused, and took years (with WGSL design and committee politics). SDL_gpu is pragmatically “wrap native APIs,” with fewer constraints and faster iteration.

Design and Feature Choices

  • Supports multiple backends (D3D11/12, Metal, Vulkan; consoles under NDA). Backend selection can be automatic or forced via hints / device creation.
  • Focuses on features widely available across platforms; advanced features like bindless, ray tracing, mesh shaders, work graphs likely deferred.
  • Exposes command buffers and explicit CPU–GPU transfers, but handles tricky details such as barriers and memory allocation.
  • Uses floats for most coordinates in SDL3, with some legacy integer uses (e.g., viewports).

Shaders and Tooling

  • Core API expects platform‑native shader formats; users bring their own compilation/translation pipeline.
  • There are related projects for a cross‑platform shading language and for converting HLSL/SPIR‑V to backend formats, but these are optional and at varying maturity.
  • A proposed custom shader language draws criticism for unnecessary deviations from C‑like syntax; others welcome such changes.

Integration, Compatibility, and Examples

  • API is part of mainline SDL3 rather than a separate add‑on; some argue this is natural because SDL must provide efficient rendering, others fear “second system effect” and bloat.
  • SDL1→2 incompatibilities are cited as precedent; a compatibility shim exists for SDL1, but piecemeal migration remains hard. SDL3 may repeat some of this pain but is expected to evolve over a long timescale.
  • Example repos exist for SDL_gpu usage; docs and examples are still emerging.

Performance, Use Cases, and Skepticism

  • Some report SDL2’s render API is slow or awkward for non‑integer, physics‑driven 2D, leading them to alternatives; others say recent SDL2 with geometry batching is very fast when used correctly.
  • SDL is widely valued as the minimal cross‑platform layer for windows, input, audio, and now GPU, especially on Linux and embedded systems.
  • Concerns raised about: resource renaming semantics, synchronization model, hint‑overriding of explicit parameters, shader‑format discoverability, and whether the API will stay small while handling real‑world driver quirks.
  • Enthusiasts see it as a high‑quality, pragmatic option that lowers the barrier compared to writing Vulkan/D3D/Metal directly. Skeptics prefer simpler SDL focused only on windowing/input or question whether new complexity is justified.