1.介紹

1.1 Vulkan及其演化史

著名的OpenGL API問世已經差不多四分之一個世紀，而且它還在 不斷髮展。本質上來說，OpenGL是一個純粹的狀態機，其中包含了若 幹個開關量，可以設定為開/關的狀態（on/off）。這些狀態資料被用來構建裝置中的依賴對映關係，對資源進行管理，並通過最優的方法進行控制以達到效能的最大化。

這種狀態機可以隱式地自動化資源管理，但是它對應用程式邏輯 的解讀不夠智慧化，而應用程式正是資源管理背後的驅動力所在。其產生的結果可能是使用者無法預測的，比如實現中斷，導致著色器程式碼 被重新編譯，但是應用程式並不需要系統這麼做。此外，OpenGL API 也會受到其他因素的限制，例如不可預測的程式行為、多執行緒的擴充套件 性、渲染的故障等。後續會將OpenGL與Vulkan API進行比較來理 解兩者之間的各種差異。 Khronos於2016釋出了革命性的新架構Vulkan API，它充分利用了 現代圖形處理器單元的優勢，來實現高效能圖形和計算應用程式的開 發。

Khronos是一個會員制的社群和專注於釋出開放標準和免費API的 組織。更多資訊請參閱網站：https://www.khronos.org。

Vulkan的原始概念是由AMD基於它們的私有Mantle API設計和實現 的。這個API已經在幾款不同的遊戲中體現了自己的先進特性，它有著 革命性的實現方案，完全滿足了工業界的競爭性需求。AMD開源了自己 的Mantle API並且貢獻給Khronos組織。在多家硬體和軟體供應商的協 同幫助下，Khronos釋出了Vulkan標準。

Vulkan並不是目前唯一的新一代3D圖形API，它還有多家不同的競 爭者，例如Microsoft的Direct-X 12和Apple的Metal。不過，DirectX只能用於不同的Windows系統，而Metal只能用在Mac系統（OS X和 iOS）。因此，Vulkan得以脫穎而出。它的跨平臺特性可以支援所有現 存的OS平臺，其中已經包括了Windows（XP、Vista、7、8、10）、 Linux、Tizen、SteamOS和Android。

1.2 Vulkan與OpenGL的對比

Vulkan相比OpenGL有了不少的新特性和效能提升，如下所示。

• 降低驅動負載和CPU的使用量：Vulkan在設計上更為接近於底層 的圖形硬體。因此，它可以嚮應用程式的開發者提供更為直接的控制權力，來操作宿主機上的計算資源，使用GPU來儘可能高效地完成渲染工作。這一特性使得相關軟體可以直接訪問圖形處理器，從而達到 更好的效能要求。

• 多執行緒的可擴充套件性：OpenGL中的多執行緒擴充套件能力是非常有限的，所以很難利用多執行緒的各種優勢來管理CPU資源。不過，Vulkan在設計時特別考慮了終端使用者對於多執行緒功能的迫切需求，並且通過非常透明的方式予以支援（並不會隱含任何的全域性狀態變化）。不同線 程下的任務、任務的建立過程，以及任務提交執行的過程之間都是完 全獨立的，不存在資料耦合。

• 顯式的API定義：OpenGL的API是隱式的，資源管理的工作交給 驅動層去完成。驅動層負責讀取應用程式端的提示引數並跟蹤資源的 處理，這樣帶來了很多不必要的負擔。

• Vulkan採用了顯式的API定義，驅動並不負責資源以及資源之間相互關係的管理。這些工作由應用程式處理。這種清晰的實現方式更容易預測，驅動層也不需要在使用者場景的後面偷偷做資源管理的小動 作了（這正是OpenGL的弊端）。這樣的結果是，使用者任務的處理可以 直截了當地以流水線的方式完成，從而獲得最佳效能和可預測的行為 模式。

• 預編譯的中間級著色語言：OpenGL需要使用OpenGL著色語言 （GLSL）原始碼的形式來實現著色器，而Vulkan使用可移植的標準化 中間級語言（SPIR-V）作為中間級語言標準，為平行計算和圖形處理 提供了著色器支援，其他原始碼語言的編譯器（例如GLSL、HLSL或者LLVM）必 須將SPIR-V作為輸出的目標語言，並且提供工具來實現SPIR-V輸入數 據的支援。Vulkan可以讀取這種能夠馬上執行的二進位制中間資料，並且 在著色器執行階段直接使用。

• 驅動層和應用程式層：OpenGL中的應用程式層相比驅動層而言 要單薄得多，因為驅動層會自動完成資源管理和狀態跟蹤的工作。 Vulkan與之相反。它的驅動層更為接近硬體底層，負載較小。而應用程 序層需要負責邏輯、資源和狀態的管理。圖1-2給出了這兩個API各自的 驅動層和應用程式層程式碼的總量對比。

• 記憶體的控制：Vulkan暴露了系統當中的多種不同型別的記憶體介面，交由應用開發者去選擇適合自己的記憶體型別，實現各種資源的管理和使用。與之相反，OpenGL是通過驅動層的內部處理機制來完成資源儲存的，不同的供應商可能因此有完全不同的實現，並且當驅動層改變了資源的儲存位置時。很可能產生預期之外的記憶體碎片，或者降低儲存效率。
• 可預測行為：Vulkan與OpenGL相比，其行為具有很高的可預測性，它不會在渲染時產生任何延遲或者抖動。使用者任務傳遞到驅動層之後會被立即提交，而OpenGL的任務提交過程不是立即完成的，它需 要等待驅動層再去進行排程。 
• 單一的API：OpenGL有多個獨立的版本，包括桌面端的 API（OpenGL）和嵌入式系統的API（OpenGL ES）。Vulkan相比之下 更為清晰，它只提供了單一的API介面來面對所有型別的系統平臺。 Vulkan會優先支援移動平臺，這一點與OpenGL也是不一樣的。 OpenGL通常會優先實現某個功能的桌面端版本，然後再將它更新到 OpenGL ES API當中。
• 直接訪問GPU：Vulkan暴露了自己的底層功能和硬體特性，從而給應用層使用者提供了大量的控制手段。它提供了多種不同型別的物理裝置、記憶體型別、指令快取佇列，以及功能擴充套件。這樣的模式確保軟 件層更接近實際硬體的特性。