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。

附：

Vulkan-实践剖析

Vulkan-性能及精细化控制