翻譯：趙菁菁（軒語(yǔ)軒緣）
審校：李笑達(dá)（DDBC4747）

本文還有一篇草稿，2009第一次在GPU Pro上發(fā)表，名為《高級(jí)渲染技術(shù)》。這篇草稿是我和好朋友Stephen McAuley共同完成的。但里面的有些東西現(xiàn)在我真的不怎么同意了，我沒(méi)修改太多就發(fā)表出來(lái)了（只有些許的修正）。

LightPre-Pass渲染器[Engel08, Engel09, Engel09a ]越來(lái)越受渲染架構(gòu)的青睞，已成為當(dāng)代的實(shí)時(shí)應(yīng)用了，具有廣泛的動(dòng)態(tài)照明需求。在這篇文章中，我們介紹和描述一種技術(shù)，可以在Cell寬帶引擎?上用來(lái)加速任意三維場(chǎng)景的實(shí)時(shí)照明，無(wú)需向目標(biāo)應(yīng)用程序添加任何額外的幀延遲。本文中描述的技術(shù)是為即將推出的Blur的PlayStation?3[1]版本開(kāi)發(fā)的，該版本于2010年5月[2]發(fā)布。

Blur截圖
1. 概述

隨著GPU變得越來(lái)越強(qiáng)大，人們希望利用GPU圖形以外的用途。這開(kāi)辟了一個(gè)研究領(lǐng)域稱為GPGPU（通用圖形處理器），各大顯卡廠商都在極力研究。例如，所有的NVIDIA?GeForce? GPU現(xiàn)在都支持PhysX?技術(shù)，使物理計(jì)算得以在GPU上執(zhí)行。然而，相反的現(xiàn)象卻少了很多——隨著系統(tǒng)中CPU的速度和數(shù)量的增加，在某些架構(gòu)上，將某些圖形計(jì)算從GPU轉(zhuǎn)移到CPU上變得可行。即將發(fā)布的硬件，如英特爾的Larrabee，甚至結(jié)合了兩種形式[ Seiler08 ]，這肯定會(huì)導(dǎo)致之前只有GPU問(wèn)題的基于CPU的解決方法越來(lái)越受關(guān)注。今天，這樣的架構(gòu)是PlayStation?3，其中強(qiáng)大的Cell寬帶引擎?從一開(kāi)始就設(shè)計(jì)為在處理活動(dòng)種[ Shippy09 ]支持GPU。本文解釋了如何利用Cell寬帶引擎?計(jì)算light pre-pass渲染引擎環(huán)境下的光照。

2. Light Pre-Pass 渲染

在計(jì)算機(jī)圖形學(xué)中經(jīng)常遇到的一個(gè)問(wèn)題是：如何在場(chǎng)景中構(gòu)建一個(gè)可以處理很多動(dòng)態(tài)光線的渲染器。傳統(tǒng)的正向渲染不能很好地表現(xiàn)多個(gè)光源。例如，如果一個(gè)像素著色器被寫(xiě)入最多四個(gè)點(diǎn)光源，那么只能繪制四個(gè)點(diǎn)光源（沒(méi)有投光燈）。每增加一次光，我們可以增加像素著色器組合的數(shù)量來(lái)處理盡可能多的情況，或者我們可以多次渲染該幾何體。但這兩種解決方案都不可取，因?yàn)樗鼈冊(cè)黾恿藸顟B(tài)更改的次數(shù)，并將繪制調(diào)用的次數(shù)增加到不可控級(jí)別。

這個(gè)問(wèn)題的一個(gè)流行的解決方案是使用延遲渲染[Deering88 ]。我們不從像素著色器中全部寫(xiě)出點(diǎn)亮的像素，而是把與表面相關(guān)的信息寫(xiě)入G緩沖區(qū)，包括深度、法向量和材質(zhì)信息。如下是G緩沖格式示例：

來(lái)自延遲渲染引擎的G緩沖格式示例（插圖來(lái)自[Valient07]）
然后我們利用G緩沖提供的信息，再把燈光融合到場(chǎng)景中。這樣一來(lái)，許多光線都可以渲染，不需要額外的幾何成本或著色器排列。此外，通過(guò)為每個(gè)光渲染封閉的體積，我們可以確保只對(duì)光直接影響的像素進(jìn)行計(jì)算。然而，有了延遲渲染，所有材質(zhì)必須使用相同的照明方程，只能通過(guò)存儲(chǔ)在G緩沖中的的渲染屬性更改。渲染進(jìn)入（和讀?。┻@么多緩沖區(qū)也會(huì)消耗巨大的內(nèi)存帶寬，帶寬和MSAA一同增長(zhǎng)。

為了解決這些問(wèn)題，Engel 建議使用light pre-pass渲染器，先在[ Engel08 ]上在線發(fā)表，后來(lái)發(fā)表在[Engel09 ]上，雖然其他人也提出了類似的想法，最近該想法已經(jīng)用于《神秘海域：德雷克的寶藏》等游戲中：德雷克的財(cái)富[Balestra08]。不是渲染出整個(gè)的G緩沖，light pre-Pass渲染器存儲(chǔ)一個(gè)或兩個(gè)渲染目標(biāo)的深度和法向量。之后是照明階段，所有光的屬性積累到照明緩沖區(qū)中。然后第二次渲染場(chǎng)景，采樣照明緩沖區(qū)以確定該像素上的照明情況。

使用Blinn-Phong光照模型意味著照明緩沖區(qū)的紅色、綠色和藍(lán)色通道存儲(chǔ)了擴(kuò)散計(jì)算，而我們可以在alpha通道中安裝一個(gè)鏡面，其中的細(xì)節(jié)在[ Engel09 ]中詳述。也就是說(shuō)，與延遲渲染不同，不同的材質(zhì)可以按不同方式處理照明值。這增加了靈活性，同時(shí)減少了內(nèi)存帶寬成本，我們發(fā)現(xiàn)light pre-pass越來(lái)越流行，最近許多游戲在各種硬件平臺(tái)上都使用著。

