I learned Vulkan and wrote a small game engine with it

Original Article ↗ Hacker News Discussion ↗

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.