作者：Don Burns，2001
譯者：王銳，2008

新的設(shè)想

場(chǎng)景圖形的主要目的是改善場(chǎng)景優(yōu)化，渲染狀態(tài)排序和各種其它操作的性能，降低圖形渲染引擎的負(fù)荷，并實(shí)現(xiàn)復(fù)雜場(chǎng)景的“實(shí)時(shí)”渲染。實(shí)時(shí)渲染的目標(biāo)是以足夠高的幀速（符合人眼的交互要求）渲染場(chǎng)景。飛行模擬程序通過(guò)窗口輸出（out-the-window）的圖像生成頻率要求為60Hz或者更高，這樣顯示的內(nèi)容才不會(huì)發(fā)生異常。而30Hz，20Hz或者15Hz的頻率則是“可交互”的，即，視口可以交由用戶進(jìn)行操控，并在合適的時(shí)間響應(yīng)用戶的輸入。基于這些目標(biāo)，我們需要參照幀速60Hz的仿真要求實(shí)現(xiàn)我們的設(shè)計(jì)。我們假定幀速率恒定，且圖形子系統(tǒng)針對(duì)垂直消隱時(shí)間（vertical blanking time，即電子槍掃描完一幀之后返回原點(diǎn)的時(shí)間）與渲染交換緩沖區(qū)（rendering buffer swap）執(zhí)行同步的能力恒定。此外，我們還假定多顯示的系統(tǒng)已經(jīng)實(shí)現(xiàn)了同步鎖相（genlock），至少實(shí)現(xiàn)了幀鎖相（frame lock，借助硬件使每個(gè)顯示屏上的幀實(shí)現(xiàn)同步），這樣就可以實(shí)現(xiàn)垂直回描邊界（vertical retrace boundary，即電子槍掃描完一幀之后返回的邊界）在所有圖形子系統(tǒng)上的同步。

多任務(wù)，多顯示，單系統(tǒng)繪圖的傳統(tǒng)方法

使用場(chǎng)景圖形實(shí)現(xiàn)實(shí)時(shí)渲染的“傳統(tǒng)”方法是實(shí)現(xiàn)多個(gè)階段，即：APP（用戶階段），CULL（揀選階段），DRAW（繪制階段）。APP階段用于更新所有的動(dòng)態(tài)用戶數(shù)據(jù)，包括相機(jī)的位置，以及運(yùn)動(dòng)對(duì)象的位置和屬性變化。CULL必須跟隨在APP之后，這一階段中，首先參照視口錐截體（viewing frustum）中的可見對(duì)象，其次參照用于渲染性能的渲染狀態(tài)，對(duì)場(chǎng)景進(jìn)行排序。CULL階段更新攝像機(jī)位置的依賴數(shù)據(jù)，并為其后的DRAW階段構(gòu)建一個(gè)“顯示列表”（display list）。DRAW階段僅僅是遍歷整個(gè)顯示列表，并執(zhí)行OpenGL的各種調(diào)用，將數(shù)據(jù)傳遞給圖形子系統(tǒng)進(jìn)行處理。

在一個(gè)具備多個(gè)圖形子系統(tǒng)的系統(tǒng)中，有必要為每個(gè)圖形子系統(tǒng)設(shè)置CULL和DRAW 階段，因?yàn)樵诩俣ǜ鱾€(gè)視口錐截體均不同的前提下，只有CULL階段能夠?yàn)槊總€(gè)子系統(tǒng)構(gòu)建唯一的“顯示列表”。而APP階段則不必設(shè)置多個(gè)，因?yàn)槊總€(gè)視口均會(huì)共享同一個(gè)APP階段更新的動(dòng)態(tài)數(shù)據(jù)。

