I learned Vulkan and wrote a small game engine with it

Original Article ↗ Hacker News Discussion ↗

An engineer shares their experience learning the low-level Vulkan graphics API and building a small game engine, prompting broader reflection on when Vulkan’s control and performance are worth its heavy complexity compared to OpenGL, WebGPU, or existing engines. Commenters highlight Vulkan’s improved debugging, explicit control, and access to modern GPU features, but note that its steep learning curve, boilerplate, and need for careful synchronization make it better suited to engines and serious projects than to quick game prototyping. The thread also surfaces general engineering lessons—like avoiding premature abstraction, balancing “do the simplest thing” against long-term maintainability, and choosing tools based on goals such as cross‑platform support, graphics fidelity, and development velocity.

Learning Vulkan & Reaction to the Post

  • Many readers appreciate the write-up as a practical, motivating account of learning Vulkan and building an engine.
  • Several with OpenGL background say they previously “bounced off” Vulkan due to boilerplate and complexity but feel encouraged to try again.
  • Others state bluntly they have no interest in writing thousands of lines just to see a triangle and will stick with simpler APIs or full engines.

Vulkan’s Complexity vs Other APIs

  • Repeated theme: Vulkan has heavy upfront cost (hundreds–1,000+ LOC for “Hello Triangle”), especially around initialization, swapchains, pipelines, descriptors, and synchronization.
  • Advocates argue modern Vulkan (1.2/1.3, dynamic rendering, descriptor indexing, sync v2) is significantly more ergonomic than 1.0, especially with helper libraries.
  • Critics argue Vulkan is overkill for most projects and that killing OpenGL without a higher-level “OpenGL Next” was a mistake; Vulkan feels like exposing assembly instead of C.
  • Comparisons:
    • OpenGL: simpler, good for 2D/low‑poly/“good enough” graphics; but deprecated on some platforms, driver behavior inconsistent, no validation layers.
    • WebGPU/wgpu: seen as a middle ground—modern, less verbose, portable (native + browser), but missing advanced features (mesh shaders, ray tracing, robust multi‑queue, bindless) and has limited tutorials and incomplete browser support.
    • Direct3D 11: cited as easy and powerful, but tied to Microsoft platforms.
    • Direct3D 12: similar issues as Vulkan; easy to get worse performance if you don’t know what you’re doing.

Performance, Drivers, and When Vulkan Matters

  • Vulkan can outperform OpenGL only if the user recreates, correctly, the large amount of driver-side work OpenGL does (pipelines, batching, sync, threading).
  • Some claim even getting to “OpenGL‑equivalent” performance is nontrivial; others highlight benefits like validation layers, explicit multi‑queue transfers, mesh shaders, ray tracing, and better multi-threading.
  • Mobile Vulkan drivers are widely described as poor; desktop Vulkan 1.3 support is said to be good on reasonably recent hardware with updated drivers.
  • Several point out translation layers:
    • ANGLE (GL ES → Vulkan/Metal/D3D) and Zink (GL → Vulkan) as ways to keep using OpenGL on top of Vulkan.
    • These are seen as de‑facto higher‑level APIs in the future.

Ecosystem, Abstractions, and Learning Resources

  • Common helper layers: VMA (memory), vk-bootstrap, volk, plus full abstractions like bgfx, sokol, The Forge, wgpu, Rend3.
  • Some lament that almost all tutorials use these libraries, making it hard to see “raw” Vulkan memory management.
  • Recommended learning resources mentioned include vkguide.dev, the official Vulkan Guide, existing engines (e.g., vkQuake), books/talks on memory allocation patterns, and various YouTube channels.

Engineering Philosophy & Meta Discussion

  • Strong side thread on YAGNI/KISS vs over‑engineering:
    • For solo/experimental engines, “build only what you need now” and accept rewrites.
    • For large organizations, investing in solid architecture, clear interfaces, and refactorability is seen as crucial.
  • Some worry Vulkan’s difficulty raises the barrier to in‑house engines and pushes more developers toward big proprietary engines.
  • Smaller tangents cover minimalist web design for the article, whether LLMs can write such experience-rich posts, and experiments with GPU‑driven engines and shader‑centric designs.