然而，延遲渲染和light pre-pass 渲染器都存在這么一個(gè)事實(shí)：照明是在圖像空間中進(jìn)行的，因此幾乎不需要光柵化。這使得照明通道從GPU回到CPU的理想候選。Swoboda在[ Swoboda09 ]中，在PLAYSTATION?3和?Cell寬帶引擎?上首次用延遲渲染器證明了這一方法，現(xiàn)在我們將他的工作擴(kuò)展一下，為lightpre-pass渲染器應(yīng)用類似的技巧。

3. PLAYSTATION?3 與CBE?

索尼計(jì)算機(jī)娛樂(lè)在2006發(fā)布了PlayStation 3 。它包含的Cell寬帶引擎?由索尼計(jì)算機(jī)娛樂(lè)公司、東芝公司和IBM公司共同開(kāi)發(fā)[Shippy09, M?ller08, IBM08]。Cell是PlayStation 3的中央處理單元（CPU）。除了Cell芯片外，PlayStation 3還有GPU，現(xiàn)實(shí)合成器，或RSX?。RSX?由NVIDIA 公司開(kāi)發(fā)，本質(zhì)上是一個(gè)改進(jìn)的GeForce?7800 [M?ller08]。圖3是架構(gòu)的高級(jí)視圖。

3架構(gòu)（插圖來(lái)自[M?ller08, Perthuis06]）
在Cell芯片中，可以找到兩種截然不同的處理器。有PowerPC處理器（PPE）和八個(gè)[3 ]純SIMD處理器[M?ller08]，也叫做協(xié)同處理器（SPE），均是高速連接起來(lái)的，“令牌環(huán)式”總線稱為元件互連總線（EIB），見(jiàn)圖4。本文中技術(shù)的介紹和描述，主要關(guān)心的是特殊目的實(shí)體的使用，省略了進(jìn)一步討論P(yáng)PE。

Cell寬帶引擎（插圖來(lái)自[IBM08]）
SPE的一個(gè)有趣的奇怪之處是它不直接訪問(wèn)主地址空間，而是有自己的內(nèi)部存儲(chǔ)器，稱為本地存儲(chǔ)。CBE當(dāng)前實(shí)現(xiàn)的本地存儲(chǔ)是256KB大小。內(nèi)存是統(tǒng)一的，不可譯也不受保護(hù)[Bader06, IBM08]，必須包含SPE的程序代碼、調(diào)用堆棧和任何可能處理的數(shù)據(jù)。要從主地址空間加載或存儲(chǔ)數(shù)據(jù)，程序員必須顯式使用內(nèi)存流（MFC）。每個(gè)SPE擁有自己的MFC，能夠排隊(duì)十六個(gè)直接內(nèi)存訪問(wèn)（DMA）[IBM08]。

由于SPUISA主要操作SIMD定點(diǎn)和浮點(diǎn)的向量運(yùn)算[IBM09]，這很適合處理大量的矢量化數(shù)據(jù)。它有一個(gè)非常大的注冊(cè)文件（4KB），有助于隱藏流水線的延遲和展開(kāi)循環(huán)，而在容量的本地存儲(chǔ)是比較小的，足以讓一個(gè)程序員通常能夠通過(guò)高效多緩沖隱藏內(nèi)存訪問(wèn)的巨大延遲[ 4 ]。要高效地執(zhí)行SPE上的代碼，應(yīng)該充分發(fā)揮SPE的優(yōu)勢(shì)。

有關(guān)PlayStation?3和Cell寬帶引擎?更深入的討論超出了本文的范圍，感興趣的讀者可以參考IBM的網(wǎng)站深入了解Cell芯片更多細(xì)節(jié)[IBM09]，和M?ller、海恩斯和霍夫曼描述在[M?ller08]中闡述了PlayStation? 3的一些架構(gòu)。

4. GPU/SPE同步

隨著我們目標(biāo)平臺(tái)中的處理器數(shù)量越來(lái)越大，有關(guān)這些處理元素執(zhí)行工作調(diào)度的自動(dòng)化需求也越來(lái)越多。這一直持續(xù)到游戲開(kāi)發(fā)團(tuán)隊(duì)現(xiàn)在，他們圍繞作業(yè)調(diào)度程序的概念建立了自己的游戲和技術(shù)[Capcom06]。我們的引擎不例外也沿襲這一趨勢(shì)，我們提出的GPU / SPE處理器間通信的解決方案與這一技術(shù)緊密結(jié)合。正是因?yàn)檫@個(gè)原因，我們相信我們的解決方案是一個(gè)強(qiáng)大的、可行的RSX?/SPE 通信問(wèn)題解決方案，大家可以很容易地把這一方案融入他們現(xiàn)有的調(diào)度框架。為了在SPE上執(zhí)行片段著色，不會(huì)為渲染管線引入不必要的延遲，需要有一定數(shù)量的跨GPU和SPE處理器之間的通信。本節(jié)我們討論用于實(shí)現(xiàn)這種同步的方法。

每個(gè)SPE有幾個(gè)內(nèi)存映射I/O（MMIO）寄存器，可用于處理器與其他SPE或PPU間通信。然而，不幸的是，這些不是從RSX?上平凡可寫(xiě)的。需要另一種方法，需要RSX?發(fā)信號(hào)告知SPES，法線/深度緩沖區(qū)的渲染是完整的，它們現(xiàn)在可以開(kāi)始工作了，無(wú)需SPE程序在全部六個(gè)SPE上浪費(fèi)寶貴的處理時(shí)間。