鑒于此，一個(gè)具備多圖形子系統(tǒng)的系統(tǒng)，要實(shí)現(xiàn)多任務(wù)的機(jī)制，則需要定義過(guò)程如下：一個(gè)單處理器的系統(tǒng)需要順序地執(zhí)行各個(gè)階段（例如，APP，CULL_0，DRAW_0，CULL_1，DRAW_1，CULL_2，DRAW_2），而一幀的時(shí)間也就相當(dāng)于這些階段耗費(fèi)的總時(shí)間。因此，我們需要實(shí)現(xiàn)的任務(wù)主要有兩個(gè)：（1）唯一的APP任務(wù)，（2）每個(gè)圖形子系統(tǒng)各自的CULL/DRAW任務(wù)。

在多處理器系統(tǒng)中，如果處理器樹木足夠多的話，那么每一個(gè)任務(wù)都可以在某一個(gè)處理器上并行地執(zhí)行。此外，CULL/DRAW任務(wù)也可以分離為兩個(gè)任務(wù)并行地運(yùn)行。

并行多處理器環(huán)境的模型實(shí)現(xiàn)主要有兩個(gè)目標(biāo)。（1）分離并行化（Task Division Parallelization）：將一個(gè)大型的任務(wù)分解成多個(gè)可以并行運(yùn)行的小型任務(wù)，以削減運(yùn)行時(shí)間；（2）集成并行化（Task Aggregation Parallelization）：將一個(gè)任務(wù)N次倍乘后，并行地運(yùn)行它的每個(gè)實(shí)例，而不增加運(yùn)行時(shí)間。將CULL/DRAW階段從APP階段分離出來(lái)，然后將CULL和DRAW分離成獨(dú)立并行的任務(wù)，這是一個(gè)“分離并行化”的例子。將多個(gè)CULL/DRAW組合的任務(wù)添加給各個(gè)圖形子系統(tǒng)，這是一個(gè)“集成并行化”的例子。

并行地運(yùn)行各個(gè)階段可能會(huì)帶來(lái)一些問(wèn)題。首先，各個(gè)階段必須順序地處理數(shù)據(jù)。換句話說(shuō)，APP階段完成對(duì)數(shù)據(jù)的處理之后，CULL階段才可以開始使用這些數(shù)據(jù)。同樣，DRAW階段也不可以在CULL完成數(shù)據(jù)生成之前使用這些數(shù)據(jù)。不過(guò)，APP階段不需要等待CULL和DRAW階段的工作完成，就可以開始下一幀的數(shù)據(jù)處理工作，因此，系統(tǒng)管線流程的設(shè)計(jì)如下圖所示:

此外，各個(gè)階段之間共享的數(shù)據(jù)也需要進(jìn)行保護(hù)和緩存。由之前的階段寫入的數(shù)據(jù)，不可以被同時(shí)發(fā)生的其它并行階段讀取。這樣場(chǎng)景圖形軟件就需要引入復(fù)雜的數(shù)據(jù)管理功能。

以上所述是SGI Iris Performer在九十年代提出的一種框架結(jié)構(gòu)。在當(dāng)時(shí)它是合適的，但是現(xiàn)在已經(jīng)有些過(guò)時(shí)。

實(shí)時(shí)且具備窗口輸出（out-the-window）的飛行模擬系統(tǒng)需要60Hz的幀速率，也就是說(shuō)，每個(gè)階段只有16.667毫秒的時(shí)間來(lái)完成其任務(wù)。1990年，SGI開始開發(fā)實(shí)時(shí)圖形系統(tǒng)，它所使用的處理器速度是現(xiàn)在處理器的1/60。由于圖形系統(tǒng)與圖形處理器的能力成比例相關(guān)，APP和CULL階段所需的時(shí)間負(fù)荷并不是相同的。上圖所示的系統(tǒng)設(shè)計(jì)中，APP和CULL階段被假定可能占用整整一幀的時(shí)間進(jìn)行處理。

