光線追蹤在OpenCL平台下使用堆疊在加速結構中效能之探討

全文

(1)國立台灣師範大學資訊工程研究所碩士論文. 指導教授：張鈞法博士. 光線追蹤在 OpenCL 平台下使用堆疊在加速結構中效能之探討. Performance Evaluation of Acceleration Structures with Stack for Ray Tracing in OpenCL. 研究生：鄒毓偉撰. 中華民國一百零六年一月.

(2) 摘要光線追蹤是一種在計算機圖學中用於繪圖的演算法，藉由以物理的光學為基礎，模仿光的自然現象，能讓渲染出的場景更具真實性，然而，提升真實性的代價，就是必須大量運算光線追蹤演算法中的數學公式，使得光線追蹤演算法相較於其他演算法渲染速度來的慢，為了改善此缺點，使用開放式計算語言(OpenCL) 來進行多核心的平行化運算，並且將場景物件資訊建構成 Bounding volume hierarchy (BVH) tree 的加速結構，藉由以上的加速方法，能夠縮短完成渲染工作的時間。使用 OpenCL API 後，將光線追蹤演算法中龐大的計算量做平行處理，但實際應用後，可以發現 OpenCL 的內核(kernel)在撰寫時會有許多限制，尤其是函式無法遞迴呼叫和本研究最為相關，論文程式中，有使用到樹狀的加速結構，所以要有 tree traversal 的方法，在 OpenCL 有自己實作的記憶體空間，為了模擬陣列而宣告的 stack 在 kernel 函式中，要宣告於何種記憶體空間裡，是程式設計師可以選擇的，本論文就是研究在各個種類的 OpenCL 記憶體中以及改變一些參數來實作 stack 時，來觀察以及探討效能的表現與變化。. 關鍵字: 光線追蹤、計算機圖學、OpenCL、BVH-tree I.

(3) Abstract Ray tracing is an Algorithm that used to render picture in computer graphics. It is based on ray in physical properties and imitates the natural phenomena of ray, which makes the rendered scene becomes more realistic. However, the cost of improving realistic is must compute a large number of operations in ray tracing. In order to improve this disadvantage, OpenCL is used to perform parallel computing on multi-core platform, and the object in the scene is constructed as an acceleration structure that called Bounding volume hierarchy tree. The acceleration method can reduce rendering time. After using the OpenCL API, A large number of operations in ray tracing is parallel. However, there are some limitations programming kernel of OpenCL, especially tThe function can’t be called recursively in kernel. The program uses an acceleration structure in tree structure, so it must have the way to traverse the tree structure. OpenCL has its own implementation of the memory space, the programmer can choose which type of the memory space to simulate the array and declare the stack in the Kernel function. The purpose of this paper is to study the performance to change some parameters and implement the stack in a variety of OpenCL memory.. Keyword: ray tracing、computer graphics、OpenCL、BVH-tree. II.

(4) 目錄摘要 .............................................................................................................. I Abstract ..................................................................................................... II 目錄 ...........................................................................................................III 附表目錄 .................................................................................................... V 附圖目錄 ................................................................................................... VI 第一章緒論 ............................................................................................... 1 1.1 研究背景.......................................................................................................... 1 1.2 研究目的.......................................................................................................... 2 1.3 論文架構.......................................................................................................... 3. 第二章相關文獻探討 ............................................................................... 4 2.1 raytracing .......................................................................................................... 4 2.2 BVH tree ........................................................................................................... 5 2.3 實驗硬體架構................................................................................................... 7 2.4 OpenCL ........................................................................................................... 16. 第三章 Intel OpenCL Memory Model .................................................. 21 3.1 Private Memory .............................................................................................. 21 3.2 Local Memory ................................................................................................. 22 3.3 Global Memory ............................................................................................... 24 3.4 Constant Memory............................................................................................ 26. 第四章使用 OpenCL 實作有加速結構之光線追蹤程式 .................... 27 4.1 步驟一............................................................................................................. 28. III.

(5) 4.2 步驟二............................................................................................................. 29 4.3 步驟三............................................................................................................. 33 4.4 步驟四............................................................................................................. 34. 第五章實驗與數據分析 ......................................................................... 35 5.1 實驗環境與方法............................................................................................ 35 5.2 各項實驗與討論............................................................................................ 37. 第六章結論與未來方向 ......................................................................... 49 6.1 結論................................................................................................................. 49 6.2 未來與改善方向............................................................................................ 50. 附圖與附表引用來源 ............................................................................... 51 參考文獻 ................................................................................................... 53. IV.

(6) 附表目錄表 3.1 各個記憶體在 Host 端與 Kernel 端特性 ...................................................... 21 表 5.1.1 開發環境與場景設定列表 ......................................................................... 35 表 5.1.2 實驗硬體資訊列表 ..................................................................................... 36 表 5.2.1 實驗名稱與實驗目的列表 ......................................................................... 37 表 5.2.2 硬體設備與執行時間列表 ........................................................................ 42 表 5.2.3 測試 BVH-tree 加速效能模型列表 ........................................................... 43 表 5.2.4 HD Graphics 6100 環境下各模型執行時間列表 ...................................... 44 表 5.2.5 GTX 960 環境下各模型執行時間列表 ..................................................... 44 表 5.2.6 HD Graphics 6100 環境下使用各種記憶體資訊列 .................................. 45 表 5.2.7 GTX960 環境下使用各種記憶體執行時間列表 ...................................... 46 表 5.2.8 HD Graphics 6100 環境下記憶體大小對效能影響資訊列表 .................. 47 表 5.2.9 GTX960 環境下記憶體大小對效能影響資訊列表 .................................. 48. V.

(7) 附圖目錄圖 2.1.1 光線追蹤演算法實作基本物件 .................................................................. 4 圖 2.1.2 論文程式繪製 CornellBox........................................................................... 5 圖 2.2.1 BVH-tree 物件分組形成節點與各節點構成的樹狀結構 .......................... 5 圖 2.3.1 Intel® Iris™ Graphics 快取階層 .................................................................. 7 圖 2.3.2 Execution Unit 細節 ...................................................................................... 8 圖 2.3.3 Subslice 細節 ................................................................................................. 9 圖 2.3.4 Gen8 Slice 細節........................................................................................... 10 圖 2.3.5 Gen7.5 Slice 細節........................................................................................ 10 圖 2.3.6 第八代圖形整合顯示核心處理器細節 ..................................................... 11 圖 2.3.7 使用 SoC Ring Interconnect 的架構來串連資料傳輸 ............................. 11 圖 2.3.8 Intel 記憶體階層 ........................................................................................ 12 圖 2.3.9 採用 Maxwell 架構的 GTX980 與 GTX780 Ti ........................................ 13 圖 2.3.10 SMM 結構 ................................................................................................. 14 圖 2.3.11 GTX960 Full-chip block 結構................................................................... 15 圖 2.4.1 OpenCL 整合異構平台 .............................................................................. 16 圖 2.4.2 Host 端與 Device 端架構 ........................................................................... 17 圖 2.4.3 使用 Code Builder 分析工具列出 OpenCL 資訊 ..................................... 17 圖 2.4.4 OpenCL 工作單元架構 .............................................................................. 18 圖 2.4.5 OpenCL 記憶體架構 .................................................................................. 19 圖 2.4.6 OpenCL 資料移動途徑 .............................................................................. 20 圖 3.2 Local Memory Access 範例 ........................................................................... 23 圖 3.3 Global Memory 與 Constant Memory Access 範例 ...................................... 25 圖 3.4 Kernel 中的 OpenCL Memory Model ........................................................... 26. VI.

(8) 圖 4.1.1 程式執行流程 ............................................................................................. 27 圖 4.1.2 場景設定檔範例 ........................................................................................ 28 圖 4.2.1 以數量來分類的新節點 ............................................................................. 29 圖 4.2.2 同個 bounding box 以數量平分與使用 SAH 來分類 .............................. 30 圖 4.2.3 父節點 C 與劃分出有重疊區域的子節點 A、B ..................................... 31 圖 4.3 傳遞資料整理 ............................................................................................... 33 圖 4.4 平行化策略 ................................................................................................... 34 圖 5.2.1 Sponza 模型繪製範例 ................................................................................ 37 圖 5.2.2 HD graphics 6100 環境下執行時間與 Local size 關係圖......................... 38 圖 5.2.3 GTX960 環境下執行時間與 Local size 關係圖 ........................................ 39 圖 5.2.4 HD graphics 6100 環境下執行時間與 BVH tree 層數關係圖 ................. 40 圖 5.2.5 GTX960 環境下執行時間與 BVH tree 層數關係圖................................. 41 圖 5.2.6 硬體設備與執行時間長條圖 ..................................................................... 42 圖 5.2.7 HD Graphics 6100 環境下 stack size 與執行時間關係圖......................... 47 圖 5.2.8 GTX960 環境下 stack size 與執行時間關係圖......................................... 48. VII.