向作業(yè)調(diào)度程序添加作業(yè)的時(shí)候，作業(yè)調(diào)度程序是隨意在RSX?-映射內(nèi)存上給出一個(gè)地址，該作業(yè)依賴這個(gè)地址。當(dāng)調(diào)度程序從作業(yè)隊(duì)列中取出下一個(gè)作業(yè)時(shí)，它會(huì)檢查這個(gè)地址，以確保它是寫(xiě)一個(gè)RSX?的已知值。如果該值不已知，該作業(yè)被跳過(guò)，繼續(xù)從隊(duì)列中取出下一個(gè)作業(yè)并處理，如果內(nèi)存中的位置被寫(xiě)入，那么我們的作業(yè)就可以自由運(yùn)行了。這個(gè)依賴關(guān)系如圖5所示。

RSX? 和 SPE 通信，當(dāng)法線/深度緩沖區(qū)可以處理時(shí)RSX?寫(xiě)入一個(gè)128字節(jié)的值， SPE從相同的位置取出值來(lái)獲得其開(kāi)始工作的時(shí)間
確保GPU等待來(lái)自SPE的光緩沖問(wèn)題的解決方案，對(duì)于PlayStation?3開(kāi)發(fā)者來(lái)說(shuō)是眾所周知的，但不幸的是我們不能在這里透露。感興趣的PLAYSTATION?3開(kāi)發(fā)者可以可以咨詢索尼的官方發(fā)展支持網(wǎng)站。

RSX?繼續(xù)與SPE進(jìn)行照明計(jì)算這樣有用的工作是眾望所歸的。在Blur中，我們很幸運(yùn)，因?yàn)槲覀冇性S多附加視圖，這些視圖不依賴于光緩存，例如平面反射和后視鏡（在其他應(yīng)用程序中，這些應(yīng)用程序還可能包括陰影緩沖區(qū)），如圖6所示。如果在RSX?上沒(méi)有有用的工作可以執(zhí)行，可能會(huì)像[Swoboda09]中那樣潛在地進(jìn)行一幀光照計(jì)算（取決于你的內(nèi)存預(yù)算和您的應(yīng)用程序要求），這種方法還可以降低停轉(zhuǎn)RSX?的可能性。

RSX?繼續(xù)做有用的工作，SPE為我們的場(chǎng)景計(jì)算動(dòng)態(tài)光照。

5. Pre-Pass

要開(kāi)始照明pre-pass，我們必須首先建立法線和深度緩沖區(qū)。我們以8:8:8:8格式存儲(chǔ)視圖空間法線，因?yàn)槲覀兛梢詮乃x擇的硬件上的深度緩沖區(qū)讀取內(nèi)容，所以深度不需要單獨(dú)的目標(biāo)。我們選擇在視圖空間中進(jìn)行照明，因?yàn)槲覀儼l(fā)現(xiàn)它比世界空間更快。

接下來(lái)，我們將相關(guān)的固體和alpha測(cè)試的幾何體渲染到緩沖區(qū)中。我們只渲染受燈光影響的幾何圖形——我們根據(jù)光線的包圍空間剔除所有的繪制調(diào)用，同時(shí)還引入遠(yuǎn)裁剪平面（注意，一個(gè)簡(jiǎn)單的空間試驗(yàn)是不夠的，我們還需要渲染附近遮擋光圈的物體）。這些剔除方法約減少一半的繪制pre-pass幾何圖形代價(jià)。

當(dāng)渲染場(chǎng)景時(shí)，我們讓模板可以用0xff這個(gè)參考值寫(xiě)入。模板緩存區(qū)事先清除為0x00，為我們屏幕的相關(guān)區(qū)域屏蔽掉模板緩沖。無(wú)論在RSX?還是SPE上渲染光線，這都會(huì)使我們能夠使用早期的模板以確保我們只照亮相關(guān)像素。

我們目前不提供pre-pass或MSAA光緩沖。這存在一些缺點(diǎn)，包括在物體邊緣周?chē)囊恍┱彰鱾蜗?，以及喪失在主?chǎng)景中使用深度緩沖作為深度pre-pass的能力（我們用MSAA渲染主場(chǎng)景）。然而，我們發(fā)現(xiàn)的偽像極少，繪制light pre-pass MSAA的額外成本大于有深度pre-pass的存儲(chǔ)。這仍然是我們將來(lái)希望回歸的領(lǐng)域。

一旦我們有了法線和深度的緩沖區(qū)，我們就可以執(zhí)行照明。目前，我們使用朗伯漫反射模型，把光線渲染進(jìn)入8:8:8:8緩沖。這是為了簡(jiǎn)單和性能，但是以沒(méi)有鏡面反射和照明范圍有限為代價(jià)。這也意味著照明緩沖區(qū)的alpha通道未使用。關(guān)于使用的一些想法在進(jìn)一步工作的章節(jié)中進(jìn)行了解釋。

我們維護(hù)了一個(gè)照明模型的GPU實(shí)現(xiàn)方法，供其他平臺(tái)參考。首先，模板測(cè)試設(shè)置為“等于”一個(gè)引用值0xff，所以我們只渲染在模板緩沖區(qū)中標(biāo)記了的像素。然后，用兩種非常不同的方法，用點(diǎn)光源和投光燈來(lái)渲染燈光。

點(diǎn)光源渲染和[ Balestra08 ]中的方法一樣——幀緩沖區(qū)被分割為若干塊（tile），我們集合了影響了每塊的光線列表（最多八個(gè)）。然后我們使用一個(gè)對(duì)應(yīng)于它的燈光數(shù)的著色器來(lái)渲染每一塊。這種方法節(jié)省了填充率，我們可以不在意點(diǎn)光源的數(shù)目，對(duì)于每個(gè)像素只重建一次視圖空間位置和來(lái)自法線/深度緩沖區(qū)的法線。

