• single-pass, multi-light
• multi-pass, multi-light
• deferred shading

Single-pass, Multi-light

for each object:
　render object with all lights in one shader


此種作法是最單純且直接，但是此方式會連 hidden surface 也一併 shading ，造成運算上的浪費。此外，當光源數目 N 很大的時候，shader code 必須擴展進而去計算每盞光源的作用。但若是指令數超過 shader model 的限制時(視 shader model 而定)，就不得不拆成多個 render pass。

Multi-pass, Multi-light

for each light:
　for each object affected by light:
　　render target += BRDF(object, light)

這方式是將每盞燈光的所影響的結果累加於 render target，+= 的部分是透過 ping-pong 的方式在兩個 render target 之間作替換。然而 invisible surface 所造成的計算浪費仍舊沒有獲得解決之道，新增的 geometry pass 也在 vertex transform 與 setup 的部分帶來了額外的開銷。這部份的問題，雖然可以透過粗略的 front-to-back sorting 獲得一些抒解，但 deferred shading 卻對此問題有著更根本的解決方案(當然也會帶來其他的限制)。

Deferred Shading

for each object:
　render lighting properties to G-buffer
for each light:
　render target += BRDF(G-buffer, light)

Deferred shading 之所以能解決 hidden surface 所造成的 shading 浪費，主要是因為它在第一階段先輸出 position, normal 與其他參數至 G-buffer。使第二階段的 lighting 運算能完全作用在 visible 的 fragment 上，同時也有助於降低 light/object 之間的相依性，藉此達到 render 效率的提升。一切看起來似乎都很美好，但故事就這樣結束了嗎？喔！不，故事才剛開始…

每個 pixel 的顏色在 lighting 的階段是由 ambient, diffuse 和 specular 這三個部分所組合而成的。由於 deferred shading 一般都把 ambient light 和 environment light 的部分拆在其他 pass 獨立運算，因此在僅考慮 local lighting model 的情況下，deferred shading 的公式主要可分為 diffuse 和 specular 兩個部分：

其中 和 是 diffuse 和 specular 的 local reflection model(ex. lambert, phong, blinn, … etc)， 是 surface 的 diffuse 和 specular color， 與 則分別代表著第 k 盞燈光的方向與 intensity。

傳統的 deferred shading 大致將上式的運算分解成下列步驟：

1. render 場景內非透明的物件，並將所需的參數存至 G-buffer (ex. position, normal, albedo, roughness, … etc)。
2. render 一個 image plane (screen space quad)，在 pixel shader 中透過 texture sampler 讀取所需的參數並完成上面 shading 的計算。
3. 按照 back-to-front 的順序，render 場景中透明的物件。

現在，light/object 的相依性已經從原先的 O(MN) 轉變至 O(N)，也就是說，現在運算複雜度主要會卡在步驟 2 的 fill-rate。其效率主要受到兩個因素所影響：傳輸 G-buffers 所需的 bandwidth 與燈光的個數 N 。

G-buffers 所儲存的資訊和場景中那 M 個 material 有著密切的關係，當 M 個 material 的 reflection model 過於複雜時，G-buffers 必然要儲存更多的資訊，否則便無法在步驟 2 中完成相對應的 shading 計算。因此，降低 bandwidth 的方式便是針對場景內 M 個 material 的內容作進一步的調整與簡化，試圖在 visualization 和 computation 之間作個取捨。而 G-buffers 裡各參數的配置也要作更詳盡的規劃，使其盡可能滿足 MRT 的 layout 以便增進步驟 1 中 G-buffers 的輸出效率。

有了 G-buffers 所提供的 material 資訊之後，便可在步驟 2 中搭配 lights 的各項參數完成 shading 的計算。為了要在一個 pixel shader 中同時支援 directional lights, spot lights 和 point lights 的運算，直覺的作法便是在 pixel shader 中用 branch 分派運算的內容，並盡可能在同一個 pass 處理複數盞燈(因為一旦 N 的數目變大，accumulate 的成本便隨之提升)。此外，為了增進 fill-rate ，對於 spot lights 和 point lights 等具範圍性的光源，尚可以搭配 stencil buffer 來濾掉一些燈光所照射不到的 pixels ，盡可能地降低 pixel shader 的負擔。