(9) 第一章緒論 1.1 研究背景隨著電腦科技的演進，帶動了許多科學研究與產業的發展，其中在計算機圖學這門學科中也隨著電腦效能日益強大，有了長足的進步，最明顯的地方就是，早期電腦繪製的圖片都較為粗糙，不外乎因為電腦效能的問題，使得圖片的解析度不足或是使用的模型中構成三角片的過少，然而，近年來電腦效能的提升，單位時間的運算量大幅提升，繪製出來的圖片品質就較為精緻。雖然藉由電腦繪製的圖片變得較為精緻，人們在大多數情況還是能夠分辨出電腦繪圖與相片的差別，原因就在於電腦繪圖在渲染(rendering)時，運算所有場景照明資訊是非常困難且耗時的工作，所以大部分只考慮了直接照明，即只把光源當作主要影響場景亮度的因素，使得即使物體的顏色都繪製的正確，還是顯得不真實，為了解決這個問題，也要把間接照明的影響考慮進來，除了光源之外，也會考慮各條光線經過反射、折射等等的光學現象，讓電腦繪製的圖片可以更接近如同相片拍出來的效果。為了讓繪製的圖片更加真實，本篇論文採用光線追蹤(raytracing)的演算法，是一種在電腦圖學中用於渲染的演算法，以物理的光學為基礎，推算出數學式子來計算光的折射、反射、產生陰影等效果，以這種模仿光的自然現象之方法，讓渲染出的場景更具真實性，然而，提升真實性的代價，就是必須大量運算光線追. 1.

(10) 蹤演算法中的數學公式，使得光線追蹤演算法相較於其他演算法渲染速度來的慢，為了改善此缺點，使用開放式計算語言(OpenCL)，在圖形處理器(GPU)上多核心平行化運算，來處理龐大的計算量，同時也把模型的三角片資料中建立 BVH tree 的加速結構，藉由以上的加速方法，來縮短完成渲染工作的時間。. 1.2 研究目的 OpenCL 是一個可以用來做平行計算的 API，用以處理光線追蹤演算法中龐大的計算量，但實際應用後，可以發現 OpenCL 的內核(kernel)在撰寫時會有許多限制，例如:無法動態宣告陣列、指標型態無法直接指向 OpenCL 實作的記憶體空間(private、local、global)、函式無法遞迴呼叫等等…，函式無法遞迴呼叫和本研究最為相關，本研究所撰寫的程式中，有使用到樹狀的加速結構，提到樹的資料結構，就會牽涉到要如何拜訪樹的各個節點?即 tree traversal 實作方法，通常第一個想到的都是使用遞迴來完成這個工作，但 OpenCL 實作上有所限制，不存在實作遞迴最重要的堆疊(stack)，因此，取而代之，就改用迴圈再加上自己宣告陣列當作 stack 來模擬遞迴的行為，依序的拜訪節點來完成 tree traversal 的工作，讓加速結構的功能發揮出來，然而這裡就遇到了一個課題，以往在使用 C++程式使用遞迴呼叫時，系統會自動處理這些呼叫堆疊的工作，程式設計師只要注意不要讓遞迴呼叫的深度過深，導致 stack overflow 即可，但前文提到了 OpenCL 有自己實作的記憶體空間，為了模擬陣列而宣告的 stack 在 kernel 函式中，要宣告於何種. 2.

(11) 記憶體空間裡，是程式設計師可以選擇的，本論文就是研究在各個種類的 OpenCL 記憶體中實作 stack 以及改變一些參數來實驗使用到加速結構的程式，來觀察與探討效能的表現與變化，供程式設計師在實作時的有所參考及幫助。. 1.3 論文架構該論文的第一章為緒論，會簡介研究背景、研究目的與論文架構，會說明整個論文的大方向，以及為何會選擇這個主題做研究。第二章則為相關文獻探討，會介紹到論文程式用的演算法與資料結構的一些內容，例如:Raytracing 演算法、 BVH-tree 加速結構，另外，還有幫助進行平行計算的 OpenCL 基本簡介、工作單元分類、記憶體階層，再加上實驗硬體架構的相關資料，來幫助後面的實驗內容，其數據能夠有合理的解釋。第三章為 Intel OpenCL Memory Model，會詳細介紹在 Intel 的硬體架構下，OpenCL 記憶體實作的細節，一樣做為解釋實驗數據的參考資料。第四章為論文程式實作的各個步驟細節，主要分成四個步驟，從初始化程式到繪製圖片的過程依序講解。第五章為實驗與數據分析，會提到所做的實驗，並且對實驗數據有所討論。第六章會為整個論文做出結論與未來可以改進的方向。. 3.

(12) 第二章相關文獻探討 2.1 raytracing. 圖 2.1.1 光線追蹤演算法實作基本物件圖片引用(1) 光線追蹤演算法[1]是一啟發於自然現象中，光源發出的光線打到第一個阻擋光線前進物體表面才停止，這是整個演算法的最早雛型，Turner Whitted 把整個演算法改良得更完整，把折射、反射、陰影這幾個因素也考慮進去，讓渲染出來的畫面可以更接近真實世界的狀況，並提出可以用遞迴的方法來實作程式，整個演算法的流程為:從攝影機的位置對投影的方向來發射光線，當光線打到第一個物體後會再成生成三條類型的光線:反射的光線、折射的光線、陰影的光線，這幾條光線藉由遞迴執行，然後將函式回傳回來對計算像素的貢獻加總起來，就成為該點. 4.

(13) 像素的顏色，再用迴圈的方法將上述過程對螢幕中的每一個像素執行，就完成整個演算法的流程。不過上述的早期方法使得各個像素只被單一光線的物理現象所影響，導致反射、折射的效果不夠真實，陰影的光線也只考慮碰撞到的點與光源的連線，無法產生柔和陰影，即自然現象中"半影"的效果，因為這些缺點，後續也有了許多改良的演算法，在這就不加贅述了。. 圖 2.1.2 論文程式繪製 CornellBox. 2.2 BVH tree. 圖 2.2.1 BVH-tree 物件分組形成節點與各節點構成的樹狀結構圖片引用(2). 5.

(14) Bounding volume hierarchy (BVH) tree[2]是一種用於加速的資料結構，在圖學的領域中也可以使用到，由 Herman Johannes Haverkort 提出，核心概念為對空間中的物件，根據使用者的定義來做分類分群形成節點，最後在構成一個 tree 的結構，建置時可以採用 bottom-up 的方法之外，也可以用 Top-down 的方法建立，本論文程式是採用後者。建置完成後，所有的物件會存在 tree 的結點中，上層的結點中的物件會包括下層結點物件，根據這個特性，只要檢查時光線沒有碰撞到上層節點，則不用檢查下層的節點，也就是說不用去檢查所有的節點，因此就能省去一些運算的時間。在光線追蹤演算法中，光線與組成模型的三角形需要做交點測試，且是每一條的光線都要和所有物件做交點測試，就會有龐大的運算，若將 BVH tree 的想法套用在光線追蹤演算法中，就可以將組成模型的三角形在排序過後做分類形成節點，然後不斷結合構成樹狀結構，檢查時可以用 tree traversal 的方法，把光會打到葉結點挑選出來，只需對葉結點中存放的三角形做交點測試，如此一來，光線就不用每次都對所有的三角形做檢查，就能省去不少的計算時間，但要特別注意的是，有打節點並不代表有打到物件，實際上還是一定要檢查節點中的物件才行。. 6.

(15) 2.3 實驗硬體架構由於硬體架構會和 OpenCL 的實作平行運算會有相關，所以在此處會談到一些實驗硬體架構的內容，在本論文中實驗的硬體有 Intel Processor Graphics Gen8[3] 的 HD Graphics 6100 與 Geforce 900 series[4]的 GTX 960，以下依序介紹: 1.英特爾第八代圖形整合顯示核心處理器(Intel Processor Graphics Gen8) 在該代是採用 Broadwell 架構的微處理器，是一種多晶片模組的設計，該設計可以在一個封裝內容納兩個或兩個以上的裸晶，所以運算效能較上一代能夠有所提升。. 圖 2.3.1 Intel® Iris™ Graphics 快取階層圖片引用(3) 硬體架構會和 OpenCL 記憶體的實作息息相關，上圖為第七代整合顯示圖形卡高階型號的快取階層圖，到了第八代仍然採用此架構，雖然圖上快取資料流動方向標為單方向的箭頭，但事實上，平行運算時，資料會在這些快取(Cache)階層中雙方向流動，讓每個 EU 的運算單元都可以拿到要使用的資料。. 7.

