こちらの特集記事『「Sandy Bridge」完全攻略!! Core i7-2600KとCore i5-2500Kを徹底的に試す』で、「Media SDKを使っても高速化できない」という話をレポートしたわけだが、Sandy Bridgeの場合、「Desktop向け製品の場合、Discrete Graphicsを使っているとMedia Processingが利用できない」という制限があることが判明した。というわけで、これに関してちょっと追加で検証を行った。
Media Processingは記事でも紹介した通り、Sandy BridgeのGPUに内蔵される形で搭載されており、これをIntelのMedia SDK 2.0経由で利用することでエンコードなどを高速にできるというものだが、この結果としてGPUが稼動できる状況でないと利用できない。で、Sandy Bridgeの場合、Mobile向けの製品は外部にDiscrete Graphicsを接続している状態でも内蔵GPUを有効にできるため、Media SDK 2.0経由でMedia Processingを利用可能だが、Desktopの場合はこれが不可能に設定されている。なので、H67などを使ったケースでもDiscrete Graphicsを装着すると利用できないし、P67では内蔵GPUが一切使えないことになる。前回の評価はP67の環境で行ったので、そういう意味ではMedia Processingが事実上使えていなかったわけだ。そんなわけで、テスト環境をH67搭載のDH67BLに切り替えて再テストしてみた。ちなみにCPUはちょっとCore i7-2600Kが用意できなかったので、Core i5-2500Kでの比較である。
ちなみにTMPGEnc Video Mastering Works 5自身もわずかな間にバージョンアップされており、最新の体験版は5.0.1.19となっている(Photo62)。さて、この環境で前回のMPEG-4/AVCのファイル出力設定を読み込ませて見ると、ちゃんとエンコーダにIntel Media SDK Hardwareが出現した(Photo63)。もっともこのままの設定でエンコードを掛けようとすると、この通りエラーとなる(Photo64)。そんなわけで、もう一度あらためて出力設定をやりなおしてみた(Photo65)。
|
|
Photo62: 前回比較の際のバージョンは5.0.1.17であった。バージョンアップ内容は見当たらなかった。 |
Photo63: パフォーマンスが「とても遅い」なのが悪かった模様。これはx264では選択できるが、Media SDK Hardwareでは選択できない。 |
|
|
Photo64: 最初はVBRが悪いのかと思ったのだが、そういう訳ではないようで。 |
Photo65: テストに利用した出力設定はこんな感じ(MPEG-4の場合)。 |
テストに利用したのは、
- MPEG-2 : HDV向けMPEGファイル
- MPEG-4 : MP4(AVC)ファイルの作成
のそれぞれのテンプレートで、MPEG-2はデフォルトのまま、MPEG-4は映像エンコーダの種類(x264/Intel Media SDK Hardware/Intel Media SDK Software)とレート調整モードの変更(CBRとVBR(平均ビットレート))のみで、あとは一切変更せずに実施している。エンコードソースはグラフ80～83と同じく、1440×1080pixel@23.97fpsのWMV9映像(3671フレーム)である。
|
さて、エンコード速度の結果はグラフ90の通りである。MPEG-2は前回のPhoto58同様に4 Threadが100%に張り付き(Photo66)。MPEG-4は? というとx264(Photo67)はCBR/VBR共にやはり98～99%前後の利用率である。問題のMedia SDK Hardwareは? というと33%前後(Photo68)、Media SDK Softwareの場合は27%程度だった。エンコード速度そのもので言えば、Media SDK Hardwareを使った場合、x264を利用した場合と比較してCBRの場合でほぼ倍、VBRの場合では4倍もの差がついている。もっとも、Media SDKを使った場合はCBRとVBRでまるで性能に差が無い(Media SDK Softwareの場合、若干ながら高速化までしている)というあたり、一体Media SDKではVBRをどう処理しているのか不明な部分が残る結果ではあるのだが、CBRで比較しても軽く倍というあたりで、その威力は確認できたと言えよう。
|
|
Photo66: Core i7-2600Kの8ThreadですらCPUを使い切るだけに、当然4Threadだと100%。 |
Photo67: x264を使う場合も、やはり全コア100%近く。 |
|
|
Photo68: Media Processingを使う場合、割と満遍なくすべてのCPUが利用される感じである。 |
Photo69: Media Processingが使えない場合、特定の1 CPUだけですべての処理が使われている感じになる。 |
ついでにこの際の消費電力を比較したのがグラフ91である。Idleは何も処理を行っていない待機状態の数値である。これだとやや差がわかりにくいので、待機時と各処理を行っている場合の消費電力差を示したのがグラフ92である。MPEG2やx264を使った場合の消費電力と、Media SDK Softwareの場合の消費電力から、CPUコア1個あたりの消費電力は100%換算で12～13W程度と想定される。(残りはメモリコントローラとかRing BusなどのUncore部が、負荷が高まったことで消費電力が増えていると考えられる)。この計算で言えば、Media SDK Hardwareを使っている際のCPUコアの消費電力は概ね20W程度。これにメモリコントローラなどを加えた分で37W程度となり、これと実際の消費電力(44～46W)が、Media Processingの消費電力増分と考えられる。ということで、計算上は7～9W程度の消費電力で、およそCPUコア1個あたりと比較して6.2倍程度のエンコード能力を提供できるという計算になる。
|
|
これは確かに強力なツールと言えそうだ。ただ、最初にも書いたとおりP67とかH67+Discrete Graphicsの環境では利用できない(今回試しにDiscrete Graphicsを装着して見たところ、メニューからIntel Media SDK Hardwareが消えた)ようなので、自作PCのユーザーなどは環境構築時に注意したほうがいいだろう。VBRの実装がやや不思議なのはおそらくMedia SDK側の問題と思われるので、このあたりは実際に使う場合はエンコード結果を比較するといった作業は別途必要になると思う。