點(diǎn)光源使用更標(biāo)準(zhǔn)的方法來(lái)繪制燈光的包圍空間——在這種情況下是圓錐。我們渲染正面，除非我們?cè)诹Ⅲw空間內(nèi)，在這種情況下我們才渲染背面。

當(dāng)深度邊界測(cè)試在目標(biāo)硬件上可用時(shí)，我們進(jìn)一步利用這一方法來(lái)優(yōu)化照明代碼。深度邊界測(cè)試將當(dāng)前片段坐標(biāo)下的深度緩沖值與給定的最小深度和最大深度值進(jìn)行比較。如果存儲(chǔ)的深度值超出給定范圍，則碎片將被丟棄。當(dāng)畫(huà)一個(gè)點(diǎn)光源或一個(gè)光點(diǎn)空間時(shí)，我們將深度邊界范圍設(shè)置為光的最小和最大深度范圍。

這給出了一個(gè)快速、優(yōu)化的照明模型GPU實(shí)現(xiàn)方法。然而，它仍然占我們幀渲染時(shí)間很例，其圖像空間的性質(zhì)使它成為從GPU卸載到SPE上的完美候選者。

6. 照明SPE程序

本節(jié)詳細(xì)描述執(zhí)行照明計(jì)算的SPE程序。為了盡量將每個(gè)子部分置于整體背景下來(lái)闡述，我們已經(jīng)給出了圖7，展示了作為整體的SPE程序的高層結(jié)構(gòu)。

SPE照明程序的高層流
6.1 原子塊決定者

由于720p幀緩沖對(duì)內(nèi)存占用比較大；SPE本地存儲(chǔ)的大小限制；PlayStation 3 ?RSX?創(chuàng)建的表面內(nèi)部格式，我們的照明SPE程序工作在幀緩沖區(qū)的上，64×64像素的大小，如圖8所示。因此，需要跟蹤哪些塊可以帶到本地存儲(chǔ)區(qū)進(jìn)行處理。我們發(fā)現(xiàn)實(shí)現(xiàn)這一最簡(jiǎn)單、最并行方式是通過(guò)一個(gè)自動(dòng)遞增的駐留在主存儲(chǔ)器中的塊索引。應(yīng)該指出的是，SPE和RSX?是只有在處理放置到正確的映射內(nèi)存的資源時(shí)才能夠有效地合作。

每個(gè)SPE通過(guò)內(nèi)存中自動(dòng)遞增的塊索引給自己分配任務(wù)。
為了提高效率（和避免緩存線爭(zhēng)搶），塊索引對(duì)齊到128字節(jié)邊界，填充128個(gè)字節(jié)大小，與SPES原子單元緩存線的寬度完全匹配（ATO）[IBM08, IBM07]。塊的有效地址（EA）由塊索引乘上一個(gè)塊總大小，與幀緩沖區(qū)開(kāi)頭地址作和，如方程6.1所示。對(duì)于我們選擇的塊大小，得到的有效地址總是落在16字節(jié)的邊界上，因?yàn)槲覀兊膲K大小本身是一個(gè)16字節(jié)的倍數(shù)。


6.2. 多緩沖

多緩沖對(duì)于幾乎所有處理重要數(shù)據(jù)的SPE程序都是必要的[Bader07]，我們的照明方案也不例外。在我們的實(shí)現(xiàn)中，我們使用三重緩沖來(lái)最小化主存中的法線/深度緩沖區(qū)的訪問(wèn)延遲。三重緩沖區(qū)中的每個(gè)緩沖區(qū)都有足夠的空間來(lái)支持單個(gè)工作單元（即：幀緩沖區(qū)的一個(gè)單獨(dú)的塊）。我們的三重緩沖區(qū)中的第一個(gè)緩沖區(qū)被用作入DMA的目標(biāo)，它利用自己的標(biāo)簽組，一旦上一個(gè)塊的塊解碼過(guò)程[ 5 ]完成，DMA就進(jìn)入這個(gè)緩沖區(qū)。第二和第三緩沖區(qū)用作解碼過(guò)程的輸出目標(biāo)。除此之外，它們作為照明計(jì)算的暫存存儲(chǔ)器，是從運(yùn)行的SPE程序返回主存中的光緩存的源[ 6 ]。這是通過(guò)交替使用兩個(gè)緩沖區(qū)來(lái)實(shí)現(xiàn)的，以便允許輸出DMA異步地執(zhí)行下一塊的解碼和照明。我們的多緩沖策略的高級(jí)視圖如圖9所示。

我們照明SPE程序中的三重緩沖策略。
這里介紹的多緩沖系統(tǒng)非常有效，我們的SPE程序的每幀、每SPU等待數(shù)據(jù)被傳到內(nèi)存和從內(nèi)存中傳出，平均5μs，這與延遲了程序的執(zhí)行早應(yīng)該體。大部分延遲是在程序執(zhí)行的早期引入的，正如人們所預(yù)料的那樣。

6.3. 集光

當(dāng)法線緩沖區(qū)和深度模板緩沖區(qū)塊的輸入狀態(tài)已經(jīng)完成了，我們可以開(kāi)始處理。在我們照明之前，我們首先收集影響給定塊的光線。我們?yōu)槊恳粔K構(gòu)造一個(gè)視錐，并將光的包圍球剔除到截錐體上。此外，我們還對(duì)模板緩沖區(qū)進(jìn)行了剔除。這是一個(gè)至關(guān)重要的優(yōu)化，因?yàn)樗鼫p少了在昂貴的照明階段所做的工作。

