使用OpenCL實現互動式光子映射

全文

(1)國立臺灣師範大學資訊工程學系碩士學位論文. 使用 OpenCL 實現互動式光子映射. Interactive Photon Mapping in OpenCL. 研究生：. 林郁凱. 撰. 指導教授：. 張鈞法. 博士. 中華民國. 一百零三年. 七月.

(2) 摘要近年來圖形處理器運算能力大幅增加，其應用紛紛走向通用圖形處理器的發展模式，藉由圖形處理器多個計算單元平行化計算的能力，可使運算效率顯著的提升，在各家廠商的支持下亦發展了開放式計算語言平台，使得在圖形處理器上設計程式的功能便利許多，並能夠有效率地處理 3D 圖學所需的大量運算。為了使 3D 場景的繪製達到更逼真的畫質，至今已經發展了許多不同的演算法以模擬真實環境的光照情形，其中，光線追蹤方法擁有數學運算的正確性並能夠直覺性地計算光照效果，若搭配光子映射所具備的環境照明資訊，則具備繪製出擬真畫質的潛力，但是，由於需要非常龐大的計算量，使用傳統的架構都有速度上的限制，因而必須對畫面品質與渲染速度做出抉擇。幸運地是，光線追蹤演算法具有容易平行化計算的特性，可對所渲染畫面中的每一個像素平行地計算出光照色彩，利用此一特性，配合最近蓬勃發展的通用圖形處理器之能力，可得到大幅度的效能提升。本研究渲染的對象為靜態場景，利用 OpenCL 能夠在異質系統架構中平行且良好地運作之特性，我們在現今常用的裝置實現光線追蹤以及光子映射演算法，並將重點著重於可行性的探討與提升程式效能，針對所使用的平台進行實驗結果比較以及影響效能的相關探討，最後，我們將因應平台特性將演算法與之結合，試圖找出在多核心平行化架構下提升各平台程式效能的實驗依據，並且針對光子映射演算法進行改良，使其能更加符合平行化架構特性，快速渲染出具備全域照明品質的畫面。. 關鍵字光線追蹤、光子映射、全域照明、平行運算、OpenCL、異質系統架構。.

(3) Abstract In recent years, the computing power of graphics processor has increased gradually, and the GPGPU application model is more popular now. The ability of parallel computing in graphics processors can significantly enhance computing efficiency. And the support of various vendors to open computing language (OpenCL) platform, leads to convenient features and the ability to handle memory using multiple layers with different bandwidth. Also, OpenCL is a good interface for the heterogeneous system architecture (HSA) implementations because it naturally supports cross-platform and parallel programming of modern processors. In order to improve the image quality, a number of different algorithms have been developed to simulate real-world lighting situations in 3D rendering, where the math correctness of ray tracing and the ability to calculate various lighting effects have been proved. By using the information of the illumination environment such as photon map, the image quality will get more close to photo-realistic image. However, we must make a choice between render speed and image quality on traditional architecture because the huge amount of calculation. Fortunately, the ray tracing algorithms have parallel computing feature, which can render each pixel on the screen in parallel. We take advantage of this feature to obtain a significant performance boost on GPGPU platforms. In this research, we render static scene and focus on fast rendering and global illumination effects. We implement ray tracing and photon mapping algorithms on today's commonly used devices in OpenCL and analysis the characteristics of the algorithms to adjust to OpenCL platform. We also focus on the feasibility to enhancing program performance by some experimental results and try different way to make improvements for the photon mapping algorithm.. Key Words Ray Tracing, Photon Mapping, Global Illumination, Parallel Computing, OpenCL, Heterogeneous System Architecture.. II.

(4) 目錄摘要.......................................................................................................................... I 關鍵字...................................................................................................... I Abstract .................................................................................................................. II Key Words .............................................................................................. II 目錄..................................................................................................................... III 附圖目錄................................................................................................................ V 附表目錄............................................................................................................... VI 第一章緒論........................................................................................................... 1 1.1 背景.......................................................................................................... 1 1.2 研究動機.................................................................................................. 1 1.3 研究目標.................................................................................................. 2 1.4 論文架構.................................................................................................. 2 第二章. 文獻探討............................................................................................. 3. 2.1 Global Illumination ................................................................................... 3 2.1.1 Ray Tracing .................................................................................... 3 2.2 Photon Mapping on GPGPU ..................................................................... 4 2.2.1 Photon Emission ............................................................................ 4 2.2.2 Final Gathering .............................................................................. 4 2.3 OpenCL Platform ...................................................................................... 5 2.3.1 Execution Model ............................................................................ 5 2.3.2 Memory Model .............................................................................. 6. III.

(5) 第三章. 系統實作............................................................................................. 7. 3.1 Ray Tracer ................................................................................................. 8 3.1.1 Shadow Ray ................................................................................... 9 3.1.2 Phone Shading ............................................................................... 9 3.2 K-D Tree ................................................................................................... 9 3.2.1 Construction Method ................................................................... 10 3.2.2 Traversal Function ....................................................................... 11 3.3 Photon Emission ..................................................................................... 12 3.4 Final Gathering ....................................................................................... 12 3.4.1 Basic Method ............................................................................... 13 3.4.2 Tile Gathering .............................................................................. 13 第四章. 實驗結果分析................................................................................... 15. 4.1 K-D Tree ................................................................................................. 15 4.1.1 Thread Divergence ....................................................................... 16 4.2 Cross-Platform ........................................................................................ 17 4.3 Gathering Method ................................................................................... 18 4.3.1 Tiled Method ................................................................................ 19 4.3.2 Number of Photons ...................................................................... 20 4.4 Global Illumination ................................................................................. 21 4.4.1 Reflection and Refraction ............................................................ 22 4.4.2 Caustic.......................................................................................... 22 第五章. 結論與未來研究............................................................................... 24. 附錄....................................................................................................................... 26 參考文獻............................................................................................................... 28 其他參考資料....................................................................................................... 29 IV.