后來(lái)，系統(tǒng)頻寬的增長(zhǎng)降低了基于本地的圖形分配的消耗，而DRAW階段需要分離成兩個(gè)獨(dú)立的執(zhí)行線程：一個(gè)在主機(jī)上運(yùn)行，另一個(gè)在圖形子系統(tǒng)上運(yùn)行。這一改變將在后面的部分詳述。

最后一個(gè)需要提及的話題是等待時(shí)間（latency，即獲得系統(tǒng)任何形式響應(yīng)所需的最小時(shí)間）。飛行模擬系統(tǒng)可以允許有大約三幀的視覺(jué)反應(yīng)延遲時(shí)間。這一時(shí)間延遲是符合真實(shí)人體行為研究的結(jié)果的，因此我們不得不參照上述過(guò)程模型的要求進(jìn)行折衷的設(shè)計(jì)。

新的實(shí)現(xiàn)方案

在目前的硬件條件（以60Hz為幀速率標(biāo)準(zhǔn)）下運(yùn)行的大多數(shù)應(yīng)用程序，其CULL預(yù)階段（即APP階段）和CULL階段的處理時(shí)間分別限制在少于1毫秒和少于3-5毫秒的范圍內(nèi)。這樣的話，各個(gè)階段要各自占用完整的一幀，或者占用一個(gè)完整的CPU時(shí)間，恐怕是浪費(fèi)且不切實(shí)的。下面的圖表反映了這一事實(shí)。

有一種提議是，交由CULL預(yù)階段和CULL階段來(lái)執(zhí)行復(fù)雜的任務(wù)，以增加了它們的運(yùn)行時(shí)間。但是，大多數(shù)執(zhí)行復(fù)雜操作的應(yīng)用程序任務(wù)，其更好的實(shí)現(xiàn)方案是與幀的實(shí)現(xiàn)部分同步運(yùn)行。

首先我們考慮單處理器，單圖形子系統(tǒng)的系統(tǒng)模型。當(dāng)CULL預(yù)階段和CULL階段的計(jì)算需求降低時(shí)，各階段的運(yùn)行相位可以如圖進(jìn)行設(shè)計(jì)：

這一方案的好的方面是，所有的三個(gè)階段可以在一幀執(zhí)行，響應(yīng)時(shí)間也只有一幀。不利的方面是，DRAW階段分配的時(shí)間較以前大大減少，其啟動(dòng)時(shí)間也在一幀的中部位置。使用場(chǎng)景圖形的另一個(gè)益處是，CULL階段可以去除不可見的場(chǎng)景，以降低主機(jī)圖形子系統(tǒng)的帶寬壓力，同時(shí)它還負(fù)責(zé)按照狀態(tài)變化值對(duì)所有對(duì)象進(jìn)行排序，以優(yōu)化圖形流水線的性能。

由于系統(tǒng)帶寬和圖形性能的不斷提高，那些運(yùn)行在老式硬件平臺(tái)下的應(yīng)用程序，其需求可能較以前有所降低。分配給渲染的時(shí)間也許是充足的。這樣的話，場(chǎng)景圖形系統(tǒng)也就不必再考慮數(shù)據(jù)保護(hù)和管理上的特殊需要了。

現(xiàn)在我們考慮多圖形子系統(tǒng)，多處理器的系統(tǒng)模型。為了使用多處理器系統(tǒng)的優(yōu)勢(shì)，我們需要設(shè)置一個(gè)主線程，用于運(yùn)行CULL預(yù)階段的任務(wù)，并為每個(gè)圖形子系統(tǒng)設(shè)置CULL/DRAW線程。為此，我們要針對(duì)數(shù)據(jù)管理考慮以下兩個(gè)方面：
（1）CULL預(yù)階段的公共數(shù)據(jù)寫入。
（2）CULL階段生成的內(nèi)部數(shù)據(jù)，分別復(fù)制到各個(gè)CULL/DRAW階段中。
然后，我們才可以安全地執(zhí)行各個(gè)階段，如下圖所示：