為了執(zhí)行剔除和照明，我們實(shí)際工作在幀緩沖塊的子塊上，大小為3216像素。在較小區(qū)域的剔除更為有效，我們發(fā)現(xiàn)在我們的條件下上述大小的子塊是最優(yōu)的。

接下來(lái)，我們?cè)谏疃饶０迳系?，以收集每個(gè)子塊的最小和最大深度值和最小、最大模板值。深度值將形成我們子塊視錐體的近和遠(yuǎn)裁剪平面，模板值允許我們進(jìn)行一個(gè)模板測(cè)試，類似于GPU上的早期模具硬件。

在五部分，我們會(huì)介紹在渲染pre-pass緩沖區(qū)時(shí)把0xff寫(xiě)入模板緩沖，因此任何帶有0x00模板的像素，都是我們不希望照亮的。然而，我們沒(méi)有基于每個(gè)像素創(chuàng)建模板，而是跳過(guò)子塊照明，如果最大模板值等于0x00的話（因此整個(gè)子塊都是0x00）。

一旦子塊通過(guò)了模板測(cè)試，我們就構(gòu)建了它的視錐。了解了子塊的角落位置，通過(guò)使用投影矩陣的值，我們可以在距相機(jī)一米的固定距離內(nèi)構(gòu)造其在視點(diǎn)空間中的位置（見(jiàn)方程6.5）。通過(guò)最小和最大視圖空間深度值相乘，我們得到了八個(gè)頂點(diǎn)，我們可以從中構(gòu)造出六個(gè)平面（見(jiàn)方程6.4，如何利用深度緩沖值構(gòu)造視圖空間z）。

然后，我們分別構(gòu)造了點(diǎn)光源和投光燈的列表，它們相交于這個(gè)視錐。在每個(gè)圓臺(tái)平面上測(cè)試每一個(gè)光的邊界包圍球，測(cè)試通過(guò)點(diǎn)光源添加到點(diǎn)光源列表中，測(cè)試通過(guò)的投光燈添加到投光燈列表中。


如果沒(méi)有聚集到光，那么子塊將遵循與模板測(cè)試失敗相同的路徑——即跳過(guò)光照，將零輸出到幀緩沖區(qū)。然而，如果至少有一個(gè)光確實(shí)影響了子塊，那么點(diǎn)光源列表和點(diǎn)光源將被傳遞到我們的照明函數(shù)中，以完成工作中最重要的部分。

6.4. 點(diǎn)光源

用于照明的SPE程序是用C編寫(xiě)的，并大量使用SPE特定語(yǔ)言擴(kuò)展。我們?cè)谠缙谶x擇了支持內(nèi)在Si風(fēng)格的，而不是更高級(jí)別的SPU的風(fēng)格。這是由于近距離映射到下面由編譯器生成的操作碼[Acton08]。

照明代碼對(duì)于軟件流水循環(huán)展開(kāi)來(lái)講都是一個(gè)很好的候選；我們的照明是一次性執(zhí)行一批16個(gè)像素。我們發(fā)現(xiàn)，對(duì)于我們光照循環(huán)的每次迭代，十六個(gè)像素浪費(fèi)的周期非常少，而且我們?nèi)匀豢梢园阉璧膬?nèi)容裝入4KB(128, 16 字節(jié))的注冊(cè)文件中[7]。相對(duì)較大的像素集產(chǎn)生大量獨(dú)立指令，相鄰指令所引起的延遲幾乎完全消除，整體性能大幅度提高（僅受發(fā)出指令的數(shù)量限制）。非依賴指令彼此交錯(cuò)的結(jié)果是指令可用一段時(shí)間后才被使用；這個(gè)著名的優(yōu)化技術(shù)也有以下副作用：提高奇數(shù)和偶數(shù)執(zhí)行管道的指令平衡，因?yàn)橛懈噙m合的、無(wú)依賴性的指令可以在協(xié)同執(zhí)行單元（SXU）占據(jù)一個(gè)取出組。我們發(fā)現(xiàn)，將像素分成16組，是我們先前的嘗試方法的像素吞吐量的三倍，我們之前通過(guò)照明四個(gè)像素小組簡(jiǎn)單地模仿RSX?四周。


在任何照明開(kāi)始之前，重要的是把正確的輸入重建到我們?cè)诜匠?.3里表達(dá)的照明方程中。方程6.4演示了如何重建給定像素深度緩沖值的視點(diǎn)空間位置和視錐的近遠(yuǎn)平面的z分量。當(dāng)給定視圖空間中像素的x和y坐標(biāo)和視圖投影矩陣時(shí)，計(jì)算視點(diǎn)空間位置的x和y分量同樣微不足道。方程6.5顯示了這一點(diǎn)。



在HLSL /Cg著色器中，使用飽和的內(nèi)在功能把值限制到[0..1]范圍內(nèi)是很常見(jiàn)的。為了在SPE上做到這一點(diǎn)，我們覺(jué)得這里有一個(gè)聰明的技巧值得一提。Day等人介紹了快速飽和/壓縮技術(shù)，使用SPU的浮點(diǎn)轉(zhuǎn)換指令以實(shí)現(xiàn)把一個(gè)浮點(diǎn)值限制到各種不同的范圍。這取決于與指令發(fā)布的范圍偏差操作數(shù)的組合[Day08]。在流水線循環(huán)中，如我們的照明循環(huán)，指令計(jì)數(shù)常常是代碼執(zhí)行速度的主要決定因素，因此我們能夠利用這個(gè)技巧產(chǎn)生巨大的效果。清單1演示了這一技術(shù)。