(6) 附圖目錄圖 1：系統流程圖。 ................................................................................................. 7 圖 2：直接光照成果圖。 ......................................................................................... 8 圖 3：3000 顆光子可視化之後的畫面效果，採用光線追蹤渲染。 .................. 11 圖 4：效能倍數差距折線圖。 ............................................................................... 16 圖 5：光子數量對於畫面影響之比較。 ............................................................... 20 圖 6：Direct Illumination、Global Illumination 之成果比較圖。 ........................ 21 圖 7：鏡面反射場景效果。 ................................................................................... 23 圖 8：玻璃材質 bunny 場景的折射與焦散效果。 ............................................... 23. V.

(7) 附表目錄表 1：我們的實驗環境 ........................................................................................... 15 表 2：K-d tree 於不同架構之效能 ......................................................................... 16 表 3：使用 k-d tree 於光子發射階段之加速效能 ................................................. 17 表 4：各裝置上直接光源的光線追蹤之效能數據 ............................................... 18 表 5：光子映射於 Intel HD Graphics 5000 上使用不同方法之效能表 .............. 19. VI.

(8) 第一章緒論 1.1 背景圖形處理器(GPU)運算模式大幅演進，走向通用圖形處理器(GPGPU)的發展模式，運算效能越趨強大，在各家廠商支持下亦發展了開放式計算語言(OpenCL)，使得在 GPU 上設計程式的功能便利許多，並且藉由多核心平行化的方式將能夠有效的處理計算機圖學龐大的計算量。而 3D 場景繪製為了達到逼真的畫質，發展了許多不同的方法計算光照，其中全域照明(global illumination)是達成擬真效果(photo realistic)的里程碑，它能夠考量到直接照明(direct illumination)、間接照明(indirect illumination)、反射、折射、焦散(caustic)等效果。. 1.2 研究動機近年來的研究多利用 GPU 平行計算作為光線追蹤(ray tracing)的加速方式，為了計算全域照明，使用了接近暴力法(brute force)的方式在場景中發射大量光線，去模擬真實環境中的光照情形，然而，此方法針對光源模擬的方式通常只限制在場景中只包含同一種光源，若環境光源是較為複雜的情形將受到很大挑戰。另一個計算全域照明的方式則是使用光子映射(photon mapping)，先行在場景發射大量光子做為光照能量的資訊，在最終彙集(final gathering)階段則蒐集這些光子資訊進行渲染(rendering)，然而，最終彙集運算量非常龐大，近年來特定平台上的研究雖然發展了許多不同的加速方法，但大多不能兼顧效率與畫質，更缺發跨平台的彈性。. 1.

(9) 1.3 研究目標以往的研究雖然在最終彙集的議題上雖有不少進展，但在運算速度、品質上多有取捨。大多數的研究都無法有效符合 SIMT 的特性，更缺乏跨平台運算的彈性。本研究希望透過光子映射的技術，在 OpenCL 跨平台的彈性基礎上，配合 GPU 平行化架構特性(SIMT)，有效利用共享記憶體區塊，加速最終彙集的步驟，期望能夠達到良好的效率與畫面品質，使其應用能夠更加廣泛。. 1.4 論文架構本論文中共有五章，第一章為緒論，敘述本研究的背景、動機以及目標；第二章為文獻探討，將針對本研究中所涉及的領域進行研究與探討；第三章為系統實作，對本論文中所使用的技術以及實作內容進行介紹；第四章則進行實驗數據結果的分析與相關探討；第五章為本研究之結論與未來方向探討。. 2.

(10) 第二章文獻探討 2.1 Global Illumination 全域照明是 3D 計算機圖學領域中為了使畫面更為逼真而考慮真實光線於 3D 場景中光照效果的總稱，全域照明除了考慮到直接光源的照明，更包含了如間接照明、反射、折射、焦散等效果。此領域至今已經發展出許多方法能夠達到擬真的畫質，如輻射度(radiosity)、路徑追蹤(path tracing)、光子映射…等。但由於模擬真實光照情形都避免不了大量複雜的運算，使其效能一直未見起色，在全域照明的實作中也分成了兩派：著重畫質的靜態渲染(off-line rendering)以及著重效能的即時渲染(real-time rendering)，前者多為電影、動畫所使用的技術，而後者則運用在遊戲產業以及相關特效上。本研究中，我們將專注於以光子映射實作全域照明效果，並盡可能地利用 GPU 平行化的能力提升其效能，然而，光靠光子映射的資訊無法完整的捕捉到多種層次的照明效果如：鏡面反射、透明折射…等，因此，這些效果需要藉重其他方法的輔助以實現，我們使用了光線追蹤法的幫助以逼近這些效果。. 2.1.1 Ray Tracing 光線追蹤演算法的概念是由攝影機所在的位置，朝投影平面發射光線，判斷該條光線是否擊中場景，並藉由擊中點與光源之間的關係來決定畫面中每個像素的顏色，在[Whitted 80]的研究中，追蹤了不只一層的光線，並將光線分為陰影、折射以及反射三種性質，借此計算出每一層次所追蹤的光照貢獻。另外，藉由發射陰影射線，從擊中點射向光源位置判斷是否與場景物體有交點，則能夠快速地計算出該處是否被場景所遮蔽，因此能夠計算出陰影。光線追蹤演算法具有渲染 3.

(11) 畫面的數學正確性，並且能夠直覺地進行計算，是一個十分有發展性的演算法，而為了模擬更真實的光照情形，例如全域照明或是次表面散射，部份進階的光照算法或特殊材質則會需要更多的光線來模擬。. 2.2 Photon Mapping on GPGPU Photon mapping [Jensen 01]是一個在 GPGPU 架構下能夠良好運行的演算法，具有模擬出真實光照中部分效果的能力，例如：間接散射、範圍光源、焦散…等等。更重要的是他具備了在各種等級的裝置中能夠收斂於正確結果的特性，使得光子映射演算法十分適合 GPU 平行化的性質。 Photon mapping [Jensen 01]演算法分為幾個步驟，發射光子、追蹤光子以及彙集光子，近年來的研究中，已經有一些例子將 photon mapping 實作應用於 CUDA 與 OpenGL shader 平台上以利用 GPU 的平行運算能力。為了方便後續討論，我們將發射光子以及追蹤光子步驟直到產生光子映射圖(photon map)的階段，統稱為 photon emission，而彙集光子的貢獻部份則稱為 final gathering。. 2.2.1 Photon Emission Photon mapping[Jensen 01]演算法中，這一個步驟將計算光子的發射、追蹤與紀錄，是形成光子映射資訊的主要運算，光子的發射與追蹤跟光線追蹤的方式大同小異，差別在於由光源位置做為出發點發出射線，在找到場景交點時以俄羅斯輪盤(Russian roulette)的方式，隨機地決定光子於場景中是否儲存於交點位置或是繼續下一輪彈跳，並因應不同的材質修改追蹤的路徑，在我們的實作中，限制了光子路徑的追蹤深度以減少延遲，並且只執行到累積一定的光子數量為止。. 2.2.2 Final Gathering 最終彙集(final gathering) 由於必須計算所有鄰近光子對於物體的貢獻，因此 4.

