QSVEncの強いメモリ速度依存性
正直びっくりした。
QSVEncはメモリ速度に結構左右される、とは思っていたけど、これほどまでとは…。
ふと、QSVEncの速度がメモリの速度に左右されやすいのではないか、と思い至った。
調べてみると、
4.gamers - Ivy Bridge基礎検証。CPUの基本性能やGPGPU性能などから，Sandy Bridgeとの違いを徹底的に探ってみるのグラフ11などで、QSVにメモリ速度が関係あるかもしれない、ようなことが指摘されている。
そこで、実際に測ってみた。
環境
Win7 x64
Intel Core i7 3770K (4C/8T / 3.9GHz)
HD Graphics HD4000 @ 1150MHz
DDR3-xxxx 16GB Dual-Channel
(G.Skill F3-2133C9Q-16GAB)
Aviutl 0.99m
m2v.aui 0.7.5a
lsmashinput.aui 自ビルド (別に変わったことはしてないです)
QSVEnc 0.08
Intel HD Graphics 2761ドライバ
Aviutlのフィルタは無し
MPEG2 1440x1080i 29.97fps 10000frame
QSVEnc設定
品質: Quality
CQP: 24:26:27
Vpp: インタレ解除(通常)
この環境・設定で、
DDR3-1066 (17.1GB/s) [8-8-8-20] 1.40V
DDR3-1333 (21.3GB/s) [9-9-9-24] 1.40V
DDR3-1600 (25.6GB/s) [9-9-9-24] 1.40V
DDR3-1866 (29.9GB/s) [9-11-10-28] 1.50V
DDR3-2133 (34.1GB/s) [9-11-10-28] 1.62V
と変化させ、エンコード速度を測った。
また、比較のため、
x264 r2216 x64
x264guiEx 1.58
でも測った。
インタレ解除はAviutlの「自動」、
x264は--crf 23 --slow
という設定。
結果
まずはx264のエンコードから。デコーダはlsmashinput.aui。
こんな感じで、メモリ速度が速いほどエンコードも高速化するけど、さほど大きな差ではない。ふつう、メモリの速度はこんな感じであまり実行速度に影響しない。Aviutlでフィルタをかけたり、10bit版x264を使ったり、x264をもっと重い設定にするともっと差は縮まる。
DDR3-2133のメモリとかは相変わらず高いので、コストパフォーマンス的には微妙なところ?
今度はQSVEnc、QSVなのでそこそこ高速。こちらはlsmashinput.auiでデコードした場合とm2v.auiでデコードした場合の両方を測った。
これほどまでとは…。
DDR3-1066からDDR3-2133へと2倍にする間に、エンコード速度は1.7倍になっている。
また、メモリ速度を上げていくとデコーダの速度差が効いてくるのも面白い。m2v.auiもlsmashinput.auiもデコード専用にスレッドを立てるけれども、m2v.auiは1スレッドなのに対してlsmahsinput.aui(というか内部のlibavcodec)はマルチスレッドなので、その差が出てくるんじゃないかと思う。
こうなってくると高いメモリ買ったかいもあるというもの…?
どうしてこうなった…?
基本的にCPUからするとメモリアクセスというのはかなり"遅い"操作になっていて、それをなんとかするためにL1/L2/L3の3段階のキャッシュがついている。
こちらのグラフ14やらグラフ15を見れば分かる通り、キャッシュ領域(～8MBまで)に比べ、メモリ領域(16MB超)のレイテンシは10倍以上、帯域は1/10以下だ。つまり、キャッシュ内に収まるデータについての計算やメモリコピーは高速で、メモリの速度は処理速度にあまり影響しないのだけど、キャッシュからあふれ始めると処理が遅くなり、またメモリ速度が処理速度に大きく影響するようになる。
そしてQSVEncでエンコ中は大容量のメモリアクセスを頻発させてしまう。
QSVEncで出力中のAviutlのおおまかな処理の流れはたぶんこんな感じ…。なんか間違ってたら教えてください。
GPU EUというのはGPUの実行ユニット、MFXというのがいわゆるQSV固定ハードウェアのこと。
実線矢印を追えば処理の流れがわかり、破線も含めて矢印の色ごとにループを追えば、主な3つのループの動きがわかる…えと、わかる…よね? え、わかりにくい? すいません。
ここで、QSVというのはIntel iGPUにあるので、CPUメモリからGPUメモリへのコピーが発生し(物理的には同じメモリーだが、メモリコピーは発生する)、またVpp処理やエンコードのStage1(動き探索等)はGPU EUで行うため、このへんでも相当なメモリアクセスが発生するようだ。加えてAviutl側のメインループもx264エンコ時などよりはずっと高速に回るため、キャッシュを食い合い、メモリアクセスを乱発させる、ということになってるんじゃないかな…と予想できる。
つまり、高速で処理される結果、x264エンコ時と比べてメモリアクセスの頻度が相対的に大きくなって、メモリ速度が大きく影響するようになっているのだと思う。
ところで、さっきの記事ではSandyでは差が見られない、という話だった。
記事には、IvyBridgeからメモリコントローラが改善されていることが理由なのではないか、と書かれている。個人的にはそれに加えてGPU Boostの影響もあるかもしれないと思う。
SandyBridgeではIvyBridgeと比べるとGPU側のBoostがかかりにくかった記憶がある。そのため、メモリの速度云々以前の問題として、GPU Boostがかからないことも速度的に問題になっているかもしれないと思った。(GPUが通常駆動のままだとさすがに遅いです)
QSVEncはメモリ速度に結構左右される、とは思っていたけど、これほどまでとは…。
ふと、QSVEncの速度がメモリの速度に左右されやすいのではないか、と思い至った。
調べてみると、
4.gamers - Ivy Bridge基礎検証。CPUの基本性能やGPGPU性能などから，Sandy Bridgeとの違いを徹底的に探ってみるのグラフ11などで、QSVにメモリ速度が関係あるかもしれない、ようなことが指摘されている。
そこで、実際に測ってみた。
環境
Win7 x64
Intel Core i7 3770K (4C/8T / 3.9GHz)
HD Graphics HD4000 @ 1150MHz
DDR3-xxxx 16GB Dual-Channel
(G.Skill F3-2133C9Q-16GAB)
Aviutl 0.99m
m2v.aui 0.7.5a
lsmashinput.aui 自ビルド (別に変わったことはしてないです)
QSVEnc 0.08
Intel HD Graphics 2761ドライバ
Aviutlのフィルタは無し
MPEG2 1440x1080i 29.97fps 10000frame
QSVEnc設定
品質: Quality
CQP: 24:26:27
Vpp: インタレ解除(通常)
この環境・設定で、
DDR3-1066 (17.1GB/s) [8-8-8-20] 1.40V
DDR3-1333 (21.3GB/s) [9-9-9-24] 1.40V
DDR3-1600 (25.6GB/s) [9-9-9-24] 1.40V
DDR3-1866 (29.9GB/s) [9-11-10-28] 1.50V
DDR3-2133 (34.1GB/s) [9-11-10-28] 1.62V
と変化させ、エンコード速度を測った。
また、比較のため、
x264 r2216 x64
x264guiEx 1.58
でも測った。
インタレ解除はAviutlの「自動」、
x264は--crf 23 --slow
という設定。
結果
まずはx264のエンコードから。デコーダはlsmashinput.aui。
こんな感じで、メモリ速度が速いほどエンコードも高速化するけど、さほど大きな差ではない。ふつう、メモリの速度はこんな感じであまり実行速度に影響しない。Aviutlでフィルタをかけたり、10bit版x264を使ったり、x264をもっと重い設定にするともっと差は縮まる。
DDR3-2133のメモリとかは相変わらず高いので、コストパフォーマンス的には微妙なところ?
今度はQSVEnc、QSVなのでそこそこ高速。こちらはlsmashinput.auiでデコードした場合とm2v.auiでデコードした場合の両方を測った。
これほどまでとは…。
DDR3-1066からDDR3-2133へと2倍にする間に、エンコード速度は1.7倍になっている。
また、メモリ速度を上げていくとデコーダの速度差が効いてくるのも面白い。m2v.auiもlsmashinput.auiもデコード専用にスレッドを立てるけれども、m2v.auiは1スレッドなのに対してlsmahsinput.aui(というか内部のlibavcodec)はマルチスレッドなので、その差が出てくるんじゃないかと思う。
こうなってくると高いメモリ買ったかいもあるというもの…?
どうしてこうなった…?
基本的にCPUからするとメモリアクセスというのはかなり"遅い"操作になっていて、それをなんとかするためにL1/L2/L3の3段階のキャッシュがついている。
こちらのグラフ14やらグラフ15を見れば分かる通り、キャッシュ領域(～8MBまで)に比べ、メモリ領域(16MB超)のレイテンシは10倍以上、帯域は1/10以下だ。つまり、キャッシュ内に収まるデータについての計算やメモリコピーは高速で、メモリの速度は処理速度にあまり影響しないのだけど、キャッシュからあふれ始めると処理が遅くなり、またメモリ速度が処理速度に大きく影響するようになる。
そしてQSVEncでエンコ中は大容量のメモリアクセスを頻発させてしまう。
QSVEncで出力中のAviutlのおおまかな処理の流れはたぶんこんな感じ…。なんか間違ってたら教えてください。
GPU EUというのはGPUの実行ユニット、MFXというのがいわゆるQSV固定ハードウェアのこと。
実線矢印を追えば処理の流れがわかり、破線も含めて矢印の色ごとにループを追えば、主な3つのループの動きがわかる…えと、わかる…よね? え、わかりにくい? すいません。
ここで、QSVというのはIntel iGPUにあるので、CPUメモリからGPUメモリへのコピーが発生し(物理的には同じメモリーだが、メモリコピーは発生する)、またVpp処理やエンコードのStage1(動き探索等)はGPU EUで行うため、このへんでも相当なメモリアクセスが発生するようだ。加えてAviutl側のメインループもx264エンコ時などよりはずっと高速に回るため、キャッシュを食い合い、メモリアクセスを乱発させる、ということになってるんじゃないかな…と予想できる。
つまり、高速で処理される結果、x264エンコ時と比べてメモリアクセスの頻度が相対的に大きくなって、メモリ速度が大きく影響するようになっているのだと思う。
ところで、さっきの記事ではSandyでは差が見られない、という話だった。
記事には、IvyBridgeからメモリコントローラが改善されていることが理由なのではないか、と書かれている。個人的にはそれに加えてGPU Boostの影響もあるかもしれないと思う。
SandyBridgeではIvyBridgeと比べるとGPU側のBoostがかかりにくかった記憶がある。そのため、メモリの速度云々以前の問題として、GPU Boostがかからないことも速度的に問題になっているかもしれないと思った。(GPUが通常駆動のままだとさすがに遅いです)
スポンサーサイト
