一月底的時候我在巴黎的ISART Digital（視頻游戲和3D動畫學校）參加了一個座談討論會:“新一代圖形API座談會：關于早期的Vulkan”。這次會議是由來自Unity的Christophe Riccio組織和主持的，這次會議的主題是關于Khronos Group新一代圖形與計算API：Vulkan。

這次座談會的嘉賓有來自獨立軟件供應商（ISV）的,獨立硬件供應商（IHV）的,以及不同應用開發平臺人員，他們有非常豐富的經驗，從現代渲染算法到API實現以及驅動實現：

? Sébastien Lagarde (現任Unity渲染研究總監，以前曾任職于EA Frostbite)
? Julien Ignace (現任Unity R&D渲染程序員，以前曾任職于Quantic Dream)
? Jasper Bekkers (現任OTOY渲染工程師, 以前曾任職于EA Frostbite)
? Cyril Crassin (現任NVIDIA研究科學家)
? Jon Kennedy (現任Intel高級圖形軟件工程師)
? Adrian Bucur (現任Samsung SERI高級軟件工程師)

我們討論了多個話題，包括Vulkan最適合的開發模式；將Vulkan集成進現有的渲染引擎中有多難；調試工具對Vulkan的影響有多大。在這篇文章中總結了我認為最有意思的討論點和挑戰。

解決OpenGL的一些問題

用了將近兩年時間，Khronos的一個工作小組負責設計下一代圖形與計算API，致力于解決OpenGL最大的局限性問題，如下：

? 設計一個通用跨平臺的API（桌面，控制臺，移動和嵌入式平臺）
? 緊密貼合現代GPU架構
? 提供一個控制臺友好型，低開銷，顯示的API

專家組成員被問到是否可以從新設計一個API而不使用OpenGL的規范。OpenGL的一些先進性，例如AZDO和GL_KHR_no_error擴展，向我們證實到大量的API相關CPU開銷是有可能避免的。設計一個全新的OpenGL并側重于這些想法會給開發者帶來顯著的性能提升。

然而這個設計路線可能還是會有一些問題,例如：

? 緩存分配和同步的實現還是不夠透明，在某些平臺上卡死和緩存重影仍然會發生。
? 狀態仍然是全局的。開發者需要清晰的理解每個獨立硬件平臺的GPU狀態是如何設置的，以保證OpenGL的狀態能夠被有效的配置。
? 高效多線程命令提交仍然很難在OpenGL類似型API中解決。

經過討論后專家成員認為方向可能有些冒險，但是Vulkan API已經能夠滿足所有合理幀時間（time frame）的設計目標（盡管有一點點兒延遲）。

Vulkan對于開發者來說究竟有多相關？

大多數獨立硬件供應商同意提供一個由開發者控制內存分配，狀態設置和調用驗證的API會提供更高的運行性能，同時使驅動的跨平臺操作更加的可預測，這也會降低維護花銷。

獨立軟件供應商（ISV）卻有些懷疑。獨立硬件供應商花費了數年時間來優化他們的OpenGL,OpenGL ES和DirectX驅動。要想獲得同樣的或者更好的性能就會要求獨立軟件供應商投入大量的資源來設計和優化他們的引擎來兼容這個新的顯示API，例如高效的捕獲系統狀態。

除此之外，現有的中間件將需要繼續支持老版本的API很長一段時間。對現在來說，Vulkan將是另一個實現與支持的標準，這將會增加維護渲染引擎代碼的整體花銷。

正是影響引擎的各種限制因素創造了一個機遇，就是開發更加靈活的中間件。Oxide Games公司開發的Nitrous引擎被作為一個例子進行的討論，它已經能夠兼容這個圖形API的前沿技術。對于其他引擎要實現相同的性能還需要很長時間。