(12) 計算量十分龐大，加速此一步驟一直是光子映射演算法的主要研究議題，至今，已發展出許多不同的方式進行加速。主要分為兩種做法，一個是 photon gathering，針對每一個場景交點計算光子對其造成的貢獻，另一個是 photon splatting，對於每一個光子計算所影響到的像素，兩者都發展出螢幕空間的方法能夠大幅地提升效率。 Photon Mapping [Jensen 01]使用 distributed ray tracer 配合光照的層次不同，利用光子映射資訊做出近似計算；Image Space Photon Mapping(ISPM) [McGuire 09] 利用 GPU 硬體的能力產生多張 bounce map 並使用 photon volume 加速光子彙集的計算，達到了即時的效能；Efficient GPU Density Estimation [Mara 13]中討論了許多種彙集光子的方法，包含在傳統 GPU 硬體以及 GPGPU 的加速方式，其中提到了兩種在目前架構上最可行的方式：2.5D gathering 與 tiled gathering，前者利用傳統 GPU 硬體以螢幕空間加上 Z-buffer 的資訊計算彙集光子的區域，後者利用 GPGPU 共享記憶體儲存並以螢幕空間區隔光子，節省檢查次數和記憶體頻寬，此方法被我們認為在目前異質多核心平台架構最具有潛力以及可行性。. 2.3 OpenCL Platform OpenCL 全名為開放式計算語言(Open Computing Language)，主要由 Khronos 所開發，具備了跨平台的特性，能夠利用裝置中的多個核心平行計算，並且具有符合異質系統架構運算的能力，是現今許多廠商共同支持的多核心計算標準。OpenCL 不僅僅在 CPU、GPU 上能夠運行，在平板電腦以及移動式裝置上亦能夠良好的搭載。藉由他的多核心平行化能力提供了以任務為主(task-based)與以資料為主(data-based)的平行化機制，使得複雜的計算得以平行化處理。. 2.3.1 Execution Model 在 OpenCL 平台上，程式主要分為兩個部份：主機端(host)與裝置端 (device)，主機端程式是屬於一般的應用程式，而裝置端則是執行裝置內核程式 5.

(13) (kernel program)，一個主機端程式可以啟動多個內核程式進行不同的運算，並且也具有同時在不同裝置下執行內核程式的能力，在異質系統架構中，由於不需要頻繁地在主機端記憶體與裝置端記憶體之間傳遞資料，最被看好的即是此種多裝置平行化運算的潛力。 OpenCL 的內核程式執行架構是屬於 Single Instruction Multiple Thread (SIMT) 的模式，同一個工作群組(work group)中的內核執行緒(kernel thread)將同時執行同一行指令，因此，使用者能夠根據裝置具有的運算單元數量，自行調整內核程式的工作群組大小，決定程式平行化的程度，藉此提升效能。. 2.3.2 Memory Model. 根據裝置端所使用到的不同架構，OpenCL 平台記憶體層次也分成全域記憶體(global memory)、唯讀記憶體(constant memory)、共享記憶體(local memory)、私有記憶體(private memory)四種層次。全域記憶體是所有的內核執行緒都能夠存取的記憶體區塊，其容量最大但是存取的速度最慢，因此現今的裝置架構提供了一到三層不同大小的快取區域以減少記憶體存取延遲。唯讀記憶體寫入的資料不能夠再做修改，由於存取速度較全域記憶體快上一些，因此部分參數的存取將使用到這一個區塊。而共享記憶體可以和同一個工作群組共享資料，其讀取速度與快取區域差不多快，如果能夠善用這一個區塊，對於節省記憶體頻寬有很大的幫助。私有記憶體是只有單一個內核執行緒能夠存取的區塊，相當於暫存器的功能，存取速度也最快。另外，OpenCL 提供了 image object 的形式以利用全域記憶體區塊，最大的優點是能夠存取一整塊的區域，並提供快取功能，但必須透過特定 API 來支援，適合存放存取頻繁的資料，但現今大多的裝置都能夠自動地支援全域記憶體的快取，因此我們沒有用到這個特殊功能。. 6.

(14) 第三章系統實作如同 OpenCL 平台的基礎模型，我們的系統也由主機端以及裝置端所組成(參見圖 1)。主機端的主程式會先讀入場景資料，並建置加速結構，接著驅動第一個內核程式平行地計算光子在場景中發散情形，透過俄羅斯輪盤方法儲存其位置、能量相關資訊，得到光子映射圖。. Device. Host. Ray Generation. Read Scene. Tile Insertion. Construct K-d tree. Intersection Test Compute Photon Map Compute Color Contribution Setting kernel Arguments Frame Accumulation. 圖 1：系統流程圖。. 在處理完計算光照環境所需的各種資料之後，主機端會將資料一併傳入裝置端，存放於全域記憶體，並等待回傳的畫面(frame buffer)以更新螢幕上的顯示畫面。裝置端接收到資料並啟動渲染畫面的內核程式後，藉由 SIMT 的特性，就畫面中的每一個像素產生追蹤光線，再計算出該執行緒所在的群組螢幕空間的區域對應於場景中的範圍，並將於影響範圍內的光子資訊複製到共享記憶體區塊(此步驟稱為 tile insertion)，接著進行場景交點測試，若光線與場景得到交點，於顏色計 7.

