環境
| CPU | i9 12900K |
|---|
| コア数 | 8P+8E / 24T |
| L2 Cache | 14MB |
| L3 Cache | 30MB |
| 電圧 | Offset -0.13V～0.00V |
| PL1/PL2 | 241W |
| tau | 56s |
| IccMax | Unlimited |
| メモリ | DDR4-3600 2ch |
| メモリ容量 | 8GBx4 |
| タイミング | 16-19-19-39-1 |
| メモリコントローラ | Gear1 |
| iGPU | Intel UHD Graphics 770 (32EU)
(ドライバ: 30.0.101.1191) |
| dGPU | Intel Arc A380 (128EU)
(ドライバ: 30.0.101.3259 Beta) |
| マザー | MSI MAG Z690 TOMAHAWK WIFI DDR4 |
| 冷却 | Corsair iCUE H150i RGB PRO (360mm) |
| 電源 | Seasonic FOCUS PX-750 |
| ケース | Themaltake Core V71 |
| OS | Windows 11 22000 |
なお、Arc A380はCPU直結のPCIe4x8レーンを用いた。
エンコーダ
QSVEncC 6.08
QSVEncC 7.08+ (DG2用)
入力動画
MPEG2 1920x1080 29.97fps 5203frame
AvisynthのLWLibavVideoSourceで読み込み (SWデコード)
H.264でのHyper Encode
Hyper Encode onの場合、iGPU(内臓GPU)とdGPU(外付GPU)で同じオプションが必要になる。
今回の環境では、Arc A380がFFモードのみ対応、12900KがH.264のFFモードではBフレームに対応していない関係で、Hyper Encodeを使用しようとすると自動的にFFモードでBフレームが0になってしまう。
ということで今回は下のようなモードで速度をチェックしてみた。
・12900KのPGモード
・12900KのFFモード
・Arc A380のFFモード
・Arc A380のFFモード (Bフレーム0)
・Hyper Encode on (FF, Bフレーム0)
また、Hyper Encodeは、
GOP長を短くし、内部バッファサイズである--async-depthを大きくするとより効果が出るとされているため、さらに"--gop-len 15 --async-depth 60"とした場合についてもチェックした。
仕様コマンドでまとめるとこんな感じ。
H.264 使用コマンド
qsv H.264 (-u 1:quality, 4:normal)
--icq <x> -u <1,4>
qsv H.264 FF (-u 1:quality, 4:normal)
--icq <x> -u <1,4>
--fixed-func
qsv H.264 FF Bframe 0 (-u 1:quality, 4:normal)
--icq <x> -u <1,4> --fixed-func
-b 0
qsv H.264 FF Hyper Encode on (-u 1:quality, 4:normal)
--icq <x> -u <1,4> --fixed-func
--hyper-encode on
qsv H.264 FF Hyper Encode on GOPLen 15 (-u 1:quality, 4:normal)
--icq <x> -u <1,4> --fixed-func --hyper-encode on
--gop-len 15 --async-depth 60
H.264 bitrate-fps
まずは縦軸をエンコード速度(fps)にとってエンコード速度を比較。
※凡例の □ をクリックすると、グラフ線のオン/オフができます。
※マウスをグラフの 〇 のところにあてると、値が確認できます。
グラフが表示されない場合は→
こちら
Arc A380単体のH.264エンコードの速度はqualityで250fps前後、Bフレーム0では少し高速になり270fps前後。
ここからHyper Encodeを有効にすると逆に速度が下がって185fps前後となってしまう。
これはやはりGOP長(デフォルト=300)などが原因のようで、GOP長を15とし、--async-depth 60を追加したもの(GOPLen 15)では、330fps近く出ており、高速化できていることがわかる。
Hyper Encodeを活用しようとすると、GOP長と--async-depthに気を使わないといけないようだ。
なお、表にしは載せていないが、今回--async-depthを60以上にしてもほとんど効果はなかった。また、--gop-len 30では270～280fps前後となってしまい、Hyper Encodeの効果があまり見られなかった。
H.264 bitrate-ssim
このときの画質についてもチェックしてみた。
縦軸SSIMが高いほど画質がよく、横軸ビットレートが小さいほど圧縮できているので、左上にいればいるほど良いことになる。
※凡例の □ をクリックすると、グラフ線のオン/オフができます。
※マウスをグラフの 〇 のところにあてると、値が確認できます。
グラフが表示されない場合は→
こちら
Hyper Encodeを使用する前のArc A380単体のFFモードに対し、Hyper Encode使用時はBフレームを0とする必要があるため、画質－容量比が一段低下してしまっているのがわかる。「Hyper Encode on」と「(Hyper Encodeを使用せず)Bframe 0」としたものがほぼ重なっていることから、Hyper Encodeそのものの圧縮効率への影響は小さいようだ。
一方、Hyper Encodeで速度を出すためにGOP長を15としたものは一段と画質－容量比が悪化している。GOP長を制限することによる影響は大きいようだ。
HEVCでのHyper Encode
HEVCでも同様にチェックしてみた。ただし、現時点のドライバ(3259 Beta)は、HEVCエンコードが不安定で、異常終了してしまうことがあり、サンプル点が足りていないため、グラフとして歪であったり、本来の実力かはわからない点に注意してほしい。
特に"-u 1" : quality は完走できないことが多すぎ、2-3点しかデータが得られずグラフを描くどころではないため、省略した。
なお、HEVCでは、H.264と異なりHyepr Encode使用時のBフレームに関する制約は存在しない。
HEVC使用コマンド
qsv HEVC
--icq <x> -u 4 -c hevc
qsv HEVC FF
--icq <x> -u 4 -c hevc
--fixed-func
qsv HEVC FF Hyper Encode on
--icq <x> -u 4 -c hevc --fixed-func
--hyper-encode on
qsv HEVC FF Hyper Encode on GOPLen 15
--icq <x> -u 4 -c hevc --fixed-func --hyper-encode on
--gop-len 15 --async-depth 60
※ 10bitの場合には、さらに "--profile main10 --output-depth 10"を追加する
HEVC bitrate-fps
まずは縦軸をエンコード速度(fps)にとってエンコード速度を比較。
※凡例の □ をクリックすると、グラフ線のオン/オフができます。
※マウスをグラフの 〇 のところにあてると、値が確認できます。
グラフが表示されない場合は→
こちら
こちらはH.264のときとは少し違う傾向で、単純にHyper Encodeを使用してもGOP長が長いまま(デフォルト=300)ではあまり効果が出ず、速度がほとんど変わらないことがわかった。
GOP長を制限した場合、HEVC 8bitでは大きな効果があり、約270fpsから約320fpsまで高速化しているが、HEVC 10bitでは約210fpsから140-190fps程度まで速度が低下してしまっている。とはいえ、現時点でHEVCエンコードは不安定で、特に10bitは安定していないため、真の実力ではないかもしれない。
HEVC bitrate-ssim
このときの画質についてもチェックしてみた。
縦軸SSIMが高いほど画質がよく、横軸ビットレートが小さいほど圧縮できているので、左上にいればいるほど良いことになる。
※凡例の □ をクリックすると、グラフ線のオン/オフができます。
※マウスをグラフの 〇 のところにあてると、値が確認できます。
グラフが表示されない場合は→
こちら
注意点として、今回完走できたケースが少なく、サンプル点が少ないため、綺麗なカーブを描けていない。そのため、直線で引かれてしまっているところと、カーブをきれいに描けているところを比較するのは適切ではないので注意。
最も画質の良いのは12900KのPGで、Arc A380のFFはそれよりわずかに画質－容量比が低いだろうか。Hyper Encodeの有無による差はあまりなさそう(カーブが歪なのではっきりとはわからないが…
H.264のときもそうだったように、HEVCでもGOP長制限の影響は大きく、画質－容量比が悪化してしまっていることが確認できる。
というわけで、ひととおりIntel Arc A380を使った時のDeep Link (Hyper Encode)の速度と画質をチェックした。
Hyper Encodeを使用するには、Arc A380がプライマリGPUである必要があったり、Arc A380と内臓GPUが共通で使用できるエンコードパラメータである必要があるなど、制約が多く、癖が強い。
また、速度を引き出すにはGOP長を制限したりする必要もあり、こうした制約からどうしても画質が犠牲になる傾向がありそう。
今後内臓GPU側のQSVエンコーダもアップデートされ、Arc A380と同様のエンコーダとなれば、「内臓GPUと共通で使用できるパラメータ」は実質的に制約ではなくなるかもしれないし、面白い仕組みだと思うので、今後の進化にも期待したい。
まあただ、Hyper Encodeうんぬん以前に、HEVCについてはまずは安定して動くようになってほしいところ。(Arc A380のH.264は問題ないし、12900K内臓GPUのHEVCでも問題なく動作するので、アプリ側の問題ではないと思うのだが…)
Betaでもいいので、ドライバの更新をお願いします…。
