游戏巨头用DX12，为何有人偏爱Vulkan？

当许多3A大作在Windows上飞驰于DX12的高速公路时，Vulkan像一本“全球通行证”，让同一份渲染代码驶向Windows、Linux、Android、Steam Deck，甚至可借助兼容层登陆更多设备。选择它的人，往往不是逆潮流而行，而是更清楚自己想要的“掌控感、跨平台、与长期可持续”。巨头钟情DX12，有深厚的产业逻辑。Windows与Xbox是它们的主战场，DX12的工具链极其成熟：PIX与Visual Studio带来强力调试与分析，驱动优化长期深耕，团队与中间件生态围绕DX长期打磨。商业制作管线追求稳定、可预期的交付与大规模协作，DX12在Windows阵营几乎是事实标准，少了跨平台的摩擦成本，多了与系统协同的确定性。而偏爱Vulkan的人，看重的是“一个代码库覆盖更多平台”的自由。Vulkan是开放标准，原生支持Windows、Linux与Android，Steam Deck更是以Vulkan为核心栈之一。对独立开发者与自研引擎团队来说，这意味着同一套渲染内核可以自然延展到桌面与移动端。更现实的是，Android自7.0起支持Vulkan，今天的移动生态把Vulkan当作高性能图形的主力，CPU占用与能耗相较OpenGL ES显著下降，实测场景里功耗可减少约15%，对续航与稳定帧很有吸引力。技术掌控感也是Vulkan的魅力。它将同步、内存、管线、着色器编译等权力交回开发者手中：SPIR‑V预编译减少驱动不确定性，多线程提交更好压榨CPU并行，显式同步让性能问题定位更可控。配套的验证层把错误“说人话”，配合RenderDoc、Nsight等工具，调试体验扎实可靠。很多人从OpenGL迁移到Vulkan，会直观感受到“没有全局状态”的清爽：用动态渲染替代繁琐的RenderPass/Subpass，配合vk-bootstrap、VMA、volk等轻量库，初始化与资源管理不再是沼泽，代码结构更模块化、更可测试。更重要的是，Vulkan并不只是“能跑起来”，而是“能跑得优雅”。借助描述符索引的“类绑定less”做法，你可以在着色器中按ID取任意纹理；用Buffer Device Address与可编程顶点拉取，将顶点布局从固定管线解耦；把骨骼动画的蒙皮搬到计算着色器，统一静态/动态网格的渲染路径；前向渲染下启用MSAA，配合手写的深度resolve与后处理链路，既清晰又高效。很多开发者的亲历告诉我们：Vulkan并非“只有样板代码”，它也可以是简洁而现代的工程学。生态与未来同样影响选择。Vulkan是跨厂商标准，减少平台绑定风险；驱动层面，开源与社区加速前进，比如Linux阵营整合到更强势的开源Vulkan驱动路线，使开发者收益于更一致的实现与更快的问题响应。对于同时面向PC与移动的团队，这是降低长期维护成本的重要砝码。当然，没有银弹。Vulkan学习门槛高于传统API，显式同步与资源生命周期需要扎实的工程纪律。但今天的Vulkan已比过去“友好”太多：动态渲染、优秀教材与示例工程、实战型工具链，让它从“只有专家能玩转”的印象，转变为“愿意钻研就能驾驭”的现代API。所以，巨头用DX12，是产业规模与平台重心的理性选择；而许多人偏爱Vulkan，则是为了跨平台覆盖、开放标准、长线可维护与更高的技术主权。若你的目标是Windows/Xbox独占、深度依赖微软工具链，DX12依旧无可替代；若你追求多平台发行、移动与掌机适配、或自研引擎与高自由度调优，Vulkan会是更好的舞台。最终，选择图形API，不只是性能指标表上的数字，更是你对“自由与控制”“效率与可达”的权衡。理解底层，让你不再被黑盒牵着走；拥抱开放，让你的作品走得更远。工具只是路，作品才是目的——而你，决定走哪条。

自制游戏引擎，是重复造轮子还是艺术创作？

