【文档】如何正确的入门Vulkan？

Vulkan学习曲线非常陡峭？ 为啥？ 要明白最基本的出发点，Vulkan 几乎95%特性是AMD GCN之后的GPU硬件的面向对象封装，Vulkan的所有概念都是直接从硬件抽象出来的，给大家据一些例子，例如

1、Command Queue，分为Graphics, Compute, Transfer, Coder，这些Command Queue通过Event组成有向无环图。这四种类型的Command Queue对应四个不同硬件IP。

2、Command Buffer和Secodary Command Buffer, Indirect Buffer也是对硬件的封装。

3、Bindless Texture也是GCN最重要的概念，就是所有的Buffer(Constant, Vertex, Index)， Texture都是可以通过加载常量描述符的方式，从而获得最大的编程性，其他公司的Descriptor Set都有一个限制，很多公司的Shader可能只能支持128 texture, GCN架构的通用计算能力最强，它没有限制，能够加载2^32-1个Textures!

4、Texture，被分为Linear, Tiled，硬件都是用Tiled方式来提高Cache Hit Rate，最大化利用Cache利用率，每家公司的Tile算法不完全一样。Linear方式用CPU方式的方式比较容易统一。同时Tiled一般都带有无损压缩和有损压缩，因此如果想用image_store, image_atomic只能用Linear Mode。

5、同步时比较难理解的，分为硬件不同IP之间的同步，CPU与GPU数据Copy，还有Pipeline的不同 Stages。本质是什么? 就是硬件执行任何一个功能，可以抽象为 foo(p,a,b); p是前置条件， a是输入数据，b是输出数据；硬件这么多同步要做到 while(p!=true)；同时a没有任何脏数据？怎么才能没有脏数据？需要靠memory access的同步，就是GPU的各种Cache(constant, Instruction, Buffer, Texture, Depth/Stencil/Cache, PageTable, Context Register)。

6、那么多 Shader Stages，同时硬件又有200-300个不同的 Cache，因此Memory Access，通俗地理解为汽车的并行生产线工人必须同步，否则出厂的车灯不工作，左右轮胎不一致，就出错了。

7、Validation就是对生产线做调试验收的。

8、Vulkan 最奇怪的Pipeline就是可以没有Depth/Stencil/Color，然后把Pixel Shader当作 Compute Shader用。

9、另外一个比较难理解的是各种Shader Features，SubGroup，Shuffle等操作，这些都是从GPGPU概念保留过来的。

10、另外一些小众Feature, PUSHConstants16,PUSHConstants8, 都是为了某个特定性能优化问题而加的硬件特性，实际上很难用，低精度问题，一旦出来BUG，调试效率非常低。不建议使用。

11、HDR特性是最近几年，不断增加, 10BITS, 12BITS。

12、简单总结： Vulkan来源于AMD GCN硬件做面向对象抽象的结果，从硬件体系结构，特别是GPU硬件的5大IP( GPU, DMA, GPGPU, Video Codec, Command Queue)，多IP之间同步，以及Grapics Pipeline + Cache ( Constant, Instruciton, Texture/Buffer, Index, Depth/Stencil， Color)同步问题，能够理解这些API的目标，从API到解决实际应用问题。

13、Small Tips:

1）厂家extensions尽量避免使用。

2）mobile GPU尽量不要用Shared Memory , Atomic这些操作，这种性能都是噩梦的；

3) mobile GPU通常不支持64Bits运算；

3）开发初期尽量不要使用16bits/8Bits运算，低精度出错Debug，哭干眼泪都没用。

闫老师说过：你要学习的是图形学，不是一个API，这一点就很重要。Vulkan是很轻薄很底层的API，这就意味着如果你没有完整的着手开发过一套上层的渲染，就根本不知道怎么去封装效率最高，怎么去封装看起来既简洁又优雅，甚至可能就只能画个三角形就不知道怎么做了。所以我的建议是，先使用一个现有的渲染框架实现一套管线。

我本人学习DirectX 12到完成基础组件的封装大概只用了一个月，其中有绝大多数时间其实是在熟悉DX那堆很“Windows”风格的奇葩调用上，而Vulkan就不会有这样的问题，因为在此之前我已经使用Unity那套比较傻瓜式的API开发一套完整的上层管线了，比较清楚在工程中会遇到哪些可能的方向，所以接下来的底层开发就是有bear来，在简洁性和优雅性上也能够做到一个可以接受的程度。

通过对上层的学习，敲定了封装的形态以后，就要考虑自己这套封装怎么做才能够让性能最大化，毕竟是底层开发，如果说优美和简洁的重要性是第一位，那么性能最大化则永远是排在第0位的（既然题干说在工作，那么我就假设是做工程项目了）。C++讲究zero overhead abstraction，而vulkan就非常能够实现这一点，vulkan在设计上几乎没有CPU端的状态记录，因此可以做到完美的多线程渲染模式，但是这就要求我们用最高的性能去自己追踪管线的状态，譬如资源的读写状态，各种Pass，RenderTarget的状态，这些其实就和图形学没什么关系了，就回到数据结构和多线程开发等传统的计算机科学领域了，而恰恰是这个部分可能需要进行反复的推敲

所以一直到现在我都有这样的习惯：接到需求不直接往渲染器里写，而是先在Unity里快速实现验证一下，搞清思路，搞清哪些地方是可以预见的可以针对优化的性能短板，然后再在渲染器中实现完整版，因为我非常明白，API只不过是一个夹在图形开发者和硬件厂商之间的搬砖工，它只需要安静的完成自己搬砖的职责就可以了，其他的无论是管线封装也好，图形实现也罢，大多数也都是和API没什么关系的，纠结于API的学习收益并不会很大。