Light Indexed Deferred Lighting

既然，material 的複雜度會嚴重影響到 bandwidth，那何不反過來，把參數複雜度較為固定的 light 資訊存進 buffers 中呢？LIDL [Damian Trebilco] 的概念就是作了一個這樣的嘗試，不過它不是在每個 shading pixel 裡直接紀錄 light 的參數(ex. position, color, attenuation, … etc)，而是先賦予每個 light 一個獨立的 index，將其記錄在每個 shading pixel 中，然後透過這 index 去另一批參數 buffers 擷取 light 的參數。主要的步驟大致如下：

1. render depth。
2. 將每盞燈影響的範圍(light volume)  render 至 light index texture。
3. 用 forward rendering 的方式 render geometry，從 light index texture 擷取參數並完成 lighting 的運算。

步驟 1 是為了讓步驟 2 能免去 hidden surface 造成的運算浪費。步驟 2 主要的目的則是記錄每個 pixel 會被哪些燈光所影響，降低後續 lighting 計算方面的開銷。儘管現在需要 cache 的參數相對降低，但在步驟 2 中有時會發生 light volume 重疊的情況。RGBA 共可以記錄 4 個 indices，倘若每個 pixel 受到超過 4 盞光源的照射，一種作法是按照 priority 篩選出 4 盞燈光，或是增加 buffer 來記錄更多組 index(但除非每個 pixel 都被超過 4 個的光源所照射，不然在一般情況下，這方式恐怕不會帶來令人滿意的效益)。

除了 light index texture 之外，還需要另一批 textures 來儲存每盞燈光的各項參數。根據燈光種類的不同，各參數於 textures 中的配置會是另一項議題。若參數儲存配置不得宜，一樣會造成 bandwidth 的瓶頸。要舒緩這部份的問題，還是需要做出取捨，去調整與簡化 lighting 運算的實作才行。

Pre-Lighting / Light Pre-Pass Render

為了降低傳統 deferred shading 於 bandwidth 的瓶頸，pre-lighting/light pre-pass render 的觀念也在近幾年應運而生[Wolfgang Engel] [CryEngine3]。和以往最大不同的地方是它把 lights 相關的性質(ex. light color, attneuation, N.L, …etc)，再進一步從 shading 公式中抽離出來：

1. render 非透明的物件，輸出 normal, depth 等資訊。
2. render 一個 screen quad pass，將 lights 的屬性輸出至 light buffers。
3. 再 render 一次場景內所有不透明的物件，搭配 light buffers 的各項資訊完成每個 material 的 shading 計算。
4. render 場景內透明的物件。

這方式最大的優點是有效降低參數傳遞的 bandwidth，但是它最大的代價是需要兩次 geometry pass (步驟 1 和 3 )。此外，步驟 2 輸出的資訊可能無法充分滿足 material 的運算式，進而造成 material 設計彈性上的犧牲(像是 roughness 在步驟 2 中便無法得到確切的數值，替代方案是用定值或是從步驟 3 中 reconstruct 出 R.V 再運算 roughness 的影響)。此法的中心思想是降低 bandwidth，所以步驟 1 和 2 輸出的資訊自然也不能為了滿足 material 的運算而過度膨脹，若是 bandwidth 沒有達到某種程度的節約，第二次的 geometry pass 就會顯得不太值得，變成無謂的額外開銷。

以上，便是我目前為止對 deferred shading  粗淺的認識。基本上，deferred shading 的目的就是要去除 invisible surface 的 shading 浪費，同時並降低 light 與 object 之間的耦合度，使其在 M 個 material 相異的物件與 N 盞 lights 的情況下，盡可能地提升 render 的效率。各種形式的 deferred shading 都沒有絕對的優劣高下，所以在實際應用的過程中，還是免不了要在彼此的優缺點中不斷地作出權衡與取捨…