把第一行图形 API 的初始化代码敲进屏幕时，你可能并不是在“造轮子”，而是在雕刻一件只属于你的工具艺术。引擎不是一堆函数的集合，它能决定你的游戏如何呼吸、如何看、如何听，甚至如何被团队使用与扩展。问题从来不在“要不要重造”，而在“这只轮子会带你去哪里”。亲手写引擎，确实会慢。你要和显式同步较劲，要为图形内存布置做选择，要在调试器里与一帧帧的命令缓冲对话。但回报也清晰可见：零全局状态带来更干净的架构，更强的可预测性；校验层和抓帧工具把“猜错就黑屏”变成“定位到字节”；可编程顶点拉取与设备地址让顶点格式解耦，bindless 纹理把“绑槽位”的时代一笔带过。你不再受限于“引擎觉得合理的样子”，而是让渲染管线长成你要的样子。更重要的是，技术选择会塑造美学。用计算着色做骨骼蒙皮，让静态与蒙皮网格统一走一套材质路径；用一条 draw 调用批量画 UI 和精灵，支撑对话与文字系统的丝滑过场；自制的 sRGB 策略让调色盘与屏幕一致；级联阴影、PBR、MSAA 的取舍，都会变成你的风格标签。连关卡如何被搭建——比如把 Blender 当关卡编辑器、用节点命名驱动 prefab——也会反过来改变团队的创作方式。这不只是工程，是在为创作“定制画笔”。当然，商业引擎的魔法也真实存在。蓝图和可视化工具让四个程序员撑起几十人的内容团队并非神话；庞大的生态、跨平台管线、成熟的资产与插件，能让“想法→可玩”缩短到天级别。但越强大的黑箱越需要规训：文档与版本的错位、Nanite/Lumen 等特性的参数地雷、TAA/TAAU 错用带来的“油腻模糊感”，都在提醒你——性能与画质不是默认的赠品，而是策略与调优的产物。所以答案不在理念对错，而在你的约束与野心。若你要尽快发布、玩法主导、团队以内容为先——选现成引擎，借力生态，是明智的工程。若你想掌控平台细节、验证新型渲染技术、构建独特制作流或纯粹想成为更好的图形程序员——写一个“为某类游戏量身定制”的小引擎，就是正确的创作。别追求通用，先做一关能打通的小游戏，再把可复用部分抽成引擎，这会让你避开“自行车棚效应”。也别真的从零。把轮毂借来：用内存分配器管理显存；用加载器减掉初始化样板；用 ECS、物理库、UI 调试、剖析器接好地基；着色器离线编译减少运行时报错。把胎面自己雕：动态渲染、push constant + bindless、显式 barrier 的同步模型、按帧上传的 NBuffer、计算蒙皮与批渲染。这不是重复发明，而是“在成熟零件上造出你的路感”。别忽视新变量——AI 正在改变资产与代码的生产关系。集成式 AIGC 工作流能把“想法→原型”压缩到小时级；3D 生成模型让小团队的内容密度跃升；云端智能体与无服架构在运行期放大你的迭代与规模。自己做引擎，你可以把这些工作流深度焊进管线；用商业引擎，你也能以插件与工具链实现同样的飞轮。关键仍然是目标与边界。自制游戏引擎，既可能是重复造轮子，也可能是艺术创作——差别在于你是否在解决真实问题，是否在表达独特的技术审美，是否让团队与玩家因此受益。技术是为了抵达体验，轮子是为了抵达远方。愿你做出的选择，既让作品跑得稳，也让它跑得“像你”。当你下一次犹豫，不妨问一句：这个轮子，能不能带我去别人到不了的地方？如果答案是“能”，那就开工吧。

Vulkan加持，手机能变身PC游戏机吗？

