Vulkan API 的簡要概述

那麼，這個新的 Vulkan API 有什麼大不了的，我們為什麼要關心呢？

這是 100 字以內的 Vulkan API：它是用於 3D 圖形和計算應用程序的低開銷、接近金屬的 API。 Vulkan 基本上是 OpenGL 的後續版本。 它最初被稱為“下一代 OpenGL 計劃”，它包括來自 AMD 的 Mantle API 的一些零碎的東西。 Vulkan 應該提供優於其他 GPU API 的眾多優勢，實現卓越的跨平台支持、對多線程處理器的更好支持、更低的 CPU 負載以及少量操作系統不可知論。 它還應該使驅動程序開發更容易，並允許對驅動程序進行預編譯，包括使用以各種語言編寫的著色器。

那是 93 個字，所以如果您不感興趣，可以跳過接下來的 3,500 個字。 另一方面，如果您想了解更多關於未來幾年將與我們一起推出的圖形 API，我將從基礎開始。

Vulkan API 是如何誕生的

Vulkan 最初由 Khronos 集團於 2015 年 3 月宣布，暫定於 2015 年底推出。如果您不熟悉 Khronos，它是 15 年前由業內一些知名人士創立的非營利性行業聯盟。圖形行業，包括 ATI（現在是 AMD 的一部分）、Nvidia、Intel、Silicon Graphics、Discrete 和 Sun Microsystems。 即使您沒有聽說過 Khronos，您也可能聽說過他們的一些標準，例如：OpenGL、OpenGL ES、WebGL、OpenCL、SPIR、SYCL、WebCL、OpenVX、EGL、OpenMAX、OpenVG、OpenSL ES、流輸入、COLLADA 和 glTF。

到現在為止，您可能在想“啊，是那些傢伙”，所以我可以跳過其餘的介紹並專注於 API 本身。

與它的前身或前身不同，Vulkan 的設計初衷是為了在各種平台上運行，從手機和平板電腦到遊戲機和高端台式機。 API 的底層設計是分層的，或者我們應該說是模塊化的，因此它可以創建一個通用但可擴展的架構，用於代碼驗證、調試和分析，而不會影響性能。 Krhonos 聲稱分層方法將提供更大的靈活性，促進跨供應商 GPU 工具的強大創新，並提供複雜遊戲引擎所需的更直接的 GPU 控制。

現在，我了解到許多技術愛好者對“靈活”、“可擴展”和“模塊化”等營銷術語持保留態度，但這次我們要處理的是真正的 McCoy。 事實上，這就是 Vulkan 背後的基本理念：它被設想為一個面向大眾的 API，從孩子們在智能手機上玩遊戲，到他們的父母在工作站上設計建築和遊戲。

從理論上講，Vulkan 可用於並行計算硬件，控制數百億個 GPU 內核，用於微型可穿戴設備和玩具無人機，用於 3D 打印機、汽車、VR 套件，以及幾乎任何其他內置兼容 GPU 的東西。

有關更多詳細信息，我建議您查看 PDF 中的官方 Vulkan 概述。

AMD 地幔 DNA

如果接近金屬的方法聽起來非常熟悉，那麼您可能在過去兩年左右一直在關注 AMD 的 GPU 公告。 AMD 在 2013 年宣布其 Mantle API 時令行業觀察家感到驚訝，當它決定取消 API 的插件時再次讓他們感到驚訝，並在 2015 年 3 月宣布不會將 Mantle 1.0 作為公共 SDK 發布。 簡而言之，Mantle 承諾在某些情況下提供顯著的性能和效率改進，尤其是在 CPU 前端，因為它會減少處理開銷。 這聽起來是個好主意，因為遊戲玩家可以將定制 PC 與稍慢的處理器放在一起，並在頂級顯卡上投入更多資金。 這對 AMD 來說聽起來也很方便，因為該公司多年來一直沒有有競爭力的高端 CPU，儘管它仍然有很好的 GPU 產品。