清單1. 在兩個(gè)偶數(shù)管道指令中使qword飽和。
我們的照明的GPU實(shí)現(xiàn)和SPE實(shí)現(xiàn)之間存在一個(gè)有趣的區(qū)別：從GPU上的默認(rèn)結(jié)構(gòu)數(shù)組（AOS）數(shù)據(jù)布局切換到SPE上的轉(zhuǎn)置的、SIMD友好的數(shù)組結(jié)構(gòu)（SOA）[ 8 ]數(shù)據(jù)布局。圖10說(shuō)明了數(shù)據(jù)格式方面差異。通過(guò)將數(shù)據(jù)存儲(chǔ)、加載和置亂成一個(gè)SOA布局，我們能夠在SPE上執(zhí)行我們更加優(yōu)化的照明計(jì)算。一個(gè)令人愉悅的的切換副作用是：生成的C代碼外觀更像標(biāo)量，這使得其他程序員 [ Bader06] 更容易遵循。

把AoS置亂成SoA.
SPE是只能處理16字節(jié)對(duì)齊與本地存儲(chǔ)相關(guān)的寫(xiě)入和讀取[Bader06, IBM08, IBM08a]。在SPU存儲(chǔ)和負(fù)載單元（SLS）讀取或?qū)懭氲刂分?，?lái)自所有加載和存儲(chǔ)操作的目標(biāo)首先經(jīng)過(guò)LSLR寄存器的邏輯“與”（當(dāng)前的CBE實(shí)現(xiàn)是設(shè)置為0x3ffff）[IBM08,IBM08a]。寫(xiě)入標(biāo)量值是通過(guò)加載本地置亂存儲(chǔ)模式實(shí)現(xiàn)的。因此，在16字節(jié)邊界上執(zhí)行加載和存儲(chǔ)是可取的。我們的程序需要法線/深度緩沖區(qū)大量的4字節(jié)的加載，也需要很多同樣大小的對(duì)于我們的光緩沖區(qū)的寫(xiě)入，我們不再分批處理這些16字節(jié)塊的加載和存儲(chǔ)，為的是消除額外代碼的開(kāi)銷，如果在逐像素的基礎(chǔ)上執(zhí)行這些操作，那么就需要這些代碼。事實(shí)證明，這將大大提高性能，尤其是在存儲(chǔ)幾乎所有管道氣泡都消除的地方。我們將清單2中像素寫(xiě)入代碼中的一部分用于一個(gè)四像素塊：

清單 2. 像素被從浮點(diǎn)表示轉(zhuǎn)換為32位值，批量處理為16字節(jié)的塊，并存儲(chǔ)。
6.5 投光燈

為了完整性，我們提出了在方程6.6中常用的“投光燈”的計(jì)算。


請(qǐng)注意，這與點(diǎn)光源的方程是相同的，在結(jié)束處附加一個(gè)術(shù)語(yǔ)。d是光的方向（與l相反，是從光到點(diǎn)的方向），θ是內(nèi)錐的角，φ是外錐的角。然而，我們會(huì)存儲(chǔ)它們光的余弦值，而不是每次都計(jì)算。所有點(diǎn)光源和投光燈的所有照明值的每個(gè)像素相加，得到6.7的方程。



7.主通道

當(dāng)SPE計(jì)算完了光緩存器，就會(huì)通知RSX?可以渲染主通道了。如上所述，這個(gè)階段的同步非常重要——我們不想從不完整的光緩存中讀取數(shù)據(jù)。為了將光緩存與主場(chǎng)景組合起來(lái)，我們將它作為像素著色器中的紋理讀取。然而，并不是我們場(chǎng)景中的每一個(gè)像素都會(huì)接收到來(lái)自我們pre-pass的光（見(jiàn)上面，我們只將幾何渲染到接收到光的pre-pass中），我們?cè)趫?chǎng)景中使用了兩種著色器技術(shù)：一種是從光緩存中采樣，另一種則沒(méi)有。對(duì)于前一種技術(shù)，每個(gè)像素使用其屏幕空間坐標(biāo)在光緩存器中查找其光照，然后將光值復(fù)合為漫射光，如下所示：


通過(guò)簡(jiǎn)單的加法、乘法來(lái)混合整個(gè)場(chǎng)景的照明看似很有力，但從上可以看出，這種方導(dǎo)致不正確的照明。這是由于我們場(chǎng)景中存在額外的靜態(tài)照明。

還可以從主通道中的法線緩沖區(qū)讀取，這意味著從法線貼圖讀取和從正切空間轉(zhuǎn)換到視圖（或世界）空間只發(fā)生一次。然而，這也意味著存儲(chǔ)在pre-pass中的法線的低精度變得更加明顯（每個(gè)組件只有8位）。由于這個(gè)原因和其他原因，我們沒(méi)有使用這個(gè)方法。

在渲染的最后，我們有許多使用Cell寬帶引擎?進(jìn)行動(dòng)態(tài)光渲染的場(chǎng)景。這不僅為我們的渲染引擎提供了令人興奮的新的可能性，而且GPU的成本是最小的，大量的工作在CPU上進(jìn)行。

8. 結(jié)論

我們提出了一種方法，將Cell寬帶引擎?上RSX?和SPE之間的lightpre-pass渲染工作分開(kāi)。我們利用這兩個(gè)組件的有點(diǎn)來(lái)達(dá)成我們的優(yōu)勢(shì)。：RSX?渲染pre-pass集合的光柵性能和SPE計(jì)算照明緩沖的向量數(shù)學(xué)性能。通過(guò)在SPE上的并行照明計(jì)算，和RSX?上的其他渲染（例如，動(dòng)態(tài)立方體貼圖），照明變成免費(fèi)的，這是一個(gè)主要的GPU優(yōu)化。事實(shí)上，即使沒(méi)有額外的并行化，我們發(fā)現(xiàn)，在某些情況下，在進(jìn)行照明計(jì)算時(shí)，五個(gè)SPE運(yùn)行精心打造的程序比RSX?效果要好。