把手机插上显示器、连接手柄，点开一款“3A”大作，画面里有实时反射与柔和阴影——这不是科幻，而是Vulkan时代的现实雏形。Vulkan像一条通往跨设备“同一套渲染逻辑”的高速公路：同一份着色器，同一种显式同步，同一个低开销的指令流，在桌面与移动之间流畅切换。问题来了：有了Vulkan，手机真的能变身PC游戏机吗？先看Vulkan带来的根本改变。它抛弃传统API的隐式全局状态，采用SPIR-V预编译与显式同步，显著降低CPU管理开销，特别适合多核与多线程。实测对比显示，在相同画质下，Vulkan的CPU占用常低于10%，能耗比OpenGL ES下降约15%。这意味着同样的功耗预算里，你能把更多时间留给像素与光线，而不是驱动调用与状态切换。再看硬件的跨越。新一代移动SoC已把“主机级”特性塞进口袋：独立的光线追踪单元、增大的共享缓存、动态缓存策略与更高带宽。实际表现并非口号——某旗舰平台在1440p离屏Vulkan基准下达到154fps，综合图形分数较前代提升约33%；在光追压力场景中得分甚至翻倍。落到游戏，《王者荣耀》极致画质稳定120帧且功耗约2.8W；像《崩坏：星穹铁道》这类重负载场景，972p渲染也能维持接近60帧，曲线平稳。这些数字说明：移动端的“持续性能”已经跨过休闲娱乐门槛，开始触碰“主机观感”的底线。内容与兼容性决定“能不能玩”。Vulkan的跨平台特性，已让引擎侧的多平台构建更直接；Unity与虚幻在移动端的原生支持不断完善，大量新作能以移动为一级目标交付。而对既有PC库，Vulkan生态中出现了把Direct3D翻译为Vulkan的方案，部分经典大作已在高端安卓设备上跑通，这展现了可行性。但必须坦白：反作弊、中间件、驱动差异会带来不可忽视的“长尾”问题，稳定性与合规性往往比纯性能更难攻克。要“无改即跑所有PC游戏”，还远。体验是一条木桶，最短的那块板常见于散热、操控与显示。手机的瞬时性能很强，但持续高负载会遇到热限制，主动散热背夹与桌面模式能显著拉高长时间帧率。操控上，手柄与键鼠映射已成熟，外接显示器可上到4K，但开发者需准备高分辨率资源与不同宽高比的UI适配，否则“像素泥”会毁掉第一观感。电源与网络也很关键：外接供电与有线网络能让稳定性跃迁。开发侧的“正确姿势”，直接决定你能把多少PC感觉带上手机。以Vulkan 1.1作最低基线，用Vulkan Profiles验证特性齐备；显式同步处理好GPU-GPU与GPU-CPU依赖；正确处理屏幕预旋与多方向；用厂商性能工具和验证层定位瓶颈；在材质与后处理上提供可伸缩的“档位”。这些工程细节，比炫技更能把“体验黑洞”填平。那么结论是什么？在Vulkan加持下，手机能在两条路径上“像PC”：一是原生移动游戏的画质与物理复杂度快速逼近主机，1080p/120fps、入门级光追已可量产化，外接大屏与手柄后，观感上已很接近“客厅主机”。二是经良好移植或专门优化的PC作品，能在高端设备上以中高画质稳定运行，满足“随身玩大作”的愿望。而“彻底替代PC、无改直跑全库”的愿景，短期仍受限于热设计、内存带宽、驱动生态与合规体系。更现实的答案是：Vulkan让手机成为“随身的次世代游戏终端”，与PC形成互补——移动端负责随时随地与长续航，PC负责极致分辨率、MOD生态与全尺寸体验；云游戏再把空隙补齐。也许更重要的不是“谁替代谁”，而是开放标准如何把创作成本和技术门槛一起往下拉。当渲染的语言在更多设备上统一，玩家的自由就会被悄悄放大。等到某天，你在地铁里继续昨晚客厅里那一关时，Vulkan已经给出了它最动人的答案：真正好的技术，不是把舞台换个地方，而是让舞台无处不在。

给你三个月，你会选择造引擎还是做游戏？