當哭泣的 AMD 粉絲聚集在一起哀悼他們的救世主去世時，Mantle 奇蹟般地複活了。 好消息來自 AMD 視覺和感知計算副總裁 Raja Koduri 撰寫的博客文章。 巧合的是，為了與宗教主題保持一致，有一次 Koduri 在 2013 年 AMD 的夏威夷發布會期間舉行了一次登山佈道，但我離題了。

一邊開玩笑，科杜里的團隊做得很好。 雖然 Mantle 沒有成為新的行業標準，但它確實成為了 Vulkan 的基礎。 最大的不同是 Vulkan 不會僅限於 AMD GCN 硬件； 它將適用於來自不同供應商的更多 GPU。 您可能會看到我的目標； 擁有一個可在不同操作系統和硬件平台上運行的單一低開銷圖形 API 比擁有用於不同 GPU 架構、操作系統等的專有 API 更好一些。

Vulkan API 只是從 Mantle 蛋糕中分一杯羹，並與所有人分享，無論操作系統、硬件、種族或宗教如何。

哦，還有一件事：Mantle 最終迫使微軟和 Khronos 最終對 DirectX 和 OpenGL 的膨脹和低效採取了一些措施。 正如 Toptaler 的一位同事喜歡說的那樣，這是一種溫和、友好的後踢，或“badonkadonk”。

Vulkan 與 OpenGL 相比如何？

顯然，我需要概述 Vulkan 和 OpenGL 之間的基本區別。 Khronos 提出了一個簡單的說明，展示了使用新 API 可以消除多少驅動程序膨脹。

Vulkan 允許應用程序更接近金屬，從而消除了對大量內存和錯誤管理以及大量著色語言源的需要。 司機會更輕、更瘦、更刻薄。 Vulkan 將只依賴 SPIR-V 中間語言，並且由於它具有針對移動、桌面和控制台市場的統一 API，它也應該得到開發者更多的溫柔和關愛。

但是等等，這不是簡單地把更多的工作交給了遊戲開發者嗎？ 當然，他們將能夠更有效地使用硬件，但他們自己的工時呢？ 這就是分層生態系統方法進入競爭的地方。

開發人員將能夠選擇 Vulkan 生態系統的三個不同級別或層級。

• 直接使用 Vulkan 以獲得最大的靈活性和控制力。
• 使用 Vulkan庫和層來加速開發。
• 通過對新 API 進行全面優化的現成遊戲引擎使用 Vulkan。

第一個選項顯然不適合所有人，但我懷疑它會成為一些不錯的基準測試軟件。 Khronos 預計第二個選項將成為“豐富的創新領域”，因為許多實用程序和層將是開源的，並且將簡化從 OpenGL 的過渡。 如果出版商有一些需要調整和更新的 OpenGL 標題，這就是他們會使用的。

最後一個選項也許是最誘人的，因為繁重的工作已經由 Unity、Oxide、Blizzard、Epic、EA、Valve 等行業巨頭完成。

這是一個快速的 OpenGL 與 Vulkan 表：

老實說，我認為將兩者進行比較是不公平的。 Vulkan 是 Mantle 的衍生產品，而 OpenGL 是擁有 20 年包袱的乳齒象。 Vulkan 應該拋棄大量遺留的東西。 這就是重點。 Vulkan 應該通過 SPIR-V 中間語言簡化測試和實施，使驅動程序更精簡，並提高著色器程序的可移植性。

這將我們帶到下一個問題。 Vulkan 對開發人員的真正意義是什麼？

SPIR-V 有望改變語言生態系統

那麼 SPIR-V 在哪裡發揮作用，舊的 GLSL 會發生什麼？

GSLS 將暫時保持活力，它將成為 Vulkan 支持的第一個著色語言。 GLSL 到 SPIR-V 的翻譯器將完成繁重的工作，瞧！，您將準備好 SPIR-V 來滿足飢餓的 Vulkan 運行時。 遊戲開發者將能夠使用 SPIR-V 和 Vulkan 後端，可能依賴於開源編譯器前端。 除了 GLSL，Vulkan 還可以支持 OpenCL C 內核，同時增加對 C++ 的支持的工作正在進行中。 未來的特定領域語言、框架和工具是另一種選擇。 Khronos 甚至提到了開發新的實驗性語言的可能性。

