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

這次座談會(huì)的嘉賓有來自獨(dú)立軟件供應(yīng)商（ISV）的,獨(dú)立硬件供應(yīng)商（IHV）的,以及不同應(yīng)用開發(fā)平臺(tái)人員，他們有非常豐富的經(jīng)驗(yàn)，從現(xiàn)代渲染算法到API實(shí)現(xiàn)以及驅(qū)動(dòng)實(shí)現(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高級(jí)圖形軟件工程師)
? Adrian Bucur (現(xiàn)任Samsung SERI高級(jí)軟件工程師)

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

解決OpenGL的一些問題

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

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

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

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

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

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

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

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

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

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

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

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

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

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