Vulkan同步機(jī)制和圖形-計算-圖形轉(zhuǎn)換的風(fēng)險（二）

作者：Gerry Raptis

利用乒乓機(jī)制的交錯隊列減少風(fēng)險

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

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

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

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

這種方法會產(chǎn)生良好的結(jié)果，但會有損幀分離性，使維護(hù)更加困難。它對邏輯資源的需求將加倍，因為至少部分后期幀的操作代碼需要比早期幀操作先調(diào)度。此外，會引入一個額外的滯后幀。

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

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

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

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

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

每個任務(wù)使用不同隊列

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

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

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

更簡單、通用的方案：乒乓機(jī)制的交錯隊列

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

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

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

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

簡單來說：從同一隊列源中創(chuàng)建兩個相同的隊列，然后對于每個幀，您提交負(fù)載到與上一隊列不同的隊列上。隊列源很重要，因為它可以使您不必?fù)?dān)心資源隊列所有權(quán)等問題。
因此，幀提交過程如下：

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

...等等。

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

確實可行。B_N（當(dāng)前幀計算）和 C_N（當(dāng)前幀的后期圖形）之間的barrier將阻止 C_N在B_N完成之前啟動，但不會阻止 A_N+1（下一幀的早期圖形）啟動，因為它在與Barrier不同的隊列上提交（一個額外的好處，由于隊列不同，A_N+1與C_N不需要強(qiáng)制排序）。

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

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

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

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

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

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

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

其他的適用方案

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

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

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

注意事項：如何采用交錯隊列防止亂序

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

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

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

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

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

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

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

...等等。

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

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

重要性能說明

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

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

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

未來工作

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

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

這種情況可能工作如下：

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

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

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

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

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

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

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

結(jié)論

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

我們在 PowerVR SDK中的許多演示中都使用此技術(shù)，而且我們在編寫后處理演示時也受到了啟發(fā)，并使用了該技術(shù)。

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