無論開發人員選擇做什麼，所有的道路都通向 Vulkan，通過 SPIR-V，然後通向眾多不同的設備。

SPIR-V 應該以三種方式提高可移植性：

• 共享工具
• 單一 ISV 的單一工具集
• 簡單

由於不需要每個硬件平台都配備高級語言翻譯器，因此開發人員將處理更少的翻譯器。

單個 ISV 可以使用單個工具集生成 SPIR-V，從而消除高級語言的可移植性問題。

SPIR-V 比典型的高級語言更簡單，實現和處理更容易。

性能將通過多種方式得到改善，具體取決於 Vulkan 的實現方式：

• 沒有編譯器前端，很多處理都可以離線完成
• 優化通過可以更快地解決，優化離線執行
• 多個源著色器減少到相同的中間語言指令流

Khronos 沒有指定任何性能數據，並指出“里程肯定會有所不同”。 這完全取決於如何使用 Vulkan。 如果您想查看詳細信息，請務必查看 SPIR-V 白皮書。

從開發人員的角度來看，Vulkan 看起來很有前途

我已經概述了一些應該使 Vulkan 和 SPIR-V 在開發社區中流行的特性，而 Khronos 也熱衷於傳達這一點。 使用相同的工具和技能為多個平台進行開發的前景似乎很有趣，尤其是現在各種平台之間的性能差距正在縮小。

當然，為 PC 開發大預算的 AAA 級遊戲仍將是一個極其複雜和耗時的過程，涉及大量現金和人力資源，但最新的英特爾和 AMD 處理器中採用的移動平台和集成 GPU 已經提供了大量的休閒遊戲玩家的 GPU 性能。 此外，小型獨立開發者或自由職業者更有可能從事跨平台休閒遊戲，而不是主要發行商生產的 AAA 遊戲。

Khronos 概述了 SPIR-V 帶來的以下優勢：

• 開發人員可以跨多個平台使用相同的前端編譯器來消除跨供應商的可移植性問題
• 運行時著色器/內核編譯時間將減少，因為驅動程序只需要處理 SPIR-V
• 開發人員不必分發著色器/內核源代碼，因此他們享有更高級別的 IP 保護
• 驅動程序更簡單、更可靠，因為不需要包含前端編譯器
• 開發人員對內存分配有更好的了解，並可以相應地調整他們的內存分配方法

我相信你會同意這聽起來不錯，但還有很長的路要走。

Vulkan：它有效，但它正在進行中

正如我所說，Vulkan 仍然是一項正在進行的工作，我們應該在今年年底之前擁有完整的規範。 然而，從我們目前看到的情況來看，即使使用當前一代的硬件，新的 API 也可以釋放很多性能。

到目前為止，我所看到的關於 Vulkan 的最佳示例來自 Imagination Technologies，它是目前領先的移動 GPU 設備之一。 Imagination Technologies GPU IP 用於所有 iOS 小工具，以及許多其他基於 ARM 的片上系統設計，甚至用於一些低壓 Intel x86 芯片。

上週，Imagination 發表了一篇博文，詳細介紹了 Vulkan 帶來的性能提升。 它的硬件選擇有些不同尋常：Google Nexus Player，基於很少使用的 Intel 四核處理器和 PowerVR G6430 GPU。 該設備使用用於 PowerVR GPU 的最新 Vulkan API 驅動程序進行了測試，而參考運行是在 OpenGL ES 3.0 上執行的。 性能差距簡直是驚人的。