我們已經(jīng)解決了集成并行化所存在的問(wèn)題，但是還沒(méi)有解決DRAW階段少于一幀時(shí)間的問(wèn)題。我們必須將CULL和DRAW階段分割成不同的處理線程來(lái)實(shí)現(xiàn)這一目標(biāo)。因此我們需要考慮如何保護(hù)和緩存數(shù)據(jù)，這些數(shù)據(jù)由CULL階段生成，由DRAW階段處理。下面的部分將討論這一主題，其階段圖如下所示。

對(duì)于硬件廠商來(lái)說(shuō)，上圖所示的情景一定是十分誘人的，因?yàn)樗褂昧?個(gè)CPU來(lái)控制3個(gè)圖形子系統(tǒng)。而且還有一種說(shuō)法是，如果保留CPU 0來(lái)執(zhí)行操作系統(tǒng)任務(wù)，從CPU 1開始執(zhí)行仿真任務(wù)，那么我們還需要第八個(gè)CPU。但是，對(duì)于工程人員來(lái)說(shuō)，上圖中存在了太多的空閑空間。同時(shí)，我們還增加了每一幀的響應(yīng)時(shí)間。不過(guò)這還是好過(guò)舊式模型的三幀的響應(yīng)時(shí)間。

主機(jī)繪制 vs. 圖形子系統(tǒng)繪制

到這里為止，我們一直都把DRAW作為一個(gè)獨(dú)立的階段，或者一個(gè)獨(dú)立的線程（進(jìn)程）進(jìn)行介紹。在舊式的系統(tǒng)上，由于繪制（DRAW）過(guò)程受到主機(jī)向圖形子系統(tǒng)傳輸?shù)膸捄蛨D形處理速度的影響，這一工作模型應(yīng)當(dāng)說(shuō)是合理的。但是如今，我們需要認(rèn)識(shí)到，當(dāng)DRAW階段運(yùn)行于主機(jī)的某個(gè)專有CPU上時(shí)，它同時(shí)與圖形子系統(tǒng)上的另一個(gè)并行處理器產(chǎn)生交互。OpenGL程序所做的僅僅是封裝了OpenGL協(xié)議（以數(shù)據(jù)和信息流的方式），并傳遞給圖形子系統(tǒng)，后者處理數(shù)據(jù)和信息流的內(nèi)容并執(zhí)行實(shí)際的矩陣變換，并實(shí)現(xiàn)結(jié)果的渲染。主機(jī)的繪制（DRAW）過(guò)程略微提前于圖形子系統(tǒng)的繪制過(guò)程開始，并略微提前（有時(shí)可能會(huì)大幅提前）結(jié)束處理。通過(guò)使用基于主機(jī)的計(jì)時(shí)工具來(lái)進(jìn)行圖形基準(zhǔn)測(cè)試，即可獲得這一結(jié)論。

下圖所示為主機(jī)DRAW（也稱作分派）階段和圖形子系統(tǒng)DRAW階段的實(shí)時(shí)運(yùn)作流程

從上圖可以看出，一幀時(shí)間內(nèi)，主機(jī)DRAW（分派）過(guò)程在幀的邊界開始。而主機(jī)DRAW分派OpenGL調(diào)用和圖形子系統(tǒng)開始處理這些調(diào)用之間的時(shí)間區(qū)域，被稱作分派時(shí)間（Dispatch latency）。黃色的條帶表示圖形子系統(tǒng)完成數(shù)據(jù)流的讀入和處理，完成矩陣變換，渲染，并執(zhí)行渲染緩存的交換所需的時(shí)間。由于交換緩存在下一次垂直回描（vertical retrace）消隱之前不會(huì)開始，因此圖形子系統(tǒng)在這段時(shí)間里處于空閑。