Blur的另一張截圖
隨著新架構(gòu)的出現(xiàn)，我們相信將有越來(lái)越多的機(jī)會(huì)把處理負(fù)載從GPU上轉(zhuǎn)移到CPU上。當(dāng)把GPU和CPU在因特爾Larrabee 上結(jié)合起來(lái)時(shí)，事情將如何發(fā)展還有待觀察。[ Seiler08 ]，但在Cell寬帶引擎?上，我們提供的GPU在以下情況中可以大大加快：如延遲照明或通過(guò)編寫(xiě)在SPE上運(yùn)行的自定義CPU實(shí)現(xiàn)lightpre-pass渲染。

9. 未來(lái)工作

我們所描述的技術(shù)可以做很多改進(jìn)的地方。首先，我們現(xiàn)在忽略了光照模型中的鏡面反射。我們建議要么寫(xiě)出到另一個(gè)緩沖區(qū)，要么如[Engel09]所述，在照明緩沖區(qū)的alpha通道中放一個(gè)單色反射項(xiàng)?？梢酝ㄟ^(guò)在法線緩沖區(qū)的alpha通道中增加鏡面反射強(qiáng)度來(lái)控制材料屬性。另一個(gè)問(wèn)題是，我們的照明目前是LDR，它存儲(chǔ)以8:8:8:8整數(shù)格式存儲(chǔ)。一種選擇是改到16:16:16:16浮點(diǎn)型，但Wilson認(rèn)為，應(yīng)該采用CIE LUV色彩空間[ Wilson09 ]。使用這種方法，我們還可以使用一個(gè)8:8:8:8緩沖，但顏色的亮度部分使用16位。這一技術(shù)在GPU上有問(wèn)題，因?yàn)闊艄獐B加在一起不再起作用，但在SPE程序中，我們沒(méi)有這樣的問(wèn)題，這是比較可行的；如果你想實(shí)現(xiàn)更多的GPU技術(shù)，漫射光的強(qiáng)度也可以存儲(chǔ)在apha通道中，如[Valient07 ]所述。

前面的兩個(gè)建議都包括在照明緩沖區(qū)中使用當(dāng)前未使用的alpha通道。雖然這個(gè)字節(jié)肯定有很多可能的用途，但我們目前正在研究的一個(gè)想法是存儲(chǔ)每個(gè)像素的霧量。我們認(rèn)為，如果使用高度霧，這對(duì)于更昂貴的霧化方程來(lái)說(shuō)尤其有利。這是向SPE程序[Swoboda09a ]增加值的例子。

考慮到已經(jīng)完成的工作，包括處理整個(gè)法線和深度緩沖，還有額外的渲染工作可以在SPE程序中完成。一個(gè)簡(jiǎn)單的例子是把深度緩沖到向下采樣到四分之一分辨率——可以通過(guò)MFC異步輸出，增加一點(diǎn)SPE程序開(kāi)銷，而且對(duì)于許多降低分辨率的效果是有用的，如運(yùn)動(dòng)模糊、遮擋剔除甚至屏幕空間環(huán)境光遮蔽?？梢酝ㄟ^(guò)把視圖空間的法線和深度合并為一個(gè)32位的緩沖，減少對(duì)法線深度緩沖的處理量。通過(guò)把法線X和Y分量編碼進(jìn)入頭兩個(gè)通道中（或轉(zhuǎn)化為球面坐標(biāo)），把線性視圖空間深度打包進(jìn)其余的16位。這使我們的SPE程序所需的數(shù)據(jù)量減半。事實(shí)上，這種方法就是我們?yōu)樽罱K版本的Blur選擇的方法。

最后，我們打算徹底溢出緩沖區(qū)的解碼，并在編碼的法線/深度緩沖區(qū)上進(jìn)行照明，這有幾個(gè)優(yōu)點(diǎn)。解碼過(guò)程可以通過(guò)把幀緩沖塊中所有像素用簡(jiǎn)單通道來(lái)代替，這將導(dǎo)致整體照明性能的輕微提高，同時(shí)節(jié)省照明緩沖所需的存儲(chǔ)器。然而，這種額外的性能和改進(jìn)的內(nèi)存占用是以數(shù)學(xué)復(fù)雜性的增長(zhǎng)為代價(jià)的，因?yàn)榕缮袼氐囊晥D空間位置變得事關(guān)重大。這是因?yàn)樾枰紤]編碼緩沖區(qū)格式對(duì)像素的最終視圖空間位置的影響。

10. 致謝

首先，我們要真誠(chéng)地感謝SCEE研組的發(fā)Matt Swoboda，他為我們的持續(xù)努力奠定基礎(chǔ)，并為我們的實(shí)現(xiàn)方法提供建議。我們也要感謝SCEE研發(fā)組的Colin Hughes，感謝他的幫助和優(yōu)化建議。

我們也要感謝所有的超級(jí)天才，他們組成了BizarreCreations公司的核心技術(shù)團(tuán)隊(duì)，尤其是Ian Wilson, Paul Malin, LloydWright, Ed Clay, Jose Sanchez, Charlie Birtwistle, Jan van Valburg, Kier Storey,Fengyun Lu, Jason Denton, Dave Hampson, Chris Cookson 以及 Richard Thomas.

11. 參考文獻(xiàn)

[Acton08]M. Acton, E. Christensen, “無(wú)休SPU的最佳實(shí)踐,”http://www.insomniacgames.com/te ... ogramming_gdc08.php, 發(fā)表于2009.7.2.

