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

新的設想

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

多任務，多顯示，單系統繪圖的傳統方法

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

在一個具備多個圖形子系統的系統中，有必要為每個圖形子系統設置CULL和DRAW 階段，因為在假定各個視口錐截體均不同的前提下，只有CULL階段能夠為每個子系統構建唯一的“顯示列表”。而APP階段則不必設置多個，因為每個視口均會共享同一個APP階段更新的動態數據。

鑒于此，一個具備多圖形子系統的系統，要實現多任務的機制，則需要定義過程如下：一個單處理器的系統需要順序地執行各個階段（例如，APP，CULL_0，DRAW_0，CULL_1，DRAW_1，CULL_2，DRAW_2），而一幀的時間也就相當于這些階段耗費的總時間。因此，我們需要實現的任務主要有兩個：（1）唯一的APP任務，（2）每個圖形子系統各自的CULL/DRAW任務。

在多處理器系統中，如果處理器樹木足夠多的話，那么每一個任務都可以在某一個處理器上并行地執行。此外，CULL/DRAW任務也可以分離為兩個任務并行地運行。

并行多處理器環境的模型實現主要有兩個目標。（1）分離并行化（Task Division Parallelization）：將一個大型的任務分解成多個可以并行運行的小型任務，以削減運行時間；（2）集成并行化（Task Aggregation Parallelization）：將一個任務N次倍乘后，并行地運行它的每個實例，而不增加運行時間。將CULL/DRAW階段從APP階段分離出來，然后將CULL和DRAW分離成獨立并行的任務，這是一個“分離并行化”的例子。將多個CULL/DRAW組合的任務添加給各個圖形子系統，這是一個“集成并行化”的例子。

并行地運行各個階段可能會帶來一些問題。首先，各個階段必須順序地處理數據。換句話說，APP階段完成對數據的處理之后，CULL階段才可以開始使用這些數據。同樣，DRAW階段也不可以在CULL完成數據生成之前使用這些數據。不過，APP階段不需要等待CULL和DRAW階段的工作完成，就可以開始下一幀的數據處理工作，因此，系統管線流程的設計如下圖所示:

此外，各個階段之間共享的數據也需要進行保護和緩存。由之前的階段寫入的數據，不可以被同時發生的其它并行階段讀取。這樣場景圖形軟件就需要引入復雜的數據管理功能。

以上所述是SGI Iris Performer在九十年代提出的一種框架結構。在當時它是合適的，但是現在已經有些過時。

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

后來，系統頻寬的增長降低了基于本地的圖形分配的消耗，而DRAW階段需要分離成兩個獨立的執行線程：一個在主機上運行，另一個在圖形子系統上運行。這一改變將在后面的部分詳述。

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

新的實現方案

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

有一種提議是，交由CULL預階段和CULL階段來執行復雜的任務，以增加了它們的運行時間。但是，大多數執行復雜操作的應用程序任務，其更好的實現方案是與幀的實現部分同步運行。

首先我們考慮單處理器，單圖形子系統的系統模型。當CULL預階段和CULL階段的計算需求降低時，各階段的運行相位可以如圖進行設計：

這一方案的好的方面是，所有的三個階段可以在一幀執行，響應時間也只有一幀。不利的方面是，DRAW階段分配的時間較以前大大減少，其啟動時間也在一幀的中部位置。使用場景圖形的另一個益處是，CULL階段可以去除不可見的場景，以降低主機圖形子系統的帶寬壓力，同時它還負責按照狀態變化值對所有對象進行排序，以優化圖形流水線的性能。

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

現在我們考慮多圖形子系統，多處理器的系統模型。為了使用多處理器系統的優勢，我們需要設置一個主線程，用于運行CULL預階段的任務，并為每個圖形子系統設置CULL/DRAW線程。為此，我們要針對數據管理考慮以下兩個方面：
（1）CULL預階段的公共數據寫入。
（2）CULL階段生成的內部數據，分別復制到各個CULL/DRAW階段中。
然后，我們才可以安全地執行各個階段，如下圖所示：

我們已經解決了集成并行化所存在的問題，但是還沒有解決DRAW階段少于一幀時間的問題。我們必須將CULL和DRAW階段分割成不同的處理線程來實現這一目標。因此我們需要考慮如何保護和緩存數據，這些數據由CULL階段生成，由DRAW階段處理。下面的部分將討論這一主題，其階段圖如下所示。

對于硬件廠商來說，上圖所示的情景一定是十分誘人的，因為它使用了7個CPU來控制3個圖形子系統。而且還有一種說法是，如果保留CPU 0來執行操作系統任務，從CPU 1開始執行仿真任務，那么我們還需要第八個CPU。但是，對于工程人員來說，上圖中存在了太多的空閑空間。同時，我們還增加了每一幀的響應時間。不過這還是好過舊式模型的三幀的響應時間。

主機繪制 vs. 圖形子系統繪制

到這里為止，我們一直都把DRAW作為一個獨立的階段，或者一個獨立的線程（進程）進行介紹。在舊式的系統上，由于繪制（DRAW）過程受到主機向圖形子系統傳輸的帶寬和圖形處理速度的影響，這一工作模型應當說是合理的。但是如今，我們需要認識到，當DRAW階段運行于主機的某個專有CPU上時，它同時與圖形子系統上的另一個并行處理器產生交互。OpenGL程序所做的僅僅是封裝了OpenGL協議（以數據和信息流的方式），并傳遞給圖形子系統，后者處理數據和信息流的內容并執行實際的矩陣變換，并實現結果的渲染。主機的繪制（DRAW）過程略微提前于圖形子系統的繪制過程開始，并略微提前（有時可能會大幅提前）結束處理。通過使用基于主機的計時工具來進行圖形基準測試，即可獲得這一結論。