想象把一年切成四块，只拿走一块——三个月。你要用它打造一台发动机，还是先开到终点线？这不是二选一的哲学题，而是目标、平台、经验与风险的博弈：你想要“可玩可上架”的作品，还是要“可复用可扩展”的底层能力和履历？如果你的目标是发布、验证玩法、获取玩家反馈，我会毫不犹豫地说：做游戏。三个月是做出一个扎实的纵向切片的黄金窗口：一个核心循环、一段流程、一整套美术风格和声音体验，外加能跑全局的存档、UI 与设定。选择成熟引擎（Unity、Unreal、Godot），你把时间花在内容、手感、关卡与打磨上，而不是内存屏障和同步栅栏。更现实的是，2025 年的发行场景早已多元：Steam 的独立体验、小程序平台的轻量化上架、甚至弹幕互动玩法，这些都更需要稳定帧率、快速迭代与粗中有细的优化，而不是“从零造轮子”。三个月做成一个可试玩的 Demo，比任何“正在开发中的引擎”更能转化愿望单与机会。可如果你的目标是系统性掌握现代图形栈，三个月“造引擎”也并非痴人说梦，但要精准降维与果断取舍。把它当作“一个能跑两段小演示的定制渲染器”，而不是通用引擎。选定桌面（Windows/Linux）、使用 Vulkan，享受更好的验证层、可控的同步与稳定的跨 GPU 体验。用动态渲染简化 RenderPass，用一个“全局绑定组”实现近似 bindless 的纹理/采样器索引，用 push constants + Buffer Device Address 做可编程顶点拉取，先做前向渲染配合 MSAA，随后再加基于深度的后处理。把皮肤动画丢给一个计算着色器输出变形后的顶点缓冲，让静态/蒙皮走同一条管线。调试上全程依赖 RenderDoc，性能用 Tracy，内存用 VMA，初始化交给轻量的引导库。关卡制作直接使用 Blender 导出 glTF，省去自研编辑器的噩梦；2D/对话/调试 UI 统一走“单次绘制、实例化精灵批渲染”，做到 1 万张以内的轻松吞吐。同步一开始用“肥栅栏”在 Pass 间切割，等有瓶颈再上更细粒度或引入渲染图。这样收敛的目标，三个月足以站稳。到底怎么选，取决于你是谁、要到哪儿去： - 想尽快上线、验证变现或比赛冲刺？做游戏。哪怕你热爱底层，也先用现成引擎把玩法打通，再把“可重用”的子系统沉淀为你的技术资产。 - 想转型图形/引擎岗，或要为后续数个项目打造同一套桌面渲染骨架？造引擎，但务必“以小见大”：前向管线、一种阴影、一个后期、一个 UI、两种材质，能跑两个演示即可。把抽象留到第 2 个项目发生真实需求时再做。给你一份三个月的节奏感：做游戏时，以“玩法—视觉—内容—优化”的顺序推进，第一月做核心循环与一关纵切，第二月把美术、音频和 UI 带到可展示水位，第三月做性能与打磨，准备发布物料与用户测试。做引擎时，以“能看见—能动起来—能量产”的顺序推进：第 1 月出窗口、模型、光照与调试；第 2 月上阴影、后期与批渲染 UI；第 3 月打通 glTF 关卡、基础物理与两段 demo。任何超出你场景需要的“完美主义”，都先写到 TODO 里，让性能分析工具而不是直觉来决定优先级。还有一个常被忽略的维度是平台。目标 Windows/Xbox 且强依赖本地工具链，DirectX 生态更顺；要跨平台到 Linux/Android/Steam Deck，Vulkan 更稳；打算入局小程序或弹幕互动，三个月的“引擎梦”性价比极低，内容与体验才是王道。你也可以折中：先做一个小型游戏，把真正可复用的渲染、资源、UI、关卡加载“反向提纯”为引擎模块，这正是很多成熟团队的演进路径。归根到底，三个月是把“可能性”变成“确定性”的时间。选择做游戏，你把确定性交到玩家手里；选择造引擎，你把确定性刻在工具与知识里。无论怎么选，都别把精力消耗在与目标无关的完美上。愿你在有限的刻度里，跑出属于自己的速度：要么照亮一个好玩的世界，要么点亮一盏能照亮许多世界的灯。

苦学三个月自制引擎，究竟图的是什么？

