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

OpenGL ES

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

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

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

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

隱含同步

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

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

立即模式

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

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

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

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

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

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

Vulkan

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

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

管線

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