[Bader07]D. A. Bader, “Cell 編程小貼士技巧,”http://www.cc.gatech.edu/~bader/CellProgramming.html, 發(fā)表于2009.7.2.

[Balestra08]C. Balestra 和 P. Engstad, 未知的技術(shù)：德雷克的寶藏，2008游戲開(kāi)發(fā)者大會(huì)上，鏈接：HTTP：/ / www.naughtydog。COM /公司/出版社/ 202008 /unchartedtechgdc2008.pdf[Capcom06]Capcom Inc. “MT框架,” http://game.watch.impress.co.jp/docs/20070131/3dlp.htm,發(fā)表于2009.7.3.

[Day08]M. Day, J. Garrett, “更快的SPU壓縮,”http://www.insomniacgames.com/te ... aster_spu_clamp.php,發(fā)表于2009.7.2.

[Deering88]M. Deering, “三角形處理器和普通矢量著色器：高性能圖形的VLSI系統(tǒng)，” SIGGRAPH 1988.

[Engel08]W. Engel, “Light Pre-Pass 渲染器,”

http://diaryofagraphicsprogramme ... -pass-renderer.html,accessed on 4th July 2009.

[Engel09]W. Engel, “Designing a Renderer for Multiple Lights: The Light Pre-PassRenderer,” in ShaderX7, edited by Wolfgang Engel, Charles River Media, 2008:pp. 655-666.

[Engel09a]W. Engel, “Light Pre-Pass 渲染器 Mach III,” 出現(xiàn)在ACM SIGGRAPH09會(huì)議上, 2009.

[IBM08]IBM公司，Cell寬帶引擎編程手冊(cè)1.11版。

[IBM08a]IBM公司，協(xié)同處理單元指令集體系結(jié)構(gòu)。

[IBM09]IBM公司。IBM的Cell項(xiàng)目，http://researchweb.watson.ibm.com/cell/home.html，2009年7月4日。

[M?ller08]T. Akenine-M?ller, E. Haines, N. Hoffman, “Real-Time Rendering 3rd Edition,”978-1-56881-424-7, A.K. Peters Ltd. 2008.

[Perthuis06]C. Perthuis, “PS3圖形管線簡(jiǎn)介,” 歐洲制圖學(xué)會(huì)2006.

[Seiler08]L. Seiler, D. Carmean, E. Sprangle, T. Forsyth, M. Abrash, P. Dubey, S.Junkins, A. Lake, J. Sugerman, R. Cavin, R. Espasa, E. Grochowski, T. Juni, P.Hanrahan, “Larabee: 用于可視化計(jì)算的多核x86體系結(jié)構(gòu)，” ACM圖形事務(wù),27卷, 三期, ACM SIGGRAPH 2008,2008.8.

[Shippy09]D. Shippy, M. Phipps “新型游戲機(jī)：在新Xbox360和Playstation 3內(nèi)部創(chuàng)建芯片,” 978-0-8065-3101-4, Citadel Press, 2009.

[Swoboda09]M. Swoboda, 延遲照明和后處理的PlayStation? 3，游戲開(kāi)發(fā)者大會(huì)2009 ，鏈接：http://www.technology.scee.net/f ... ProcessingonPS3.ppt[Swoboda09a]M. Swoboda, 私人信件, 2009.

[Valient07]M. Valient, “《殺戮地帶2》中的延遲渲染,” http://www.dimension3.sk/mambo/D ... ing-In-Killzone.php,發(fā)表于2009.7.4.

[Wilson09]P. Wilson, “Light Pre-Pass 渲染器：使用CIE Luv 彩色空間,” 發(fā)表于在ShaderX7, Wolfgang Engel, CharlesRiver Media編輯, 2009: pp.667-677.

[1]“PlayStation”, “PLAYSTATION”和“PS” 家族徽標(biāo)是注冊(cè)商標(biāo)，“Cell寬帶引擎”是索尼計(jì)算機(jī)娛樂(lè)公司的商標(biāo)，“Blu ray Disc”和“Blu ray Disc”徽標(biāo)是商標(biāo)。[2]Blur的截圖表現(xiàn)了動(dòng)視暴雪公司和Bizarre Creations有限公司的興趣。

[3] 八個(gè)SPE中的一個(gè)被鎖定以提高芯片的產(chǎn)量，另一個(gè)是由索尼的Cell操作系統(tǒng)保留。在PlayStation?3上運(yùn)行的應(yīng)用程序?qū)嶋H可以利用六個(gè)SPE。

[4] 正如人們所期望的，線性訪問(wèn)模式比隨機(jī)訪問(wèn)明顯好得多。

[5] 關(guān)于如何解碼，索尼PlayStation?3開(kāi)發(fā)者可以咨詢RSX?用戶手冊(cè)。

[6] 我們目前沒(méi)有對(duì)照明結(jié)果進(jìn)行編碼，請(qǐng)關(guān)注我們未來(lái)的工作以了解更多信息。

[7] 在我們的實(shí)現(xiàn)中，單個(gè)循環(huán)中的任何像素都有可能導(dǎo)致寄存器溢出。

[8]SOA組織也稱為“并行數(shù)組”。

via：Gad

銳亞教育，游戲開(kāi)發(fā)論壇|游戲制作人|游戲策劃|游戲開(kāi)發(fā)|獨(dú)立游戲|游戲產(chǎn)業(yè)|游戲研發(fā)|游戲運(yùn)營(yíng)| unity|unity3d|unity3d官網(wǎng)|unity3d 教程|金融帝國(guó)3|8k8k8k|mcafee8.5i|游戲蠻牛|蠻牛 unity|蠻牛