該場景總共包括 400,000 個對象，具有不同的細節層次，從 13,000 到 300 個頂點不等。 廣角鏡頭顯示了大約一百萬個三角形，植物上的一些 alpha 以及侏儒和植物的大約十種不同的紋理。 每種對像類型使用不同的著色器並且沒有實例化 gnome，每個繪製調用可能是完全不同的對象，具有不同的材質，但最終結果將是相似的。

儘管如此，還是有一個很大的警告：這不是您在現實生活中可以期待的那種性能提升。 Imagination Technologies 團隊使用誇張的場景來突出 Vulkan 的優勢，將其推向極限，在這個特定場景中，極限有利於 Vulkan 與 OpenGL ES。 另外，請記住，這個測試是 GPU 綁定的，但它仍然是 Vulkan 出色的 CPU 利用率的一個很好的例證。

Vulkan 如何降低 CPU 使用率？

還記得我們之前的 OpenGL 與 Vulkan 表，或者更具體地說，是平鋪渲染位嗎？ 可能不是，簡而言之就是這樣：Imagination 使用 Vulkan 將繪製調用批處理到圖塊中並一次渲染一個圖塊。 根據渲染幀時瓦片的位置，它可以進入或退出視圖，更改其細節級別等等。 在 OpenGL ES 中，所有的繪製調用都是動態​​的，它們根據視野中的內容隨每一幀一起提交。 已經執行的繪圖調用不能被緩存。

因此，OpenGL ES 需要多次調用內核模式來更改驅動程序的狀態並對其進行驗證。 Vulkan 沒有，因為它依賴於預先生成的命令（命令緩衝區）來減少 CPU 開銷並消除在渲染循環期間驗證或編譯的需要。 Imagination 團隊將重用命令緩衝區的能力描述為“在某些情況下很有用”，並且可以在許多遊戲和應用程序中“在很大程度上”使用。

第二個改變遊戲規則的是並行緩衝區生成，它使 Vulkan 能夠利用所有 CPU 內核的能力。 OpenGL ES 是在多核移動芯片出現之前設計的，但在過去三年中，該行業已經從兩個、四個、到八個和十個 CPU 內核，使用 Apple 的 A 系列 SoC 和基於丹佛的 Nvidia Tegra芯片是唯一值得注意的例外。 我在之前的一篇博客文章中談到了移動 SoC 趨勢，涵蓋了即將推出的優化Android 編譯器，因此您可以查看它以獲取更多信息。

讓我們打個比方：如果 Vulkan 是內燃機，它將存儲和重複使用部分動力，就像渦輪增壓器和中冷器（命令緩衝器）一樣，它可以使用四個、六個、八個甚至十個氣缸而不會降低效率（並行緩衝生成）。 將 Vulkan 與 OpenGL ES 進行比較聽起來有點像在您祖父的 Triumph Trophy 中將新的小型渦輪發動機與舊的單缸發動機進行比較。

好吧，至少爺爺是一個真正的搖滾樂手，而不是一個模特。

最終結果是一個更加高效的環境，能夠充分利用所有可用的硬件，這與在大多數情況下受 CPU 限制的 OpenGL ES 不同。 這意味著 Vulkan 可以提供類似水平的性能，同時將 CPU 保持在較低的時鐘頻率，從而降低功耗和節流。

潛在的 Vulkan API 缺點（劇透警告：沒有那麼多）

我不是吹毛求疵； 我覺得列出 Vulkan API 的優缺點也很重要。 幸運的是，除了一些小問題，可能還有一兩個大問題，沒有那麼多缺點。 如果您認為 Vulkan 是自切片麵包以來最好的東西，並且您渴望在下一個項目中嘗試一下，您可能需要考慮以下幾點：

• 在某些情況下增加了代碼複雜性
• 上市時間
• 行業支持水平
• Vulkan 在某些平台（桌面）上可能不那麼相關或有效
• 說服開發人員在某些平台上使用 Vulkan
• 與舊硬件的有限兼容性

如果開發人員想要實現本文中概述的一些簡潔功能，則將涉及大量工作。 每個都必須在代碼中實現，但好消息是行業領導者將通過新的驅動程序更新使流程更容易。

