【其他】为什么GPU瓶颈的情况下不推荐用Vulkan解决?

Vulkan能在GPU端多线程执行：这完全是误解。

OpenGL/Vulkan这些图形API，本质上是与GPU驱动进行通信的一种规范。GPU驱动则是CPU与GPU进行通信的软件，所有这些（图形API、驱动）都是执行在CPU端，而非GPU端。

所以，不同的图形API影响的只是CPU端与GPU端通信的效率，协同的方式，而不是GPU端工作的效率。

因此，当为GPU瓶颈的时候，仅仅通过替换图形API是没有太大意义的，因为这主要改变的是CPU端的负荷，而此时真正的问题：GPU端的工作负荷或者工作方式并不会因此发生大的改变。

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

总的来说就是你所引用的那句话作为大原则是说得没有问题的，但是实际具体情况还需要具体分析，不可一概而论。

vulkan dx opengl这些实际上更像是tcp协议一样的东西，显卡是远程服务器，你可以用各种方式给服务器发送请求，并要求服务器以一定的形式返回。考虑到网络带宽有限，可以用各种技巧充分利用带宽，减少发送请求需要的时间。

但服务器怎么处理你的请求，你是控制不了的，如果你真的发了个要求渲染10^100个三角形这样的请求，那不管你用各种方式发请求，服务器要完成计算都是很慢，没什么太本质的差异

vulkan和opengl这类图形api是通过在cpu端给gpu提交命令来让gpu干活。gpu怎么执行这些命令（多线程还是什么什么）是gpu自己决定的，和图形api无关。vulkan相比于opengl的多线程是说vulkan能在cpu端多线程提交命令。

所以cpu瓶颈适合改用vulkan，gpu瓶颈不适合。

Vulkan的所谓多线程并行指的不是gpu端，而是cpu端，它可以通过多个commandlist来并行收集和编译渲染指令。其实通过优化barrier也是能优化gpu端的性能的，当然async compute也是优化的一种特殊手段。

建议看一下 Khronos 发布 Vulkan 时的slides， 基本都可以找到答案。

首先是 Vulkan 在什么背景下提出，有哪些优势：

另外就是何种条件下选择用 Vulkan：

从这里可以看出，CPU是瓶颈点但如果CPU任务无法并行化，用Vulkan也不一定能解决问题。

当然，Vulkan 提供了更灵活的CPU command生成、更细粒度的GPU控制，可以尝试的方法会更多一点，也算是一个潜在的性能提升思路。。

我个人理解，VULKAN的接口碎片化导致编程难度大幅上升。

碎片化带来的性能提升相比于OPENCL并没有数量级的提升。

然后诸如IO瓶颈，本质上还是硬件限制，用什么框架，差距也不大。

不是追求极致中的极致，我个人觉得能用OPENCL还是OPENCL吧，别总跟自己过不去。