作者：Gerry Raptis

利用乒乓機(jī)制的交錯(cuò)隊(duì)列減少風(fēng)險(xiǎn)

在本篇文章中，我們將提到Vulkan 圖形處理過程中夾雜計(jì)算任務(wù)時(shí)遇到的各式問題。為更準(zhǔn)確地了解我們的話題，可查看文章第一部分。

第一部分概述了在Vulkan中如何使用barrier;具體來說，涉及圖形→計(jì)算barrier，隨后是一個(gè)中間幀計(jì)算→圖形barrier。這會(huì)嚴(yán)重削弱GPU任務(wù)調(diào)度能力，并導(dǎo)致暫停，降低性能。為此我們給出了在多種資源配置情況下的不同解決方案。

體系架構(gòu)級(jí)方法

"算法"優(yōu)先的方法是手動(dòng)使任務(wù)交錯(cuò)：也就是說，以我們希望的順序提交任務(wù)，并使它們?cè)贕PU 上執(zhí)行。這會(huì)生成正確結(jié)果，也為我們提供足夠的可控性。在該情況下，首先為上一"邏輯"幀提交計(jì)算任務(wù)B_N-1（注意缺少早期圖形任務(wù)），然后提交當(dāng)前幀A_N的早期圖形任務(wù)。隨后，將提交計(jì)算/圖形Barrier，接下來提交上一幀C_N-1的后期圖形任務(wù)，最后提交圖形/計(jì)算Barrier。

這種方法會(huì)產(chǎn)生良好的結(jié)果，但會(huì)有損幀分離性，使維護(hù)更加困難。它對(duì)邏輯資源的需求將加倍，因?yàn)橹辽俨糠趾笃趲牟僮鞔a需要比早期幀操作先調(diào)度。此外，會(huì)引入一個(gè)額外的滯后幀。

其執(zhí)行過程如下：

幀N: B_N-1→A_N→ 計(jì)算/圖形barrier → C_N-1 → 圖形/計(jì)算barrier→提交N-1

幀N+1: B_N→ A_N+1→ 計(jì)算/圖形barrier → C_N → 圖形/計(jì)算barrier→提交N

這將允許B_N-1/A_N重疊。

聽起來很復(fù)雜，而且也確實(shí)如此：計(jì)算多個(gè)幀操作通常需要大量的記錄。但是，如果在此方案中任務(wù)封裝的不錯(cuò)，至少一定程度上會(huì)緩解該問題。但是，如果復(fù)雜性更高時(shí)（即更復(fù)雜的猜測(cè)計(jì)算→barrier→圖形→barrier→計(jì)算→barrier→圖形工作負(fù)載），它仍然可能崩潰。在任何情況下，為降低不斷增加的CPU 端復(fù)雜性成本，可以定制解決方案。

每個(gè)任務(wù)使用不同隊(duì)列

另一個(gè)有效的解決方案是使用不同的隊(duì)列，并在每個(gè)隊(duì)列提交幀的不同部分：每個(gè)早期計(jì)算、后期計(jì)算、早期圖形和后期圖形提交到自己的隊(duì)列，任務(wù)間連接使用信號(hào)量而非barrier。例如 ，PowerVR開發(fā)套件中的Vulkan粒子系統(tǒng)就是采用該方法，在對(duì)應(yīng)的專用隊(duì)列中提交所有計(jì)算。

但在我看來，該方案有其挑戰(zhàn)性，它比交錯(cuò)幀更好，因?yàn)樗试S GPU 處理自己的問題，而不會(huì)弄亂引擎的非 API 部分。在我看來，它也是第一個(gè)"真正的"解決方案。類似于上述方案，它至少會(huì)緩解部分問題。在討論其自身體系結(jié)構(gòu)上的計(jì)算后處理時(shí)，Arm 在其社區(qū)網(wǎng)站上也將目光投向該方案。但是，它又取決于某些特定任務(wù)的重疊，一般來說，需要仔細(xì)生成大量的信號(hào)量，并且借助于隊(duì)列優(yōu)先級(jí)，這些增加了部分復(fù)雜性，但也為您提供了另一個(gè)控制向量。在多個(gè)交錯(cuò)計(jì)算/圖形任務(wù)的情況下，它也可能不能完全按照我們預(yù)期的方式工作。該方案非常有效，可能將其與別的方案結(jié)合是個(gè)好思路。