(16) 圖上除了常見的 L1、L2、L3 快取與 LLC、DRAM 記憶體外，在虛線中為的 EDRAM 為某些高階型號的整合顯示核心才會有此記憶體，該記憶體是一種內嵌式的動態記憶體，可以有效降低延時以增進繪圖效能。介紹完快取階層，了解資料的流動方向後，過來會說明整個圖形整合顯示核心處理器的組成元件，由小到大分別是: Execution Unit(EU)、Subslice、Slice，然後再組成 Intel Processor Graphics Gen8，以及和外部記憶體連結後的資料傳遞架構。 (1)Execution Unit(EU). 圖 2.3.2 Execution Unit 細節圖片引用(4) 在 Gen8 架構中最基本的執行運算單元，其中 OpenCL 的內核(kernel)函式會在 EU 上執行，每個 EU 都是有複數 thread 的 SIMD(Single Instruction Multiple Data) 處理器，最多會有 7 個 thread 在 EU 中，且每個 thread 有自己的暫存器可以儲存資料。. 8.

(17) (2)Subslice. 圖 2.3.3 Subslice 細節圖片引用(4) 每個 Subslice 中會有 8 個 EU 執行運算，並加入了 Instruction cache、Local Thread Dispatcher、Data Port 的元件來運行 Subslice，更重要的是，L1、L2 的快取階層也加入在其中幫助資料傳輸，由上圖可推估出，每個 Subslice 會有 56 個 thread 同步執行運算。. 9.

(18) (3) slice. 圖 2.3.4 Gen8 Slice 細節圖片引用(4) 在每個 slice 中有三個 Subslice，並可看出有 24 個核心(EU)在執行運算，同時再加入 Fixed function units、Atomics、Barriers，來協助同步執行 EU 進行平行計算的元件，並引入 L3 階層的快取與 Shared Local Memory 來傳遞資料。. 圖 2.3.5 Gen7.5 Slice 細節圖片引用(3). 10.

(19) (4)Intel Processor Graphics Gen8. 圖 2.3.6 第八代圖形整合顯示核心處理器細節圖片引用(4) 在整個顯示核心處理器中會有兩個 Slice，並可看出整個處理器有 48 個運算核心(EU)，同時加入 Command Streamer、Global Thread Dispatcher、Rendering fixed function units 來維持處理器的運行，同時藉由 GTI(Graphics Technology Interface) 介面，來與更外層的記憶體和 CPU core 等…，可以互相傳遞資料。. 圖 2.3.7 使用 SoC Ring Interconnect 的架構來串連資料傳輸圖片引用(4). 11.

(20) (5) Intel Level Memory Hierarchy. 圖 2.3.8 Intel 記憶體階層圖片引用(4) 上圖為 Intel 官方釋出的記憶體階層圖，可以看出位階越高層的記憶體讀取速度會越快，但容量也會越小，反之低階記憶體則是容量相當大，但讀取速度較慢，因此在撰寫 OpecCL 的內核函式時，要特別注意記憶體的使用，否則平行化的演算法寫得再好，反而會因為記憶體的問題而拖慢程式的執行。另外在圖上的 Shared Local Mem 為往後實驗會常用到的記憶體，圖上標明的容量大小為每個 Subslice 有 64KB，所以整個圖形整合顯示核心處理器會有 384KB 的 Shared Local Mem 可以供內核函式來使用。. 12.

(21) 2. NVIDIA GeForce GTX 900 Series GPUs. 圖 2.3.9 採用 Maxwell 架構的 GTX980 與 GTX780 Ti 外觀圖片引用(5) 在 NVIDIA 推出的 900 系列外接顯示卡產品，是第二代採用『Maxwell』架構所製成，第一代的『Maxwell』架構產品為 GeForce GTX 750/750 Ti，和第一代想比，第二代多了幾項新技術: 動態超分辨力(Dynamic Super Resolution)、第三代三角洲顏色壓縮(Third Generation Delta Color Compression)和多圖元程式設計採樣 (Multi-Projection Acceleration)、Nvidia VXGI(Real-Time-Voxel-Global Illumination) 和 MFAA(Multi Sampling Anti-Aliasing)，同時並加入了支援 HDMI 2.0 的功能。整個硬體架構由小到大為 :CUDA Core 、 SMM(Maxwell Streaming Multiprocessor)、GPCs(Graphics Processing Clusters)，然後再加上 memory controllers 與 PCIE 介面組成整個架構。. 13.

(22) (1) CUDA Core 與 SMM. 圖 2.3.10 SMM 結構圖片引用(6). 14.

(23) NVIDIA 與 Intel 在硬體上的設計有相似的地方，在計算核心(CUDA Core)方面，多個核心會形成一個群組，並在這群組加入 Register 與 Buffer 來存取計算指令與資料，然後這些計算群組在組成更大架構 SMM，並加入 Shared Memory 與 L1 Cache 的元件，如同 Intel 快取階層般的設計，記憶體的存取會隨著階層大小的改變，在存取大小與存取速度會有階層式的改變。另外在 multiprocessor 中，執行平行運算的 warps，是將 32 個 threads 組成一個群組來給執行單元使用，是否意味著最多只能同時計算 32 個內核程式?還有待藉由後面章節的實驗來證實。 (2)GPC 與 Full-chip block. 圖 2.3.11 GTX960 Full-chip block 結構圖片引用(7) 多個 SMM 會組成一個 GPC，再加入第二層的快取:L2 Cache，讓每個 GPC 可以共享此 Cache 的資料，並加上 memory controllers 與 PCIE 構成 Full-chip。. 15.

(24) 2.4 OpenCL 1.簡介. 圖 2.4.1 OpenCL 整合異構平台圖片引用(8) OpenCL[5]是一個為異構平台編寫程式的框架，可以幫助程式撰寫者利用 CPU 或是 GPU 裝置來進行平行計算，其提供了基於任務分割和資料分割的這兩種平行計算機制，程式撰寫者可以依據需求來使用，在使用時必須編寫在 OpenCL 裝置上執行的函式，稱之為內核(kernel)，然後由 excution uint(EU)上的 Single Instruction Multiple Data(SIMD)來執行，其內容是一個基於 C99 所構成的語言，大部分使用起來和撰寫 C 程式語言差不多，少部分的函式可能要看各家廠商的支援與定義，此外 kernel 所需要用到的運算資料，在 OpenCL 1.2 之前都必須從 Host 端 map 到 Device 端才能使用。. 16.

(25) 圖 2.4.2 Host 端與 Device 端架構圖片引用(8) OpenCL 平台的由一個 Host 端再加上數個 Device 端組成，平台底下可以選擇要使用在 CPU 或 GPU 上的 Device 進行平行運算，這些 Device 有: CPU 的運算單元、CPU 中的圖形處理單元(內顯)、外接顯示卡(外顯)，另外 OpenCL 也提供一個實驗性的平台供 OpenCL2.0 以上的版本來使用，但目前只能在特定 CPU 上的 Device 上使用。. 圖 2.4.3 使用 Code Builder 分析工具列出 OpenCL 資訊. 17.

(26) 2. OpenCL 工作單元介紹. 圖 2.4.4 OpenCL 工作單元架構圖片引用(8) (1)Work-item: 最小且最基本的工作單位，在進行平行計算時，每個 Work-item 都會去執行 kernel 中的程式碼，這個動作可以由一個或多個處理元件執行。 (2)Work-group: 數個 Work-item 會組成一個 Work-group，Work-group 中的 Work-item 可以由系統指定或是由使用者定義，但要注意的事:雖然可以自行定義數量大小，但每個硬體設備的運算資源都會有上限，因此給定的數量過大，超過時硬體設備的上限時，同步執行的 Work-item 數量就可能會停在一個上限的定值，並不會讓運算效能無限的增長，此外，OpenCL 運行時，可以同步執行一個以上的 Work-group，但會受限於記憶體大小，同步執行的 Work-group 數量上也有限制。. 18.