注意，由于DRAW分派過(guò)程在圖形子系統(tǒng)的處理完成之前已經(jīng)結(jié)束。為了實(shí)現(xiàn)應(yīng)用程序與圖形子系統(tǒng)的同步，大多數(shù)主流的圖形軟件都會(huì)選擇在下一幀之前等待一個(gè)指示“交換緩存已經(jīng)執(zhí)行”的信號(hào)。這可以說(shuō)是一個(gè)優(yōu)化主機(jī)運(yùn)行時(shí)間的機(jī)會(huì)。

綜上，再考慮到主機(jī)和圖形系統(tǒng)的并行特性，我們可以設(shè)想如下圖所示的過(guò)程模型。

在這個(gè)模型中，我們根據(jù)圖形子系統(tǒng)垂直回描信號(hào)的精確時(shí)間，規(guī)劃主機(jī)上的幀調(diào)度工作。不過(guò)，我們可以控制時(shí)間產(chǎn)生輕微的擺動(dòng)，這樣就可能在垂直回描之前，在主機(jī)上開始 新的一幀。當(dāng)垂直回描信號(hào)產(chǎn)生，同時(shí)圖形子系統(tǒng)的處理重置之時(shí)，我們?cè)谥鳈C(jī)上完成CULL預(yù)階段，CULL階段，并向下傳遞由主機(jī)DRAW過(guò)程生成的OpenGL協(xié)議。這一工作的起始時(shí)間與圖形子系統(tǒng)的幀邊界盡量貼近。注意，CULL和DRAW（分派）位于同一線程中，執(zhí)行串行處理。其結(jié)果是，原本用于等待垂直回描信號(hào)而浪費(fèi)的主機(jī)時(shí)間，現(xiàn)在得到了有效的節(jié)約。

這一模型意味著場(chǎng)景圖形的內(nèi)存管理計(jì)算強(qiáng)度得到了改善，同時(shí)給圖形系統(tǒng)的DRAW階段提供了最大的渲染時(shí)間。此外，響應(yīng)時(shí)間也降低到少于兩幀。

-----------------------------------------------------------------------------------------------------------

開放場(chǎng)景圖形多處理器模型的設(shè)計(jì)

開放場(chǎng)景圖形多處理器（Open Scene Graph Multi Processor）模型的設(shè)計(jì)如圖所示。

圖中所示的矩形塊表示的是一種抽象的概念，它不是與硬件緊密結(jié)合的，也無(wú)法直接加以實(shí)現(xiàn)。模型的實(shí)現(xiàn)方法將在本文中陸續(xù)給出。紅色的字體表示模型配置文檔和實(shí)現(xiàn)時(shí)所用到的專有名詞。線和箭頭表示數(shù)據(jù)在系統(tǒng)中的流向，最終完成在顯示器上的渲染。

主線程（Main Thread）

主線程是運(yùn)行CULL預(yù)階段的進(jìn)程或線程。其內(nèi)容包括了用于運(yùn)行此線程的CPU。我們假設(shè)主線程在它被觸發(fā)的主機(jī)上開始運(yùn)行。我們使用配置管理器來(lái)啟動(dòng)并初始化上圖的每一項(xiàng)內(nèi)容，而主線程則運(yùn)行在配置管理器所運(yùn)行的主機(jī)上。

揀選/繪制線程

揀選（CULL）/繪制（DRAW）可以作為一個(gè)線程來(lái)執(zhí)行，也可以像之前章節(jié)所述的那樣，運(yùn)行于不同的線程上。它可以指定兩個(gè)參數(shù)：一個(gè)是系統(tǒng)運(yùn)行的主機(jī)名稱，另一個(gè)是在該主機(jī)上負(fù)責(zé)調(diào)度線程的CPU序號(hào)。如果CPU的數(shù)目為復(fù)數(shù)（不大于2），那么我們假設(shè)揀選/繪制線程可以作為不同的線程來(lái)運(yùn)行。

渲染表面