我們已經(jīng)找到了值得推薦的不同方案。

更簡(jiǎn)單、通用的方案：乒乓機(jī)制的交錯(cuò)隊(duì)列

我們相信我們可以更簡(jiǎn)單、更有效的方式來完成計(jì)算。為此，我們需要從全局上考慮我們的最終目標(biāo)：我們需要在沒有Vulkan 規(guī)范介入的前提下，使 GPU 能夠在連續(xù)兩個(gè)幀中交替工作。

Vulkan 規(guī)范團(tuán)隊(duì)中的精明者可能已經(jīng)意識(shí)到，barrier是始終指向單個(gè)隊(duì)列的構(gòu)造器。

PowerVR（和許多其它設(shè)備）設(shè)備可能會(huì)暴露多個(gè)相同/可互換的通用隊(duì)列（圖形+計(jì)算以及可能的呈現(xiàn)）。

因此，在這種情況下，為在不重新調(diào)整幀前提下避免跨幀同步，我們可以在不同隊(duì)列中為每個(gè)幀提交負(fù)載。這將允許一個(gè)幀中的任何負(fù)載與下一幀中的任何負(fù)載交錯(cuò)執(zhí)行，即使具有多個(gè)不同的圖形、頂點(diǎn)和計(jì)算任務(wù)，因?yàn)樗鼈冊(cè)诓煌?duì)列上顯式執(zhí)行，可以不受制于彼此的barrier。

簡(jiǎn)單來說：從同一隊(duì)列源中創(chuàng)建兩個(gè)相同的隊(duì)列，然后對(duì)于每個(gè)幀，您提交負(fù)載到與上一隊(duì)列不同的隊(duì)列上。隊(duì)列源很重要，因?yàn)樗梢允鼓槐負(fù)?dān)心資源隊(duì)列所有權(quán)等問題。
因此，幀提交過程如下：

幀 0：獲取下一個(gè)圖像→ 渲染 0(A₀)→ 圖形/計(jì)算barrier→ 計(jì)算0(B₀)→計(jì)算/圖形barrier→渲染0′(C₀)→提交到隊(duì)列0 →呈現(xiàn)到隊(duì)列 0
幀 1：獲取下一個(gè)圖像→ 渲染 1A₁→ 圖形/計(jì)算barrier→ 計(jì)算1B₁→計(jì)算/圖形barrier→渲染1′C₁→提交到隊(duì)列1→呈現(xiàn)到隊(duì)列1
幀 2：獲取下一個(gè)圖像→ 渲染2 A₂→ 圖形/計(jì)算barrier→ 計(jì)算2B₂→計(jì)算/圖形barrier→渲染2′C₂→提交到隊(duì)列0 →呈現(xiàn)到隊(duì)列 0
幀 3：獲取下一個(gè)圖像→ 渲染 3A₃→ 圖形/計(jì)算barrier→ 計(jì)算3B₃→計(jì)算/圖形barrier→渲染3′C₃→提交到隊(duì)列1→呈現(xiàn)到隊(duì)列1

...等等。

那么，這行得通嗎？而且，如果可以，其原因是什么？

確實(shí)可行。B_N（當(dāng)前幀計(jì)算）和 C_N（當(dāng)前幀的后期圖形）之間的barrier將阻止 C_N在B_N完成之前啟動(dòng)，但不會(huì)阻止 A_N+1（下一幀的早期圖形）啟動(dòng)，因?yàn)樗谂cBarrier不同的隊(duì)列上提交（一個(gè)額外的好處，由于隊(duì)列不同，A_N+1與C_N不需要強(qiáng)制排序）。

