HSA雖好，EPIC並不感冒：編程語言不統一依然是個挑戰

CANCERS

　　AMD謀劃的HSA異構運算之路已經有兩年時間了，他們向開發者描繪了一個宏大的藍圖：有了HSA，未來的CPU和GPU就可以聯合運行，大幅提升性能。這不僅可以用在CPU運算上，遊戲開發也會從中受益，因為GPGPU通用計算也可以提高遊戲性能。

　　在索尼的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++模型。