References

• Deferred lighting approaches from Real-Time Rendering
• The Light Pre-Pass Renderer – Designing a Renderer for Multiple Lights, by Wolfgang Engel
• 6800 Leagues Deferred Shading
• Photo-realistic Deferred Lighting from Beyond3D

上次只用一個 thread 算 y-twist 的時候成效不彰，這次便把它拆成一堆 thread blocks 來試試看!!

先前提到要讓 SM 中平行處理的 wraps 數目越多越好，使其盡可能地增進平行化的效能。但在這次實驗的發現，y-twist 的 kernel 在 block size 設定為 512 或是 64 個 threads 去 deform 99 萬個 vertices 時，運算時間的差距其實只在 1 ms 左右。所以接下來便以每個 block  含 512 個 threads 為前提，將 memory access 的部分作為變因，再繼續作一些小測試。

將上次 kernel 中的 for loop 展開成 1D 的 grid ，每個 grid cell 含有一個 2D block 會變成下面這個新的 kernel：

__global__ void gpu_twist(float4 pts[], float magnitude, float env)
{
	int k = blockIdx.x * BLOCK_WIDTH * BLOCK_WIDTH + threadIdx.y * BLOCK_WIDTH + threadIdx.x;

	float ff = magnitude * pts[k].y * env;
	if( ff != 0.0f )
	{
		double cct = __cosf(ff);
		double cst = __sinf(ff);
		double tt = pts[k].x * cct - pts[k].z * cst;

		pts[k].z = pts[k].x * cst + pts[k].z * cct;
		pts[k].x = tt;
	}
}

拆成多個 threads 之後，運算時間便從 1620 ms 大幅降為 19 ms，而對照組 CPU 版本的計算時間則是大約在 120 ms 左右(可見在 GPU 只用一個 thread 作運算有多麼搞笑)。現在 kernel 裡的變數除了幾個是 automatic variable 之外，其餘都是來自 global memory。因為 y-twist 的運算單純到沒變數需要 share，所以接著要作的事便是把一些多次存取 global memory 的部分轉至 automatic variable 中。不過我在這過程中犯了一個錯誤：我原先認為 pts[k].y 只被讀取一次，若將其放進 automatic variable 中，反倒多浪費一個 register，似乎不太划算，因此我最初只把重複存取的 pts[k].x 和 .z  放進 automatic variable 中:

float ptX = pts[k].x;
float ptZ = pts[k].z;

雖然這樣也可獲得一些成效，使計算時間降至 15.7 ms 左右，但後來在翻閱 programming guide 時發現了下面這一段話：

the device is capable of reading 32-bit, 64-bit, or 128-bit words from global memory into registers in a single instruction.

這代表直接把 pts 讀進 float4 其實比拆成兩個要有效率：

float4 pt = pts[k];

另一個重點是 kernel automatic variable 的個數其實並不直接等於 register 的個數!! 雖然它一般都會被放進 register 裡頭，但若遇到比較複雜的 structure 或是 array 時，這些變數是會放至 local memory 裡的 (其存取的 cost 和存取 global memory 是差不多的)。但這些資訊很難直接從程式碼中推測出來，有時稍微變更一下 expression 的順序，便會影響 register 的使用數目。若需精確查詢 kernel 裡面 register 的使用數目或是 shared/local/const memory 的使用量，有以下兩種方式：

• 將 PtxAsOptionV 設為 Yes (–ptxas-options=-v)
  之後在 build 的時候，便可以在 output panel 看到每個 kernel 的資源使用狀況。
• 開啟 keep preprocessed files
  相關資訊都寫在 .cubin 檔案中每個 code 區塊的標頭裡。

此外， SDK 也提供了一個很實用的 excel 檔案 — “CUDA_Occupancy_calculator”。只要先選擇現在使用的 compute capability，並將剛剛那些查詢得來的數值一一輸入相對應的欄位，便可掌握目前 SIMT 配置 threads 的概況。