下圖所示為主機DRAW（也稱作分派）階段和圖形子系統DRAW階段的實時運作流程

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

注意，由于DRAW分派過程在圖形子系統的處理完成之前已經結束。為了實現應用程序與圖形子系統的同步，大多數主流的圖形軟件都會選擇在下一幀之前等待一個指示“交換緩存已經執行”的信號。這可以說是一個優化主機運行時間的機會。

綜上，再考慮到主機和圖形系統的并行特性，我們可以設想如下圖所示的過程模型。

在這個模型中，我們根據圖形子系統垂直回描信號的精確時間，規劃主機上的幀調度工作。不過，我們可以控制時間產生輕微的擺動，這樣就可能在垂直回描之前，在主機上開始 新的一幀。當垂直回描信號產生，同時圖形子系統的處理重置之時，我們在主機上完成CULL預階段，CULL階段，并向下傳遞由主機DRAW過程生成的OpenGL協議。這一工作的起始時間與圖形子系統的幀邊界盡量貼近。注意，CULL和DRAW（分派）位于同一線程中，執行串行處理。其結果是，原本用于等待垂直回描信號而浪費的主機時間，現在得到了有效的節約。

這一模型意味著場景圖形的內存管理計算強度得到了改善，同時給圖形系統的DRAW階段提供了最大的渲染時間。此外，響應時間也降低到少于兩幀。

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

開放場景圖形多處理器模型的設計

開放場景圖形多處理器（Open Scene Graph Multi Processor）模型的設計如圖所示。

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

主線程（Main Thread）

主線程是運行CULL預階段的進程或線程。其內容包括了用于運行此線程的CPU。我們假設主線程在它被觸發的主機上開始運行。我們使用配置管理器來啟動并初始化上圖的每一項內容，而主線程則運行在配置管理器所運行的主機上。

揀選/繪制線程

揀選（CULL）/繪制（DRAW）可以作為一個線程來執行，也可以像之前章節所述的那樣，運行于不同的線程上。它可以指定兩個參數：一個是系統運行的主機名稱，另一個是在該主機上負責調度線程的CPU序號。如果CPU的數目為復數（不大于2），那么我們假設揀選/繪制線程可以作為不同的線程來運行。

渲染表面

渲染表面描述了最終渲染結果顯示的屏幕空間。其中定義了
·主機（Host）：執行顯示的系統所在的主機名稱；
·顯示設備（Display）：即圖形子系統，此處假設在XWindow系統下使用顯示設備；
·屏幕（Screen）：此處假設在XWindow系統下使用屏幕；
·窗口（Window）：此處假設在XWindow系統下使用窗口；
·視口（Viewport）：視口指的是窗口內的一個矩形區域，用于安置渲染的最終結果。
以上所述在配置文檔中均為實際的實現細節。

配置

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

多處理器（MP）模型

前面的章節敘述了兩種類型的MP模型，用于實現多任務，多顯示的開放場景圖形系統 的實現。其不同點可以歸結為CULL/DRAW作為一個線程還是分開處理的問題。如果考慮到同一主機上，存在移相的幀的調度，那么把CULL/DRAW分別進行處理可能就是不妥的。此外，忽略其帶來的優越性的話，上述實現方法所引入的內存管理問題也可能導致性能降低。

不過，我們仍然會在這里依次討論這兩種模型。

MP模型A - 數據流

如前面的章節所述，這里我們假設一個單一的，基于主機的APP/CULL/DRAW流水線，注意這里可能存在多個CULL/DRAW過程。

這個模型中假設有一個基于主機的可微調的幀調度機制，一個單一的線程來執行CULL/DRAW。時間線A，B，C表示下一幅圖中數據流的活動時間。

如前文所述，CULL預階段負責更新場景圖形中的動態數據。這些動態數據包括攝像機位置，場景中的移動物體位置，時間戳，幀數，消耗時間，以及其它一些數據管理的參量。我們假設這些數據已經被正確分配，且都是應用程序可以訪問的公共量。當CULL預階段結束時，它向CULL階段發送一個信號，使其進入運行狀態。CULL負責讀取更新的動態數據，并生成內部的數據（應用程序無法訪問它們），供DRAW階段使用。這些數據是串行進行處理的。DRAW階段將遍歷這些內部數據并傳遞相應的OpenGL調用。

這個模型較為簡練，它只需要簡單地實現主機上幀發生相移（phase shifted）時調度的實時性即可。OpenSceneGraph本身已經包括了多顯示系統中，對多重渲染上下文（rendering context）的支持。

當CULL/DRAW作為一個線程運行時，不需要做特殊的更改。

MP模型B - 數據流

下面我們討論CULL/DRAW分別在不同線程上運行的情況。注意，下圖中并沒有包括圖形子系統的DRAW部分。此模型假設不存在相移，且主機已經處理了與圖形子系統的同步問題。

此模型的數據流程如下圖所示。

上圖與單線程CULL/DRAW過程圖的區別在于，從CULL傳遞到DRAW的內部數據需要經過雙緩存的過程。CULL生成的數據將被寫入“緩存0”，此時DRAW從“緩存1”讀取數據。到達CULL和DRAW線程的同步點時，執行兩個緩存的交換。

這種方法需要編寫內部數據的雙重緩存，以及CULL和DRAW線程的同步位置實現代碼。

總結

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