本文是該系列的最后一篇文章。該系列文章在我的網(wǎng)頁上已載有數(shù)月，由于Vulkan產(chǎn)品的發(fā)布占用了我很多時間，最后收官之作的發(fā)表可能有些晚，希望大家還能關(guān)注它。本文中，我將闡述為何Vulkan比上一代API更適合硬件，同時，我還將深入PowerVR GPU的一些細(xì)節(jié)，并援引具體案例。

OpenGL ES

首先，讓我們看看當(dāng)下行業(yè)領(lǐng)先的API及其問題存在的原因。距OpenGL ES的發(fā)行已有12年多，而API是基于OpenGL ES的產(chǎn)品。OpenGL早在23年前便已設(shè)計問世，其最初設(shè)計的硬件與當(dāng)下使用的各式硬件大為不同。

狀態(tài)機(jī)

OpenGL是一款大型的全球狀態(tài)機(jī)，每次操作均需要考慮當(dāng)前狀態(tài)的各個部分，如混合模式、當(dāng)前的著色器、深度測試信息等。所有的事情看似一個簡單的制動開關(guān)或杠桿，可以不計實際的后果隨意改變開關(guān)狀態(tài)——它只是一個函數(shù)調(diào)用？對于現(xiàn)代硬件而言這是不切實際的——例如很多狀態(tài)會被轉(zhuǎn)化為著色代碼。

在移動產(chǎn)品的高效性一文中，我已經(jīng)提到，考慮到掛接及渲染期間CPU的使用率，著色器修復(fù)是不確定的。還有另一個我之前未提及的問題——著色器本身的低效率。如果必須修復(fù)著色器狀態(tài)，則會出現(xiàn)優(yōu)化后編譯，即附加至剩余的著色器中是有效的。如果在編譯時狀態(tài)已知，則可以一直優(yōu)化編譯，以避免出現(xiàn)幾條指令。為解決此問題，驅(qū)動器可能會進(jìn)行背景的重新編譯，但這本身也是一個問題(消耗更多的CPU時間)。

隱含同步

OpenGL ES假設(shè)很多東西是相互隱含同步的。只有引入柵欄時，計算著色器及其不良反應(yīng)才被認(rèn)為是任何形式的異步工作。大部分API僅僅只是工作——事實上這可以歸結(jié)為資源跟蹤、緩存刷新和場景后的依賴關(guān)系鏈建設(shè)。

驅(qū)動器不可能非常準(zhǔn)確地檢測依賴項——它們十分保守，以能實現(xiàn)OpenGL ES功能。這意味著將不可避免地進(jìn)行一些不必要的緩存刷新或不必要的序列化工作——換言之，硬件需要做更多的工作。

立即模式

自始至終，OpenGL ES中指定的命令應(yīng)該嚴(yán)格按照規(guī)定的先后順序來執(zhí)行。一個簡單的命令如繪制調(diào)用通常被當(dāng)作一個單一的整體工作單元，其在GPU中有規(guī)定的隊列順序。這種行為即立即執(zhí)行模式——每個指定的工作以某種方式被即刻發(fā)送至GPU進(jìn)行處理。

在過去，立即渲染模式(IMR)架構(gòu)可以很好地映射到這種思維方式中，但現(xiàn)代IMR傾向于批量處理工作以提高性能。

基于區(qū)塊貼圖的渲染 (TBR)或基于區(qū)塊貼圖的延遲渲染 (TBDR)從未以這種方式工作。迄今為止存在的最多產(chǎn)的類型是GPU架構(gòu)類型：這些架構(gòu)類型的主要工作單元非常大——渲染通道便是很好的詮釋——所有的繪制調(diào)用都集中在相同的幀緩沖區(qū)中。

TBR和TBDR都有兩級渲染，早期階段主要處理幾何圖形及在屏幕空間貼圖中進(jìn)行分類排序。第二階段則將貼圖柵格化，使整個貼圖完全保存在片上幀緩沖區(qū)中——這可節(jié)省大量的帶寬，其在移動市場占據(jù)優(yōu)勢。Rys Sommefeldt做了更詳細(xì)的闡述，感興趣的可以查閱他的文章。

關(guān)鍵在于，在光柵化階段，繪制調(diào)用是無意義的——一個單一的繪制調(diào)用可能產(chǎn)生多個貼圖的光柵化，每個貼圖包含了多個繪制調(diào)用的工作。如果某些信息引起繪圖之間的沖刷，則整個渲染就會分裂，這就需要對很多貼圖進(jìn)行再次渲染。在貼圖開始和結(jié)束時，必須加載幀緩沖區(qū)數(shù)據(jù)到貼圖中，并隨后進(jìn)行存儲——這樣重復(fù)多次后便失去了基于區(qū)塊貼圖架構(gòu)的優(yōu)勢，而架構(gòu)本身是極力避免消耗此類帶寬的。

總之，現(xiàn)代硬件傾向于批量處理工作，且提交單個繪制調(diào)用會降低效率。在OpenGL ES中有很多操作迫使驅(qū)動器提交單個繪制調(diào)用，這一點(diǎn)大家有目共睹。在TBR或TBDR中，這會產(chǎn)生很多不必要的且驅(qū)動器無力應(yīng)對的帶寬。

Vulkan

我可能呈現(xiàn)給大家的OpenGL ES是比較沉悶的形象，但不要灰心，不然當(dāng)今的移動世界便不會有如此多精彩的圖像內(nèi)容。

Vulkan甚至比一個高度優(yōu)化的OpenGL ES驅(qū)動器做的更好。我以前提過，Vulkan是顯式的，且需要在應(yīng)用程序中獲取大量的信息——所有這些都是確保Vulkan可以流暢地工作，且不會產(chǎn)生很多用戶不可見的成本。

管線

Vulkan假定所有的狀態(tài)都將被再次啟用，因此其比OpenGL ES看起來更為靜態(tài)。管線多采用先前的動態(tài)狀態(tài)，并與著色器一起被編譯。這意味著任何先前需要著色器修復(fù)的信息現(xiàn)在可以提前被編譯。在編譯時擁有這些信息意味著可以對繪制調(diào)用即刻使用的著色器和狀態(tài)進(jìn)行完整的編譯和優(yōu)化，且不需要在渲染循環(huán)中將這些信息進(jìn)行打包處理。