回到開始的問題這個API與誰最相關。各種引擎肯定會支持它，但是那些不得不支持老版本API的引擎進化得可能就比較慢了。那些最簡單調用的工程將會是最早受益。2D渲染引擎多用于桌面顯示，例如谷歌的Skia，將會支持這個API來降低功耗。這個API的低開銷特性可以讓開發者在短期內提升他們設計的系統性能，從而滿足設計要求。例如車內手寫導航系統對于CPU,GPU和內存限制非常嚴格。

供應商制定的代碼路徑是必需的嗎？

目前除了擴展功能（總是要求新的代碼路徑和回調）。不幸的是大多數使用OpenGL和OpenGL ES的跨平臺渲染引擎都要求各種各樣的代碼路徑以兼容供應商制定的驅動操作和bugs。專家組成員被問到這些偏差是否將會在Vulkan渲染引擎中繼續延續。

隨著獨立軟件供應商不斷接入到Vulkan API，很難說有多少代碼路徑。從理論上講，不斷降低的驅動復雜度會使各種操作變得更加透明，更少的bugs以及更少的因素去實現供應商制定的代碼路徑。然而專家組成員同意相比OpenGL在Vulkan中對硬件架構的理解和編程更加的重要，例如利用供應商制定的DMA隊列優化數據傳輸。

開發工具會影響Vulkan API的流行嗎？

獨立軟件供應商（ISV）贊同相比API自身因素，開發工具對于API的成功有更大的影響。例如開發者通常會首先采用Sony的平臺和API，因為它們擁有工業標準最好的工具（很多人這樣認為）。

OpenGL的開發是比較困難的。現在有很多功能模塊正在被平臺開發者，獨立軟件供應商，獨立硬件供應商和社區所維護，但是這是經歷了多年的發展才達到現在這個階段的。

隨著Vulkan的出現，Khronos Group將更多的思考放到工具上而不是以前的標準，例如加載層的設計讓開發者能夠使用Khronos組織提供的調試工具以及第三方提供的或者自定義的解決方案。不幸的是，類似OpenGL一樣Vulkan缺少很多調試操作的規范化實現方式，例如分析和復現調用操作。除非Khronos組織為工具開發組織一個團隊與API的開發同步進行，否則這種情況可能不會改變。

自Vulkan正式發布以來，我們看到已經有很多可用的工具，以及更多由Khronos推廣者，貢獻者和咨詢組織成員正在開發的工具。不同平臺例如谷歌和Valve將會為它們的操作系統提供跨供應商的工具。社區維護工具例如RenderDoc將會讓開發者實現跨各種操作系統和GPU的調試操作。

最后對于工具的討論，以為觀眾問到是否GPU的性能能夠通過Vulkan API暴露出來。不幸的是這個功能還沒有實現，但是未來這個問題可以通過擴展來解決。

這次座談會得出一個結論就是好的工具對于Vulkan的成功是非常有必要的。現在有各種各樣的專用的和社區支持的工具可用，能夠讓開發者快速找到符合自己需求的調試流程。

Khronos Group也開發了一個高層次應用摘要嗎？

在這個API的設計期間，這個組織就考慮開發一個幫助手冊讓開發者更容易入門Vulkan操作。經過一些考慮后，如果開發一個通用的使用摘要會花費太多的精力，耽誤Vulkan API的開發進度。

社區提供了各種庫，例如PowerVR框架，這讓開發者根據需要選擇各種通用和不同領域的庫。同時Khronos貢獻者也已經計劃開發這樣一個框架，專家組成員同意參考使用摘要會兼容Vulkan API 1.0正式版，同時不會影響Vulkan API的開發進度。

如果你想了解更多就來GDC2016吧

希望這篇文章讓大家對硬件與軟件供應商關心的問題和API的發展有一個了解。如果你想了解更多關于Vulkan的資訊，以及它是怎樣在我們的硬件上工作的。那就趕緊來GDC 2016現場吧（在鏈接下面評論或者來我們的論壇討論）。