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

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

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

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

解決OpenGL的一些問題

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

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

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

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

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

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

Vulkan對于開發(fā)者來說究竟有多相關(guān)？

大多數(shù)獨立硬件供應(yīng)商同意提供一個由開發(fā)者控制內(nèi)存分配，狀態(tài)設(shè)置和調(diào)用驗證的API會提供更高的運行性能，同時使驅(qū)動的跨平臺操作更加的可預(yù)測，這也會降低維護花銷。

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

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

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

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

供應(yīng)商制定的代碼路徑是必需的嗎？

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

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

開發(fā)工具會影響Vulkan API的流行嗎？

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

OpenGL的開發(fā)是比較困難的?，F(xiàn)在有很多功能模塊正在被平臺開發(fā)者，獨立軟件供應(yīng)商，獨立硬件供應(yīng)商和社區(qū)所維護，但是這是經(jīng)歷了多年的發(fā)展才達到現(xiàn)在這個階段的。

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

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

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

這次座談會得出一個結(jié)論就是好的工具對于Vulkan的成功是非常有必要的?，F(xiàn)在有各種各樣的專用的和社區(qū)支持的工具可用，能夠讓開發(fā)者快速找到符合自己需求的調(diào)試流程。

Khronos Group也開發(fā)了一個高層次應(yīng)用摘要嗎？

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

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

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

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