rigayaの日記兼メモ帳

---

以下、Introduction to AVX2 optimizations in x264からおおまかに意味をとると、

---

x264は様々なデータ型を多様なSIMD命令を使って計算している。SIMDコードのうち、128bitから256bitへ素直に拡張できるのはほんの少しで、多くはもっと複雑である。64bitから128bitへの拡張した際に倍速になることがほとんどなかったように、128bitから256bitへの移行も倍速となることはほとんどないだろう。

SSE2からAVX2への移行は、MMXからSSE2への移行と似ている部分が多いけれども、いくつかの点で異なることもある。

1つは、初期のSSE2命令は遅かったりしたけど、HaswellのAVX2命令はちゃんと速いということである。
SSE2が最初に出たときは、SSE2命令が結構遅かった。初期のSSE2はMMX命令を2回(64bit×2)とSSE2を1回(128bit×1)が同速だったり、下手するとSSE2命令1回のほうが遅いなんてこともあった。この状態が解消され、MMX命令1回とSSE2命令1回がきちんと同速になるにはCore2の45nm世代までかかった。今回はそんなことはなさそうで、HaswellではAVX2命令はちゃんと速そうだ。

2つめは、AVX2命令はなんか変なことが多くて、一部のvpermdのような命令を除くと、256bitに素直に拡張したというよりは、128bit×2をやる命令、という形で拡張されている場合が多い。これによってIntelの実装は楽になるのだけど、コードを128bitから256bitに拡張するのに余計な手間がかかったりする。

3つめは、x264が256bit幅より狭いデータを扱う関数がそれなりにたくさんあって、こうしたものに対して、有効にAVX2を使うのは非常に難しかったり、不可能だったりする、ということだ。比較的複雑な関数の多くは、AVX2に移植しても予想よりあまり効果を上げられなかったりした。


多くの関数をAVX2に移植したけれども、まだ十分な最適化を行った、という段階ではないので、まだ高速化の余地はある。実際に動かしてみると、速いだろうと思っていたコードをさらに速くする方法を見つけられたりしたし、今後もそういう発見があるだろう。加えて、まだAVX2に対応できていない関数もあるので、全体としてはあと少し最適化の余地があるように思う。

加えて言えば、x264はすべてがSIMDコードというわけではなく、実行時間の半分ぐらいは普通のCのコードなため、すべてのSIMDコードが倍速になっても、x264全体としては1.33倍しか速くならない。実際にはAVX2によって倍速になることはほとんどないので、高速化率はさらに低めだろう。

---

で、あとは関数ごとの高速化率の一覧が書いてある。

---

というわけでAVX2の実装ありがとうございます。おかげで、Haswellが期待はずれに終わる、ということは無さそう。x264が対応したことで、Haswellはぐっと魅力的なものに…。うー、早く出ろ。

もうひとつ言うなら、表はHaswellにおいての「AVXまで」vs「AVX2」の比較なので、これをSandy/Ivyと比べたらもう少し高速化率に上乗せできそうな気がする。(さらに+10%ぐらい?)

あとは、256bit幅より狭いデータを扱う場合にAVX2が効果的でない、ということだけど、裏を返すと10bit版だとより高速化できるかもしれないのかな…と思う。

---

---

x264の--threadsでは、bitrateの増加は気にしない、と書いた。で、今度は一応そのへんも気にしてみよう、ということ。

画質はとりあえずssimの値で評価する。(まあ画質をssimだけで比較するのは微妙だろうけど、それ以外に客観的に比較できないので)

---

環境
Intel Core i7 3770K (4C/8T, 3.9GHz @ 1.05V)
メモリ DDR3-1600 9-9-9-24 16GB

Win7 x64
Aviutl 0.99m
x264 r2208 x64 8bit
x264guiEx 1.57

素材
H.264 1920x1080p 23.976fps 2154frames

Aviutl フィルタ無し

x264 オプション
--preset slow --tune ssim --crf 20 --qcomp 0.7 --min-keyint 4 --keyint 240 --subme 9 --trellis 2 --ssim

Core i7 3770Kは論理8コアなので--threadsは自動設定なら"12"となる。

---

とりあえず、今回も速度から。

