OpenCL 2.0

OpenCL 2.0規格要開出來了，有一些有趣和實用新功能。對於手機系統來說，2.0應該是好用多了，或許我們該跳過1.2，提早看2.0。
https://www.khronos.org/news/press/khronos-releases-opencl-2.0

- 如何把OpenCL 2.0的implementation做好，對於聯發科是挑戰，也是機會。
- 如何善用OpenCL 2.0的新功能，對於應用開發者是項挑戰，也是機會。
- 我們這幾陣子講硬軟體統合設計，這就是個好例子。看看這些新功能就知道，都是跟效能最佳化有關。
- 有興趣的同學可以下載規格來看看，自問是否看得懂? 看得懂的話，就表示你可以活用平行處理、計算機結構、作業系統所學的知識。規格下載點:
http://www.khronos.org/registry/cl/specs/opencl-2.0.pdf

Facebook貼文出去後，有位朋友的朋友  Champ Yen，寫了以下的留言，因為寫得很讚，所以在此分享給大家:

路人甲又來不自量力地獻醜一下

1. Shared Virtual Memory (共享虛擬記憶體)
這點應就是 AMD 所倡導的 HSA, CPU-GPU 間能夠直接使用 Host 上的 pointer 傳遞資料, 好處是能夠減少因為 Host-Device 位置空間的不同所做的資料傳輸, 由於 Host/Device 能夠有一致的 VA, 因此對於硬體的挑戰是, Device 可能必須支援 Host Processor MMU 的 page table 格式.

2. Dynamic Parallelism (動態平行化)
應該是單純的 software framework 的改進, GPU 能夠 self-enqueue kernels, 減少 CPU 的介入. 如此可以降低 Host Processor 在 OpenCL 中的重要性. 官方說法是當 CPU 速度不夠快時, 這樣的作法效能較佳.

3. Generic Address Space (通用記憶體空間)
由於 1. 的緣故, OpenCL 1.x 的 Memory Model (global, local, private) 已不適用, Device 可能是直接針對 Host Processor 的 Buffer 計算讀寫, 因此 compilation time 時無需再使用 local, global 等修飾詞.

4. Images ( OpenCL 的 Image 功能)
Image 是 OpenGL/OpenCL 的特別功能, 主要在於 OpenGL Sampler 硬體的支援, 與材質很有關係, 也關係到顯示的部份, OpenCL 1.x 不支援在一個 Kernel 中對同一 Image Buffer 同時提供 read/write 的能力, 移除限制的好處是可以直接對 Image 做修改, 減少這樣的限制造成的 Image Buffer 需求, 許多運算可以直接on-the-fly, 特別是現在已很常見的 FullHD 或是下一世代的4K2K這樣的解析度, 如此能夠大幅減少相當的記憶體使用量, 另外也增進了與 OpenGL 協同的能力, 這對於計算畫面到 OpenGL 有更方便的支援. 硬體上實作上在 image buffer 的使用與 Sampler 硬體可能必須考量讀寫流程與同步上的問題.

5. C11 Atomics
OpenCL 1.x 僅支援 inter-workitem synchronization, 這點應該支援有限的 inter-workgroup synchronization, 這部份應該也是軟體支援上同步機制的要求提高了.

6. Pipes
這點對於硬體的影響是強制必須提供足夠彈性的 DMA 支援與介面.
Pipe 提供了動態資料流動的能力, 在 OpenCL 1.x 的時候, 必須 Kernel 執行之前特定把所有的資料配置完成, 程式在運作時都是存取固定的資料, 這樣的設計缺點是必須遷就資料的流程來設計程式, 另外執行前大量 memory access, 在需大量資料的情況可能會因此造成效能折損, 再者這樣一陣一陣的 memory burst access 對於 SoC 系統並不是好事, 而在 1.x 這樣的問題, 是在 Host 端透過各別的 Queue, 來分開 Control 與 Data 的傳輸, 但這樣的方式也取決於該硬體平台的資料傳輸部份是否支援這樣的行為, 這裡藉由納入規範的 pipe 將能夠對 memory 的存取能有更平均且有效的利用. 

7. Android Installable Client Driver Extension (Android 的 ICD 擴充)
看來是準備推廣到 Android 平台上了.

個人認為比較可惜的是 SPIR 沒有列為必要的項目, 僅僅列在 extension 的部份
對於 Programmer 來說, OpenCL 2.0 的限制變少了, 提供了 pointer 傳遞資料就讓Programmer 不用再考慮Host-Device 間惱人的 buffer 同步問題, 更不用說這樣最大的差異是 Programmer 能夠輕易地 leverage to GPU, 未來因為HSA所帶來的影響可以說一定非常巨大(想想 GUI framework or Vector Rendering 這類軟體架構與環境, 能大幅利用 OpenCL 來分散工作, 大幅提高效能), 還有 Pipe FIFO 這工具可以使用, 同步上也提供了更多的機制. OpenCL 2.0 對於 Programmer 的友善程度真的是大幅提升, 可以說我同意 OpenCL 2.0 可以說是 HW-SW co-design 的好例子.