此技術(shù)解決了問題的核心：應(yīng)用程序設(shè)置的barrier，旨在在單個(gè)幀中等待風(fēng)險(xiǎn)的發(fā)生，不會(huì)導(dǎo)致后續(xù)幀之間的任務(wù)間等待。我發(fā)現(xiàn)它相當(dāng)令人欣喜，而且是迄今為止最簡(jiǎn)單的可實(shí)現(xiàn)方案——只要您的通用隊(duì)列源中有多個(gè)隊(duì)列，就可以使用單個(gè)計(jì)數(shù)器（甚至是布爾類型）并交換每一幀，此時(shí)無需進(jìn)一步修改：只要我們確保 CPU 資源得到正確管理（與單個(gè)隊(duì)列相同），不須施加額外同步。

簡(jiǎn)而言之，由于每個(gè)連續(xù)幀都在不同的隊(duì)列中提交，因此 GPU 可以自由地在幀之間并行調(diào)度任務(wù)，預(yù)期結(jié)果為 （C_N+1） 在（A_N） 完成之后開始執(zhí)行。它可確保渲染器及其相應(yīng)的調(diào)度程序始終繁忙，并且中間的計(jì)算不會(huì)串行化幀。

—————–
計(jì)算工作負(fù)載：B0B1 B2B3 B4B5
圖形工作負(fù)載：A0 A1 C0 C1 A2 A3 C2 C3 A4 A5 C4 C5 ...

或（基本相同的效果）如下：

計(jì)算工作負(fù)載：B0 B1 B2 B3 B4 B5
圖形工作負(fù)載：A0 A1 C0 A2 C1 A3 C2 A4 C3 A5 C4 C5 ...

乍一看，這看起來可能很復(fù)雜，但實(shí)際很簡(jiǎn)單。無論如何，該圖示告訴我們，GPU 正在處理一個(gè)幀（N）的計(jì)算，同時(shí)處理下一幀 （N+1） 的早期圖形或上一幀的后期圖形。

完全封裝的情況是"相當(dāng)不可能"，它甚至沒有必要達(dá)到這種水平的封裝。但是，您應(yīng)具備類似的特征，計(jì)算與頂點(diǎn)/片段任務(wù)一起調(diào)度，允許USC 加載使用盡可能多的容量。

其他的適用方案

通常，在任何存在barrier的情況下（而不僅僅是圖形/計(jì)算/圖形）時(shí)使用此技術(shù)是一個(gè)好思路。在任何情況下，它都不會(huì)有損性能，并且在--任何情況下調(diào)度器都具備更好的靈活性。調(diào)度器可能不需要額外的靈活性，但在任何情況下它都不會(huì)有損性能，而且增加的復(fù)雜性微不足道。

任何類型的barrier（包括圖形/圖形）都有可能損害 GPU 調(diào)度不同幀負(fù)載的能力并會(huì)導(dǎo)致暫停（順便說一下，這是考慮使用barrier一個(gè)非常重要的原因，如果不考慮該因素，可以使用子類依賴性而非barrier）。計(jì)算示例非常重要，因?yàn)榧词顾鼈児蚕?PowerVR 上的執(zhí)行內(nèi)核、圖形和計(jì)算部件，它們也在不同的數(shù)據(jù)主設(shè)備上工作，因此始終有些任務(wù)要并行執(zhí)行，因此，如果可能，我們總是希望它們盡量重疊工作。但是，即使只是不同幀的圖形負(fù)載交錯(cuò)執(zhí)行，也通常允許您在頂點(diǎn)和片段任務(wù)之間獲得更多的重疊，并確保 GPU 更好的飽和性。

因此，任何barrier情況都存在潛在風(fēng)險(xiǎn)，所以使用多個(gè)隊(duì)列是備選。

注意事項(xiàng)：如何采用交錯(cuò)隊(duì)列防止亂序

我們未能發(fā)現(xiàn)任何嚴(yán)重的不利條件。在不同幀之間使用不同的隊(duì)列沒有額外開銷。我們確定的唯一限制很明顯：同一隊(duì)列源必須支持多個(gè)圖形計(jì)算隊(duì)列，不過，所有 PowerVR 設(shè)備都支持該特性。

我們能夠識(shí)別的另一潛在問題是確保正確的呈現(xiàn)順序。但是，交換鏈對(duì)象本身將確保這一點(diǎn)，因?yàn)閳D像以 FIFO 和郵箱呈現(xiàn)模式調(diào)用的 vkQueuePresent 順序呈現(xiàn)。對(duì)于其它模式（例如即時(shí)），您可能需要確保當(dāng)前操作正確同步，以便按順序執(zhí)行；這也相當(dāng)容易實(shí)現(xiàn)。