まあ、これまでとほぼ同じ傾向。--threads 12～21ぐらいまでが最速。22～24はやはり多すぎるのか、やや遅くなっている。

次に、容量(bitrate)とssimの変化を見てみる。

違いがあるとはいえ、そんなに大きな差じゃない。

わかりにくいので、--threads 1の時に対する値の変化をグラフにしてみる。

bitrateが増えたといっても今回は0.2%以内なので、そんなに気にする程でもない。

しかし、容量は画質とあわせて考えるべきもの。画質が良くなっていれば、容量が増えるのは当たり前だ。その点、このグラフでは容量と画質を合わせて考えるのには向いていない。

容量と画質を合わせて考えるためにグラフの書き方を変えてみた。

横に容量の変化、縦に(ssim)画質の変化をとっている。点の横についているラベルが--threadsの値。

左にいくほど高圧縮、上にいくほど高画質なので、左上にいくほど良くなっていて、右下に行くほどよろしくない。

--threadsを増やしていくと、徐々に低画質・低圧縮の「よろしくない」右下に移動していってしまう。あまりスレッド数を増やすのは良くないのかもしれない。特に--threads 15以上は特に速くなっていないのに容量・画質がわずかだが共に悪くなっているようだ。

---

スレッド数をむやみに増やすと速度がやや遅くなるだけでなく、画質・圧縮率もわずかに悪くなるみたいだ、ということがわかった。

繰り返すと、「画質・圧縮率もわずかに悪くなる」といってもたいした差はないので、あまり気にするほどではない。速度が上がるなら、--threadsは増やしたほうがいいと思う。

しかし自動で設定される論理コア×1.5以上に設定してもほとんど速度は上がらないし、画質・圧縮率の面でもいいことがない。--threadsは自動でいい、と。…というか結論はずっとこれですな。

---

CPU使用率やスレッド表示はProcessHackerを使用。眺めてると面白いです。…わたしだけか。

---

まず、この前のCPU使用率。

こんな感じでAviutlが5～10%、残りがx264で、ほとんどx264ばかりが動いている状況。

スレッドとかの状況。

クリックで拡大

でも、自動フィールドシフトとか、その他いろいろな重いフィルタを使用すると、Aviutlのほうの処理が重くなるので、もっとAviutl側が動くようになり、x264の使用出来るCPU時間が減っていく。

ちょっと条件を変えて、
・自動フィールドシフト(スレッド=16)
・透過性ロゴ
・クリップ&クロップ
・リサイズフィルタ
・エッジレベル調整MT
・バンディング低減MT
(NL-Means Light GPUは省略)
あたりのフィルタを入れてみると

Aviutlが40%前後、x264が60%前後…

こういうAviutlとx264がCPUを奪いあうような状況では、x264の--threadsの値がエンコード速度にどう関係するのか…、デフォルトのままでいいのか…。

---

環境
Intel Core i7 3770K (4C/8T, 3.9GHz @ 1.05V)
メモリ DDR3-1600 9-9-9-24 16GB

Win7 x64
Aviutl 0.99m
x264 r2208 x64 8bit
x264guiEx 1.57

素材
犬日々ED部分 1920x1080i 29.97fps 1分35秒

Aviutl フィルタ
・自動フィールドシフト(スレッド=16)
・透過性ロゴ
・クリップ&クロップ
・リサイズフィルタ
・エッジレベル調整MT
・バンディング低減MT
(NL-Means Light GPUは省略)

x264 オプション
--preset slow --crf 20 --qcomp 0.7 --aq-strength 0.4 --psy-rd 1:0.2 --min-keyint 4 --subme 9 --trellis 2

---

(参考)各スレッドの状況

クリックで拡大

Aviutlのスレッドの状況の拡大

クリックでもっと拡大

こんなかんじで、大量のスレッドがAviutlの方でも動き、さらにx264のスレッドもたくさん動く、というカオスな状況になっている。

---

結果

今回は、--threads 15～21あたりが最速。とはいえ、自動設定の--threads 12と差はごく僅か。あと、やはりスレッド数を増やしすぎると、少し遅くなるようだ。(--threads 22～24はやはりやや遅い)

--threads 10がなんか妙に遅いのは割り込みが入った(なんか裏で動いた)のかもしれない…寝ている間にやらせているのでよくわからないけど。