渲染表面描述了最終渲染結(jié)果顯示的屏幕空間。其中定義了
·主機(jī)（Host）：執(zhí)行顯示的系統(tǒng)所在的主機(jī)名稱；
·顯示設(shè)備（Display）：即圖形子系統(tǒng)，此處假設(shè)在XWindow系統(tǒng)下使用顯示設(shè)備；
·屏幕（Screen）：此處假設(shè)在XWindow系統(tǒng)下使用屏幕；
·窗口（Window）：此處假設(shè)在XWindow系統(tǒng)下使用窗口；
·視口（Viewport）：視口指的是窗口內(nèi)的一個(gè)矩形區(qū)域，用于安置渲染的最終結(jié)果。
以上所述在配置文檔中均為實(shí)際的實(shí)現(xiàn)細(xì)節(jié)。

配置

上面所述的內(nèi)容可以按照三個(gè)獨(dú)立的環(huán)境進(jìn)行配置。
（1）單系統(tǒng)映像（Single System Image）
如果主機(jī)域名始終保持不變，那么我們的系統(tǒng)將在同一個(gè)主機(jī)上進(jìn)行初始化。然后我們就可以根據(jù)CPU域的定義來(lái)設(shè)置線程的參數(shù)。
（2）圖像集群（Graphics Cluster）
如果CULL/DRAW階段所在的主機(jī)域與CULL預(yù)階段所在的主機(jī)域不同，那么在CULL/DRAW的主機(jī)上需要啟動(dòng)一個(gè)CULL預(yù)階段的代理器，它用于執(zhí)行CULL預(yù)階段（另一臺(tái)主機(jī)上）生成的動(dòng)態(tài)數(shù)據(jù)集的同步。如果數(shù)據(jù)同步?jīng)]有完成，那么這個(gè)代理器會(huì)阻塞CULL階段的運(yùn)行。
（3）WireGL設(shè)置
渲染表面包括一個(gè)“主機(jī)”域。它可以用于實(shí)現(xiàn)WireGL（一種集群渲染系統(tǒng)）的執(zhí)行，以處理主機(jī)DRAW階段傳遞的OpenGL協(xié)議。這種配置調(diào)度的方便之處在于，它允許上述配置之間互相“混合搭配”（mix-and-match）。例如，某個(gè)應(yīng)用程序可以在三個(gè)本地圖形子系統(tǒng)上運(yùn)行其窗口輸出的渲染，同時(shí)為仿真工作站（Instructor Operator Station）提供多集群的顯示，并在WireGL集群系統(tǒng)上實(shí)現(xiàn)各個(gè)顯示結(jié)果的最終合成。

多處理器（MP）模型

前面的章節(jié)敘述了兩種類型的MP模型，用于實(shí)現(xiàn)多任務(wù)，多顯示的開放場(chǎng)景圖形系統(tǒng) 的實(shí)現(xiàn)。其不同點(diǎn)可以歸結(jié)為CULL/DRAW作為一個(gè)線程還是分開處理的問(wèn)題。如果考慮到同一主機(jī)上，存在移相的幀的調(diào)度，那么把CULL/DRAW分別進(jìn)行處理可能就是不妥的。此外，忽略其帶來(lái)的優(yōu)越性的話，上述實(shí)現(xiàn)方法所引入的內(nèi)存管理問(wèn)題也可能導(dǎo)致性能降低。

不過(guò)，我們?nèi)匀粫?huì)在這里依次討論這兩種模型。

MP模型A - 數(shù)據(jù)流

如前面的章節(jié)所述，這里我們假設(shè)一個(gè)單一的，基于主機(jī)的APP/CULL/DRAW流水線，注意這里可能存在多個(gè)CULL/DRAW過(guò)程。

這個(gè)模型中假設(shè)有一個(gè)基于主機(jī)的可微調(diào)的幀調(diào)度機(jī)制，一個(gè)單一的線程來(lái)執(zhí)行CULL/DRAW。時(shí)間線A，B，C表示下一幅圖中數(shù)據(jù)流的活動(dòng)時(shí)間。

