一月底的時候我在巴黎的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渲染引擎中繼續延續。