很多許多情況下，一個應用程序可能僅使用一個著色器及一組或兩組狀態——保持低成本。然而某些情況下，需要設置很多不同的狀態，因此會產生大量的管線對象。Vulkan沒有降低管線對象數量，同時，通過使用管線緩存編譯整個著色器組所花費的時間應該具有可比性(或更快)。創建一組管線時，管線緩存是可以與創建信息一起被傳輸的對象，且緩存的是有用信息或管線所需的編譯狀態和著色器。如果兩個管線具有相同的著色器，但狀態略有不同，那么創建和編譯的成本將遠低于單獨編譯的成本。

PowerVR GPU的管線

以混合狀態為例——眾所周知，我們沒有用于混合的固定功能硬件。通常不太需要此類硬件——片上存儲非常快，直接在著色器內核中混合會更加簡單。隨后，在OpenGL ES中設置混合模式會產生一組指令，其表示在當前著色結束時進行混合修復。

正如我之前所說，著色器修復可能引起效率降低。而著色器分析顯示，混合修復則情況不會太糟，其通常只有一個或兩個指令。這看似不切實際，不然今天我們就得重新審視我們的方案，但其確實合乎情理。Vulkan在創建管線時就給了全方位的信息，使我們在編譯之前就可以折疊這些指令，精簡著色器的處理工作。其他狀態如幀緩沖區格式和頂點布局可分為相似的類型(更瑣碎和不常見的狀態)。

顯示同步

相比其他圖形API，該API的各操作之間有更多的同步控制。主要用“what”、“when”、“where”和“how”信息來描述內存和執行依賴關系。

?依賴關系中涉及的對象和操作是什么？
?依賴關系何時開始何時結束？
?依賴關系在管線的哪個位置生成(如頂點著色)以及其必須在哪個位置實現(如片段著色)？
?相互依賴的雙方如何使用圖像？

所有這些信息可以使驅動器建立一個全面的依賴關系鏈，且如果應用程序可準確表示依賴關系，那么便可以僅僅等待需要絕對刷新的緩存和絕對完成的操作。

PowerVR GPU的顯示同步

在基于區塊貼圖的架構中，工作分為了兩個部分——幾何貼圖階段和光柵化階段。在OpenGL ES中，只有任務相當繁重的手控同步——柵格、隱式同步和內存屏障。光柵化階段無需等待，或者說只有在貼圖階段才需要等待——驅動器通過啟發式算法來實現等待或者完整的同步事件才需要等待——這將嚴重影響性能。通常，我們在OpenGL ES中使用大量的啟發式算法來完成這項工作，但付出的代價是這樣往往過于保守，導致性能大為降低。

在Vulkan中，可以使用為每個同步事件描述的管線級數來決定執行哪個硬件階段。如果在事件早期片段階段需要等待，則可以執行貼圖階段來提前獲取繪制調用，以求得先機，并在處理過程中提升性能。同樣，如果貼圖階段的任務需要等待，則表明在光柵化之前便已經開始執行任務。這兩種情況都會導致任務之間的延遲時間縮短，并通過允許多個任務的重疊減少在GPU上不必要的空閑時間。

命令緩沖區和硬件隊列

Vulkan使用延期命令提交模型——將繪制調用記錄成許多命令緩沖區，隨后應用程序將這些緩沖區作為獨立的操作提交至硬件中。這樣便可以提前了解場景大部分的信息，并適合地優化提交內容，而這些曾經在OpenGL中是很難實現的。

單獨的硬件隊列可以很好地映射到現代GPU中——其通常有一個或多個前端輸入隊列用來處理命令輸入。準確地曝光這些隊列可以給應用程序展示一個底層硬件視圖，而這個視圖本是不存在的。例如，如果GPU有一個用于圖形命令的前端——應該在API中僅曝光一個圖形隊列。隊列提交是外部同步的，所以驅動器在處理多個線程時不需要持有鎖，且由于有一個緊密的映射到硬件中，隊列提交是一個相對低成本的操作。

PowerVR GPU的命令緩沖區和硬件隊列

PowerVR以不同的順序運行，這可能原本是對即時光柵化程序的預期，正如上所述。為獲得所需的硬件效率，以一個特定的方式排列操作至關重要(而不是即刻提交頂點和光柵任務)。在Vulkan中，應用程序提前在命令緩沖區記錄中明確布局了所有的依賴關系。記錄命令緩沖區時，可確定最有效的操作序列并恰當地提交工作任務——OpenGL中的工作任務必須動態完成。正如之前所述，繪制調用的命令緩沖區可以用于貼圖任務和光柵化任務，并被硬件直接消耗。