把一块原本像“黑盒”的显卡，拆开到每一条指令、每一次屏障、每一次采样都在你掌控之中——这就是自制引擎三个月的真正收获。它像是从开车转为造车：辛苦，但你从此不再害怕拐弯、爆胎和未知的路况，因为你知道每颗螺丝为什么在那儿。图的首先是“掌控”。OpenGL 的全局状态像一团会变形的史莱姆，Vulkan 则把一切摊在台面：显存分配、管线布局、同步、着色器中每个字节的走向。你得到更低的 CPU 开销、更可预测的多线程性能、跨平台一致性，以及把错误扼杀在编译期和验证层的安全网。RenderDoc 单步调试着色器、VMA 管理显存、vk-bootstrap 砍掉初始化样板，这些不是炫技，是把未知变成可解释性的硬通货。图的是“工程化的跃迁”。做一个会跑的游戏，不靠魔法靠流程： – 用动态渲染替代传统渲染通道，帧内灵活编排各步骤。 – 用计算着色器做蒙皮，一次写入、多处复用，静态与骨骼网格统一数据路径。 – 用 bindless 描述符和缓冲区设备地址，把“绑槽位”的时代翻篇，一枚整型 ID 就能在全局采样任意纹理。 – 用可编程顶点拉取，免配置顶点格式，顶点数据像指针一样“直达”。 – 用 N-buffer 或多帧飞行的上传策略，明白什么时候要省显存、什么时候要省心。 – 用 CMake 把 GLSL 预编译成 SPIR-V，并追踪 include 依赖，构建即验证。图的是“从功能到产品的闭环”。三个月并不虚：引擎核心不过万余行，却跑起了两款 Demo。你能数得出来的成果都有硬指标：4096×4096 的级联阴影，PBR 光照，手写的深度 resolve，MSAA 一键见效；一条管线绘制上万张精灵图只需几百微秒；UI 用原点、相对尺寸、相对位置自动布局；Blender 当关卡编辑器，glTF 做资产中枢；entt 做 ECS，Jolt 做角色运动，Tracy 做火焰图，ImGui 做工具面板且正确处理 sRGB。不是虚浮的“能跑”，而是“可维护、可扩展、可查错”的能跑。图的是“技术判断力”。什么时候不写通用引擎，先做一个小 3D 游戏再抽象；什么时候克制重构，给代码留 TODO 但保持前进；什么时候用胖障碍做同步，等瓶颈出现再细化到资源级；什么时候选 Vulkan 而不是 WebGPU、DX12——你会真正用需求去反推架构，而不是为了“完整”而“完整”。这份判断力，在下一个项目里依然值钱。图的是“职业续航”。现代图形开发的核心能力，正是这些你亲手踩过的点：资源生命周期、同步哲学、渲染管线编排、调试与验证、数据导入导出、GPU/CPU 协同。你不仅能把 Bug 定位在“哪层抽象”，还能把渲染顺序、缓存命中、绑定成本这些“看不见的消耗”讲明白。更实际点说，这份底层功底给了你换引擎、换平台、换着色语言的自由度与可信度。也要承认，图的不是“超过 Unreal/Godot”。若你的目标是最短时间上线，现成引擎无可替代。自制引擎的价值，在于可解释、可控、可定制，更在于你真正理解“为何有效”。当你能把“一个像素为什么这样亮”从经验变成定理，工具就不再是束缚，而是载具。更深一层，图的是一种创造的主权。你从“调用库的人”变成“定义边界的人”，从“修 Bug”变成“设计因果”。当你第一次在帧之间插入一条正确的屏障，看到画面从闪烁变为稳定，那一刻你会明白：我们学习复杂系统，不是为了崇拜复杂，而是为了把复杂驯化为秩序。三个月是一段旅程的起点，它让你有资格在接下来的岁月里，把性能、画质、可维护性，真正捏在自己手里。

新知 - 大圆镜｜三个月，一人，攻克图形编程“珠峰”：一个自学者的Vulkan引擎征途

大圆镜

内容由AI生成，思考得你完成

App Store 下载 Android 下载

在游戏开发的众神殿中，Vulkan API如同一座令人生畏的巨像。人们常说，驾驭它如同“亲手编写显卡驱动”，是只有拥有数十年经验的AAA级工作室才能触及的圣杯。然而，一位名叫Elias Daler的自学程序员，用短短三个月的实践，打破了这一迷思。他不仅从零开始学会了Vulkan，还构建了一个功能完备的游戏引擎，并附带两个游戏演示。这个故事，不仅是一次技术壮举，更是对现代图形编程学习路径的一次深刻揭示。

一位独行侠的“登顶”之路

Elias Daler并非图形学界的科班精英，他自称是“图形编程领域的自学者”。凭借着之前积累的OpenGL经验，他一头扎进了Vulkan的深海。三个月后，一个名为“EDBR”（Elias Daler's Bikeshed Engine）的项目在GitHub上诞生。这个包含约1.9万行代码的引擎，驱动着一个3D猫咪游戏和一个2D平台跳跃游戏，实现了包括glTF模型加载、计算着色器驱动的骨骼动画、级联阴影贴图（CSM）和基础PBR渲染在内的完整图形流程。

