鐵之狂傲
標題:
HSA雖好，EPIC並不感冒：編程語言不統一依然是個挑戰
[列印本頁]
作者:
CANCERS
時間:
13-9-3 04:01
標題:
HSA雖好，EPIC並不感冒：編程語言不統一依然是個挑戰
AMD謀劃的HSA異構運算之路已經有兩年時間了，他們向開發者描繪了一個宏大的藍圖：有了HSA，未來的CPU和GPU就可以聯合運行，大幅提升性能。這不僅可以用在CPU運算上，遊戲開發也會從中受益，因為GPGPU通用計算也可以提高遊戲性能。
13-9-3 04:02 上傳
下載附件 (點選圖片檢視原圖)
(262.34 KB)
在索尼的PS4主機上就出現了這樣的描述，PS4使用了8GB GDDR5做CPU和GPU的統一記憶體，
架構設計師表態稱遊戲開發商可以利用這個遊戲來改善遊戲性能
。
雖然前景如此美妙，但是並非所有遊戲開發商都對HSA感興趣。EPIC Games創始人Tim Sweeney認為，即便有了hUMA支援，CPU和GPU編程語言的不一致依然是一個極大的障礙。
他在給
VR-Zone
的郵件中說到“將記憶體定址變成一個快取一致的共享定址空間對目前的GPU/CPU編程來說是個進步，但問題是在PC上如何實現它？DirectX還是OpenGL？這種變化會降低新技術被接受的步伐。不一致的編程模型(CPU上用C++，GPU上用OpenCL/
CUDA
)依然是一大極大的挑戰。最終，我還是會選擇C++這樣的主流編程語言，可以通過循環矢量化、編譯器自動化並行轉換來搞定硬體定址，而不會選擇用另一種語言在GPU上編程。”
VR-Zone又聯繫了AMD企業理事Phill Rogers，後者也對Tim的質疑做了回應，Roggers表示Tim的問題正是HSA異構運算未來的目標——在CPU和GPU上使用單資源、高級語言編程。這也是他們開發HSA的原因——統一定址，提供完整的記憶體一致性以及擴充GPU處理器對C++的完整支援能力。
除了HSA平台之外，編程語言模型確實需要進一步發展以便更易於GPU加速，OpenCL 2.0和C++AMP在這個方面已經邁出了堅實的一步。OpenCL 2.0已經支援統一定址及快取一致性，C++AMP已經允許在GPU和CPU上編譯特殊的算法。HSA平台將推動這些編程模型進一步發展，以使它們變成開發者熟悉的純C++模型。
歡迎光臨 鐵之狂傲 (https://gamez.com.tw/)