結果把 pts 的讀取方式作修改之後，每個 kernel 中使用的 register 數目雖由 6 個增為 8 個，但此數值仍是在安全範圍內。最後計算的時間則是再快個 1 ms，時間約為 13.7 ms。哈! Hello World 差不多告一段落了，該是找實戰練習題的時候了!!

CUDA 的架構是由 N 個 SM (streaming multiprocessor) 所構成的，而每個 SM 內含有 M 個 SP (scalar processor) 、 shared memory 和其他硬體原件。當 host CPU 呼叫 kernel function 時，硬體是以 block 為單位將工作分派給目前有能力處理的 SM 進行(據說以 block 為單位是為了方便 porting 至其他硬體)。當 SM 接受到任務之後，便會處理手頭上的 blocks，執行其中所包含的 threads。當手邊任一個 block 裡的 threads 皆執行完畢之後，該 SM 才能再去多接另一個新的 block 的工作。

那 SM 是如何處理 block 呢？ CUDA 是透過一個稱為 SIMT (single-instruction, multiple-thread) 的架構來處理整個流程。SIMT 會將數以千百計的 threads 分成一堆 wraps，每個 wrap 內含 K 個 ID 連續的 threads，並以 wrap 為單位作排程。在處理每個 wrap 時，SIMT 會將其中的每一個 thread 批次對應於每個 SP，而這些 thread 都保有自身 register 的狀態，並在同一時間各自獨立地執行某個相同的 instruction。

在G80的架構下，每個 SM 有8個 SP，每個 wrap 有 32 threads。所以每個 wrap 在執行每項指令時，總共需要 32/8 = 4 輪，才能處理完畢。而該 wrap 會一直執行，直到指令全部結束或是停在需要 sync 的位置，SIMT 這時便會選擇其他等待執行的 wrap 來遞補接替，如此反覆交替進行到全部的 wraps 皆處理完畢為止。至於branch 的部分，SIMT 則會執行每一個分歧的路線，最後在根據每個 thread 的狀態，選擇符合條件的結果。

從上述的流程中，我們可以發現到，真正平行處理的 threads 其實是每一個 SP 當下所處理的 thread，而這些 threads 則是來自於每個 wrap 中的某一輪。所以為了要 hide I/O latency，便要盡可能增加 wrap 的數量，使 SIMT 在排程時有更多的選擇(盡量讓硬體總有事情可作，避免讓它晾在那裡等 I/O 之後的 synchronization)。但是為了要增加平行處理的 thread 數量，單單只增加 gridDim 和 blockDim 的值來呼叫 kernel function 是不夠的(值越大還不見得比較好，有時候反會導致平行執行的 threads 更少)，我們還必須考量 Compute Capability 所帶來的限制。以 Compute Capability 1.0 為例：

• 每個 block 中最多只能有 512 threads
• 每個 wrap 含有 32 threads
• 每個 SM 最多只能有8個block、24個wraps、768個threads

再看以下幾種 block 設定與每個 SM 所含最多 thread 數目的關係：

雖然 CUDA 程式的執行效能不單只受平行處理的 threads 數目所影響，memory access 的 pattern 也是另一個重要的因素。但是在優化程式過程中，若發現平行 threads 的負載量已經到達某種極限時，便可以摒除這部分的因素，朝其他方面著手。以免投注太多心力於錯誤的方向，造成事倍功半的遺憾。在 CUDA 的架構下，如何將有限的資源，發揮最大的效用，之中還有很多課題需要再進一步地學習與探索。希望，有一天，我也能找到 CUDA 的方向感!!

環境設定

在撰寫 CUDA 的程式碼之前，我們必須先在原來的 cpp project 中新增一條 build rule…

將 CUDA SDK 附的 Cuda.rules 加入列表並啟用…
(為了方便起見，我們可先新增一個環境變數 CUDA_SDK_PATH 使其指向 CUDA SDK 的安裝位置。 而 Cuda.rules 所在的位置則是在 $(CUDA_SDK_PATH)common 裡面)