这个成就之所以引人注目，不仅在于时间的短暂，更在于其过程的透明与务实。Daler的经历如同一张详细的地图，为后来者标示出了通往Vulkan世界的捷径与陷阱。

从“自动挡”到“手动挡”：为何Vulkan如此艰难？

要理解Daler的挑战，必须先明白Vulkan与它的前辈OpenGL有何不同。如果说OpenGL像一辆自动挡汽车，为开发者封装了大量细节，提供了便捷的“状态机”模式，那么Vulkan就是一辆高性能手动挡赛车。它将几乎所有的控制权都交还给了开发者：

显式控制一切：从内存分配、资源同步到渲染状态切换，Vulkan要求开发者明确告知GPU每一步该做什么。这带来了极致的性能潜力，但也意味着海量的“样板代码”和陡峭的学习曲线。
告别全局状态：OpenGL的“绑定”操作和全局状态机是错误的温床。Vulkan则彻底摒弃了这一点，所有操作都通过具体的对象和指令缓冲来完成，代码更清晰，也更利于多线程并行处理。
同步的深渊：在Vulkan中，CPU和GPU的协作不再是自动的。开发者必须手动插入“栅栏”（Fences）和“信号量”（Semaphores）等同步原语，来确保数据在被读取时已经准备就绪。这被公认为是Vulkan最难掌握的部分之一。

正是这种“贴近硬件”（Close-To-Metal）的设计哲学，让Vulkan在提供强大性能的同时，也给初学者设置了极高的门槛。

征服巨像的智慧：取舍与捷径

Daler的成功，并非源于硬啃每一处复杂性，而是充满了工程智慧的取舍。他的经验为我们揭示了一条务实的成长路径：

规避“过度设计”的陷阱：他反复强调要避免“Bike-shedding”（纠结于琐碎细节的过度工程）。他的核心原则是：“除非你现在就需要它，否则不要实现它”。他建议先开发一个简单的游戏，再从中提取引擎，而不是一开始就试图构建一个通用引擎。
拥抱现代Vulkan特性：他大量使用VK_KHR_dynamic_rendering等新扩展，这极大地简化了传统Vulkan中复杂的渲染流程（Render Pass）和帧缓冲区的创建，让代码更直观。
巧用“无绑定”（Bindless）设计：传统图形API中，向着色器传递纹理和数据需要复杂的描述符集（Descriptor Sets）管理。Daler巧妙地利用了“无绑定”技术和“缓冲设备地址”（Buffer Device Address），将所有纹理放入一个巨大的全局数组，在着色器中仅通过一个索引ID就能访问任意纹理。这极大地简化了渲染逻辑，让代码更接近现代CPU编程的直观体验。
站在巨人的肩膀上：他毫不避讳地推荐使用vk-bootstrap、Vulkan Memory Allocator (VMA)等高质量库来处理繁琐的初始化和内存管理工作，让自己能专注于引擎的核心逻辑，而非重复造轮子。

旅程的终点，亦是新的起点

当被问及从转向Vulkan中获得了什么时，Daler的回答极具启发性。除了**更优异的性能、跨平台的稳定体验和强大的调试工具（RenderDoc）**外，他提到了一种更深层次的回报：一种智识上的骄傲和对图形系统更本质的理解。他说：“能够自豪地说‘我有一个用Vulkan编写的自定义引擎，而且它能用’，这本身就让我感到快乐和自豪。”

Elias Daler的故事，是对所有自学者和独立开发者的鼓舞。它证明了，即使是像Vulkan这样看似高不可攀的技术壁垒，也可以通过务实的规划、聪明的取舍和持续的热情去征服。他的开源引擎和详尽的分享，不仅是一个技术成果，更是一份邀请函，邀请更多开发者踏上这条充满挑战与回报的现代图形编程之旅。

一位独行侠的“登顶”之路

从“自动挡”到“手动挡”：为何Vulkan如此艰难？

征服巨像的智慧：取舍与捷径

旅程的终点，亦是新的起点

评论