(27) (3)NDRange: 所有的 Work-group 所形成的集合，是全部的工作數量，最多可以由 X、Y、 Z 三個維度組成。. 3.OpenCL 記憶體階層與工作單元. 圖 2.4.5 OpenCL 記憶體架構圖片引用(8) 此處先簡介 OpenCL 記憶體與工作單元之間的關係，之後在詳盡介紹各個記憶體的特性和細節，OpenCL 中的記憶體有四種:私有記憶體(Private memory)、區域共享記憶體(Local memory)、全域記憶體(Global memory)、唯讀記憶體(Constant memory)。. 19.

(28) 私有記憶體:每個 Work-item 獨自擁有的記憶體空間，相當於暫存器，容量為最小的。區域共享記憶體: 在同一個 Work-group 共同分享的記憶體空間，行為類似電腦中的 cache 功能。全域記憶體:所有的 Work-group 與 Work-item 都可以讀取其內容的記憶體，雖然容量為最大，但速度相較於私有記憶體與區域共享記憶體來的慢，若要重複讀取資料不建議使用這個記憶體。唯讀記憶體:一塊只能被讀取的記憶體空間，資料寫入以後就不能作修改，通常被硬體實作在全域記憶體中，速度比全域記憶體稍微快些。. 圖 2.4.6 OpenCL 資料移動途徑圖片引用(9). 20.

(29) 第三章 Intel OpenCL Memory Model 在前面的章節中，先簡單的介紹了 OpenCL 記憶體階層與工作單元之間的關係，過來要再更深入的說明這些 OpenCL 所實作的記憶體細節與特性，來做為下個章節進行各項實驗時，所得出的實驗數據，可以合理解釋並歸納出結論，此處以較多官方資料 Intel HD graphics 的 GPU 為主，分別會從私有記憶體(Private Memory)、區域共享記憶體(Local Memory)、全域記憶體(Global Memory)、唯讀記憶體(Constant Memory)依序說明[6]: Private Host Kernel. Local. Constant. Global. No allocation. Dynamic allocation. Dynamic allocation. Dynamic allocation. No access. No access. Read/Write access. Read/Write access. Static allocation. Static allocation. Static allocation. No allocation. Read/Write access. Read/Write access. Read-only access. Read/Write access. 表 3.1 各個記憶體在 Host 端與 Kernel 端特性列表引用(11). 3.1 Private Memory 該記憶體的資料是儲存在 Register File 上，如果資料的大小，可以適當都存入 register 的話，access 的動作就會非常的有效率，但資料大小超過 register 可存儲的限制，例如:使用過大的資料陣列，就會將資料存到 Global Memory 中，一種相對較慢的記憶體，此時 access 的表現就會變得較差。值得一提的是，通常編譯器會 map 靜態的索引陣列到 register 中，此時使用. 21.

(30) Private Memory 的表現就會較好，然而，在某些情況下，編譯器會 map 動態的索引陣列到 register 中，此時 Private Memory access 的動作也會較沒效率。若要使用 Private Memory 就要在宣告陣列會變數或陣列時，加上 private 或 _private 的關鍵字，另外，如果不特別宣告使用記憶體的空間時，該變數或陣列也會被存入 Private Memory。在使用習慣上方面，若是資料量較小或是執行時會更改到的資料內容，就存在 Private Memory 中，如同前面章節提到，每個 Work-item 都會有一份，因此要注意資料量不能太大，否則，即使將超出 Register File 的資料存到 Global Memory 中，加總起來的記憶體量，可能會超過裝置的記憶體限制，導致程式出現錯誤，需要特別注意。. 3.2 Local Memory 此記憶體的資料會被 map 到 Shared Local Memory，在 Intel 的快取階層上，是接近 L3 cache 的位階，但是與 L3 cache 不同的是，這塊記憶體的 latency 較低，所以 access 資料時，可以稍微快一點。另外，在記憶體 access 的設計上，Local Memory 會形成 bank，而不是一串一串的 Cache line 來做 access 的動作，與使用 Global Memory 的 access 相比，提供了較多的模式可以達到 full bandwidth，即一次就將所有資料 access 進來，提供給 Kernel 來使用。. 22.

(31) 圖 3.2 Local Memory Access 範例圖片引用(2) 從上圖可看出，只要符合兩種狀況，記憶體 access 的動作就可以達到 full bandwidth，一種是讀取 bank 中的相同位址，這個情況從上圖的第二個範例就可以看出，然而，在讀取同樣 address 的 bank 時雖然較有效率，但如果是做寫入到同樣 address 的 bank 動作時，就會發生衝突而降低效能;另一種情況則是 access 的 bank 位置只要不發生衝突，也能達到 full bandwidth，從上圖的第一個與第五個範例就為此種狀況，要使用 Local Memory 就要在宣告陣列會變數或陣列時，加上 local 或_local 的關鍵字，如此一來，同個 Work-Group 下的 Work-Item 就能共享這塊記憶體空間，也都有權限對此記憶體進行讀取與寫入的動作，因此要特別注意，若在 Kernel 函式中有寫入的動作，在平行計算的運行下，每個 Work-Item 都會對此記憶體進行寫入的動作，資料將會不停的被修改，此時做讀取動作，得到的資料就不會是單看 Kernel 函式上下文，就能推斷出的內容。. 23.

(32) 3.3 Global Memory 使用這個種類的記憶體時，資料將會被 map 到 L3 cache 上，然而以本論文的實驗硬體 HD graphics 6100 為例，L3 cache 的容量為 768KB，對於需要將大量的場景資料存在 Global Memory 中，來提供 Kernel 共用的圖學程式，此容量顯得非常不足，解決辦法就是將 L3 cache 無法存取下的資料，移到系統的主記憶上，但可想而知，系統的主記憶體 access 速度和 cache 的 access 速度一定會有所差距，所以在大部分的情況下 Global memory 的速度通常會比 Local Memory 與 Private Memory 來的慢，因此在 Intel 官網的記憶體使用建議上，如果會頻繁的 access 資料的話，就不要將資料存在 Global Memory 中，要使用 Local Memory 與 Private Memory 才能提升效能。此外，在記憶體 access 方面，Global Memory 是使用 Cache Line 來做 access 的動作，進行 access 動作時是去抓取 Cache line 上的資料，只有要用的資料都剛好在同個 Cache Line 上，才會達到 full bandwidth，否則的話只能等到其他 Cache Line 進來時才能做完 access 的動作，此外，這個方法有另一個缺點: 當 access Cache line 上相同位址的資料時，就會發生衝突，並不像 Local Memory 形成的 bank 結構，允許 access 相同位址的資料而不會有衝突，相比之下，就可看出 Global Memory 達到 full bandwidth 模式就比 Local Memory 來的少，這也是 Global Memory 會比 Local Memory 慢的一個原因之一。. 24.

(33) 圖 3.3 Global Memory 與 Constant Memory Access 範例圖片引用(2) 上圖的第一個範例與第二個範例展示了要取得資料剛好都在同個 Cache line 上，達到 full bandwidth 的狀態，不過這樣的狀態通常不會很常出現，而第五個範例則展示了最差的狀況，因為不能 access 相同位址上 Cache line 的資料，如果每次要 access 的都剛好在 Cache line 的第一個，就要 access 非常多次才能得到所有的資料，相當的耗費時間，也拖慢了整個平行運算程式的執行。要使用 Global Memory 時，就要在宣告變數或陣列前加上 global 或_global 的關鍵字，這樣該變數或陣列就能讓所有的 Work-Item，都有寫入與讀取這塊記憶體空間的權限，在使用的慣例上，要傳遞的資料若為全部 Kernel 都會共用且執行時不會修改到的資料內容，就會存到 Global memory，整個 Device 端就只會儲存這一份的資料，然後讓每個 work-item 共用，此外，與 Local Memory 同樣的狀況，要注意執行時資料有沒有被單個 Kernel 給修改，以免拿到的資料為錯誤的內容。. 25.

(34) 3.4 Constant Memory 此塊記憶體基本上屬於 Global Memory 的一部分，所以 access 的動作與 Global Memory 大致上相同，且同樣可以被所有的 Work-Item 共享其內容，但不同的是，這塊記憶體是 read-only，如果在 Kernel 中嘗試做寫入的動作，在編譯 Kernel 的階段就會發生錯誤，導致程式無法執行。要使用 Constant Memory 時，在宣告變數或陣列時，要再前面加上_constant 或 constant，這樣該變數或陣列就會變為 read-only 的狀態，對於不需要修改內容的資料就能在編譯階段時，提醒是否內容有被修改，可以幫助提升 Debug 的速度。. 圖 3.4 Kernel 中的 OpenCL Memory Model 圖片引用(10). 26.

(35) 第四章使用 OpenCL 實作有加速結構之光線追蹤程式本章節會介紹:使用 C++的程式語言，在 OpenCL 平台下運行光線追蹤演算法，並且加入 BVH-tree 加速結構的程式實作，在下圖列出的各個流程中，除了會說明每個步驟的實作細節外，也會詳細說明可以改變的設定與參數，以用來實驗這些改變對於效能的影響，對往後的使用者能提供一個參考。. 步驟一. 步驟二. 步驟三. 步驟四. 完成. •對程式下達參數後，讀取場景資訊與模型檔案資訊 •初始化程式的各個變數. •建立BVH-tree加速結構. •調整OpenCL設定 •將繪製圖片所需資料送入Kernel端. •選擇實作stack使用的OpenCL記憶體與調整記憶體大小 •在Kernel中執行光線追縱演算法後，將各個像素計算結果儲存為陣列送回Host端. •顯示繪製出的圖片. 圖 4.1.1 程式執行流程. 27.

(36) 4.1 步驟一程式一開始執行前，會先對程式下達三個參數，分別是場景設定檔名稱字串、模型名稱字串以及要建立 BVH-tree 層數，在這個階段可以進行的實驗為:藉由修改 BVH-tree 層數，來確定何種 tree 的層數所建立的加速結構，對於效能的提升為最佳。 E 529.057373 246.239990 -94.169670 V -2.822931 0 0.176237 F 90 R 512 512 L 7.300000 91.599998 63.400002 圖 4.1.2 場景設定檔範例在場景設定方面，從以上的示意圖來說明，字母 E 後面接的三個浮點數字為 X、Y、Z 座標上的位置，代表攝影機的擺放位置。字母 V 後接的浮點數字為攝影照射方向的向量，然後本程式攝影機上方的向量為 Y 軸，藉由這兩個向量的資料經過一些外積計算，就能確定 ImageSpace(成像平面)在世界座標上所在的位置，字母 F 後接的數字則為視角(angle of view)的大小，此數字會影響到攝影機照射到的範圍。字母 R 後接的兩個數字為繪製圖片的解析度，會影響到要送到 Kernel 中計算的光線數量。字母 L 後接的三個浮點數字為光源的擺放位置。在模型讀取方面，會使用到 Open Asset Import Library(Assimp)[7]，一個可以讀取模型各種資訊的 Library，把模型讀取進 Assimp 設定的資料結構，然後再轉成論文程式使用的資料結構，就能完成讀取模型資料、材質資料的工作。有了上述場景設定與模型資料後，就能夠初始化程式的變數，準備開始繪製的動作。. 28.

(37) 4.2 步驟二在得到步驟一讀取進的模型三角片資料後，就可以準備建構 BVH-tree 加速結構，由於在前文的文獻探討已經對 BVH-tree 的內容有所簡介，在這步驟的實作細節主要放在分類出新節點的方法，本論文實作的 BVH tree 是採用 Top-down 的方法來建構，建立時是在程式的 Host 端完成，是一般的 C++程式，所以是可以使用遞迴的(kernel 裡為 device 端無法使用遞迴)，其基本的方法就是將上層的邊界框(bounding box)中的物件，使用特定的方法分類出兩群，再形成兩個下層的新 bounding box 後，遞迴執行這個步驟直到指定的樹深度，而這裡介紹分類出新節點的方法，主要來自於 Physically Based Ray Tracer(PBRT) [3]的做法，主要有二種:. (1) 以數量來平分出兩群 1000. 500. 250. 500. 250. 250. 圖 4.2.1 以數量來分類的新節點 29. 250.

(38) 將上層節點的物件以 bounding box 的最長軸排序後，根據數量平分成兩群，然後再重新計算出新的 bounding box，形成新的節點，這個過程使用遞迴重複多次就能完成樹的資料結構，這樣實作的好處有:程式撰寫起來非常的簡單、樹的資料結構建立起來相當的快、各個葉節點的物件數量很接近;但壞處就是: bounding box 無法達到最佳，會將一些不必要的區域也劃入，使得節點和光線做交點測試時，較容易被打到，因此需要做較多的物件交點測試，使得縮短的運算時間變得有限。. (2)使用表面積啟發式算法(Surface Area Heuristic，SAH)來分類 B. A. B. A. RAY. RAY. 圖 4.2.2 同個 bounding box 以數量平分與使用 SAH 來分類由上圖就可以看出以數量平分時的缺點，明顯的劃入了一大片根本沒有三角形物件，假如光線從圖示上的方向行進，則左圖就會因為較差的劃分法要去檢查 A 節點，就因此增加了運算的成本; 右圖較優良的劃分法則完全不用去檢查任何節點，當然就能節省更多的運算時間。. 30.

(39) 使用 SAH 劃分法的目的，就在於要找出最好的劃分，但在一個 bounding box 中根據物件的數量，有可能會有很多劃分法可以將物件分成兩群，總不可能將每種劃分法都試過一次後再去分類，更何況這種劃分在每一層的樹狀結構都要實作，全部加總起來的運算量就會非常龐大，因此根據研究，就提出了這個公式，以用來評估當下這種劃分法的成本(cost):. cost(A, B) = p(A) × n in A + p(B) × m in B 其中 A、B 各代表左子樹與右子樹的區域，n 為 A 區下的物件個數，m 為 B 區下的物件個數，p(A)為光線擊中 A 區域形成的 bounding box 機率，p(B) 則為光線擊中 A 區域形成的 bounding box 機率，cost(A,B)除了代表成本外，也代表這光線打到 A 區與 B 區的 bounding box 機率，一個好的劃分法，避免劃入不必要的區域進入 bounding box 外，更應該盡量讓光線行進時無法碰撞到 bounding box，以期望可以做更少交點測試，縮短更多的運算時間，所以 cost(A,B)這個值要越小越好，但前面有提到不可能把所有劃分法都去嘗試，算成本時也是同樣道理，在 PBRT 中是把物件分成 12 個群再去試其中的劃分點，而本論文則是採用分成數量接近 100 的群再去測試劃分點。. C. A B. 圖 4.2.3 父節點 C 與劃分出有重疊區域的子節點 A、B 31.

(40) 然而 p(A)、p(B)這兩個光線擊中 bounding box 機率要怎麼去推估?這裡先做出了一個假設:如果物體的表面積越大，那光線擊中物體的機率就越大，是一個呈現正相關的情況，套用在 BVH tree 的話，則變為 bounding box 的表面積越大，則越容易被光線擊中，基於前面的假設，此處先令父節點 C 區域的表面積為 S(C)，子節點 A、B 的表面積分別為 S(A)與 S(B)，所以光線擊中父節點 C 底下的子節點 A 的機率為 S(A)/S(C)，同理，擊中子節點 B 的機率為 S(B)/S(C)，當然實作時，會期望每次的父節點劃分後，都會讓兩個子節點的總表面積越來越小，讓光線打到的機率越來越小，但實際上，也可能發生劃分後總表面積反而變大的情況，因為會出現如示意圖的狀況，A 與 B 的 bounding box 發生了重疊，部分面積就被重複的計算，這當然不是樂見的情況，當物件數量變的較多、位置又相當相近時就無法避免，但整體來說還是能得到較佳的劃分。雖然使用了導入和表面積相關的 SAH 方法後，可以得到較佳的劃分，相對的就必須要付出額外的成本，這個成本就是在建立樹狀結構時需要花費較久的時間，因為多了要計算出最佳劃分點的時間，要注意的是:這個評估的工作是使用遞迴方法實作，所以不能給定太多的劃分點去評估，否則隨著遞迴的時間複雜度增長，反而使得建樹的時間超過渲染時間許多而適得其反。. 32.

(41) 4.3 步驟三 (1)OpenCL 設定在這個步驟會開始調整 OpenCL 設定，其基本設定在前面的文獻探討已經提過，此處從可以實驗的兩個部分著手，第一個是調整 Local Size 的大小，來觀察程式的平行化程度隨著 Local Size 改變，在效能上會有那些變化，也實驗出各個硬體的 Local Size 的上限大小，供後面的實驗做為設定的參考; 第二個是可以藉由選定不同的 CPU 或 GPU 上的 device 來執行相同的 Kernel 程式，來觀察實驗硬體對效能的變化，在本論文的實驗硬體分為 GPU 與 CPU 的部分，GPU 為: Intel HD graphics 6100 與 Nvidia Gedorce GTX960，CPU 則為 Intel® Core™ i5-4440，實驗主要集中在 GPU 硬體上，詳細的內容會在下一章的實驗章節介紹。 (2)傳遞到 Kernel 中資料的整理. 圖 4.3 傳遞資料整理傳遞的資料主要分成兩部分，較小或不需要共用的資料，如:相機資訊、光源資訊、光線資訊、光線資訊、BVH-tree 進入 Device 中的 Private 記憶體;較大或需要共用的資料，如:BVH-tree 節點資訊、像素結果計算結果資訊進入 Device 中的 Global 記憶體，有了以上資料，準備開始平行計算。 33.

(42) 4.4 步驟四 (1)平行化策略:以像素為單位來做平行化. 圖 4.4 平行化策略在這步驟已經進入到了 Kernel 中，準備開始平行計算，因此就來介紹平行化的策略，在還沒有平行化之前，每個像素的計算是使用 For 迴圈的方式，一條一條光線依序的去和模型中的三角形物件進行交點測試，但是有了 OpenCL 的幫助後，可以使用 GPU 上的 Device，在 Kernel 的記憶體大小允許限制內，同步執行多個 Work-Group，使得同一個時間內可以計算多條光線，其策略是一個像素與一條以 Global ID 編號區分的光線，加上 BVH-tree 加速結構，來與三角形交點測試後算出像素顏色，將結果計在顯示陣列上，等著之後回傳到 Host 端使用 OpenGL 中 glDrawPixels 的函式準備顯示。 (2) 選擇實作 stack 使用的 OpenCL 記憶體與調整記憶體大小由於 Kernel 無法使用遞迴，要自己在程式中實作 stack 才能進行 BVH-tree 的 tree traversal(採用 DFS)，因此會實驗將這個 stack 分別放在 Private memory、Local memory、Global memory 以及使用這些記憶體空間大小對效能的影響。 34.

(43) 第五章實驗與數據分析 5.1 實驗環境與方法首先解釋實驗方法，進行實驗時，會選定一個模型檔，以解析度 512× 512 的大小來繪製靜態場景，這個繪製過程所耗費的時間，就當作效能的參考，不過，因為重點是在使用 OpenCL 時的各個實驗探討，因此回到 Host 端後使用 OpenGL 的函式顯示圖片的時間不會計入，只計入在 Device 端中使用 OpenCL 運算的時間，其計入的時間是用 OpenCL 的 cl_event 來記錄，這個 event 代表者在 Kernel 中所進行的運算事件，可以用 OpenCL 所提供的函式，來得到事件的開始與結束的時間點(單位為奈秒)，只要將這兩個時間相減就能得到在 Kernel 中運算的時間，另外，為了減少誤差，會讓程式重複執行內核函式 100 次，將執行時間加總取平均，來得到更準確的數據。開發環境則在表中有詳細資訊。開發環境作業系統. Windows 10. 主記憶體. 8GB. 開發軟體. Microsoft Visual Studio 2015. OpenCL 版本分析工具. 1.2 Intel® Code Builder 中的 OpenCL Application Analysis 場景設定. 解析度. 512× 512. 場景類別. 靜態場景表 5.1.1 開發環境與場景設定列表. 35.

(44) 除了以執行時間做為效能的參考以外，還會使用 Intel® Code Builder 中的 OpenCL Application Analysis，這個分析工具可以列出在使用 GPU 時，EU 的三種狀態百分比，分別有活躍狀態(active)、暫時停止狀態(stall)、閒置狀態(idle)，可以用來評估 GPU 的效能是否有被充分利用，不過此分析工具只能測得 Intel GPU 的資訊，此外，該分析工具也可以測得在內核函式中那一段程式碼的延遲(latency)較久，即在執行時間耗費時間較久，可以方便找出程式的 bottleneck 來對程式碼做改善。而下表為實驗硬體的詳細資訊: CPU: Intel® Core™ i5-5257U 核心數量. 2 核心(4 執行緒). 頻率. 2.7 GHz GPU: Intel® Iris™ Graphics 6100. 頻率. 300 MHz. 核心數量. 48(EU). 單精度浮點運算能力. 844.8 GFLOPS. 平均每個核心的單精度浮點運算能力. 17.6 GFLOPS. 區域共享記憶體容量(總和). 384 KB(Shared local memory). GPU: NVIDIA GeForce GTX 960 頻率. 1127 MHz. 核心數量. 1024(CUDA core). 單精度浮點運算能力. 2,308.1 GFLOPS. 平均每個核心的單精度浮點運算能力區域共享記憶體容量(總和). 2.254003 GFLOPS 768KB (Shared Memory). 表 5.1.2 實驗硬體資訊列表 36.

(45) 5.2 各項實驗與討論以下的實驗每次都只有一個實驗的變因，其他的設定則維持相同，選定的模型用 Sponza，這個模型有 26 萬多的三角片，數量足夠來測試效能，且可以模擬在室內看場景的狀況，相當適合做實驗模型，繪製出的外觀可看下圖，另外，預計要做的實驗可以看下表。. 圖 5.2.1 Sponza 模型繪製範例實驗名稱程式 Local Size 大小實驗 BVH-tree 層數實驗. 實驗目的確立適當的 Local Size 參數確立適當的 BVH-tree 層數參數. 使用 OpenCL 加速程式實驗. 確定使用 OpenCL 能夠有效加速程式. 使用 BVH-tree 加速程式實驗. 確定使用 BVH-tree 能夠有效加速程式. 使用不同 OpenCL 記憶體當作 stack 使用不同 stack 空間實驗. 實驗使用各個記憶體效能的表現實驗 stack 大小對效能的影響. 表 5.2.1 實驗名稱與實驗目的列表. 37.

(46) (1)程式 Local Size 大小影響 GPU:HD graphics 6100 執行時間與Local size關係圖 30. 25. 24.669357. 執行時間(sec). 20. 14.808548 15. 9.490182. 10. 6.218376 4.936587 4.584087 4.594995 4.581832. 5. 0. 1. 2. 4. 8. 16. 32. 64. 128. Local size 圖 5.2.2 HD graphics 6100 環境下執行時間與 Local size 關係圖圖 5.2.2 的實驗設置為:有使用 BVH-tree 的加速結構，且是在使用 Local Memory 當作 stack 來測試，可以明顯的看出在 Local Size 在 1 到 16 這個階段時，效能會隨著 Local Size 的提升而有明顯的增加，然而 Local Size 超過 16 以後效能提升就變得平緩，甚至不再增加，似乎到達了 HD graphics 6100 這個硬體的上限，所以 HD graphics 6100 的 Local Size 往後實驗參數就設定為 16。. 38.

(47) GPU:GTX960. 執行時間與Local size關係圖 10 9. 8.823186. 8. 執行時間(sec). 7 5.527541. 6. 5 3.491685. 4 3. 2.235998 1.504431. 2. 1.13617. 1.1407. 1.158693. 32. 64. 128. 1 0 1. 2. 4. 8. 16. Local size. 圖 5.2.3 GTX960 環境下執行時間與 Local size 關係圖圖 5.2.3 實驗設置與圖 5.2.2 相同，但在 HD graphics 6100 與 GTX960 這兩個硬體的效能比較上，GTX960 的核心數量佔有優勢，單精度浮點運算能力也相差了約三倍，並且在區域共享記憶體容量相差約 2.6 倍，這些差距使得 GTX960 運算效能較高且同時間可以執行的 Work-Group 較多，預測 Local Size 上限將會比 HD graphics 6100 還要高。圖 5.2.3 可以驗證在 Local Size 在 1 到 32 這個階段時，效能會隨著 Local Size 的提升而增加，到了 Local Size 超過 32 後才變得平緩而達到硬體上限，這點與 NVIDIA white paper 提到 wraps 是 32 個 thread 為群組來做平行運算吻合，剛好可以佐證，因此 GTX960 的 Local Size 往後實驗參數就設定為 32。. 39.

(48) (2)BVH-tree 層數加速比較 GPU:HD graphics 6100 執行時間與BVH tree層數關係圖 70 60.959684. 60. 59.141121 57.911385. 57.528553. 52.877247 49.580243. 執行時間(SEC). 50. 40. 36.232869. 30. 28.17676. 19.238802. 20. 13.71181 9.926158. 10. 7.428668 5.998051. 6.846259 5.1668 4.59422 4.1901233.9192664.0342944.759248. 0 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. BVH tree層數. 圖 5.2.4 HD graphics 6100 環境下執行時間與 BVH tree 層數關係圖圖 5.2.4 的實驗設置是在使用 Local Memory 當作 stack 的環境下實作 BVHtree 加速結構的 tree traversal，從圖 5.2.4 來看，在 1 到 6 層這個階段，太多三角片被分在 leaf node 中，所以加速的效果沒有呈現出來，在超過層數 7 後加速效果才變得明顯，然後到了層數 17 後達到最佳，這時 leaf node 中大約只有 2 到 3 個三角片，再往下分出切割會使得 leaf node 多，如同每個三角片都要檢查，所以所以 HD graphics 6100 的 BVH-tree 層數往後實驗參數就設定為 17。. 40.

(49) GPU:GTX960 執行時間與BVH tree層數關係圖 6. 5. 4.8523924.8555364.854557 4.741453. 4.377293 4.357581. 4.285151. 執行時間(SEC). 4. 3.691139. 3. 2.842269. 2.786991. 2.268326 2.034825. 2. 1.789003 1.627477 1.522881 1.412105 1.265639. 1.199373. 1.098765 1.141549. 1. 0 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. BVH tree層數. 圖 5.2.5. GTX960 環境下執行時間與 BVH tree 層數關係圖. 圖 5.2.5 實驗設置與圖 5.2.4 相同，本來預期 HD graphics 6100 與 GTX960 硬體環境下畫出的線條應該要相似，但實驗後卻發現，雖然在 1 到 6 層這個階段同樣因為太多三角片被分在 leaf node 中，使得加速效果不明顯，但最佳的層數卻是出現在 13，這時 leaf node 中大約有 30 多個三角片，而層數 14 之後加速效能就變得較差，甚至如同不切隔一般，可見在 GTX960 硬體上，對某些運算有做優化，使得不同硬體會有不同的最佳 BVH-tree 層數，因此 GTX960 的 BVH-tree 層數往後實驗參數就設定為 13。. 41.

(50) (3)使用 OpenCL 加速程式. 硬體設備(Local Size). 執行時間(sec). CPU:i5-5257U(1). 21.560709. GPU:HD Graphics 6100(1). 25.944831. GPU:HD Graphics 6100(16). 4.921530. GPU:GTX 960(1). 10.743182. GPU:GTX 960(32). 1.123224. 表 5.2.2 硬體設備與執行時間列表硬體設備與執行時間長條圖 30 25. 25.944831 21.560709. 20 15 10.743182 10 4.92153 5. 1.123224. 0 i5-5257U(1). HD Graphics 6100(1). HD Graphics 6100(16). GTX 960(1). GTX 960(32). 圖 5.2.6 硬體設備與執行時間長條圖本實驗主要測試使用 OpenCL 是否能有效加速程式，實驗設為使用 BVH-tree 的加速結構，且是在使用 Local Memory 當作 stack 來測試，當在使用 CPU device 時，代表者程式沒有被平行化執行，從圖 5.2.6 顯示:雖然在 HD Graphics 6100 環境下 Local size 為 1 時，表現會不如使用 CPU，但在 HD Graphics 6100 與 GTX960 都調整到最佳的 Local size 時，程式都能有效的被 GPU 平行化執行而加速效能，證明了使用 OpenCL 能有效加速程式。. 42.

(51) (4)使用 BVH-tree 加速程式 teapot. light house. 15704. 68179. bunny. dragon. 69630. 871306. 表 5.2.3 測試 BVH-tree 加速效能模型列表上表列出本實驗用到的模型，然後再加上 Sponza 模型，以上模型都是在以 Local Memory 當作 stack 環境下執行程式，來測試 BVH-tree 對不同模型的效能加速程度，來證明該程式的 BVH-tree 為有效的加速結構。. 43.

(52) GPU: Intel® Iris™ Graphics 6100 model. teapot. light house. bunny. sponza. dragon. object size. 15704. 68179. 69630. 262267. 871306. tree depth. 9. 10. 10. 17. 17. with BVH. 0.109666. 0.03838. 0.711575. 4.393354. 32.166493. without BVH. 3.628269. 22.599282. 20.143162. 83.667708. NULL. 加速比例. 33.08472. 588.82965. 28.307855. 19.044153. NULL. 表 5.2.4 HD Graphics 6100 環境下各模型執行時間列表. GPU: NVIDIA GeForce GTX 960 model. teapot. light house. bunny. sponza. dragon. object size. 15704. 68179. 69630. 262267. 871306. tree depth. 9. 13. 3. 13. 18. with BVH. 0.01686. 0.015248. 0.157747. 1.086536. 10.322725. without BVH. 0.238801. 1.134804. 1.197199. 4.904912. 16.707732. 加速比例. 14.16376. 74.423137. 7.589361. 4.514265. 1.618539. 表 5.2.5 GTX 960 環境下各模型執行時間列表在列表中，with BVH 代表在執行時有使用到加速結構，每個像素點的光線都會經過 tree traversal 後，再去對有碰撞到的 leaf node 中三角片做交點測試; without BVH 則代表沒有使用到加速結構，每個像素點的光線一律都要對所有的三角片做檢查，相對的話一定較沒效率，因此從上面兩個列表來看，不管是在 GTX 960 或 HD Graphics 6100 的環境下，使用 BVH tree 加速結構時，雖然各個模型的加速幅度不同，但執行時間都較短，加速結構的功能有確實發揮出來。. 44.

(53) (5)使用不同記憶體當作 stack GPU: Intel® Iris™ Graphics 6100 Type. Time(sec). EU active(%). EU stall(%). EU Idle(%) Latency(cycle). Private. 4.384201. 54.97. 44.84. 0.19. 188.3. Local. 4.209583. 53.99. 45.8. 0.21. 85.3. Global. 4.543793. 50.85. 48.81. 0.34. 190. 表 5.2.6 HD Graphics 6100 環境下使用各種記憶體資訊列表按照原本 Intel 官方的記憶體速度資料來預測實驗結果的話，使用不同記憶體當作 stack 執行時間應該為: Private Menory < Local Memory < Global Memory，不過實際測試後，從上表來看執行時間卻是: Local Memory < Private Menory < Global Memory，可見執行時間不只會受到記憶體速度的影響，也和 OpenCL 實作有關係，在 Local Memory 與 Private Memory 方面，雖然 Private Memory 速度較快，但實際上在 Kernel 中，沒有特別標明的變數、函式的區域變數等等…，都會存在 Private Memory，因此光是 register 的空間就會不夠用，就必須 map 到其他的速度較低記憶體空間，使得整體速度下降，使得在該實驗中表現不如使用 Local Memory 來的好; 在 Local Memory 與 Global Memory 方面，雖然兩者都會使用到位階 L3 cache，Local Memory 提供較多的 access pattern 可以達到 full bandwidth，使得 access 的時間通常較短，所以 Local Memory 表現較好。. 45.

(54) GPU: NVIDIA GeForce GTX 960 Type. Time(sec). Private. 1.113756. Local. 1.096453. Global. 1.153695. 表 5.2.7 GTX960 環境下使用各種記憶體執行時間列表在使用 GTX960 的硬體時，執行時間也是: Local Memory < Private Menory < Global Memory，可見在不同硬體下，執行時間除了受到記憶體速度影響外，一樣會受到 OpenCL 實作的影響，不過在 GTX960 執行時間的差距又變得更小，主要是因為在 Nvadia 硬體在實作 OpenCL 記憶體時，主要是和記憶體的功能性來分類，並不是以速度區分，使得各類型的記憶體到 cache 中 access 資料時，花的時間都差不多，使的效能的表現很接近。. (6)stack 大小對程式效能的影響接下來我們會探討實作 tree traversal 的 stack，在程式中宣告的大小對效能的影響，由於在使用 Private Memory 實作時，改變大小對效能的影響並不是很顯著，因此就改用有明顯變化的 Local Memory 來實驗，列表中會加上同時可以運行的 Work-Group 數量來作為效能的參考，在 HD Graphics 6100 方面是以 Shared local memory 的 384KB，而在 GTX960 方面則是以 Shared Memory 的 768KB，各自來推估 Work-Group 可擺放的數量。. 46.

(55) GPU: Intel® Iris™ Graphics 6100 Size(int) Time(sec). EU active(%). EU stall(%). EU Idle(%). No. workgroup. 20×16. 4.526708. 53.95. 45.82. 0.24. 153.6. 20×32. 4.491110. 54.17. 45.59. 0.25. 76.8. 20×64. 5.416608. 43.93. 55.58. 0.49. 38.4. 20×128. 10.532339. 26.1. 67.86. 6.04. 19.2. 20×256. 20.530934. 13.26. 33.86. 52.88. 9.6. 20×512. 42.450820. 6.63. 17. 76.36. 4.8. 表 5.2.8 HD Graphics 6100 環境下記憶體大小對效能影響資訊列表在使用 HD Graphics 6100 硬體時，Stack Size 為 20×16 與 20×32 時還沒有明顯的變化，到了 20×64 後，效能漸漸地開始被影響，再到了 20×128 後，出現了 Stack Size 變為兩倍時，執行時間也變為兩倍，可見這時候 Local Memory 已經被資料給塞滿，EU active 狀態下降，EU Idle 狀態上升，最後到了 20×512 時，因為同時可以運算的 Work-Group 變的很少，大量的 EU 處於 EU Idle 狀態，使得效能大為下降，可見使用 Local Memory 時，要謹慎的確定宣告容量大小，因為宣告過多會直接的影響到效能，要以適當大小來使用為最好的選擇。 stack size與執行時間關係圖 42.45082. 45. 執行時間(SEC). 40 35 30 25. 20.530934. 20 15 10. 10.532339. 4.526708. 4.49111. 5.416608. 20×16. 20×32. 20×64. 5 0 20×128. 20×256. 20×512. stack size 圖 5.2.7 HD Graphics 6100 環境下 stack size 與執行時間關係圖. 47.

(56) GPU: NVIDIA GeForce GTX 960 Size(int). Time(sec). No. workgroup. 20×32. 1.112786. 38.4. 20×64. 1.494743. 19.2. 20×128. 2.672796. 9.6. 20×256. 5.456085. 4.8. 20×512. 9.678509. 2.4. 表 5.2.9 GTX960 環境下記憶體大小對效能影響資訊列表在 GTX960 環境下，得到的結論與 HD Graphics 6100 相同，Stack Size 的大小還是以適當為主，不要宣告過多，否則會影響效能，不過因為 Code Builder 無法顯示實際執行 OpenCL 的 CUDA core 的狀態，所以不確定是否是陷入 Idle 的狀態，但按照一般 OpenCL 的實作方法，應該也是因為同樣的道理，因為過大的 Stack 占用了太多的 Local Memory 空間，使得同時間能運算的 Work-Group 變少，而拖慢了運算的效率，導致效能低下。. stack size與執行時間關係圖 12 9.678509. 執行時間(SEC). 10 8 5.456085. 6 4 2. 2.672796 1.112786. 1.494743. 20×32. 20×64. 0. 20×128. 20×256. 20×512. stack size. 圖 5.2.8 GTX960 環境下 stack size 與執行時間關係圖. 48.

(57) 第六章結論與未來方向 6.1 結論以往在 OpenCL 的限制下，在 OpenCL 的環境下實作光線追蹤演算法且擁有加速結構的程式相當的少，可以查詢到參考資源有限，在實作加速結構時又會面臨到自己定義的 stack 要放在 OpenCL 下的何種記憶體會較合適? 現在經過一系列的實驗測試後，雖然執行時間的差距很小，但還是可以看出效能會被記憶體類型影響，但每個硬體的影響程度不同，以 Intel HD graphics 來看 local memory 與 global memory 的速度差異，雖然兩者都會使用到位階 L3 cache，但是 Local Memory 提供較多的 access pattern 可以達到 full bandwidth，使得 access 的時間通常較短，所以 Local Memory 表現較好。在 GTX960 執行時間的差距又變得更小，原因在 Nvadia 硬體在實作 OpenCL 記憶體時，雖然各類型的記憶體速度會有差別，但是比起 Intel HD graphics，硬體有較好的優化，使得各類型的記憶體到 cache 中 access 資料時，花的時間都差不多，使得效能的表現很接近。而在使用 Local Memory 實作 Stack 時，要謹慎的確定宣告容量大小，因為宣告過多會直接的影響到效能，要以適當大小來使用為最好的選擇。以上結論提供程式設計師在實作具有加速結構的光線追蹤演算法程式時，有這些建議可以參考，就是本論文的貢獻。. 49.

(58) 6.2 未來與改善方向主要從兩個部分著手，在繪圖品質的提升方面，由於現在每個像素點只有接收一條光線的貢獻，再加上簡單的 Phong model 的效果，畫面品質不太理想，因此可以考慮加入 Distributed ray tracing[9]的作法，讓每個像素點可以接收多條光線的貢獻，進而做出更多的光學效果。而在提升 tree traversal 的速度方面，可以考慮採用 stack-less BVH Traversal[10]，來加速 tree traversal 過程，或是參考 PBRT 的加速結構，改善 tree traversal 的流程，使之不需要每個 node 都走訪，只需拜訪最接近的物件即可，以上就是本論文的改善方向。. 50.

(59) 附圖與附表引用來源 (1) 圖 2.1.1 Wikipedia, Ray tracing https://en.wikipedia.org/wiki/Ray_tracing_(graphics). (2) 圖 2.2.1 Wikipedia, Bounding volume hierarchy https://en.wikipedia.org/wiki/Bounding_volume_hierarchy. (3) 圖 2.3.1、圖 2.3.5、圖 3.2、圖 3.3 Taking Advantage of Intel® Graphics with OpenCL https://software.intel.com/en-us/articles/taking-advantage-of-intel-graphics-withopencl. (4) 圖 2.3.2、圖 2.3.3、圖 2.3.4、圖 2.3.6、圖 2.3.7、圖 2.3.8 The Compute Architecture of Intel® Processor Graphics Gen8. https://software.intel.com/sites/default/files/Compute%20Architecture%20of%20Intel %20Processor%20Graphics%20Gen8.pdf. (5) 圖 2.3.9 http://news.mydrivers.com/1/320/320824.htm. (6) 圖 2.3.10 Nvidia, GeForce - Whitepaper NVIDIA GeForce GTX 980. https://international.download.nvidia.com/geforcecom/international/pdfs/GeForce_GT X_980_Whitepaper_FINAL.PDF. (7) 圖 2.3.11 Nvidia, geforce series 來源: http://www.geforce.com.tw/hardware/desktop-gpus/geforce-gtx-960. 51.

(60) (8) 圖 2.4.1、圖 2.4.2、圖 2.4.4、圖 2.4.5 Khronos Group, OpenCL - The OpenCL Specification version 1.2 https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf. (9)圖 2.4.6 OpenCL memory data flow https://sites.google.com/site/csc8820/opencl-basics/opencl-terms-explained. (10) 圖 3.4 OpenCL Memory Model in Kernel https://scs.senecac.on.ca/~gpu610/pages/content/openm.html. (11) 表 3.1 Memory Region - Allocation and Memory Access Capabilities https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf. 52.

(61) 參考文獻 [1]T. Whitted "An improved illumination model for shaded display" Communications of the ACM, Volume 23 Issue 6, Pages 343-349, 1980. [2] H. J. Haverkort, Results on geometric networks and data structures Chapter 1: Introduction, page 9-10+16, 2004. [3] Intel® , Developer Zone - The Compute Architecture of Intel® Processor Graphics Gen8. Available:https://software.intel.com/sites/default/files/Compute%20Architecture%2 0of%20Intel%20Processor%20Graphics%20Gen8.pdf [4] Nvidia, GeForce - Whitepaper NVIDIA GeForce GTX 980. Available:https://international.download.nvidia.com/geforcecom/international/pdfs/ GeForce_GTX_980_Whitepaper_FINAL.PDF [5] Khronos Group, OpenCL - The OpenCL Specification version 1.2 Available: https://www.khronos.org/registry/OpenCL/specs/opencl-1.2.pdf [6] Intel® , Developer Zone - Taking Advantage of Intel® Graphics with OpenCL Available: https://software.intel.com/en-us/articles/taking-advantage-of-intelgraphics-with-opencl [7] Assimp - Open Asset Import Library. Available: http://www.assimp.org/ [8] M. Pharr and G. Humphreys, Physically based rendering: From theory to implementation, 2004. [9] R. L. Cook, T. Porter, and L. Carpenter, "Distributed ray tracing" ACM SIGGRAPH Computer Graphics Volume 18 Issue 3, Pages 137-145, 1984. [10] M. Hapala, T. Davidovič, I. Wald, V. Havran, and P. Slusallek, "Efficient stackless BVH traversal for ray tracing" Proceedings of the 27th Spring Conference on Computer Graphics, SCCG '11.. 53.

(62)