(15) 算階段我們會將光線追蹤的資料加入光子映射的貢獻，結合光線追蹤的光照色彩以及最終彙集所得到的光照色彩，最後模擬出具備全域照明效果的畫面，並更新主機端顯示。. 3.1 Ray Tracer 為了幫助光子映射演算法獲得鏡面反射、透明物體、柔和陰影(soft-shodow)等光照效果，我們實作了 OpenCL ray tracer 進行光線追蹤，並取得直接照明的畫面色彩，而為了得到更逼真的畫面，我們於每一次渲染畫面計算其顏色貢獻時，將直接照明效果與光子所提供的光照效果加總，得以模擬單純於光線追蹤演算法中無法得到的全域照明效果。. 圖 2：直接光照成果圖。. 8.

(16) 在我們的實作中，一個內核執行緒將針對畫面中的像素從相機位置發射一條光線進行追蹤，當擊中場景中物體時才開始計算遮蔽、顏色貢獻的部份，由於計算方式是每個像素獨立的進行，因此相當適合平行化運算。. 3.1.1 Shadow Ray 我們使用了傳統計算陰影的方式－發射陰影射線(shadow ray)，進行物體陰影遮蔽的測試。由於光子映射演算法無法完整得到場景中視線路徑的資訊，因此我們採用蒙特卡羅方法作為輔助，取代原本的發散式(distributed)採樣，此種方法在 SIMT 架構下更能提升整體效能。在追蹤光線與場景有交點時，我們將從該交點發射陰影射線，射向光源區域中隨機選擇的採樣點，判斷與場景中其他物體是否有遮蔽情形，藉由隨機採樣光源區域，將累加採樣到像素緩衝區(frame buffer)的方式，使其效果會隨著樣本數的增加，於陰影處渲染的雜訊會逐漸地被平均掉。使我們將累積多次迴圈計算得到的畫面加以平均之後，可得到柔和陰影的效果。. 3.1.2 Phone Shading 我們的實作中，直接照明的效果採用了 phong shading model，我們將場景中交點的法線與焦點連至光源位置的方向向量做內積。不同的是，為了保留更加逼真得光照色彩，我們並未計算其中的 ambient 以及 specular coefficient。改由最後的顏色計算階段將光子映射所計算出的光照貢獻加入，彌補這一部份的不足。. 3.2 K-D Tree 傳統的光線追蹤演算法中，由於必須計算大量的光線-物體交點測試，若是場景複雜且由大量的片三角形組成，將會花費絕大部分的計算成本於交點測試上，嚴重影響其效能，畫出一張畫面可能高達數小時之久。因此，至今已發展了許多 9.

(17) 將場景以空間切割法儲存於樹狀結構中的加速方法，藉由加速結構大幅度地節省檢查次數，由於本研究中渲染的場景屬於靜態場景，因此我們針對場景的加速結構採用了 K-D tree 加速結構。 K-D tree 的演算法可分為兩個步驟探討：建構與走訪。在 GPGPU 上 RealTime K-D Tree Construction [Zhou 08]已提出於 CUDA 平台上即時地建置 k-d tree 的方法，K-D Tree Acceleration Structure [Foley 05]為了節省頻繁的記憶體使用所造成的延遲，提出了 k-d restart、k-d backtrack 方法，透過重複走訪大幅度地節省了記憶體存取次數，Interactive K-D Tree GPU Ray Tracer [Horn 07]使用較不占用記憶體的 short stack 方法，除了節省記憶體頻寬之外，也省下大量重複檢查的時間。在 Daniel 等人的實作結果中，可達到每秒鐘追蹤 10-90 百萬條主要光線 (primary rays)，在當時的背景下是非常高的資料計算量。. 3.2.1 Construction Method 在建構 k-d tree 的部分，我們的實作中使用物件的中心點(object medium)作為空間描述的分類依據，並以座標軸對稱(Axis-Aligned Bounding Box)的格式切開場景，以由上而下(top-down)的方式，將場景由三個座標軸依序並遞回地切割，建立一個有深度限制的樹狀資料結構。當主機端將 k-d tree 建置完成以後，我們會依循前序(pre-order)搜尋法將樹狀結構存入一維陣列，此做法是為了避免在裝置端執行時使用指標結構(pointer)會產生資料錯誤的可能性，讓程式能夠保有可攜性(portability)，並盡可能地節省記憶體空間。而在走訪時，我們將使用陣列中的編號做為辨識母節點、子節點的資訊。而後主機端會將此陣列傳入裝置端的全域記憶體中，並且在內核程式執行時呼叫走訪的函式，由於是靜態場景，所以當畫面重覆進行採樣時不需考慮重建時間、更新資料等問題。 10.

(18) 3.2.2 Traversal Function 走訪 k-d tree 時，由根(root)出發，每當走訪到節點(node)時，我們會判斷是否符合繼續走訪的條件，並且由光線的方向向量以及 Axis Aligned Bounding Box(AABB)的測試結果決定下一次走訪節點的先後順序。而當走到葉節點(leaf node)時，表示已經符合最小的 AABB 切割區塊，我們會對其中包含的所有物體進行交點測試。而為了進一步驗證同個 OpenCL 程式在不同裝置架構底下的效能，我們則是使用標準的方法－利用固定大小的堆疊(stack)，記錄等待走訪的節點，藉由這種方法，我們預期在全域記憶體存取頻率較高的時候，會更加吃重裝置的記憶體頻寬(memory bandwidth)效能。. 圖 3：3000 顆光子可視化之後的畫面效果，採用光線追蹤渲染。 11.