最后，如果設(shè)備強(qiáng)制采用單個(gè)呈現(xiàn)隊(duì)列，您可以修改如下，最終只在單個(gè)隊(duì)列上呈現(xiàn)：

幀 0：獲取下一個(gè)圖像→ 渲染 0→ 記錄圖形/計(jì)算barrier→ 計(jì)算0 →計(jì)算/圖形barrier→渲染0′→提交到隊(duì)列0 →呈現(xiàn)到隊(duì)列 0

幀 1：獲取下一個(gè)圖像→ 渲染 1→ 記錄圖形/計(jì)算barrier→ 計(jì)算1→計(jì)算/圖形barrier→渲染1′→提交到隊(duì)列1 →呈現(xiàn)到隊(duì)列0

幀 2：獲取下一個(gè)圖像→ 渲染2→ 記錄圖形/計(jì)算barrier→ 計(jì)算2→計(jì)算/圖形barrier→渲染2′→提交到隊(duì)列0 →呈現(xiàn)到隊(duì)列 0

幀 3：獲取下一個(gè)圖像→ 渲染 3→ 記錄圖形/計(jì)算barrier→ 計(jì)算3→計(jì)算/圖形barrier→渲染3′→提交到隊(duì)列1 →呈現(xiàn)到隊(duì)列0

...等等。

它不僅利用了并行性，還確保了具有交換鏈"特殊"實(shí)現(xiàn)的驅(qū)動(dòng)程序不會(huì)出現(xiàn)亂序幀呈現(xiàn)的風(fēng)險(xiǎn)。

簡(jiǎn)言之，我們完全可以放心的使用該技術(shù)。如果你發(fā)現(xiàn)了潛在的問題，請(qǐng)告訴我們。

重要性能說明

需要提醒的是，PowerVR 調(diào)度時(shí)與 CPU 線程調(diào)度工作方式不同，因?yàn)楹笳咝枰嘿F的上下文切換并保存到主存——如果調(diào)度器在同一 USC 上并行執(zhí)行兩個(gè)任務(wù)，在大多數(shù)情況下，它們之間切換成本為零，因此每當(dāng)需要等待操作時(shí)（例如內(nèi)存訪問），調(diào)度器都可以切換到另一個(gè)任務(wù)并隱藏內(nèi)存操作延遲。這是我們性能得以提升的重要部分。

下面是我們需要澄清的：該技術(shù)主要不是填充可能出現(xiàn)空閑的不同硬件部分負(fù)載，我們?cè)噲D做的是指導(dǎo)驅(qū)動(dòng)程序正確調(diào)度負(fù)載，減少開銷并隱藏延遲。PowerVR 是一個(gè)統(tǒng)一的體系結(jié)構(gòu)，頂點(diǎn)、圖形和計(jì)算任務(wù)都在同一個(gè) USC 上執(zhí)行。與在不同頂點(diǎn)和片段著色器內(nèi)核單獨(dú)執(zhí)行的早期圖形設(shè)備不同，100%性能提升是無法實(shí)現(xiàn)的。我們不是要填充空閑內(nèi)核;只是要 GPU非空閑時(shí)， 所有USC 都在運(yùn)行（不排除一些意外狀況發(fā)生）。

最后，在僅有圖形的負(fù)載中，還可能會(huì)遇到這樣的情況，barrier會(huì)阻止不同幀之間的重疊。

未來工作

當(dāng)您希望將不同的任務(wù)提交到不同的隊(duì)列類型/源情況下，此技術(shù)可以而且將起作用。一個(gè)重要的免責(zé)聲明是，該技術(shù)不會(huì)取代幀的不同負(fù)載使用不同隊(duì)列的潛在好處——如本文及其他文章中所討論到的，使用不同的專用隊(duì)列（特別是使用不同的隊(duì)列優(yōu)先級(jí)來最小化幀延遲）。

