---

※ 引述《obov (來噓蒼真)》之銘言：
: 推 arrenwu:推~~ 不過 AMD有沒有策略性地讓一些大軟體公司使用 OpenCL  11/26 15:44
: → arrenwu:加速運算啊？ 不然狂推GPGPU一般使用者也感受不到          11/26 15:45

我沒有掛可以爆 不過...OpenCL的可用度還很低.
一年以前還有聽人抱怨,OpenCL寫好的行為在CPU和GPU上不一致.
(有寫CUDA有參考過hotball's hive的話...對 從這位作者這邊得知的)

這問題責任不在AMD上.畢竟基礎的LLVM也是很新的東西.

雙A還沒合併前特別嚴重,2008以後改進一點.可是相較其他方面的表現,

開發東西的時候.都是去看Intel跟nVidia的資料,然後以Intel和nVidia

的平台為測試基準(最後變成,業餘開發者cpu上的IvsA,GPU上的NvsA
的偏好比絕對超過8:2).

可能在學生的時候,沒事就可以在Intel developer上翻到才出沒一年的
新影音格式,含最新的SIMD指令集最佳化的library+sample.
假定做Graphics相關的,那碰到nVidia來推廣甚麼的頻率和Intel不會差太多.
(實際還誇張一點,之前有個人搞CUDA/PhysX on ATI GPU,結果ATI的方面沒有回應它
 的問題,nVidia甚至主動送給這種來拆台的不少資料協助它...)
等這些人開始就業實際開發產品.都習慣了是很難再想到要幫AMD/ATI最佳化這問題.

AMD還有一個風險是直接被compiler婊掉,大概十幾年前,Pentium MMX
vs K6的時候,Intel C compiler 4.0(正式應用的版本裡面算蠻早期的),
沒有甚麼額外的功能比如SIMD支援,號稱對Intel CPU最佳化....
可是相比於Microsoft VC++ compiler,在Pentim MMX上不會變快,在
AMD K6上會變慢最多達40%.....現在AMD在常用compiler上不太需要擔心
發生同樣的問題.不過目前的推土機優勢的整數運算方面是比浮點數更容易
被compiler最佳化婊掉優勢的.如果我是Intel,說不定不用花大錢推新的硬體,
只要靠大家都依賴我的x86開發工具的時候搞一下AMD....

           分隔線

以前不論,AMD現在的努力也不是0,至少一年多前還把重要的人請去做Compiler,

系出同源,都來自現在叫做Open64的東西,前代的stream compiler(brook+)不是不好,



現在OpenCL的語法也是DX10硬體的抽象化(其實根本就是一對一轉換...X),
nVidia可以維持CUDA在Open64上專注於HPC市場,OpenCL面對消費市場+Apple平台.
AMD也可以同樣OpenCL但是具有兩種compiler,一個打HPC市場和CUDA競爭,一個
打消費市場.我去年有推幾個傻瓜一起入坑,自行把OpenCL語法放入Open64 compiler中,
最後借用AMD CAL IL的架構和Tool執行,雖然是玩票性質只有完成基本的雛形,
不過推估起來,把OpenCL和原有的stream compiler(brook)結合是足以對抗CUDA的.




--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.237.63

--