编程与软件工程edw.is编辑精选
我学会了 Vulkan，并用它写了一个小游戏引擎
I learned Vulkan and wrote a small game engine with it
2024 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者记录了自己学习 Vulkan 并用它写一个小型游戏引擎的经历，分享了从零搭建渲染管线时的取舍与经验。文中强调按需实现、避免过度设计，也引发了对 Vulkan 与 OpenGL 适用场景的讨论。
为什么经久不衰：它既是一份少见的 Vulkan 实战学习记录，又提供了“需要什么才做什么”的工程建议，今天读来仍对图形编程入门和引擎开发有参考价值。
HN 评论精选
做引擎或项目时应坚持最小实现，避免过度设计和盲目追新。
这篇文章里有很多好建议。让我印象最深的一条是：除非你现在就需要某个功能，否则不要实现它。这是我经常和经验较少的程序员较劲的地方——他们常痴迷于“最佳实践”和流行新工具，却很难从要解决的问题出发，专注于解决问题所需的最小方案。
spicyusername查看英文原文
Lots of good advice in this article. One that stuck out to me: Don’t implement something unless you need it right now This is a constant battle I fight with more junior programmers, who maybe have a few years of experience, but who are still getting there. They are often obsessed with "best-practices" and whatever fancy new tool is trending, but they have trouble starting with the problem they need to solve and focusing on the minimum needed to just solve that problem.
Vulkan 适合追求高级渲染的场景，多数独立游戏未必需要它。
我认为 Vulkan 很棒，但它的主要目的是充分利用高级 GPU 特性；如果你不追求高级渲染技术，一般还是推荐 OpenGL。现在有很多 2D、低多边形或 PS1 风格游戏，它们并不需要 Vulkan。Vulkan 也反映了 AAA 行业对渲染质量和外观的偏重，但游戏开发者更该关注玩法和功能，而不是渲染质量。
jokoon查看英文原文
I think vulkan is great, but its only purpose is to take full advantage of advanced GPU features. It also leads to better performance when using advanced GPU features compared to OpenGL. Generally, I feel OpenGL is the recommended route if you don't really aim for advanced rendering techniques. There are plenty 2D /lowpoly/ps1-graphics games right now, and those don't need to use vulkan. Vulkan is an example of how the AAA gaming industry is skewed towards rendering quality and appearance. AAA game studios justify their budget with those very advanced engines and content, but there is a growing market of 2D/low poly game, because players are tired and realized they want gameplay, not graphics. Also if you are a game developer, you don't want to focus on rendering quality, you want to focus on gameplay and features.
层层抽象会带来兼容性和同步难题，反衬出直接、极简使用 Vulkan 的价值。
这种极简做法非常有效。我走了相反路线，吃了不少苦头：我用 Rust 写一个元宇宙客户端，底层是 Vulkan，但上面叠了 WGPU 和 Rend3。这些层带来了问题——WGPU 要支持浏览器、Vulkan、Metal、DX11/12、Android 和 OpenGL，所以需要大团队维护，改动困难；它的 API 仍很像 Vulkan，你还是要自己做 GPU 内存分配和同步。WGPU 还有最低公分母问题，比如不支持像 Vulkan 那样多线程更新 GPU 内存，锁冲突会拖累性能。Rend3 本应是一层适度的胶水代码来处理同步和分配，但这些事很难通用，尤其是同步。
Animats查看英文原文
This minimalism is very effective. I took the opposite approach, and it has cause great pain. I've been writing a metaverse client in Rust. Right now, it's running on another screen, showing an avatar riding a tram through a large steampunk city. I let that run for 12 hours before shipping a new pre-release. This uses Vulkan, but it has WGPU and Rend3 on top. Rend3 offers a very clean API - you create meshes, 2d textures, etc., and "objects", which reference the meshes and textures. Creating an object puts it on screen. Rust reference counting interlocks everything. It's very straightforward to use. All those layers create problems. WGPU tries to support web browsers, Vulkan, Metal, DX11 (recently dropped), DX12, Android, and OpenGL. So it needs a big dev team and changes are hard. WGPU's own API is mostly like Vulkan - you still have to do your own GPU memory allocation and synchronization. WGPU has lowest-common-denominator problems. Some of those platforms can't support some functions. WGPU doesn't support multiple threads updating GPU memory without interference, which Vulkan supports. That's how you get content into the GPU without killing the frame rate. Big-world games and clients need that. Also, having to deal with platforms with different concurrency restrictions results in lock conflicts that can kill performance. Rend3 is supposed to be a modest level of glue code to handle synchronization and allocation. Those are hard to do in a general way. Especially synchronization. Rend3 also does frustum culling (which is a big performance win; you're not rendering what's behind you) and tried to do occlusion culling (which was a performance lose because the compute to do that slowed things down). It also does translucency, which means a depth sort. (Translucent objects are a huge pain. I really need them; I work on worlds with lots of windows, which you can see out of and see in.) The Rust 3D stack people are annoyed with me because I've been pounding on them to fix their stack for three years now. That's all volunteer. Vulkan has money behind it and enough users to keep it maintained. Rend3 was recently abandoned by its creator, so now I have to go inside that and fix it. Few people do anything elaborate on WGPU - mostly it's 2D games you could have done in Flash, or simple static 3D scenes. Commercial projects continue to use Unity or UE5. If I went directly to Vulkan, I'd still have to write synchronization, allocation, frustrum culling, and translucency. So that's a big switch. Incidentally, Vulkano, the wrapper over Vulkan and Metal, has lowest-common-denominator problems too. It doesn't allow concurrent updating of assets in the GPU. Both Vulkan and Metal support that. But, of course, Apple does it differently.
Vulkan 学习曲线过陡，对入门者不如 OpenGL 友好。
一年多前我试着学 Vulkan，现在再也不想碰它了。让我很不满的是，我们正在弃用 OpenGL，换成一个连做简单事情都难到离谱的 API——比如渲染一个旋转立方体就要几百行代码。OpenGL 从来不算“简单”，但普通人至少能在较短时间内学会基础；你可以去书店买本图形编程入门书，一两个下午就能渲染出点东西。Vulkan 在某些方面确实更好，但指望别人快速学会它并不现实。这就像新芯片出来后不让你写 C/C++，只让你写汇编，还说这样更可控更快——那会被大家正确地称为荒谬。
tombert查看英文原文
I tried learning Vulkan a little more than a year ago and I have no desire to ever touch it again. It really bothers me that we're deprecating OpenGL and replacing it with something that's ridiculously hard to do anything simple (e.g. doing a spinning cube takes several hundred lines of code). OpenGL was never "easy" but it was at least something a regular person could learn the basics of in a fairly short amount of time. You could go to any big book store, buy some intro to graphics programming book, and get some basic stuff rendering in an afternoon or two. I'm sure Vulkan is better in some regards but is simply not feasible to expect someone to learn it quickly. Like, imagine the newest Intel/ARM/AMD chips came along and instead of being able to write C or C++, you're being told "We are dropping support for higher level languages so you can only write assembly on this now and it'll be faster because you have more control!" It would be correctly labeled as ridiculous.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选