--threads 1の時に対する倍率に直すとこんな感じ。

AviutlのほうもCPUを食うので、高速化率は前回(最大×4.16倍)には当然及ばず、×3.2倍ほどだった。

---

これが当然の結果なのかはよくわからないけれど、Aviutlとx264がCPUを奪い合うような状況でも、前回(ほとんどx264のみが動く)時と同じ傾向のグラフになった。僅かな差はあるものの、基本的には--threadsの指定はデフォルトでいい模様(※1)。

つまり、特にいじらなくてもちゃんと速度が出るよ、という確認ができたのかな、と。

(※1)
まあ、今回の最速は--threads 15～21だったように、こんな感じで測定すれば最速となるところはわかるのだろうけど、ほんの少しの差だし、環境や設定によっても少しづつ変わるだろうし、この測定も結構面倒なので、もう自動でいいんじゃないか、とそういうこと。

続きます。(こちら>>)

---

x264が自動的に設定する論理コア数×1.5が最適で、少なくいとCPUが遊んで遅くなり、多くてもスレッド切り替えが多発してやや遅くなる、らしい。

i7 3770Kは論理8コアなので、自動設定では--threads 12。

じゃあ、ほかの--threadsを設定したらどうなるのか、比べてみる。

---

環境
Intel Core i7 3770K (4C/8T, 3.9GHz @ 1.05V)
メモリ DDR3-1600 9-9-9-24 16GB

Win7 x64
Aviutl 0.99m
x264 r2208 x64 8bit
x264guiEx 1.57

素材
H.264 1920x1080p 23.976fps 2154frames

Aviutl フィルタ無し

x264 オプション
--preset slow --crf 20 --qcomp 0.7 --aq-strength 0.4 --psy-rd 1:0.2 --min-keyint 4 --subme 9 --trellis 2

---

今回は--lookahead-threadsは気にせず自動設定にする。自動では--lookahead-threadsは--threadsの1/6(小数点以下切り捨て)になる。

--threadsを増やすと、ほかが同じ設定でも容量(ファイルサイズ)が大きくなる。確かに1%ほどビットレートが増加した。が、今回は気にしない事にする。

---

結果

--threadsを1から増やしていくと、エンコード速度がかなり上がる。--threads 12～15あたりが最速。やはりスレッド数を増やしすぎると、少し遅くなるようだ。

--threads 1の時に対する倍率に直すとこんな感じ。


--threads 1 のときと比べると、最大で4.16倍速くなった。

i7 3770Kは物理4コアなので、ハイパースレッディングも十分活用できていて、かなり効率がよい並列化なのでは?

---

というわけで、(今回のテストでは)スレッド数はデフォルトの自動設定でいい、つまり論理コア数×1.5がちょうど、ということが確認できた。

x264の並列化は素晴らしいです。

続きます。(こちら>>)

---

一度エンコードした氷菓OP(1920x1080, 23.976fps, 2157frames)を再エンコードする時間を測った。

Xeon W3680 (6C/12T) 3875MHz (オーバークロック)
Geforce GTX 460 @ 540MHz (ダウンクロック, 296.10ドライバ)
Win7 x64
Aviutl 0.99l + x264guiEx 1.42
x264オプション --preset slow --crf 23

GPU使用率は20～60%ほどだった。

openclなし 18.08fps 58,955KB
openclあり 20.23fps 58,985KB

10%ほど高速化している。

---

一方、IvyBridgeではopenclを使用できなかった。

Core i7 3770K (4C/8T) 4400MHz (オーバークロック)
HDG4000 2696ドライバ
Win7 x64
Aviutl 0.99l + x264guiEx 1.42


x264_kernel_build_log.txtには、

igdfcl64.dll successfully completed build.
igdfcl64.dll successfully completed build.
Error, line 52038: compile failed.

とあるが…。むう。

最初は全く反応しなくて(openclを使う気配すらなかった)、ドライバを入れなおしたことで、openclを使おうとはしてくれるようになった。なったのだが…。

これはあれか。またIntelのせいか。

---

画質は比べてみると少しづつ違う。

が、氷菓OPを選んだのは失敗だった。

もともと地デジ由来のノイズが多くてどっちがいいのかよくわからんかった。

環境
Win7 x64
Aviutl 0.99k
x264guiEx 1.26
Core i5 2500 (4C/4T, L3=6MB, ～AVX) 3800MHz
RAM 4GB, DDR3-1333, Dual Channnel

素材
H.264 High Profile
1920x1080p 23.976fps
2154frames (1m 30s)
ましろ色シンフォニー OPを1920x1080に拡大してエンコードしたもの
lsmashinputで読み込み

x264
x264.nlの64bit版
r2120/r2146の8bit

x264 オプション
ちょい重め。
--crf 20 --ipratio 1.5 --qpstep 12 --qcomp 0.75 --no-mbtree --rc-lookahead 60 --vbv-bufsize -1 --vbv-maxrate -1 --aq-strength 0.4 --psy-rd 1:0.2 --keyint 240 --min-keyint 4 --b-adapt 2 --me umh --subme 10 --merange 32 --direct auto --ref 4 --no-fast-pskip --no-dct-decimate --trellis 2 --colormatrix auto --colorprim auto --transfer auto

Aviutlのフィルタはなし
4回同じエンコードを行い、その最速値を結果として採用

比較
--no-asm アセンブラコードを使用しない
--asm MMX2/SSE2Fast/SSE3/SSSE3/SSE4.1/SSE4.2/AVX

x264のログ表示
--no-asm
using cpu capabilities: none!

--asm MMX2
using cpu capabilities: MMX2

--asm SSE2Fast
using cpu capabilities: MMX2 SSE2Fast

--asm SSE3
using cpu capabilities: MMX2 SSE2

--asm SSSE3
using cpu capabilities: MMX2 SSE2Fast SSSE3

--asm SSE4.1
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1

--asm SSE4.2
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2

--asm AVX
using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX

SSE3命令は使われていないのかな。まあ整数演算に効きそうな命令ないよね。

結果


こうしてみるとやっぱr2120→r2146でだいぶ速くなったねえ…

さて、予想通りSSE2はないと厳しいわけだけど、その後SSSE3、SSE4.1、意外とAVXとかも少しづつ速度を押し上げてる。

PhenomIIx6とかであんま速度が出ないらしいけど、やっぱSSSE3あたりがないのも関係してるんだろうなあ…

環境とかは前回と同じにそろえた。

共通環境
Win7 x64
Aviutl 0.99j2
x264guiEx 1.21
(今最新のものではないけど、環境を合わせるため)

環境1 (Xeon)
Xeon W3680 (6C/12T, L3=12MB, ～SSE4.2) 3875MHz
RAM 18GB, DDR3-1333, Tripple Channel

環境2 (Sandy)
Core i5 2500 (4C/4T, L3=6MB, ～AVX) 3800MHz
RAM 4GB, DDR3-1333, Dual Channnel

素材
H.264 High Profile
1920x1080p 23.976fps
2154frames (1m 30s)
ましろ色シンフォニー OPを1920x1080に拡大してエンコードしたもの
lsmashinput(POPさんビルド,r29)で読み込み(今最新のものではないけど、環境を合わせるため)

x264
x264.nlの64bit版
r1804/r1900/r1995/r2019/r2057/r2085/r2106/r2120/r2145の各8bit/10bit版
※r1804/r1900/r2019は8bit only

x264 オプション
ちょい重め。
--crf 20 --ipratio 1.5 --qpstep 12 --qcomp 0.75 --no-mbtree --rc-lookahead 60 --vbv-bufsize -1 --vbv-maxrate -1 --aq-strength 0.4 --psy-rd 1:0.2 --keyint 240 --min-keyint 4 --b-adapt 2 --me umh --subme 10 --merange 32 --direct auto --ref 4 --no-fast-pskip --no-dct-decimate --trellis 2 --colormatrix auto --colorprim auto --transfer auto
※10bit時は--input-depth 10を追加

Aviutlのフィルタはなし
5回同じエンコードを行い、その最速値を結果として採用


結果


対r2120比


さらに速くなってる…。
特にSandy環境でやたら伸びてる。

今回はCABACとかtrellisとかの辺りの高速化らしいので、そのへんの比重がより重い設定ならもっと高速化すると思う。(この測定は動き探索系が重いアホな設定にしているので、その辺の比重が高くなってしまっている。)