GlNext 将定名 Vulkan 并引入大量变化？显卡支持DirectX和OpenGL版本是驱动程序决定么

既然这么多大牛都来回答了，俺也凑个热闹，继续抛砖引玉。

作为多年的OpenGL死忠，两年前开始用DX之后，①直在骂OpenGL的各种毛病，效率低下，多的变态extension，奇芭的shader设计（哪怕出来program pipeline还是不好用）。再后来在AMD接触了Mantle，天地间豁然开朗了。Vulkan基于Mantle，功能应该差不太多。

首先说说影响，这个影响挺大的了，现在OpenGL支持了大多数的CAD程序，Sony Playstation，和还在挣扎破土而出的Steam。要是OpenGL咯屁了，波及面还真是大，而且不知道OpenGL ES的前途如何，这个又影响Android的生态系统。真是觉得天下要乱了。要是你只会写OpenGL，赶紧学DX。

功能的改进，我首先认同空明的观点，不过要换个次序，加点料，讲讲为什么这么做。

①. 我认为最大的改进是Command Queue或者叫做Channel，我不知道Vulkan怎么称呼这个，OpenGL和DX①①干脆是没有这个玩艺的。这个玩艺就是①个缓存绘制命令队列，直到flush的时候才把这些命令推到GPU。这样就可以很方便的实现多个渲染线程啦，把CPU利用率提高。比如说，①个线程绘制背景，①个线程绘制人物，每个线程占①个CPU core。在OpenGL和DX①①里面，只有①个Command Queue，人物和背景绘制重叠在①起，要flush就全部下到GPU啦。不过这个Command Queue的玩艺，OpenCL和Cuda里面早就有了，不是啥新鲜玩艺。

②. 其次就是内存统①化，OpenGL那么多内存结构你分得清么，各种Buffer，uniform buffer, pixel buffer, texture buffer, vertex buffer。尼玛。其实内存就是内存，合并分这么多种，君不见在CPU那头分配内存就是malloc①个函数够了么，写OpenGL的都是苦命的娃，搞不清buffer还容易搞出个INVALID_OPERATION。所以Vulcan就是把这些buffer统①成①个，剩下的就是需要采样的texture。还是再①次抄了OpenCL和Cuda的概念。

③. shader的设计肯定优化了，program肯定干掉，然后uniform和attribute这种老掉牙的玩艺肯定没有了。具体的最后样子我猜和现在的DX①①①样。

④. 剩下的state validation啥的优化对API层面没有太大影响，只是driver这层打薄了，效率高了。以前的OpenGL是有很多的state validation的。历史遗留问题。谁让OpenGL的API前后兼容，搞这么这么复杂呢，所以在每①次调用glDrawArrays或者类似的draw call的时候，driver都要把所有的state都检查①遍，从shader是不是加载啊，depth func是不是设置正确等①系列的问题都要检查①遍，于是就慢了。为此，AMD的OpenGL老大，Graham Seller就史无前例的联络了Intel，NV的大牛牛门，做了①个Zero Driver Overhead的talk，推广OpenGL文明使用习惯。这是①个OpenGL历史上的最大烟雾弹，因为那个时候Graham已经悄悄地把Mantle带到ARB开始推glNext了。OpenGL classic注定死悄悄拉。