今日も今日とてRichlandの記事をお届けします。もちろんそっちが書きたいのが一番ですが、最近のテレビ界がどうも現実離れしてきて･･･「4Kだ｣って押してるのはいいんですが、もはや量販店のテレビ売り場が55型以上の超々大型を｢主力｣として大きく飾り、押し出している一方で、普通に見れば充分超大型な50型すら中型扱いで雑多コーナー行き、42型はもう小型扱い。どうせ一般人は買い換えないだろうと金持ちマニアしかターゲットに出来ないってことなんだろうけど、55型や60型は家に入れるのも一苦労で好きな場所におくのは不可能。最近そろそろテレビの買い替えを･･･ともくろんでいるわたしの部屋もどうがんばっても46/47型が精一杯、出来ればもう一回り以上小さくしたいところ。今年中に42/46型の新プラズマが出なかったら、しょうがない液晶で妥協して三菱の39型あたり検討しよう。
と、テレビのあり方に苦情を入れたところで本題Richland、A10-6800K。
前回、｢速いは速いけど、もうひとつ物足りない｣と書きました。となると少しいじってみたいところですが、個人的にあまり本格的オーバークロックとか趣味じゃないし、まだたくさん記事も書かなきゃいけない段階で、万が一のことがあると･･･
エイスースクエスト！！！！！！
ＴＰＵスイッチを使え！！
おっと、ここで指令です。F2A85-M PROについている機能の一つ、お手軽オーバークロックを試す課題が出てきました。ただ、勉強会当日、AMD側から｢くれぐれもオーバークロックは自己責任でお願いします｣と釘を刺されています。自己責任、つまり壊れても文句は言いません機能を試してくれと課題を出されるのは何か矛盾している気がしなくもないですが、まぁやってみましょう、この程度で壊れるほどチャチな作りはしてないはずですし。
マザーボードの電源スイッチやリセットスイッチを挿すコネクタ付近に存在するTPUスイッチ、これをオンにすることで、安定度重視ながら若干のオーバークロック動作が実施される装置だそうです。ちなみにオンにしたあとUEFIをチェックすると、クロックが｢TURBO 非使用時で4300MHz｣となってました。これがわたしのA10-6800Kから導き出された安定して動くだろうオーバークロック数値ということです。もちろん非常に簡易的な測定で導き出した数字ですから、これが限界ということもないでしょうね。もっと突き詰めたければUEFIで調整するもよし、付属ツールやAMD純正ツールのOverDriveを使うもよし、ですから。
このTPU状態で、AviUtlの前回と同じ条件で出力時間とワット数を測定してみましょう。
前回は
19.67fps 44分40.9秒 130〜140W
でした。TPU時には
20.43fps 43分3.8秒 145〜150W
おお、少しですがあがってます。高が知れてるといえばそれまでですが、fpsが19台から20台にあがると、なんか妙にあがった気分です。ただ、その分消費電力も上がってますが
エイスースクエストパート２ゥゥゥゥゥ
ＥＰＵスイッチも使ってみよ！！！！！
スイッチつながりで今度はEPU。当然ながら省電力機能です。こちらのスイッチをオンにすると、UEFIのEPU POWER SAVING MODEが有効になります。それだけ？ って気がします。ひょっとしたら知らないところで効果が出ているのかも知れません。また同じ条件で
19.45fps 45分13.5秒 130〜135W
何もしないよりワット数の幅が小さくなり、ほぼ前半で収まるようになりました。それなりに省電力になってます。その分誤差の範囲とは言え、速度も落ちてますが。
大丈夫だ！ こんなこともあろうかと思って、ＴＰＵとＥＰＵは同時利用が可能になっている。それを試してみるんだ！
こんなこともあろうかと思って、が出てきてしまいました。まぁUEFIの中の設定を意識せずにお手軽に書き換える機能ですから、同時利用も出来て当たり前ですけどね。
20.26fps 43分26.2秒 145〜150W
あれぇ、TPU単独と比べてもあんまり下がった気がしません。そのくせほんのちょっぴりですが遅くなってます。多分EPUがTPUに引っ張られてしまって効果が半減したんでしょう。
TPUもEPUもあくまでお手軽機能です。そもそもAMDは電圧に関しては少し盛ってあることが多いので、あまり慎重にならなくてもCPU電圧を少し下げる程度の省電力は簡単に出来ますので、自分で試したほうがいいでしょう。
さて、もうひとつの本題。今使っているRichlandシステムにはDDR3-2133のメモリを使っています。これは事前に〜というか勉強会直前に秋葉原で買ってきたものです。そのときは2133対応は6800Kだけって知らなかったんですけどね、危ないところでした。ただ、実は肝心のマザーボード、F2A85-M PROが2133に正式対応していません(笑)。どうするべーとちょっとあせりましたが、オーバークロック扱いで2133メモリも使えるとのこと。そのため自動認識で2133にはなってくれませんが、まぁいいやとセットしてから手動で2133に切り替え。なお、Latencyに関してはマザーのデフォルトの9だとOSが落ちますので、10まで落としてます(メモリの指定Latencyは11)。メモリはどんどん速度が増し、ゲームなどをプレイする場合はその恩恵は受けられるでしょう。ただ、ゲームを遊ぶのなら、同じ値段でグラボ(GT640とかHD7750なら手が届くかも)を買い、メモリはあまっているDDR3-1333とかを流用したほうがいい、なんていうAPUの概念を否定する事態がベスト、なんて可能性もあるわけです。それはいけません、ゲーム以外の分野でのメモリ速度の影響を見てみましょう。普通のソフト処理もそうですが、注目はなんといってもGPGPUです。高速メモリの影響でGPGPUが飛躍的に速度が上がるのなら、DDR3-2133を入れる価値は充分あるわけです。GDDR5とかのメモリをガバチョと積んだハイクラスならともかく1万円そこそこのグラボならPCI-Eを介すムダの影響のために内蔵にはかなわないでしょうから。
手軽なGPGPUと言えば動画エンコード、APUの動画エンコードといえばVCEです。VCEの処理がGPGPUと読んでいいものなのかどうかは分かりませんが、これでやってみましょう。
前回の計測では2133(Latency10)で
75.31fps 12分27.3秒
でした。ソフト処理の19.67fps 44分40.9秒と合わせ、メモリの速度を1333(Latency9)と比較してみましょう。どれだけ落ちるか。
VCE 61.42fps 15分2.8秒
ソフト 18.83fps 46分39.9秒
ソフトエンコードも落ちていますが、微々たる差です。ソフトのために高速メモリを買うくらいだったら、それこそオーバークロックでもやったほうがマシというものです。その一方でVCEの速度差の圧倒的なこと。前回のCore i3のQSVの結果"62.72fps 14分44.4秒"と比べると、CPU差があるにもかかわらずメモリを同等速度にすると負けてしまっています。つまり、速度能力だけで判断するのなら、VCEはQSVにかなわないんです。にもかかわらず、メモリを高速にするとこの通り。GPGPUを扱う時如何にメモリの速度がものを言うかが分かります。最近のAMDはIntelを置き去りにしてメモリのクロックを上げることに注力していますが、それは決してゲームのためだけでなく、GPGPUで実現するOPEN CLのためでしょう。もちろんIntelのCPUの内蔵GPUやQSVも高速なメモリを使うことで高速化する可能性はあります。が、IntelCPUは従来の古い基準･ベンチマークソフトの数値だけでしか評価されないという宿命を背負ったCPUで、そのために多くの人は内蔵メモリコントローラーの規定速度よりも高速で動く高価なメモリとマザーボードを買うよりそのお金でグラボを単体購入すると思われます。多分内蔵GPUやQSVのための実験をしてくれる人などほとんどいないでしょう。先日登場したHaswellの評価を見ている限り、これからIntelは難しいだろうな、と思わずにいられません。シェアの面では苦戦していますが、AMDの方が未来に向けた分かりやすい戦略をとっているように見えています。
他のメモリ速度、1600と1866もVCEだけ実行してみました(2400だと起動せず)
1600
67.65fps 13分44.1秒
1866
72.27fps 12分56.3秒
1866と2133の差が小さいのは、メモリ速度が現在のVCEの処理限界に近づいたために頭打ちになったためと思われます。これからVCEはSPLASH TOP(タブレットに現在のPC画面を転送するソフト)にも使われるようになるなど、APUの重要な機能として使われるようになるはずです。hUMAとの相性も間違いなく良いので、単純なエンコード機能を含め、発展していって欲しいものです。
ただ、ここからは苦言を言いますが、現状のVCEにはまだ満足していません。まずオーバークロックとの相性が悪すぎます。先に書いたTPUによるお手軽OC状態ですら、VCEは設定画面を出すだけでOSが確実に落ちるほどでした。
その逆の省電力機能との相性もとことん悪く、利いた瞬間極端に速度が落ちるどころか、数秒間もエンコードがとまってしまうことがあります。
実は今回の速度測定、かなり苦戦しました。ウチの冷却が足りないのか(一応ASUSのツールではCPU温度は42度程度になっているのですが)、エンコード途中になぜかワットが極端に落ちるケースがありました。一瞬だけなら、スタンバイ並みの46Wまで消費電力が落ちることすらあるのを確認しています。ターボが利いているとその瞬間2GHzまで速度が落ちるのでターボを切ったりもしてみたのですが、クロックが落ちなくなるだけでCPUが半停止し、一瞬エンコードが遅くなってしまう変わりはありませんでした。実は前回書いた｢もうひとつ物足りない速度結果｣になった最大の原因がコレで、もし発生しなければもう１〜２fpsは速度が上がっていてもおかしくないんです。ですが、こういう一瞬消費電力を落とすのもRichlandの機能のうちか、と思ってソフトエンコードは存在を無視することにしました(速度もちょうどいい具合になってますし)。ところがVCEのエンコードは無視できないほどの影響があります。GPUにデータを渡すCPUが半停止するため、GPUはデータ待ちの状態になってしまいます。すなわち数秒間エンコードが完全停止するんです。その差は、終了時のfpsで最大20fps！もありました。
今回の測定結果は、POWER NOWやC6と言った省電力機能を無効にし、AMD OverDriveでターボ化対象コアを０(デフォは２)にし、かつエンコード開始と同時にAviutlを最小化した上で実行しました。それでも3回に2回は省電力停止が確認できたため、出だし5%ほどの時のfpsと終了時のfpsの差がプラマイ5fps以下〜つまり省電力に足を引っ張られず最後までVCEが完走したと判断できたものだけをデータとして採用しました。家に戻ったら、グリスを塗りなおしてクーラーを変更し、ケースに戻した上で再調査したいと思います。もちろん同条件でTrinityとの比較もしたいと思ってます。
と、テレビのあり方に苦情を入れたところで本題Richland、A10-6800K。
前回、｢速いは速いけど、もうひとつ物足りない｣と書きました。となると少しいじってみたいところですが、個人的にあまり本格的オーバークロックとか趣味じゃないし、まだたくさん記事も書かなきゃいけない段階で、万が一のことがあると･･･
エイスースクエスト！！！！！！
ＴＰＵスイッチを使え！！
おっと、ここで指令です。F2A85-M PROについている機能の一つ、お手軽オーバークロックを試す課題が出てきました。ただ、勉強会当日、AMD側から｢くれぐれもオーバークロックは自己責任でお願いします｣と釘を刺されています。自己責任、つまり壊れても文句は言いません機能を試してくれと課題を出されるのは何か矛盾している気がしなくもないですが、まぁやってみましょう、この程度で壊れるほどチャチな作りはしてないはずですし。
マザーボードの電源スイッチやリセットスイッチを挿すコネクタ付近に存在するTPUスイッチ、これをオンにすることで、安定度重視ながら若干のオーバークロック動作が実施される装置だそうです。ちなみにオンにしたあとUEFIをチェックすると、クロックが｢TURBO 非使用時で4300MHz｣となってました。これがわたしのA10-6800Kから導き出された安定して動くだろうオーバークロック数値ということです。もちろん非常に簡易的な測定で導き出した数字ですから、これが限界ということもないでしょうね。もっと突き詰めたければUEFIで調整するもよし、付属ツールやAMD純正ツールのOverDriveを使うもよし、ですから。
このTPU状態で、AviUtlの前回と同じ条件で出力時間とワット数を測定してみましょう。
前回は
19.67fps 44分40.9秒 130〜140W
でした。TPU時には
20.43fps 43分3.8秒 145〜150W
おお、少しですがあがってます。高が知れてるといえばそれまでですが、fpsが19台から20台にあがると、なんか妙にあがった気分です。ただ、その分消費電力も上がってますが
エイスースクエストパート２ゥゥゥゥゥ
ＥＰＵスイッチも使ってみよ！！！！！
スイッチつながりで今度はEPU。当然ながら省電力機能です。こちらのスイッチをオンにすると、UEFIのEPU POWER SAVING MODEが有効になります。それだけ？ って気がします。ひょっとしたら知らないところで効果が出ているのかも知れません。また同じ条件で
19.45fps 45分13.5秒 130〜135W
何もしないよりワット数の幅が小さくなり、ほぼ前半で収まるようになりました。それなりに省電力になってます。その分誤差の範囲とは言え、速度も落ちてますが。
大丈夫だ！ こんなこともあろうかと思って、ＴＰＵとＥＰＵは同時利用が可能になっている。それを試してみるんだ！
こんなこともあろうかと思って、が出てきてしまいました。まぁUEFIの中の設定を意識せずにお手軽に書き換える機能ですから、同時利用も出来て当たり前ですけどね。
20.26fps 43分26.2秒 145〜150W
あれぇ、TPU単独と比べてもあんまり下がった気がしません。そのくせほんのちょっぴりですが遅くなってます。多分EPUがTPUに引っ張られてしまって効果が半減したんでしょう。
TPUもEPUもあくまでお手軽機能です。そもそもAMDは電圧に関しては少し盛ってあることが多いので、あまり慎重にならなくてもCPU電圧を少し下げる程度の省電力は簡単に出来ますので、自分で試したほうがいいでしょう。
さて、もうひとつの本題。今使っているRichlandシステムにはDDR3-2133のメモリを使っています。これは事前に〜というか勉強会直前に秋葉原で買ってきたものです。そのときは2133対応は6800Kだけって知らなかったんですけどね、危ないところでした。ただ、実は肝心のマザーボード、F2A85-M PROが2133に正式対応していません(笑)。どうするべーとちょっとあせりましたが、オーバークロック扱いで2133メモリも使えるとのこと。そのため自動認識で2133にはなってくれませんが、まぁいいやとセットしてから手動で2133に切り替え。なお、Latencyに関してはマザーのデフォルトの9だとOSが落ちますので、10まで落としてます(メモリの指定Latencyは11)。メモリはどんどん速度が増し、ゲームなどをプレイする場合はその恩恵は受けられるでしょう。ただ、ゲームを遊ぶのなら、同じ値段でグラボ(GT640とかHD7750なら手が届くかも)を買い、メモリはあまっているDDR3-1333とかを流用したほうがいい、なんていうAPUの概念を否定する事態がベスト、なんて可能性もあるわけです。それはいけません、ゲーム以外の分野でのメモリ速度の影響を見てみましょう。普通のソフト処理もそうですが、注目はなんといってもGPGPUです。高速メモリの影響でGPGPUが飛躍的に速度が上がるのなら、DDR3-2133を入れる価値は充分あるわけです。GDDR5とかのメモリをガバチョと積んだハイクラスならともかく1万円そこそこのグラボならPCI-Eを介すムダの影響のために内蔵にはかなわないでしょうから。
手軽なGPGPUと言えば動画エンコード、APUの動画エンコードといえばVCEです。VCEの処理がGPGPUと読んでいいものなのかどうかは分かりませんが、これでやってみましょう。
前回の計測では2133(Latency10)で
75.31fps 12分27.3秒
でした。ソフト処理の19.67fps 44分40.9秒と合わせ、メモリの速度を1333(Latency9)と比較してみましょう。どれだけ落ちるか。
VCE 61.42fps 15分2.8秒
ソフト 18.83fps 46分39.9秒
ソフトエンコードも落ちていますが、微々たる差です。ソフトのために高速メモリを買うくらいだったら、それこそオーバークロックでもやったほうがマシというものです。その一方でVCEの速度差の圧倒的なこと。前回のCore i3のQSVの結果"62.72fps 14分44.4秒"と比べると、CPU差があるにもかかわらずメモリを同等速度にすると負けてしまっています。つまり、速度能力だけで判断するのなら、VCEはQSVにかなわないんです。にもかかわらず、メモリを高速にするとこの通り。GPGPUを扱う時如何にメモリの速度がものを言うかが分かります。最近のAMDはIntelを置き去りにしてメモリのクロックを上げることに注力していますが、それは決してゲームのためだけでなく、GPGPUで実現するOPEN CLのためでしょう。もちろんIntelのCPUの内蔵GPUやQSVも高速なメモリを使うことで高速化する可能性はあります。が、IntelCPUは従来の古い基準･ベンチマークソフトの数値だけでしか評価されないという宿命を背負ったCPUで、そのために多くの人は内蔵メモリコントローラーの規定速度よりも高速で動く高価なメモリとマザーボードを買うよりそのお金でグラボを単体購入すると思われます。多分内蔵GPUやQSVのための実験をしてくれる人などほとんどいないでしょう。先日登場したHaswellの評価を見ている限り、これからIntelは難しいだろうな、と思わずにいられません。シェアの面では苦戦していますが、AMDの方が未来に向けた分かりやすい戦略をとっているように見えています。
他のメモリ速度、1600と1866もVCEだけ実行してみました(2400だと起動せず)
1600
67.65fps 13分44.1秒
1866
72.27fps 12分56.3秒
1866と2133の差が小さいのは、メモリ速度が現在のVCEの処理限界に近づいたために頭打ちになったためと思われます。これからVCEはSPLASH TOP(タブレットに現在のPC画面を転送するソフト)にも使われるようになるなど、APUの重要な機能として使われるようになるはずです。hUMAとの相性も間違いなく良いので、単純なエンコード機能を含め、発展していって欲しいものです。
ただ、ここからは苦言を言いますが、現状のVCEにはまだ満足していません。まずオーバークロックとの相性が悪すぎます。先に書いたTPUによるお手軽OC状態ですら、VCEは設定画面を出すだけでOSが確実に落ちるほどでした。
その逆の省電力機能との相性もとことん悪く、利いた瞬間極端に速度が落ちるどころか、数秒間もエンコードがとまってしまうことがあります。
実は今回の速度測定、かなり苦戦しました。ウチの冷却が足りないのか(一応ASUSのツールではCPU温度は42度程度になっているのですが)、エンコード途中になぜかワットが極端に落ちるケースがありました。一瞬だけなら、スタンバイ並みの46Wまで消費電力が落ちることすらあるのを確認しています。ターボが利いているとその瞬間2GHzまで速度が落ちるのでターボを切ったりもしてみたのですが、クロックが落ちなくなるだけでCPUが半停止し、一瞬エンコードが遅くなってしまう変わりはありませんでした。実は前回書いた｢もうひとつ物足りない速度結果｣になった最大の原因がコレで、もし発生しなければもう１〜２fpsは速度が上がっていてもおかしくないんです。ですが、こういう一瞬消費電力を落とすのもRichlandの機能のうちか、と思ってソフトエンコードは存在を無視することにしました(速度もちょうどいい具合になってますし)。ところがVCEのエンコードは無視できないほどの影響があります。GPUにデータを渡すCPUが半停止するため、GPUはデータ待ちの状態になってしまいます。すなわち数秒間エンコードが完全停止するんです。その差は、終了時のfpsで最大20fps！もありました。
今回の測定結果は、POWER NOWやC6と言った省電力機能を無効にし、AMD OverDriveでターボ化対象コアを０(デフォは２)にし、かつエンコード開始と同時にAviutlを最小化した上で実行しました。それでも3回に2回は省電力停止が確認できたため、出だし5%ほどの時のfpsと終了時のfpsの差がプラマイ5fps以下〜つまり省電力に足を引っ張られず最後までVCEが完走したと判断できたものだけをデータとして採用しました。家に戻ったら、グリスを塗りなおしてクーラーを変更し、ケースに戻した上で再調査したいと思います。もちろん同条件でTrinityとの比較もしたいと思ってます。