上市時間是另一個問題，Vulkan 在較舊的應用程序和遊戲中的實施也是如此。 Vulkan 仍然是技術預覽版； 最初的規範和實施預計在 2015 年底之前完成，因此，實際上，在 2016 年年中之前，我們可能不會看到很多實際應用。

行業支持不應該成為問題； 畢竟，這是一個 Khronos 標準，但可能需要一段時間。 這就是我將這篇文章重點放在移動領域的原因之一； 移動軟件和硬件發展得更快，我們可能需要再過幾個季度才能看到 Vulkan 對桌面平台產生影響。 這就是這個行業的運作方式，在桌面領域還有更多需要擔心的事情：對專業應用程序的支持、成群的手持乾草叉的遊戲玩家在每一個被撕裂的框架上猿猴，等等。 然而，Vulkan 源自 AMD 的 Mantle 的事實令人鼓舞。

雖然 Vulkan 可以在 CPU 密集型環境中創造奇蹟，尤其是多核移動 SoC，但這些性能提昇在桌面平台上將受到限制。 台式機以更高的效率處理多核處理器，並且大多數圖形要求高的應用程序都受 GPU 限制。

在所有的拼圖都到位之前，一些開發人員可能不願意冒險和 Vulkan 混在一起。 很多人根本沒有時間進行實驗，他們只有在絕對必要時才學習新技能。 在早期階段燒掉大量資金並浪費工時來調整現有手機遊戲以使用 Vulkan，這對於許多開發商和發行商來說並不是一個選擇。

與舊硬件的兼容性可能是另一個令人擔憂的問題。 Vulkan 將需要 OpenGL ES 3.1 或 OpenGL 4.1 硬件以及新的驅動程序。 例如，Imagination Technologies 的 PowerVR series 6 GPU 可以支持它，但 series 5 不能。 高通的 Adreno 400 系列支持 OpenGL ES 3.1，但 300 系列不支持。 ARM 的 Mali T600 和 T700 系列支持 OpenGL ES 3.1，但較舊的 T400 系列設計缺乏支持。 幸運的是，當 Vulkan 變得相關時，大多數具有不受支持的 GPU 的設備都將被排除在外。 其中包括基於某些 5000 系列 Exynos 芯片的 iPhone 5/5C、第四代 iPad 和三星設備。 基於高通的設備可能沒有那麼幸運，因為 Adreno 300 系列 GPU 用於相對較新和多產的設計，例如 Snapdragon 410、Snapdragon 600、Snapdragon 800 和 801。但是，我懷疑它們中的大多數到時候都會消失Vulkan 變得真正相關。

長壽和渲染

現在說 Vulkan 是否會改變遊戲規則還為時過早，但我想你會同意它有很大的潛力。 我認為這將是一件大事，我的假設是基於 GPU 行業十年的經驗。 然而，這需要時間，而且我懷疑 Vulkan 在開始改變桌面環境之前會在移動設備中感受到它的存在。

幾乎在同一時間，經過 Vulkan 優化的驅動程序、遊戲引擎和遊戲，我們將獲得新的硬件來玩，我指的不僅僅是輕微的硬件調整。 移動 SoC 開發停滯不前的原因有很多，我現在不談，但 2016 年對於行業來說將是重要的一年，因為 14/16nm FinFET 節點可供更多製造商使用，並且對於主流硬件而不是在經濟上可行旗艦芯片。

開發人員將擁有更強大、更高效的硬件，而新的低開銷圖形 API 將是錦上添花。 我真誠地希望硬件供應商不要將顯示分辨率用作營銷噱頭，因為毫無意義的高分辨率對視覺質量沒有任何幫助，但仍然會浪費電力。 不幸的是，由於普通消費者不明白這一點，並且希望在盒子上看到更大的數字，我懷疑這不會很快發生。 我打算在我即將發布的一篇文章中研究這個奇怪的問題，所以如果你對此感到惱火，請繼續關注並隨時在評論部分發洩。