1.引言
Vulkan规范已经发布，本文将和你分享为什么Vulkan是一个牛逼的图形API， 它和OpenGL有何区别。Nvidia认为， Vulkan将是OpenGL 很好的补充，两个API都各有优势。
Vulkan的优势在于它能够更好的多线程处理和GPU底层控制能力，并能减少CPU消耗。而OpenGL，继续提供简单的硬件访问接口，这对那些CPU消耗不大应用程序来说是很方便的。 当前Nvidia 针对OpenGL的技术像“bindless”, NV_command_list, 和“ADZ0”， 都能够实现较好的单线程性能。
为使下面介绍更加容易读懂，我们省略掉其中的一些细节。
2.指令提交
在这篇文章中，我们看下绘制一帧需要哪些API
OpenGL API 的状态和绘制指令通常是立即发给GPU的， 而Vulkan API会累计这些API延迟发送；CommandBuffe 存储设置渲染状态的指令，然后提交给 Queue 去执行。
CommandBuffer 内部的操作过程看起来不应该陌生。 一个 RenderPass 和 FBO 绑定是相似的， 一个 DescriptorSet 处理 uniform bindings (buffer, texture...)， 后面有详细介绍。
- Device：Device 用来查询信息，创建大部分Vulkan API 对象。
- Queue：一个Device 可以暴露多个队列，例如， 专门的进行拷贝数据的队列，通用计算的队列，绘图的队列。单独的队列里面的操作是按序进行；但有多个对列时，多个队列的操作并行进行。
- CommandBuffer：通过CommandBuffer， 我们纪录了指令像设置状态，从顶点缓冲取数据绘制，分发计算网络，buffer之间的数据拷贝. 然而编译这些指令仍然需要一定代价,不过提交这些指令到指令队列是很快的.
3. Command Buffer 用法 我们能够并行的建立和提交多个CommandBuffers, 并重用它们. 重用在下面这些情况下尤其有用:传统CPU负担比较重, 构建多个阴影图,或者为虚拟现实眼睛生成左右图,或者提交多个复杂的对象, 或者几帧低CPU消耗的场景. Vulkan 驱动并不需要推算它们的用法, 因为开发者需要预创建各个对象信息. 下图展示的了primary commandbuffer 和 second commandbuffer 用法区别
- Primary CommandBuffer 总是处理RenderPass 状态设置. 其他的渲染操作可以直接记录或者被Secondary CommandBuffer记录.
- Second CommandBuffer 可以对Commands的子集进行编码.
就核心 Vulkan来说, CommandBuffers 之间不存在继承关系. 仅存的继承关系是, Secondary CommandBuffer 会使用Primary CommandBuffer的images.
4. 通用对象
是什么让CommandBuffer 编码那么快呢? 最关键的一方面是CommandBuffers引用更多的预先验证好的对象,因此,它克服了一些OpenGL存在的缺点. 尽管OpenGL 的 multi-draw-indirect buffers 也是重用对象完全并行处理的,但是它不允许状态改变.我们更远一点想,显示列表允许多个状态改变,但结果仅仅是部分子集内容是运行快的. 显示列表也存储了不可改变数据, 而现代方法采用的是引用数据.这意味着CommandBuffer 驱动的内容仍然可以动画, 像参考的数据矩阵和顶点数据可以独立改变.
下图展示了各种指令中用到的各种对象
- Image: 类似OpenGL Texture.
- FrameBuffer: 可被渲染的一组Image,. 它必须同RenderPass 配套使用.
- RenderPass: