OpenCL test on APU

這應該是我第一次正式測試OpenCL在APU上的表現

用的是WinZIP 16.5 (這版官方號稱有對APU最佳化)
用來壓縮解壓縮的是Mozilla Firefox 15
計時用的是DC的錄影功能,frame by frame 測量時間
用Ramdisk 儲存壓縮跟解壓縮資料,避免硬碟讀寫緩慢的影響
壓縮方式選zipx (似乎是WinZIP新推的格式,不相容以往的zip)

使用的環境是:E-350 (Full Speed),Windows 7 home prium

壓縮:
OpenCL enabled:26.96 sec
OpenCL disabled:27.68 sec

解壓縮:
OpenCL enabled:4.16 sec
OpenCL disabled:4.16 sec

壓縮的部份有開OpenCL  約可以快2.67%
解壓縮部份則有開沒開速度完全一致

很怪吧 應該不至於會這樣才對
用GPUz 看了一下,GPU 不管壓縮解壓縮
GPU時脈 始終在待機的278MHz 而不是滿載的492MHz

目前想不出辦法讓GPU持續Full Speed
等有辦法在做後續補充測試

E-350 GPU compute !?

今天把一直想做的事完成了
也就是GPU對轉檔效能影響到底如何?

想當然而採用的是好用且有用的A’s Video converter
GPU 可介入的運算有三部分,影片解碼,放大縮小,影片編碼

針對這三部分分別做了
CPU(無GPU介入運算) ,純GPU(三部分都有GPU介入運算)
以及靠CPU縮小(其他GPU有介入運算) 靠CPU編碼(其他GPU有介入運算)
註1:A’s Video Converter 無法正確偵測E-350 GPU Load,所以附上GPUZ
註2:這邊的純指的是GPU加入運算的程度

整理成表格是這樣

CPU GPU FPS
CPU 100% 0% 17
GPU 60% 29% 20
CPU encode 66% 13% 21
CPU scale 63% 15% 18

簡單的歸納:
GPU在解碼、放大縮小、編碼都有加速到(但幅度不明顯)
GPU甚至在縮小部分只有減輕CPU負擔,編碼FPS只高純CPU 1 frame
可以注意到除了純CPU之外,GPU(13~29%) CPU(60~66%)都不是高負載狀態
也就是說CPU GPU 存在著一個瓶頸
讓這兩個處理單元需要互相等來等去(沒有充分運算到運算效能)

同場加映 與E-350接近的平台
CPU:K8 X2 3800+(2G);GPU:Radeon HD 4670
(雖然說接近但GPU CPU效能都比E-350 稍微高一些)
測試還是一樣分成四個,純CPU純GPU靠CPU縮小靠CPU編碼

整理成表格是這樣

CPU GPU FPS
CPU 100% 0% 18
GPU 67% 20% 30
CPU encode 75% 11% 29
CPU scale 99% 27% 34


這兩個平台就CPU部分效能來說,同時脈K8跟E-350 相近

(註3:E-350比K10慢10%,K8比K10慢5~15%)
加上時脈的影響K8 X2 3800+ 總效能應該比E-350高10%左右
純CPU編碼的FPS也反應出此現象(K8 X2 3800+ 多了1 frame)
但其他三組測試在GPU加入運算後,E-350就明顯比K8平台低落許多
這邊可以注意到K8平台的 CPU scale部分,整個瓶頸是落在CPU效能上
(Radeon HD 4670 雖然比E-350快不少,
但E-350 GPU load 很輕 問題應該不會是在GPU上)

結論:
為什麼這兩個平台納入GPU運算後效能會差這麼多?
不外乎是APU 通用運算上,GPU、CPU可能出現架構及頻寬衝突
註4:
DDR   400MHz   頻寬(400MHz x 64bit ) / 8bit = 3.2GB/s
DDR3 1066MHz 頻寬(1066MHz x 64bit ) / 8bit = 8.5GB/s
(以上測試這兩個平台都是採單通道)

如果APU會有出頭的一天,AMD必須要解決GPU、CPU的衝突
就AMD釋出消息來看有兩個地方確定有問題
問題1.E-350設計的頻寬遠遠超過記憶體所能負荷的頻寬
由Llano看來 雙通道+1866MHz應該差不多符合 APU設計需求
(不過此時記憶體頻寬
E-3503.5,也就是E-350頻寬嚴重不足)
問題2.當進行Fusion Compute時,CPU存取弱勢必須修正

綜合以上兩者適度反應出
E-350平台在GPU加入計算之後CPU就在60%上下的原因
雖然下圖是Llano的不過Zacate (Bobcat) APU架構大部分與Llano 幾乎相同


註5:
E-350 採64bit Win7、K8 採32bit WinXP
這部份32bit、64bit、Win7、WinXP是否有很大的影響 是個未知數
(看雙方純CPU的FPS符合預期只差10%,猜測不會影響太大)