(19) 3.3 Photon Emission 光子映射圖是藉由發射大量的光子所組成，紀錄光子於場景中儲存的位置與能量資訊，我們於發射光子的計算中利用光線追蹤的原理，並藉由多個運算單元平行化地計算以增加效率。發射光子時，在裝置端的內核程式將啟動一定數目的執行緒，於場景中發射光子並累積數目到一定數量為止。每一個內核執行緒將獨立計算光子的生成與追蹤。如同傳統的光子映射演算法，光子初始資訊將由光源位置作為出發點，朝向場景的方向隨機決定其方向向量以平均分散於場景之中，我們於每一次內核程式執行時，都會隨機產生一個種子，傳入裝置端，並加入內核執行緒編號生成亂數以維持一定的亂度。於場景中，大約三到六千顆光子就能在自定義的彙集範圍內平均分佈一顆光子。上圖 3 則是為了驗證光子於場景中的隨機散佈特性，將光子以光線追蹤方式畫出方便觀察的例子。進入光子的追蹤步驟之後，我們會根據光子於場景中所碰撞到的物體材質、位置等資訊追蹤至一定的深度為止，並且每一次碰撞時由俄羅斯輪盤方式決定是否讓光子停留於該位置抑或繼續於場景中彈跳，最後，我們會根據光子停留的位置與材質，計算出光子所儲存的能量、方向等資訊，並將資料儲存回裝置端的陣列(photon map buffer)。而當發散光子內核程式執行完畢，於主機端將讀到一個儲存光子的陣列，即是光子映射圖，作為之後進行渲染時所需要的主要資訊。. 3.4 Final Gathering 在渲染畫面的內核程式中，最終彙集屬於計算顏色貢獻的主要步驟之一，光子映射圖將透過主機端傳送至裝置端的全域記憶體，並在最終彙集階段提供資訊進行彙集光子以及光通量的計算，本論文中，我們從基礎的最終彙集進行改良，於光線交點之處一定的空間範圍內蒐集光子，傳統上的光子會採用樹狀資料結構儲存，並不斷維護這個樹狀結構，以節省彙集光子的檢查次數，在 SIMT 平行化 12.

(20) 的架構認知下，我們將維護樹狀結構定義為不適合的方法，因而沒有進行實作，而近期 GPGPU 的相關研究也多改以空間雜湊(spatial hash table)的方式彙集光子。下面兩小節我們會就彙集光子的演算法於 GPGPU 上執行的效能進行探討並且研究方法上改進的可能性。我們也於 OpenCL 平台上進行一種新的嘗試：將最終彙集的運算以螢幕空間作為區分進行平行化運算，並利用共享記憶體的優勢。在我們的實驗中，此種方法得到相當大的加速幅度。. 3.4.1 Basic Method 傳統的最終彙集步驟，畫面中每一個像素都會根據場景的光線交點位置彙集鄰近的光子，以光子與該交點之距離作為過濾器(filter)，計算光子的個數與光通量，因此，當場景中累積的光子越多，在場景中分佈的情形也越平均，我們則越能夠逼近真實的光通量，得到更好的光照效果。但同時我們也觀察到一個現象：由於使用了空間兩點距離的計算方式作為過濾器的條件彙集光子，在物體的邊緣之處會收集到不正確的資訊，因為光子過濾器的篩選範圍穿越了場景空間中的物體，使有些本該被遮蔽的光子產生貢獻，此問題至今已經發展許多不同的過濾器篩選條件能夠改進，但於我們的實作中並未加入改進的方法，因此最後得到的畫面尚有人為缺陷(artifact)之處。在基礎方法的實作中由於我們沒有使用任何的加速結構，只進行演算法的評估，並在實驗的部分將其效能的數據當作探討光子映射演算法在現今 GPGPU 平行化計算方式的加速程度的依據。. 3.4.2 Tile Gathering 我們於實作中觀察到最終彙集的效率不彰，在光子數目到達一定程度時，將長時間且占用大量的記憶體頻寬，進而導致顯示卡停止回應的窘境，而 Photon Mapping [Jensen 01]中是以 balanced k-d tree 儲存光子，以便於最終彙集階段進行 k- nearest neighbor search，然而此種方法必須頻繁地維護 k-d tree，並且存取全域記憶體，相對不利於在 OpenCL 平台達成互動式的演算法效能，而近年來，這部 13.

(21) 分計算所採用的方法於 GPGPU 的平台發展越來越趨向螢幕空間(screen space)的求解方式，因此我們採取了類似 Efficient GPU Density Estimation [Mara 13]中所使用的 Tiled 演算法，希望能夠利用共享記憶體區塊節省記憶體頻寬，並且於空間切割的計算上採用螢幕區塊劃分，快速的進行切割，不同的是，由於使用 GPGPU 的方式進行螢幕空間的切割，無法透過其他方法計算出螢幕空間於場景中影響的座標範圍，在定義其影響之範圍時仍必須藉由光線交點測試的幫助。在 tile gathering 的方法實作中，我們主要分為兩個部分進行：tile insertion 與 tile gathering。第一部份 tile insertion 將使用採樣光線以找場景交點的方式，對目前的內核執行緒所在的群組之影響範圍進行採樣，決定此螢幕空間的 tile 區域於場景中之對應範圍，並將此範圍中所有具有影響之光子複製到該執行緒所在群組的共享記憶體區域，若是遇到特殊材質的物體產生多層次彈跳光線時，我們會根據最終打到的交點位置定義出適合的空間大小，並收集影響範圍內的光子，儲存至共享記憶體中，而 tile gathering 的計算部分每一個像素則只針對共享記憶體區域中的光子進行彙集以及光通量的計算，如同傳統方法，我們以光子與交點之距離作為過濾器，計算該像素於此交點的光子數目以及光通量，而差別是我們不需要再檢查一次所有的光子是否造成影響。. 14.

(22) 第四章實驗結果分析參照表 1，我們分別在 CPU 與兩個 GPU 環境底下執行同一個 OpenCL 程式，其中 Intel I5-4250U 與 Intel HD Graphics 5000 裝置的全域記憶體都是使用主機端的主記憶體與快取記憶體，因此較不容易遇到容量限制以及頻寬的問題。在我們的實驗場景中，三者都沒有使用到記憶體的儲存容量極限。其中在共享記憶體 (local memory)的部分，Intel HD Graphics 與 Nvidia 顯示卡都有內核執行緒之間可共享的記憶體區塊，在後續的光子映射實驗中我們選擇以 Intel HD Graphics 裝置作為主要實驗裝置以得到更好的效能。 Max group. Device. Type. Compute Unit. Memory. Intel I5-4250U. CPU. 4. 4G & cache. 1024. Intel HD Graphics 500. GPU. 4G & cache. 512. 1G. 512. NVidia GeForce GTX550Ti. GPU. 40 (704 GFLOPS). 192 (691GFLPOS). size. 表 1：我們的實驗環境。. 4.1 K-D Tree 由於從發射光子乃至於場景的渲染都借助光線追蹤的方式進行，因此當場景複雜程度提高時，我們相當依賴場景加速結構節省計算量之能力，我們於實作中展現了 k-d tree 之加速能力，並且分別就兩個不同性質的運算核心進行探討，另外，也分別列出發射光子與追蹤、場景光線追蹤兩個部分的加速情形。. 15.