如前文所述，CULL預(yù)階段負(fù)責(zé)更新場(chǎng)景圖形中的動(dòng)態(tài)數(shù)據(jù)。這些動(dòng)態(tài)數(shù)據(jù)包括攝像機(jī)位置，場(chǎng)景中的移動(dòng)物體位置，時(shí)間戳，幀數(shù)，消耗時(shí)間，以及其它一些數(shù)據(jù)管理的參量。我們假設(shè)這些數(shù)據(jù)已經(jīng)被正確分配，且都是應(yīng)用程序可以訪問(wèn)的公共量。當(dāng)CULL預(yù)階段結(jié)束時(shí)，它向CULL階段發(fā)送一個(gè)信號(hào)，使其進(jìn)入運(yùn)行狀態(tài)。CULL負(fù)責(zé)讀取更新的動(dòng)態(tài)數(shù)據(jù)，并生成內(nèi)部的數(shù)據(jù)（應(yīng)用程序無(wú)法訪問(wèn)它們），供DRAW階段使用。這些數(shù)據(jù)是串行進(jìn)行處理的。DRAW階段將遍歷這些內(nèi)部數(shù)據(jù)并傳遞相應(yīng)的OpenGL調(diào)用。

這個(gè)模型較為簡(jiǎn)練，它只需要簡(jiǎn)單地實(shí)現(xiàn)主機(jī)上幀發(fā)生相移（phase shifted）時(shí)調(diào)度的實(shí)時(shí)性即可。OpenSceneGraph本身已經(jīng)包括了多顯示系統(tǒng)中，對(duì)多重渲染上下文（rendering context）的支持。

當(dāng)CULL/DRAW作為一個(gè)線程運(yùn)行時(shí)，不需要做特殊的更改。

MP模型B - 數(shù)據(jù)流

下面我們討論CULL/DRAW分別在不同線程上運(yùn)行的情況。注意，下圖中并沒(méi)有包括圖形子系統(tǒng)的DRAW部分。此模型假設(shè)不存在相移，且主機(jī)已經(jīng)處理了與圖形子系統(tǒng)的同步問(wèn)題。

此模型的數(shù)據(jù)流程如下圖所示。

上圖與單線程CULL/DRAW過(guò)程圖的區(qū)別在于，從CULL傳遞到DRAW的內(nèi)部數(shù)據(jù)需要經(jīng)過(guò)雙緩存的過(guò)程。CULL生成的數(shù)據(jù)將被寫入“緩存0”，此時(shí)DRAW從“緩存1”讀取數(shù)據(jù)。到達(dá)CULL和DRAW線程的同步點(diǎn)時(shí)，執(zhí)行兩個(gè)緩存的交換。

這種方法需要編寫內(nèi)部數(shù)據(jù)的雙重緩存，以及CULL和DRAW線程的同步位置實(shí)現(xiàn)代碼。

總結(jié)

OpenSceneGraph的設(shè)計(jì)用于實(shí)現(xiàn)多任務(wù)，多處理器和多顯示的功能。它的實(shí)現(xiàn)方法是先進(jìn)的，并且充分利用了現(xiàn)有硬件環(huán)境的優(yōu)勢(shì)。開放場(chǎng)景圖形（Open Scene Graph）已經(jīng)在SGI的MPK上測(cè)試成功，執(zhí)行結(jié)果令人滿意。開放場(chǎng)景圖形的開發(fā)者迫切希望實(shí)現(xiàn)一個(gè)跨 平臺(tái)的，靈活、透明地執(zhí)行于圖形集群（graphics cluster）上的解決方案。在了解了目前的困難之后，相信一款多顯示，多處理器的實(shí)時(shí)開放場(chǎng)景圖形系統(tǒng)將會(huì)在不久之后誕生。
---------------------------------------------------------------------------------------------------------------------
原文參見：http://andesengineering.com/OSG_ProducerArticles/OSGMP/index.html