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

OpenGL ES

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

狀態機

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

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

隱含同步

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

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

立即模式

自始至終，OpenGL ES中指定的命令應該嚴格按照規定的先后順序來執行。一個簡單的命令如繪制調用通常被當作一個單一的整體工作單元，其在GPU中有規定的隊列順序。這種行為即立即執行模式——每個指定的工作以某種方式被即刻發送至GPU進行處理。

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

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

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

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

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

Vulkan

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

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

管線

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