Vulkan 并非“灵药“

前面几篇文章，我们介绍了新一代图形 API-Vulkan 的优势及特点。由于其精细化的控制和性能特点，有的小伙伴就发出了疑问“是否需要把现有的 OpenGL 项目迁移到 Vulkan 上？”，“Vulkan 效果并没有想象中的那么好是怎么回事？”。今天我们就来浅聊下这个话题。

首先我想声明的是 Vulkan 并非银弹并不是所有的渲染问题都可以通过替换图形 API 就能轻松解决的，甚至可能会有负收益和成本的问题。

场景一 业务自身性能问题

自身业务场景问题都没有有效解决，只想依靠底层提升来解决无异于杯水车薪。所有解决性能的思路都是先做度量，再根据度量结果优化项目现有问题，再通过底层基础和通用能力提升。而大部分场景都是自身问题并没有得到很好的解决。

场景二 非渲染场景下问题

当前的性能瓶颈并不是渲染相关的，可能是数据也可能是业务逻辑甚至是网络。

场景三 低延迟及少卡顿

如果你的应用对微小的卡顿或者帧率抖动比较在意，Vulkan 可以显式控制场景渲染期间何时发生耗时的操作。这就得益于 Vulkan 的精细化控制和设计哲学，比起 OpenGL 驱动通过预测管理状态和资源更加有优势。

场景四 多线程渲染

如果程序性能的瓶颈在于 CPU 上和图形相关的部分，那么 Vulkan 很有可能有机会提升它的性能，因为 Vulkan 天生支持多线程，可以充分发挥 CPU 的能力，比起 OpenGL 的单线程渲染更有优势。或者对于想要榨干某个计算资源相对有限的平台上的性能，那么 Vulkan 中允许程序对所有资源直接的分配和管理也可能对性能有一定的帮助。

场景五 性能瓶颈 GPU

这是一个较容易引起争议和误解的场景，我个人理解本质上图形 API 是与 GPU 驱动进行通信的一种规范，GPU 驱动是 CPU 与 GPU 通信的媒介，所有这些（图形 API、驱动）都是执行在 CPU 端，而非 GPU 端。

所以，不同的图形 API 并不能直接提升 GPU 本身的工作效率和提高其负载，只能改善 CPU 端与 GPU 端通信的效率，协同的方式。

虽然不能直接影响 GPU 的性能，但不同的图形 API 对 GPU 的操控能力的粒度不同，Vulkan 远比 OpenGL 操控得细，也能使用（定制）更多的 GPU 端的功能，所以部分场景下替换成 Vulkan 可以为我们提供更多的控制手段，是有可能有助于改善 GPU 执行效率的。

场景六 生态及成本

无论是技术生态还是人力成本，Vulkan 都是相对处于劣势的，所以在做项目迁移的时候一定要考虑这点，不能盲目跟从。

当然业务场景万千，开发者需要从多方面考虑谋取最大的 ROI。

欢迎关注、转发、评论，同时也可关注微信公众号，内容首发欢迎交流。愿时光不辜负每一个人。