(23) Intel. Intel Tree Intel Graphics building Graphics + tree time. Scene. Size. Intel CPU. Cornell. 26. 0.155. 0.152. 0.012. 0.020. 0.001. Teapot. 1056. 4.088. 0.442. 0.130. 0.046. 0.001. Bunny. 4994. 25.45. 0.781. 1.749. 0.074. 0.004. 45294. 235.1. 2.370. 19.72. 0.263. 0.229. Marie Cat. CPU + tree. 表 2：K-d tree 於不同架構之效能(光線追蹤一張畫面之時間，單位：秒)。. 100 80 60 40 20 0 Cornell Box. Teapot. Bunny. CPU 倍數差距. Marie Cat. GPU倍數差距. 圖 4：效能倍數差距折線圖。. 4.1.1 Thread Divergence 由於內核執行緒平行化運算的特性，當程式出現分枝(branch)時，每個執行緒必須等待其所屬的工作群組執行完畢，才能回傳結果。此一現象被稱作分枝分歧 (branch divergence)。因此，為了驗證 K-d tree 加速結構在平行化執行時得到的加速效能。我們設計了表 2 的實驗，在不同裝置架構底下比較使用了加速結構的效 16.

(24) 果，而根據所得到的數據，視覺化得出圖 4 的結果，我們可以很清楚地觀察到兩者之間的差距。當加入了 K-d tree 的結構時，判斷光線的交點必須先走訪 K-d tree，而因為 SIMT 之特性，同一個工作群組之內的執行緒則必須等待所有的執行緒都走訪完畢，因此產生了分枝分歧。所以，GPU 架構加入 K-d tree 加速結構所得到的加速倍率較 CPU 架構運算時還要小，此一現象會隨著場景變大，在走訪時所走的分枝越來越多，而有更加明顯的趨勢(見圖 4)。另外，我們也於光子發射部分採用 k-d tree 加速結構，以節省場景中檢查交點的次數，表 3 提供了有一定複雜程度的場景加速程度之比較。. Scene / photons. 15,000. 30,000. 150,000. 300,000. Bunny. 4.462. 4.642. 9.12. 15.86. Bunny K-D. 0.835. 0.85. 1.64. 2.40. 表 3：使用 k-d tree 於光子發射階段之加速效能(單位：秒)。. 4.2 Cross-Platform 我們分別於 Intel i5 4250-U、Intel HD Graphics 5000、NVidia GTX550Ti 顯示卡三種架構底下執行同一個 OpenCL 程式(見表 4)，由於 CPU 架構不會受到分枝分歧的影響而降低效能，因此它所受到的影響主要來自於隨著場景更加複雜時，檢查光線交點的次數變多所造成，讓此特性適合做為效能參考的錨點。值得注意的是，在 GPU 上進行運算，除了觀察到先前提到的分枝分歧所造成的效能衰減之外，我們也觀察到了記憶體頻寬大小對於效能的影響。當三角面的個數較少的時候，Nvidia 顯示卡因為運算單元較多，所以擁有最佳的效能。隨著三角面個數增加，Nvidia 顯示卡的效能下降幅度較 Intel HD Graphics 5000 來得更 17.

(25) 加明顯，其原因主要是我們將場景存放於全域記憶體之中，並且使用了自訂長度的 stack，使得大量全域記憶體存取造成了記憶體頻寬壅塞的問題。. Intel HD Intel i5 4250-U Graphics 5000. NVidia GeForce GTX550Ti. Scene. Size. Cornell. 26. 6.54. 50.62. 112.09. Teapot. 1056. 2.26. 21.55. 16.85. Bunny. 4994. 1.28. 13.67. 8.93. Marie Cat. 45294. 0.47. 3.66. 2.19. 表 4：各裝置上直接光源的光線追蹤之效能數據(單位：FPS)。在 Nvidia 顯示卡的環境底下，當三角面變多的時候，由於頻繁地進行場景中的光線交點測試，使得記憶體存取(memory access)次數大幅增加，它連帶影響到整個 GPU 的吞吐率(throughput)，如同在傳統 GPU 上使用標準的 K-d tree 加速結構所造成的延遲，而由於 Intel HD Graphics 的全域記憶體是跟主機端共用主記憶體與快取，因此我們觀察到記憶體頻寬壅塞所造成的影響較小，使得最終於較複雜之場景所得出的效能相對較好。. 4.3 Gathering Method 如同傳統的最終彙集步驟，畫面中每個像素都會就場景的光線交點位置彙集鄰近的光子，以光子與該交點之距離作為過濾器(filter)，當場景中累積的光子越多，在場景中分部的情形越平均，我們越能夠逼近真實的光通量，因此將會得到更好的光照效果，後續實驗中，我們將包含使用基礎方法、螢幕空間的分類描述以及共享記憶體平行處理的效能加速數據作為參考。. 18.

