1. Vulkan起源和歷史
1.1 AMD Mantle
2013年，AMD主導(dǎo)開發(fā)了Mantle。Mantle是面向3D游戲的新一代圖形渲染 API，可以讓開發(fā)人員直接操作GPU硬件底層，從而提高硬件利用率和游戲性能，效果顯著。
Mantle很好的帶動了圖形行業(yè)發(fā)展，微軟參考AMD Mantle的思路開發(fā)了DirectX 12，蘋果則提出了Metal。
但是因為AMD行業(yè)影響力和領(lǐng)導(dǎo)力不足，Mantle沒有發(fā)展成為全行業(yè)的標(biāo)準(zhǔn)。
2015年，AMD宣布不在維護(hù)Mantle，Mantle功成身退。Khronos接過AMD手中的接力棒，在Mantle的基礎(chǔ)上推出了Vulkan。
1.2 Vulkan的誕生
科納斯組織（Khronos Group）的成員來自圖形行業(yè)各個領(lǐng)域，專注于制定行業(yè)內(nèi)的開放標(biāo)準(zhǔn)（Open standard）。相對比AMD，Khronos在行業(yè)內(nèi)有更大的影響力和領(lǐng)導(dǎo)力。
來自圖形行業(yè)各個領(lǐng)域的Khronos成員都同意需要新一代的跨平臺GPU API，由此，繼承了Mantle”遺志“的Vulkan誕生了。
Vulkan的開發(fā)者來自圖形領(lǐng)域的各行各業(yè)，有GPU廠商，有系統(tǒng)廠商，有游戲引擎廠商... ...
所以Vulkan誕生之初就決定了它一定要有跨平臺屬性，目的就是成為行業(yè)內(nèi)的統(tǒng)一標(biāo)準(zhǔn)。
1.3 Vulkan-新一代GPU API的特性
OpenGL已經(jīng)發(fā)展了25年以上，并不斷滿足行業(yè)需求，但是現(xiàn)在已經(jīng)逐漸滿足不了行業(yè)的需要。
GPU的可編程性越來越強(qiáng)，越來越多的平臺開始支持加速圖形，計算，視覺和深度學(xué)習(xí)。靈活性和可移植性變得很重要。
性能上，OpenGL也不能充分發(fā)揮現(xiàn)代CPU多核多線程的性能優(yōu)勢。
為了解決上述問題，行業(yè)對新一代GPU API的提出了更高的要求：
-
Explicit（明確、透明）
- GPU driver做更少的事情，把更多的控制權(quán)交給開發(fā)者
-
Streamlined（精簡）
- 更快的性能，更低的開銷，更少的延遲
-
Portable（可移植）
- Cloud, desktop, console, mobile and embedded
-
Extensible （可擴(kuò)展）
- 支持新功能的擴(kuò)展，推動行業(yè)技術(shù)進(jìn)步
2. Vulkan的優(yōu)勢
2.1 顯式的GPU控制
在OpenGL驅(qū)動中，驅(qū)動會幫你做API驗證，內(nèi)存管理，線程管理等大部分工作。
OpenGL驅(qū)動大包大攬什么事情都管，即使應(yīng)用使用API出錯，也會幫忙解決處理，保證應(yīng)用正常運行。開發(fā)者使用起來非常簡單。
但是OpenGL為了這些事情，犧牲了大量的性能。在一些復(fù)雜的應(yīng)用場景，依然會遇到無法解決的問題，很多時候經(jīng)常是驅(qū)動的一廂情愿，應(yīng)用并不為此買單。
Vulkan則不然。
Vulkan把API驗證、內(nèi)存管理、多線程管理等工作交由開發(fā)者負(fù)責(zé)。一旦API使用出錯，應(yīng)用就會出現(xiàn)crash。
沒人幫應(yīng)用兜底，所有事情都交由應(yīng)用打理。這種方式無疑增加了API使用的復(fù)雜度和困難度，但換來的是性能上巨大的提升。單單是在驅(qū)動中去掉API驗證操作，就把性能提升了9倍。
2.2 CPU多線程的效率提升
在OpenGL中，所有的渲染操作都放在一個線程，其他線程就算處于空閑狀態(tài)，也只能圍觀。
Vulkan中引入了 Command Buffer 的概念，每個線程都可以往Command Buffer 提交渲染命令，給開發(fā)者提供了充分發(fā)揮CPU多核多線程的優(yōu)勢。在復(fù)雜場景下，性能的提升非常客觀！
2.3 可移植性
Vulkan的開發(fā)者來自圖形領(lǐng)域的各行各業(yè)，有GPU廠商，有系統(tǒng)廠商，有游戲引擎廠商... ...
所以Vulkan誕生之初就決定了它一定要有跨平臺屬性。相較于之前需要針對每個平臺做單獨開發(fā)，Vulkan可以實現(xiàn)跨平臺移植。
2.4 Vulkan和OpenGL性能對比
Khronos給出了一張各個圖形API理論性能對比：
PowerVR做了一個視頻做了Vulkan和OpenGL的性能對比：
視頻地址：PowerVR Rogue GPUs running Gnome Horde demo
3. Vulkan 適用范圍
目前，行業(yè)內(nèi)一致認(rèn)為Vulkan是未來的趨勢。但是具體到應(yīng)用開發(fā)者，我們是否現(xiàn)在就要將所有的OpenGL應(yīng)用移植到Vulkan？
要弄清這個問題，我們要知道Vulkan的優(yōu)勢是什么，它可以解決什么問題。
前文已經(jīng)說了，Vulkan的優(yōu)勢在于顯式控制和多線程功能，這些功能使我們能夠在更少的CPU時間內(nèi)將更多命令推送到GPU，并具有更精細(xì)的成本控制。
但是，OpenGL繼續(xù)提供了更易于使用的硬件訪問方式。
決定是使用OpenGL還是Vulkan，你需要平衡兩者的優(yōu)勢和缺點，針對不同情況選擇最合適的API。
3.1 性能上的考慮
如果你想通過Vulkan獲得性能上的收益，你首先要搞清楚你的應(yīng)用的性能瓶頸在哪里？Vulkan并非是解決性能問題的萬能靈藥！
3.1.1 非渲染流程導(dǎo)致的性能問題
Vulkan提升的是驅(qū)動的性能。如果你的應(yīng)用本身性能存在問題，并非渲染流程導(dǎo)致，把OpenGL替換為Vulkan并不會對你帶來巨大的收益。
3.1.2 GPU loading過重
Vulkan和OpenGL在GPU的使用上沒有質(zhì)的差距，如果你應(yīng)用的性能瓶頸在于GPU，GPU loading過重的情況下，把OpenGL換成Vulkan也未必有多大的提升。
3.1.3 對卡頓非常在意
如果你的應(yīng)用對微小的卡頓或者幀率抖動比較在意，Vulkan可以顯式控制場景渲染期間何時發(fā)生耗時的操作。這比OpenGL通過啟發(fā)式（推斷的方式）管理狀態(tài)和資源更加有優(yōu)勢。
3.1.4 希望進(jìn)行多線程渲染
如果OpenGL的單線程渲染讓你的應(yīng)用陷入了的性能瓶頸，你希望通過多線程充分發(fā)揮CPU能力，Vulkan非常適合。
3.1.5 離屏渲染
如果有離屏渲染的需求，Vulkan也可以勝任。
3.3 復(fù)雜度的考慮
3.3.1 代碼復(fù)雜度
使用Vulkan畫一個三角形就需要上千行代碼。Vulkan復(fù)雜繁瑣的API對開發(fā)者提出了挑戰(zhàn)。
對于許多用例，OpenGL仍然是一個不錯的選擇。它確實降低了復(fù)雜性和維護(hù)負(fù)擔(dān)，同時在許多情況下仍提供了出色的整體性能。開發(fā)人員能夠?qū)Ｗ⒂诮鉀Q實際圖形和計算問題，而不用編寫大量的Vulkan代碼。
3.3.2 開發(fā)者的工作量
OpenGL驅(qū)動會幫開發(fā)者做API驗證、資源管理等操作，但是Vulkan的驅(qū)動把這些交給開發(fā)者。這對開發(fā)者提出了更高的要求。在開發(fā)過程中，你需要考慮內(nèi)存管理、線程同步，一個不小心就會導(dǎo)致crash或者花屏，沒人幫你處理，一切只能靠自己。
3.3.3 不同硬件之間的移植工作
Vulkan雖然可以支持多平臺，但是因為Vulkan extension（擴(kuò)展）仍然是平臺相關(guān)的。如果想充分發(fā)揮平臺特性，代碼的耦合性依然很高。
參考文檔：
Android and Vulkan - GDD China.pdf
Vulkan Programming Guide
Vulkan Cookbook
Learning Vulkan
