GlNext 將定名 Vulkan 並引入大量變化，這將造成怎樣的影響？

01-07

https://www.khronos.org/assets/uploads/developers/library/overview/2015_vulkan_v1_Overview.pdf

Vulkan基本上就是DX12。

這一代的API的特徵包括：

統一存儲資源，僅包括線性存儲的Memory和非線性存儲的Texture。之所以仍然要區別兩者，一個是因為Locality不同，還有一個是因為Filtering的需要。
API被徹底簡化成了State和Cmd。State的集中處置意味著驅動對狀態一致性檢查的減少，這歷來是Runtime和UMD的性能大坑。
分線程的Command Buffer和集中調度。這主要是為了支持多線程。

實際上D3D12這些特徵，D3D11就已經具備不少了，只是12在Spec層執行地更徹底。

對於SPIR-V而言，好處並沒有那麼多。Runtime之上的Mid Level Shader ASM和硬體的實際指令差的挺遠，而且從Mid Level - Low Level的優化，和直接從Source走相比也是各有利弊。Bug也多是優化部分帶來的，前端不是個容易出Bug的地方。

補充一些就是這一代API都是Low Overhead + 暴露更加低層的功能(很多之前都是驅動幹掉的, 近代主機上的API都是如此). 加上Command Buffer和DMA這些讓CPU的利用率可以得到一些解放(比如不用去沒必要的wait for sync). 但是其實就是把負擔放到了程序員身上, 比如你需要自己寫各種Memory Management, 折騰Buffer利用策略等等 (因為CPU和GPU可能不是在處理同一幀, 而是並行處理不同幀, 就涉及到各種策略問題).

Vulken基本上就是Mantle, AMD把Mantle貢獻給了K社, 然後Mantle自身的SDK不會開放了. 這樣基本上就是D3D12(Windows), Vulken(跨平台)和Metal(水果).

但是問題是, Vulken的Spec都沒有, 據說要下半年 (這辦事效率....). 所以實際上部分Vendor目前也沒法去實現他. 個人覺得也不會改變什麼格局. 對於開發圖形程序的人就是又多了個後端(.

既然這麼多大牛都來回答了，俺也湊個熱鬧，繼續拋磚引玉。

作為多年的OpenGL死忠，兩年前開始用DX之後，一直在罵OpenGL的各種毛病，效率低下，多的變態extension，奇芭的shader設計（哪怕出來program pipeline還是不好用）。再後來在AMD接觸了Mantle，天地間豁然開朗了。Vulkan基於Mantle，功能應該差不太多。

首先說說影響，這個影響挺大的了，現在OpenGL支持了大多數的CAD程序，Sony Playstation，和還在掙扎破土而出的Steam。要是OpenGL咯屁了，波及面還真是大，而且不知道OpenGL ES的前途如何，這個又影響Android的生態系統。真是覺得天下要亂了。要是你只會寫OpenGL，趕緊學DX。

功能的改進，我首先認同空明的觀點，不過要換個次序，加點料，講講為什麼這麼做。

1. 我認為最大的改進是Command Queue或者叫做Channel，我不知道Vulkan怎麼稱呼這個，OpenGL和DX11乾脆是沒有這個玩藝的。這個玩藝就是一個緩存繪製命令隊列，直到flush的時候才把這些命令推到GPU。這樣就可以很方便的實現多個渲染線程啦，把CPU利用率提高。比如說，一個線程繪製背景，一個線程繪製人物，每個線程佔一個CPU core。在OpenGL和DX11裡面，只有一個Command Queue，人物和背景繪製重疊在一起，要flush就全部下到GPU啦。不過這個Command Queue的玩藝，OpenCL和Cuda裡面早就有了，不是啥新鮮玩藝。

2. 其次就是內存統一化，OpenGL那麼多內存結構你分得清么，各種Buffer，uniform buffer, pixel buffer, texture buffer, vertex buffer。尼瑪。其實內存就是內存，合併分這麼多種，君不見在CPU那頭分配內存就是malloc一個函數夠了么，寫OpenGL的都是苦命的娃，搞不清buffer還容易搞出個INVALID_OPERATION。所以Vulcan就是把這些buffer統一成一個，剩下的就是需要採樣的texture。還是再一次抄了OpenCL和Cuda的概念。

3. shader的設計肯定優化了，program肯定幹掉，然後uniform和attribute這種老掉牙的玩藝肯定沒有了。具體的最後樣子我猜和現在的DX11一樣。

4. 剩下的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註定死悄悄拉。

還沒有看到具體的文檔和資料，所以現在還不好怎麼評論。但基本上就是OGL對DX12和mantle的回應。估計是因為DX12這種API已經不太容易直接用以前擴展OpenGL的方式添加進來，於是就乾脆另起一套了。

至於影響，我並不認為會改變什麼格局。Windows之外總需要一些等價的標準的。如 @vczh 所說，但願新的API能提供Shader ASM標準，省得勉強一些無能的公司自己在驅動裡面實現充滿BUG的傻逼Shader Compiler。

這並沒有解決圖形程序員的最大痛點——識別不同驅動程序的bug，然後通過構造神奇的shader來繞過他們。

瀉藥。我不專精於圖形學與GPGPU，隨便扯扯。

看起來，Vulkan的意思是更加專註通用計算，至少也會比OpenGL更多地暴露一些底層的運行控制，而不是像現在的OpenGL那樣專註於流水線，只是在幾個特定點允許shader編程。這樣一來，圖形引擎的編寫可以更具靈活性，比如使用更多的全局演算法，而不拘泥於屏幕空間。

Vulkan引入了中間語言，而不像OpenGL在顯卡驅動里整個編譯器，這明顯是學DirectX啊。。。

不過有個問題：結構固定的流水線，應當有利於隱藏GPU之間的架構差異。如果底層暴露的更多，程序員怎樣折騰這些架構差異造成的效率區別？以前和Newton物理引擎的作者交流過少許，他認為不同設備之間的巨大架構差別，使得寫GPGPU的物理引擎其實是很困難的，至少難以非常簡單地寫出在不同設備上都高效的代碼。