(26) Scene. Size. Photons. Basic. Tiled. Reduction. Cornell. 26. 15,000. 17.551. 6.296. 0.340. Bunny. 4,994. 15,000. 19.396. 6.367. 0.503. Cornell. 26. 30,000. 40.032. 11.694. 0.453. Bunny. 4,994. 30,000. 42.849. 12.405. 0.704. Cornell. 26. 150,000. break. 54.392. 0.975. Bunny. 4,994. 150,000. break. 56.057. 1.105. Cornell. 26. 300,000. break. break. 1.891. Bunny. 4,994. 300,000. break. break. 2.022. 表 5：光子映射於 Intel HD Graphics 5000 上使用不同方法之效能表(單位：秒)， break 表示長時間記憶體頻寬壅塞，導致 GPU 驅動程式停止回應。. 4.3.1 Tiled Method. 我們於表 5 列出了不同場景、不同光子總量情形之下分別使用三種方法之效能數據，Basic 方法中，我們於最終彙集階段依序地檢查每一個光子與交點之距離，沒有透過其他的加速結構輔助，而 Tiled 方法則是將場景的光子以螢幕空間的群組劃分區域，以共享記憶體儲存，在使用了螢幕空間區分方法之後，得到約 3 倍的效能提升，原因是不需要於最終彙集步驟中檢查所有光子，節省了許多不必要的計算，並且利用了共享記憶體頻寬之後，處理大量光子的能力有顯著提升，得以進行十五萬個光子的彙集，但由於在計算 tile insertion 階段檢查光子時並未同步存放於共享記憶體中，所以依然必須就所有光子進行檢查，因此仍有改進空間，最後的 Reduction 方法則是利用多執行緒 map-reduce 之概念，在 tile insertion 階段將光子的檢查工作平均地分配至群組中的每個執行緒，然後再同步更新共享記憶體的光子儲存資訊，此作法雖然必須等待執行緒之間的同步延遲(見附錄 A)， 19.

(27) 但大幅減輕了迴圈多重檢查而產生的分歧之影響以及占用的記憶體頻寬，並較先前方法得到 20 倍以上的加速幅度。. 圖 5：光子數量對於畫面影響之比較。(左為五萬，右為十五萬). 4.3.2 Number of Photons. 如前所述，當場景中累積的光子越多，在場景中分部的情形越平均，我們越能夠逼近真實的光通量，因此將會得到更好的光照效果。而目前也發展了光子微分方程(photon differential)的方法能夠解決光子數量不足時產生的人為缺陷，並且使得光子彙集能夠更加的節省效能，而於我們的做法中，我們沒有實做這一部分 20.

(28) 的畫面過濾方法，因此得到的畫面品質與光子數目有正相關的特性，由圖 5 可明顯看出光子數量對於畫面光照效果之影響。. 4.4 Global Illumination 我們以 cornell box 當作主要場景，並在場景之中加入球體、teapot 以及 bunny 等常用模型，以方便看出效果。我們於圖 6 中顯示一般光線追蹤所渲染的直接照明效果，與加入光子映射演算法資訊以及蒙特卡羅採樣法所得到的效果，兩者真實度差異極大。. 圖 6：Direct Illumination、Global Illumination 之成果比較圖。. 於圖 6 中，我們模擬出全域照明效果，包含了多種照明的現象，藉由光子映射演算法產生的光子資訊，我們所渲染的畫面中不僅僅產生間接照明的效果，場景中多處可見因間接照明產生的滲色(color bleeding)現象，特別是無法得到直接光照的陰影之處，另外，也由於光子密度產生的自然特性，我們的場景中很自然地模擬了環境光吸收(ambient occlusion)以及散射亮度差異的光照現象。. 21.

(29) 4.4.1 Reflection and Refraction 另外，藉由光線追蹤演算法的實作與幫助，在我們的實驗中也針對不同的場景材質做相對應的光線計算，並將光子映射的資訊加入光照顏色的計算上，我們在畫面中的光線會於場景中持續追蹤直至一定的深度為止，再針對追蹤到的光線交點進行直接照明與最終彙集，最後得出如圖 7 鏡面反射與圖 8 折射的效果，而由於我們採用螢幕空間的算法，因此在某部分複雜的路徑上會使得部份工作群組所涵蓋之範圍太大，因此無法於共享記憶體中儲存所有光子，而產生了缺角的情形，其解決方法則必須增加工作群組總量以在共享記憶體容量範圍內涵蓋所有具有影響之光子，而這將會使得整體效能大幅度下降，或是減少畫面中發散的光子總量，但將導致畫面品質變差以及產生人為缺陷的問題。. 4.4.2 Caustic 如同傳統的方法，藉由光子映射圖所提供的資訊，當光子於場景中發散，我們利用光線追蹤的方式，判斷光子所擊中物體的法向量、材質等資訊，可以輕易的模擬出光子於場景的散佈情形。藉由最終彙集步驟收集光子，我們則可利用光子在場景中自然的密集程度得到焦散效果，原因是，當光子穿越透明物體時將有聚集之效果，如同真實光線的特性一般。但是，由於我們畫面中的效果綜合了直接照明與光子映射資訊得到的光照色彩，因此最終得到的光照只靠隨機散佈所得到的光子還是不夠真實，光子密度與能量遠低於真實光照焦散所需的強度，因此傳統上必須針對透明物體發射高密集度的光子來模擬完整的焦散效果，甚至使用另一張光子資訊圖來模擬，而我們為了降低於 OpenCL 實作的複雜程度，並沒有另外計算對應的方法。. 22.

(30) 圖 7：鏡面反射場景效果。. 圖 8：玻璃材質 bunny 場景的折射與焦散效果。 23.

(31) 第五章結論與未來研究在本研究中，我們探討了異質多核心平台實作即時全域照明的可行性，並就各個不同的架構分析影響效能之因素，提供未來撰寫相關程式與研究之數據參考。在我們的實作中，使用了光子映射演算法與光線追蹤方法模擬光照情形，並且就效能部分分別使用了 k-d tree、tile gathering、reduction 等加速方法。我們將光子映射演算法改以適合平行化架構的方式，進行新的實驗，在 OpenCL 上將畫面以螢幕空間的區塊切割，並利用了共享記憶體以改進現有效能之不足，成功的嘗試了一種新興的加速方式。本研究所使用的場景為靜態場景，使用 800*640 的解析度，利用光線追蹤在相對簡單的室內場景已可達到 20~50FPS 的即時效能，在稍為複雜的 bunny 與 marie cat 場景則有 1~15FPS 左右的互動式效能，若是針對場景的加速結構以及部分計算上加以優化，相信可得到更好的成果。在全域照明的渲染部分，傳統上耗費大量時間計算的光子映射演算法，利用平行化以及相關優化的加速方式，已可於 GPU 上一次處理數十萬個光子所需的運算量，最後，我們於室內的 bunny 場景中可得到 1~3FPS 的效能，達到互動式的水準。透過 OpenCL 獲得跨平台的特性以及異質系統架構的相容性，對於開發人員則可省下不少工夫，光是利用平行化計算能力已經得到不少的加速效果，當然，若是要達到最佳的效能，則必須能針對所使用的架構再進一步優化，我們認為，光子映射演算法與光線追蹤演算法在 GPGPU 的計算可行性與發展性上，依舊有不少等待發揮的空間。而隨著 GPU 運算能力越來越快，且 GPGPU 的可程式化能力越來越強大，即時更新的場景加速結構、全域照明演算法都能夠以多核心平行化運算的方式得到一定程度的速度提升，透過我們的實驗數據，則可清楚地理解到未來於此架構下 24.

