概览
Vulkan的起源
首先 我们有了显卡厂(老黄,农企)
我们还有各种API DX/OpenGL 没有这些api的时代我们称之为史前时代
老黄和农企进行竞争拼的是什么? FPS和画质,然后这两者之间必须由驱动进行妥协(你不指望拿GT1030跑刺客信条奥德赛吧)
这就是为什么有这么多的驱动程序更新来提高游戏性能的原因。 由于这些驱动程序的复杂性，应用程序开发人员还需要处理供应商之间的不一致性，例如着色器可接受的语法。
然后这些大厂发现自己的显卡很好了已经,但是CPU干活慢,导致显卡没活干,但是实际上是一核有难七核旁观,所以开始着手设计多线程支持,然后发现真是哔了狗了,现在的图形API都什么垃圾,所以推到重构。
Vulkan通过从头开始设计现代图形架构来解决这些问题。 它允许程序员使用更详细的API写清楚到底干啥，然后让多个线程并行创建和提交命令，从而减少了驱动程序开销。 它通过使用单个编译器切换到标准化字节代码格式来减少着色器编译中的不一致性。 最后，它通过将图形和计算功能统一到单个API中来承认现代图形卡的通用处理功能。
Vulkan被设计为跨GPU的跨平台抽象。 这意味着我们学过一边就可以到处追着debug了
Hello World (渲染一个彩色三角形)的正确操作步骤
- 创建一个Vulkan实例,看看自己有几块显卡,挑一块
- 用上面那块显卡创建一个逻辑设备
device然后看看使用那些扩展API(比如老黄的RTX),创建一个队列queue然后准备一堆命令(操作操作内存啊,画点东西啊)然后这个队列会异步执行 - 创建一个实体窗口和一个交换链
swapchain,这个听起来很唬人的东西其实就是一堆渲染目标串一串,交换链在完成渲染后在特定时间传给屏幕,传递的数量和条件取决于现在的模式(常见的有双缓冲和三缓冲) - 从交换链拿来我们的图像之后还不是一个正常人能看见的图片(电脑或许也看不见),我们需要把他包在
imageview和framebuffer里,这个过程一定要快准狠因为交换链里有一堆排着队等着,叫错人不行,叫慢了也不行,人家等不及走了 - 准备屏幕(一般人都是大白屏或大黑屏)
- 图形管道
pipeline可进行编程,但是vulkan的图形管线是静态的,只能动态的改一些窗口大小啊,颜色啊之类的. - 有一个命令池
commandpool和一个对应的buffer用来排队执行我们给他的命令,对于这个三角形就是:开始渲染,绑定图形管道,点三个点,结束 - 最后我们在主循环里调用上面这一堆然后扔到屏幕上等待下一帧.
震惊 Vulkan 竟然是开发者的福音,debug难度居然比OpenGL简单
因为Vulkan内置一个Debug layer它可以追踪内存管理,检查函数参数,甚至还可以自定义,而且完全0开销,这是我们能够快速找到黑屏到底是哪里手抖了.