因此，在這些情況下，可以使用相同的邏輯——唯一的區(qū)別是，您不會(huì)將一個(gè)隊(duì)列分裂為兩個(gè)隊(duì)列，而是將所有（或大多數(shù)）使用barrier的隊(duì)列復(fù)用。這可能并非所有隊(duì)列，因此不能替代常識(shí)和良好設(shè)計(jì)。在某些體系結(jié)構(gòu)中，您可能使用三個(gè)不同的隊(duì)列，并且只需要將其中一個(gè)或者多個(gè)中的兩個(gè)隊(duì)列復(fù)用并進(jìn)行乒乓操作。最重要的是在barrier旁邊至少增加一個(gè)隊(duì)列。
例如，假設(shè)一個(gè)專用計(jì)算隊(duì)列與多個(gè)通用隊(duì)列并存，此技術(shù)可能仍然有用。事實(shí)上，在多數(shù)的有趣場(chǎng)景下，擁有多組具有不同優(yōu)先級(jí)的不同隊(duì)列并且?guī)g交換集，這可以提供驚人的精細(xì)控制和靈活性。

這種情況可能工作如下：

（此處的隊(duì)列 C2 是一個(gè)專用計(jì)算隊(duì)列，隊(duì)列 0 和隊(duì)列 1 是我們要復(fù)用的通用隊(duì)列）：

幀 0：獲取下一個(gè)圖像→ 渲染 0 → 提交到隊(duì)列 0 → 信號(hào)量給隊(duì)列 2 → 計(jì)算 0，提交到隊(duì)列 C2→ 信號(hào)量給隊(duì)列 0 → 渲染0′→ 提交到隊(duì)列 0→ 呈現(xiàn)給隊(duì)列 0

幀1：獲取下一個(gè)圖像→ 渲染1→ 提交到隊(duì)列 1→ 信號(hào)量給隊(duì)列 2→ 計(jì)算 1，提交到隊(duì)列 C2→ 信號(hào)量給隊(duì)列 1→ 渲染1′→ 提交到隊(duì)列 1→ 呈現(xiàn)給隊(duì)列 1

幀2：獲取下一個(gè)圖像→ 渲染2→ 提交到隊(duì)列 0 → 信號(hào)量給隊(duì)列 2 → 計(jì)算 2，提交到隊(duì)列 C2→ 信號(hào)量給隊(duì)列 0 → 渲染2′→ 提交到隊(duì)列 0→ 呈現(xiàn)給隊(duì)列 0

幀 3：獲取下一個(gè)圖像→ 渲染3→ 提交到隊(duì)列1→ 信號(hào)量給隊(duì)列 2 → 計(jì)算 3，提交到隊(duì)列 C2→ 信號(hào)量給隊(duì)列 1→ 渲染3′→ 提交到隊(duì)列 1→ 呈現(xiàn)給隊(duì)列 1

幀 4：獲取下一個(gè)圖像→ 渲染4→ 提交到隊(duì)列 0 → 信號(hào)量給隊(duì)列 2 → 計(jì)算 4，提交到隊(duì)列 C2→ 信號(hào)量給隊(duì)列 0 → 渲染4′→ 提交到隊(duì)列 0→ 呈現(xiàn)給隊(duì)列 0

同樣，此處的多個(gè)圖形隊(duì)列是必要的，以允許在當(dāng)前幀的第二次渲染之前調(diào)度連續(xù)幀的第一次渲染。

結(jié)論

我們向您展現(xiàn)了一個(gè)非常完整和通用的解決方案，用以解決常見但現(xiàn)實(shí)的難題。無論何時(shí)，盡可能為每幀使用多個(gè)隊(duì)列，您可以無風(fēng)險(xiǎn)、更簡(jiǎn)單地獲得驚人的性能提升。希望這將對(duì)您的項(xiàng)目有幫助！如果該技術(shù)確實(shí)幫助到您，歡迎向我們分享您的故事。

我們?cè)?PowerVR SDK中的許多演示中都使用此技術(shù)，而且我們?cè)诰帉懞筇幚硌菔緯r(shí)也受到了啟發(fā)，并使用了該技術(shù)。

英文鏈接：https://www.imgtec.com/blog/vulkan-synchronisation-and-graphics-compute-...