vk是现存所有图形api中最现代，包袱最轻，概念最清晰，也是细枝末节最多的api。

换一种说法是，vk暴露给你的gpu是最gpu的，先学ogl还真不一定更好学。。。

如果对渲染不熟悉，对各种渲染管线的资源状态感到困惑，最好先搁置渲染管线，把gpu当成纯粹的异步硬件。

可以：

1、创建一个计算管线；

2、搞清楚计算管线访问buffer前中后，该buffer的状态；

3、创建更多计算管线，使用各种信号量在它们和cpu之间同步；

这样一套下来，你至少会熟悉vk的套路，如果比较灵性的话可能已经参悟gpu编程是怎么回事了。

之后：

1、了解现代gpu的渲染管线，先看整个流水线，再看各个shader stage；

2、抄一个渲染demo，带纹理的三角形就行。着重研究一下渲染管线引入的各种资源和派生状态；

3、用信号量控制计算管线和渲染管线，做些预计算/后处理，感受一下发生什么事了。

到了这里如果脑子还清醒，就说明你已经会了。再剩下的就是打开各种扩展尝试新技术了。

刚好最近在做Vulkan相关的工作。我觉得，Vulkan可能难点还是在集成到引擎中遇到的一些实际设计、RenderState Cache, Descriptor Cache等问题。

至于，基础入门的话，确实API繁杂一些，但是基本数据结构和流程跟OpenGL 4.x的是差不多的。如果，题主看过DX12 或者 Metal等新一代的图形API，再去看Vulkan， 应该会觉得都差不多，就换个API的皮而已。

Vulkan是一个学院派设计的API，我刚学的时候也觉得很蛋疼，容易在细节中丢失方向。

不如，你先去看看Metal的，Apple官方的Metal的例子。然后，再去看Vulkan，你估计就发现差不多了。除了 Descriptor Set方面，比Metal更加自由之外。

或者，仔细画个思维导图，如何绘制一帧。我总结下来主要是以下几种：资源创建，Shader创建，资源和Shader绑定，Pipeline初始化，Swapchain初始化，录制Commands(录制多个Pass)，提交Commands，交换SwapChain的Buffer 这个流程。

最后，Vulkan相比OpenGL优势，我觉得主要在于以下几个方面：

1. Commands那边其实可以并行提交，可以新建多个Commands Buffer。

2. Shader的绑定非常自由，使得可以在资源绑定方面做一些优化。

3. PSO方面，也是自由控制的，可以更加自由地做一些优化。（我觉得DX的那种更简单直观)

刚好去年入坑了Vulkan，有一些学习资料，供参考。

Vulkan man：Vulkan API手册，方便查找函数。

API without Secrets: Introduction to Vulkan：从零开始的系统介绍，中文版在这。缺点是教程不完整，太监了。

Vulkan Tutorial：也有对应的中文版。系统的Vulkan介绍，缺点是没有一个完整的代码库，要手动一段段复制粘贴代码。

RayTracingInVulkan：这是一个github repo，比较完整的Vulkan封装，并实现了ray-tracing。缺点是对显卡要求高，没有RTX跑不起来。

Vulkan-glTF-PBR：也是一个github repo，有系统的Vulkan封装，支持glTF格式，支持PBR。

另外说几句题外话，还是很赞同前面几个回答提到的，Vulkan只是一个图形API，如果想了解CG，理论远比API重要的多。CG方面的知识最好的学习资料非GAMES的系列课程莫属了。另外一个个人比较推荐的资料就是开源的引擎/渲染器，扒源码，看文档。比如学术界的Mitsuba 1 & 2，PBRT，谷歌的Filament等。

基于个人的工程经验和基础积累，每个人的学习过程和方法都不会相同，图形API和其它API一样，仅是一种工程工具，掌握他只需要你付出呈正比的时间，最终你就会正确的使用它，付出的时间不仅是花费在学习API本身，很多时间可能你都在思考其背后的硬件工作原理，哪里会产生性能热点，遇到了无头绪的bug，去怀疑和揣测是否是驱动层面的实现问题。我觉得这些过程本身都是非常有价值的时间投入，最终都会夯实你自身各个方面的基础，引导你去不断的探索一些更具深度和挑战技术实践，这是在学习一类图形API过程中最具魅力的地方。

我在工作过程中几乎使用并深入实践过全部的图形API，dx8~12、gl/gles2~3.2/webgl、vulkan、metal，对于每种api，个人认为最高效且夯实的学习方法就是去工程实践，相信在至少熟练掌握了一项图形api之后，你会对渲染抽象接口（RHI）有一个自己的深刻理解，形成一套自己的认知体系框架，当然这个过程是要反复重构和拓展的，在迭代重大技术更新时甚至要推倒重来。在vulkan和dx12还没release前，我们当时还在经历inhouse引擎的gles时代，当时的时间点最先具备可进行工程落地的技术方案是nv提出的commandlist扩展，在调研后我们发现这个方向是正确且会成为未来主流，于是花费了一些时间对上层做了较大幅度的重构来匹配commandlist结构，在vulkan release便可以轻松的以一个月左右的时间完成了接入。有了框架体系，未来的每一项新技术对你来说都更像是拼零件，每一个新的feature和extension都被缩放到一个局部的零件大小，将它应用进你的框架和管线中就不再困难了，同时还能不断的完善和提升你的认知体系。

当然，我也非常理解并不是每个人都有机会和时间去实践每一种图形API，那么你可以找到一个成熟rhi方案，然后去参考借鉴研究它，最终转变为你的生产力工具，驾轻就熟的使用它。