啟用 Cuda.rules 之後， project properties 便會出現一個 CUDA 的分類，一些相關的參數都可以在這裡作設定。

程式重構

環境設定完之後，我們新增一個 .cu 的檔案，實作與 cpp code 的溝通介面以及處理 y-twist 的 kernel function

#include
#include 

__global__ void  gpu_twist(float4 pts[], int len,
                           float magnitude, float env)
{
	for(int k=0; k<len; k++)
	{
		float ff = magnitude * pts[k].y * env;
		if( ff != 0.0f )
		{
			double cct= cosf(ff);
			double cst= sinf(ff);
			double tt = pts[k].x * cct - pts[k].z * cst;

			pts[k].z = pts[k].x * cst + pts[k].z * cct;
			pts[k].x = tt;
		}
	}
}

extern "C"
void	gpu_calc(float ptData[][4], unsigned int len,
                        float magnitude, float env)
{
	const unsigned int memSize = len * sizeof(float) * 4;
	float4 *d_data;

	cutilSafeCall( cudaMalloc((void**) &d_data, memSize) );

	// Copy data to gpu memory
	cutilSafeCall( cudaMemcpy(d_data, ptData, memSize,
                                     cudaMemcpyHostToDevice) );

	// Invoke the kernel with one thread
	gpu_twist<<<1,1>>>(d_data, len, magnitude, env);

	// Copy result from gpu memory to host memory
	cutilSafeCall( cudaMemcpy(ptData, d_data, memSize,
                                    cudaMemcpyDeviceToHost) );

	cudaFree(d_data);
}

回到原來的 yTwistNode.cpp 補上溝通介面的宣告，並對 deform function 作一點小幅修改…

extern "C"
void	gpu_calc(float ptData[][4], unsigned int len, float magnitude, float env);

MStatus
yTwist::deform( MDataBlock& block,
		MItGeometry& iter,
		const MMatrix& m,
		unsigned int multiIndex)
{
	MStatus status = MS::kSuccess;

	// determine the angle of the yTwist
	//
	MDataHandle angleData = block.inputValue(angle,&status);
	McheckErr(status, "Error getting angle data handlen");
	double magnitude = angleData.asDouble();

	// determine the envelope (this is a global scale factor)
	//
	MDataHandle envData = block.inputValue(envelope,&status);
	McheckErr(status, "Error getting envelope data handlen");
	float env = envData.asFloat();

	// { Modified block
	MPointArray ptArray;
	status = iter.allPositions(ptArray);

	// Get raw data
	float (*rawData)[4] = new float[ptArray.length()][4];
	ptArray.get(rawData);

	// Invoke cuda
	gpu_calc(rawData, ptArray.length(), magnitude, env);

	// Retrieve the data
	for(int i=0; i<ptArray.length(); ++i)
	{
		ptArray.set(rawData[i], i);
	}
	delete [] rawData;

	iter.setAllPositions(ptArray);
	// } End of modified

	return status;
}

接著在 project properties 補上一些相關設定:

• Additional Include Directories
  $(CUDA_INC_PATH); $(CUDA_SDK_PATH)commoninc
• Additional Library Directories
  $(CUDA_LIB_PATH); $(CUDA_SDK_PATH)commonlib
• Additional Dependencies
  cudart.lib cutil32D.lib
• CUDA 的 Additional Include Directories
  “$(CUDA_SDK_PATH)commoninc“
  Ps. 這裡的 path 記得要 quote 起來，不然會有 nvcc fatal : A single input file is required for a non-link phase when an outputfile is specified 的錯誤訊息!!

最後的步驟當然是 build & execute 囉!! 至於執行效能，還真的如預期中的慢!? 這是因為 y-twist 其實也沒做多少事，花在 memcpy 的時間搞不好還比計算的時間多。加上我全部的資料都宣告在 global memory ， thread 也只用一個而已。所以執行效能較慢也是預料中的事情，不過經過這一次的實驗，總算大致熟悉了從 cpp project 引入 CUDA 的流程，也終於在 CUDA 的世界中心呼喊 Hello World 了!!