以下為預測AMD未來繼續發展APU會碰到的問題
GCN核心通用運算大幅提昇
(VLIW4、VLIW5 所能處理之通用運算的範圍跟效能都遠遠不及GCN)
另外GCN 圖形運算效能比起VLIW4提昇30~40%
(E-350還只是VLIW5,今年會推出的Trinity 則是VLIW4)
GCN效能增進帶來的頻寬需求絕非雙通道+DDR3 1866MHz就可以解決
甚至雙通道+DDR4也幾乎可以確定不夠使用
雖然AMD號稱GCN記憶體控制器有改善,可以抑制頻寬需求對APU有幫助

感想:AMD啊!
你就早點走入三通道 或者把sideport memory復活 還是把記憶體做在APU上吧
這東西沒解決在怎麼畫唬爛,弄漂亮的PPT 也是沒用的

APU’s Performance / watt -Part1

入手了lenovo ideapad s205
想當然就是為了裡面這顆APU(E-350)

號稱有效能又省電的情形,實際上表現是如何呢?

播放民視HD 試試看播放時間,大致上可以播個2個半小時(wifi有打開)
勉強算是及格了吧
這兩個半小時大概可以看一部電影以上,看棒球則還稍嫌不足一點點(前提:要用硬解)

之後會陸續測試GPU 100%(遊戲中) 以及GPU 0%(純軟解SD)的時間

updated:純軟解SD的播放時間約1.67小時(沒想到比硬解1080i MLB還耗電
CPU佔用率45% CPU時脈則是一直維持1.6G

updated again:測試SD軟解部分有一些小問題
測試環境是用wifi 連線播遠端影片,耗電上wifi的部分也佔了不少
之後會再測試local上的播放情形 2.5

Hardware decode back again!

本來在Linux上是可以硬解的
不過在一段時間沒用硬解後,某天發現竟然不能硬解了

找東找西還是找不到原因,以為是驅動程式的問題就不去理它了
今天發現竟然是下面這個
mplayer-vaapi 搭配vf使用不能硬解
把他去掉馬上就回復可以硬解的狀態(很鳥的原因不知道為什麼以前沒想到)

然後搭配上為了在Linux看HiHD準備的MD-535
使用

tzap -a 0 HiHD + dvbstream -o -a 0 8192|./mplayer - -cache 2048 -va vaapi -vo vaapi

就可以完成一年多以來"在Linux上看HiHD"的目標
可惜AMD還是沒在Linux 驅動程式 加上反交錯的功能

Dynpm in kernel 2.6.35

之前在2.6.33時有介紹過
ATI Opensource driver 在KMS模式下要怎麼開dynpm(動態能源管理)
到了ubuntu 10.10(kernel 2.6.35) 這個方法就不管用了,換成一種方式

能源管理分成兩種方式 dynpm,profile
前者是依照GPU loading 作動態調整,後者是依據profile 強制於某種使用模式下

  • 先介紹比較簡單的dynpm
echo dynpm > /sys/class/drm/card0/device/power_method

這樣就可以啟動dynpm,可以執行下面指令看看有沒有成功

cat /sys/kernel/debug/dri/0/radeon_pm_info
  • 再來是稍微複雜的profile
echo profile > /sys/class/drm/card0/device/power_method

指定好電源管理模式後,profile要怎麼用

echo low > /sys/class/drm/card0/device/power_profile

紅色的地方有default,auto,low,mid,high 這些選項可以選

以上設定只是暫時性的在工作階段有作用 (重開機後設定就消失)
如果要保留設定就把命令寫在/etc/rc.local 裏面

Radeon HD 4670 bios edit

Radeon HD 4670 bios 依據廠商不同 設定有很大的差異
尤其Radeon HD 4670 有powerplay

可以設定boot,UVD,powersaving 時的時脈,電壓
進而達到省電又有效能的目的

注意:更新 or 修改BIOS 有一定風險會失敗,請自行承擔
(修改BIOS之前要知道自己在做什麼)

首先需要GPU-Z 來dump bios

然後開啟RBE (Radeon BIOSeditor)載入這個bios開始編輯
(Bios方面可以參考 Asus 的)
我參考之後再加上自己的一些嘗試結果是這個

修改完後再用winflash載入修改後的bios,在按下程式等一兩秒就完成了

備份載點
atiwinflash20111

RBE

參考用bios(AsusRV730,modRV730,RV730)

由於Radeon HD 4670 有兩種版本 GDDR3 512MB,DDR3 1GB
記憶體方面的設定可能會因為這個不同而不能通用

compile ATi open source driver

最近opensource driver 在R6xx/R7xx 更新蠻多的
可是自從6.13.1釋出後,一直等不到新版出現

所以就打算自己動手編,怎麼編照理說應該不用特別寫出來
可是中間會碰到一兩個卡卡的地方,所以還是寫這篇做註記

1.必須要更新macros

git clone git://anongit.freedesktop.org/git/xorg/util/macros
cd macros

順便指定安裝位置(編譯時需要)

./autogen.sh --prefix=/opt/xorg
make install

然後再指定macros的安裝路徑

export ACLOCAL="aclocal -I /opt/xorg/share/aclocal"

2.編譯driver (注意紅字

git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-ati
cd xf86-video-ati
./autogen.sh --prefix=/usr
make
sudo make install

Previous Older Entries