(32) 發展演算法將面對的難關，在未來的研究中，我們可以針對光子數量不足之處以光子微分方程增進畫面真實度，同時降低大量運算光子所占用的記憶體頻寬以提升速度，亦能夠對於光子的彙集採用更為精確的過濾器以減少畫面中人為缺陷的部分，在螢幕空間為基底的最終彙集演算法中，若能採用更好的方式區分場景，則可避免因共享記憶體不足而使得畫面資訊不完整的問題發生，並且更有效率的計算空間劃分以得到更快的速度。. 25.

(33) 附錄以下列出幾個重要的程式內容與架構： A.. 節錄 tile insertion 階段利用 barrier 指令進行共享記憶體同步：. void tileInsertion(){ barrier(CLK_LOCAL_MEM_FENCE); int checkNum = photonNum / lsize; int i = 0; int lcount = 0; // Tiled Reduction Mode for(i = lid*checkNum; i < checkNum*lid+checkNum; i++){ if( boxSphereInteresect(tileStart, tileEnd, photonMap[i]){ localPhoton[(*currentID)] = photonMap[i]; (*currentID)++; } } barrier(CLK_LOCAL_MEM_FENCE); }. B.. kernel code 之節錄：. __kernel void myKernel(parameters….) { __local Photon localPhoton[localPhotonNum]; // generate ray Ray r; r.ori = eyePos; r.refractID = 1.0f; r.dir = p - eyePos; vnorm(&r.dir); // tile insertion __local float4 tileStart, tileEnd,tileBound[samplePoint]; __local int currentID; currentID = 0;. 26. findSpace(light,sphere,plane,triangle,tree,lightNum,sphereNum,planeNum,triangleNu m, r,localPhoton,photonNum,tid,lid,&tileStart,&tileEnd,tileBound);.

(34) kernel code 之節錄(續)：. findSpace(light,sphere,plane,triangle,tree,lightNum,sphereNum,planeNum,triangleNum, r,localPhoton,photonNum,tid,lid,&tileStart,&tileEnd,tileBound); // and copy photon tileInsertion(photonMap,photonNum,localPhoton,lsize,tid,lid,&tileStart,&tileEnd,&cur rentID,iterations); // Ray Tracing + Final Gathering float4 color = computeColor(light,sphere,plane,triangle,tree,lightNum,sphereNum,planeNum,triangleNum, r,localPhoton,photonNum,idseed,seed,iterations); // Frame Accumulation if(iterations > 1){ float4 oriColor = zerov; oriColor.x = ((frame[tid] & 0x000000FF) >> 0) / 255.0f; oriColor.y = ((frame[tid] & 0x0000FF00) >> 8) / 255.0f; oriColor.z = ((frame[tid] & 0x00FF0000) >> 16) / 255.0f; color = (color + oriColor*iterations) / (float)(iterations+1); } frame[tid] = (int)(color.x * 255.0f+0.5f) + ((int)(color.y * 255.0f+0.5f) << 8) + ((int)(color.z * 255.0f+0.5f) << 16);. 27. /.

(35) 參考文獻 [Foley. 05] FOLEY, T., AND SUGERMAN, J. 2005. Kd-tree acceleration. structures fora GPU ray tracer. In Proceedings of Graphics Hardware. [Horn. 07] HORN, D. R., SUGERMAN, J., HOUSTON, M., AND. HANRAHAN, P. 2007. Interactive k-d tree GPU ray tracing. In Proceedings of Symposium on Interactive 3D graphics and Games, 167-174. [Jensen. 96] JENSEN, H. W. 1996. Global illumination using photon maps. In. rendering techniques, Springer -Verlag, London, UK, 21-30. [Jensen. 01] JENSEN, H. W. 2001. Realistic image synthesis using photon. mapping. A. K. Peters, Ltd., Natick, MA, USA. [McGuire 09] MCGUIRE, M., LUEBKE, D., MARA, M. 2009. Hardware accelerated global illumination by image space photon mapping. In Proc. of HPG, ACM, New York, NY, USA, HPG 09, 77 - 89. [Mara. 13] MARA, M., LUEBKE, D., AND MCGUIRE, M. 2013. Toward. practical real-time photon mapping: efficient GPU density estimation. I3D 2013: 71-78. [Whitted 80] WHITTED, T. 1980. An improved illumination model for shaded display. Communications of the ACM 23, 6 (June 1980), 343–349. [Zhou. 08] ZHOU, K., HOU, Q., WANG, R., AND GUO, B. 2008. Real-time. kd-tree construction on graphics hardware. ACM, NY, NY, USA, SIGGRAPH Asia’08, 126:1-126:11.. 28.

(36) 其他參考資料 [1] KHRONOS, 2011. Opencl overview. https://www.khronos.org/assets/uploads/ developers/library/overview/OpenCL-Overview-Jun10.pdf [2] KHRONOS, 2012. Opencl 1.2 reference pages. http://www.khronos.org/registry/cl/sdk/1.2/docs/man/xhtml/. [3] NVIDIA, 2012. Opencl programming guide for the cuda architecture, version 4.2. http://developer.download.nvidia.com/compute/DevZone/docs/html/OpenCL/doc/ OpenCL_Programming_Guide.pdf.. 29.

(37)