rigayaの日記兼メモ帳

---

【 更新内容 】

---

[ 5.00beta1/2の問題点修正 ]

・5.00 beta1から動かなかったLinuxビルドを修正。

・OpenCLフィルタを使用時、またはAV1デコード時は、d3d11モードを優先するように。
d3d9では動作しない場合があるので、自動的にd3d11に切り替えるように。

・5.00betaで-c rawを指定してもraw出力されないのを修正。

---

[ OpenCLフィルタの追加 ]

・下記OpenCLによるvppフィルタを追加。
- --vpp-afs
- --vpp-colorspace
- --vpp-deband
- --vpp-decimate
- --vpp-edgelevel
- --vpp-mpdecimate
- --vpp-nnedi
- --vpp-pad
- --vpp-pmd
- --vpp-smooth
- --vpp-tweak
- --vpp-unsharp
- --vpp-warpsharp

これまでVCEEncで実装してきたフィルタの移植に加え、いくつかNVEncからフィルタを実装。OpenCLフィルタをQSVでも使用できるようにするのは先にも書いたように5.xxでの目標の一つで、これがやっと実現できた。

問題はまあ予想通りではあるけど、OpenCLフィルタを使うと速度が結構下がってしまうこと。最適化するとどうにかなるものなのだろうか? あるいは将来のiGPUでEU数が増えていけば少しは改善されるだろうか?

---

[ TVRemotePlus関連の機能拡張 ]

・avsw/avhwでのファイル読み込み時にファイル解析サイズの上限を設定するオプションを追加。(--input-probesize)
・--input-analyzeを小数点で指定可能なよう拡張。
・読み込んだパケットの情報を出力するオプションを追加。( --log-packets )
・data streamに限り、タイムスタンプの得られていないパケットをそのまま転送するようにする。
・オプションを記載したファイルを読み込む機能を追加。( --option-file )
・動画情報を取得できない場合のエラーメッセージを追加。
・コピーするtrackをコーデック名で選択可能に。

NVEncでも実施したTVRemotePlus関連でいただいた要望の反映。チャンネル切り替えの高速化、arib-subtitle-timedmetadaterによる字幕処理への対応など。

---

[ その他いろいろな問題点の修正 ]

・字幕の変換が必要な場合の処理が有効化されていなかったのを修正。
・--vpp-subburnでサイズが0の字幕がくると異常終了が発生したのを修正。
・--videoformatに関しては入力から容易に取得できないので、"auto"を削除。
・--audio-source/--sub-sourceを複数指定した場合の挙動を改善。
・字幕のmetadataが二重に出力されてしまっていた問題を修正。
・--sub-metadata, --audio-metadataを指定した場合にも入力ファイルからのmetadataをコピーするように。

このあたりはNVEncでも実施した修正項目。

---

[ その他機能拡張 ]

・yuv444→nv12/p010/ayuv/y410変換のAVX2/SSE2版を追加。

---

[ 注意点・既知の問題 ]

・YUV422/YUV444では、現状まだ動作しないvppフィルタが多いです。
ちょっとまだYUV422/YUV444あたりは、フィルタを使うとエラー終了してしまったりしている。どこまでがMediaSDKの仕様で、どこからが実装の不具合ののか、今後チェックしてみないといけなさそう。

---

QSVEnc ダウンロード>>
ダウンロード (ミラー) >>
OneDriveの調子がいまいちの時はミラー(GDrive)からどうぞ。同じものです。

QSVEncBenchmark.zipはベンチマーク用です。(重いので注意)。run_benchmark.batをダブルクリックで実行です。

QSVEncCのオプションについてはこちら。
QSVEncCオプション一覧>

ソースはこちら

---

---

Rocketlake(i7 11700K)では妙にアイドル時の電力が高い、というのは以前書いた通り。

消費電力を測る機材はないので、実際のところはよくわからんが、HWiNFO読みだと、Package Powerが15Wを切らない、という問題があった。(以下出てくる電力値はすべてHWiNFO読み)



そこでまず、メモリコントローラの速度をGear1→Gear2に変更し、VCCSAをAuto(1.05V)から0.9Vに下げた。

効果は絶大で、System Agentの電力が8W→3W以下まで下がった。



それでも"Rest-Of-Chip"が下がらないなあ、と思ってBIOSの細かい設定を眺めていると、"Platform Power Management"という設定の中にASPM(Active State Power Management)の設定があり、これはBIOSのデフォルトのままにしていたのだが、これがすべてDisabledになっていた。これを有効にすると、"Rest-Of-Chip"も下がって以下の通り。



CPU Package Powerがアイドル時もともと15Wぐらいあったのを5Wまで抑え込めた。

---

ただ、メモリコントローラをGear2にしたことによって性能は下がるはずで、それがどのくらいなのかな、というのが気になるところ。

なので、まずはいつものメモリアクセス速度を測定するプログラムでこのあたりを測定した。

---

まずはマルチスレッド使用時のメモリ帯域から。ここではGear1とGear2の差は見えてこない。

---

次にシングルスレッド使用時のメモリ帯域。データサイズの大きいところがメモリアクセスだけど、このあたりでGear2は遅くなっているのがわかる。

---

スレッド数を変えた時のメモリ帯域。Gear1とGear2の差は、シングルスレッド時のが大きく、スレッド数を増やしていくとあまり変わらなくなるようだ。

---

キャッシュラインに対してランダムになるべく4Kページをまたがないようにアクセスしたときのレイテンシ。

データサイズの大きいところがメモリアクセスだけど、Gear2はわずかにそのあたりのレイテンシが増加している。

---

完全にランダムにアクセスしたときのレイテンシ。やはりGear2はわずかにデータサイズの大きいメモリアクセスとなるところのレイテンシ増加が見られる。

---

というわけで、Gear2にすると(当然だが)メモリアクセスがある程度遅くなるが、その差は決して大きいものではない、ということがわかった。

じゃあ、実際これが実アプリの動作にどのくらい効くの? ということで、この状態で再度ベンチマークをやってみよう。

今回は、Power Limitに関しては以前計測したPL1=125W, PL2=251Wの設定のまま。

CPU	i7 11700K 0x34
	PL1:125 / PL2:251 Gear1	PL1:125 / PL2: 251 Gear2 + ASPM ON
コア数	8C/16T
L2 Cache	4MB
L3 Cache	16MB
AVX512	Offset=0
Core Voltage	Auto
PPT/PL1	125W
PL2	251W (56sec)
IccMax	Auto
ASPM	Disabled (Default)	Enabled
Uncore	4100MHz
メモリ	DDR4-3600 2ch
メモリ容量	16GB
タイミング	18-22-22-45-2
メモリ FCLK	Gear1	Gear2
VCCSA	Auto (1.05V)	0.90V
マザー	Gigabyte Z590I AORUS ULTRA (F5a)
冷却	Thermaltake Water 3.0 Riing Edition 280
電源	Seasonic SS-620GB
ケース	Phanteks Evolv Shift X

使用ソフト
Cinebench R15, R20, R23
7zip 19.00
Aviutl 1.00 / x264guiEx 2.65 / x265guiEx 3.101 / svtav1guiEx 0.04
x264 rev3027 x64
x265 3.4+28 x64

---

Cinebench R15

---

これはマルチスレッドのほうで少しスコアが下がってしまった。(ぶれの範囲内かもしれないが)

---

Cinebench R20

---

こちらはほぼ変わらない結果に。

---

Cinebench R23

---

こちらもほぼ変わらない結果に。

---

7zip benchmark

---

ほんのごくわずかだが、Gear2にしたことでスコアが落ちている気がする。

---

x264 1080p エンコード

---

Aviutlでmpeg2 1080p 5203frame(sample_movie_1080p.mpg)をlwinput.auiで読み込み、x264guiExで出力。
オプション: --preset

これはCPU使用率の高くなってくるfastより重いプリセットでは、Gear2+ASPM ONのほうが、わずかに速度が上がっている。

---

x265 1080p エンコード

---

Aviutlでmpeg2 1080p 5203frame(sample_movie_1080p.mpg)をlwinput.auiで読み込み、x265guiExで出力。
オプション: --crf 21 --output-depth 8/10 --preset --asm avx512

これもx264同様に、Gear2+ASPM ONのほうが、わずかに速度が上がっている。

---

10bitも8bitと同様。ほんのわずかだけど、Gear2+ASPM ONのほうが速度が上がっている気がする。

---

ということで、ここまでの結果では、Gear2+ASPM ONにすると遅くなるものもある一方で、速くなるものもあるということになった。

Gear2にしてメモリアクセスは遅くなっているのになんで速くなるのか、というと、

・今回Gear2にしてVCCSAを下げ、ASPMを有効にしたことによって、System AgentとRest-Of-Chipの消費電力が10W下がった
　↓
・PL1=125Wの枠内で動作するとき、CPUコアが使える電力枠がその分10W増えた
　↓
・その分CPUのクロックが少し上がりやすくなった
　↓
・CPUクロック上昇効果が、Gear2にしたことによるメモリアクセス性能低下の影響を上回った

という感じだと思う。

---

もちろん、あまり気にする必要もないぐらいわずかの差だとは思う。

さらに、Power Limitをかけていない、あるいはその制限の影響を受けないぐらい時間が短い、あるいはCPU使用率が低い場合には、Gear1のほうがもちろん速いと思う。ゲームとかはこうした部類に入ってくるのかもしれない。

ただ、K付きでないCPUなどで、Power Limitを外せない場合などでは、なるべくアイドル電力を下げるというのも有効なのかな、と思った。

---

BIOSの設定をちゃんとよく見ろ、と言われればまあそれまでだけど、Package Power ManagementはBIOSのデフォルトでオフになっていたわけで、これはデフォルトでオンにしておいてほしいなあ、と思ったり。

なにはともあれ、若干気になっていたので、RocketlakeでもBIOS設定をいじればアイドル電力を従来と同程度まで下げられることがわかってよかった。

---

比較環境

比較したのは以下の環境。基本的にRocketlake以外のデータは去年のデータ(1)(2)と同じなので、いまとなっては古い環境もある。

	x264 x265	nvenc (1060)	nvenc (2070)	QSV (HSW)	QSV (KBL)	QSV (ICL)	QSV (RKL)	vce (Vega)
CPU	i9 7980XE			i3 4170	i7 7700K	i5 1035G7	i7 11700K	R3 3200G
GPU	-	GTX 1060	RTX 2070	HDG 4400	HDG 630	Iris Plus	HDG 750	Vega8
ドライバ	442.19			5058	7870	7641	9127	20.2.1
OS	Win10 x64

使用ソフト
x264 r2988 x64
x265 3.3+2 x64
NVEncC 4.68 x64
QSVEncC 3.33 x64
QSVEncC 5.00β2 x64 (RKLのみ)
VCEEncC 5.04 x64

入力 (実写)
sample_movie_1080p.mpg
MPEG2 1920x1080 29.97fps 5203frame

入力 (アニメ)
sakura_op.mpg
MPEG1 1280x720 30fps 3501frame

使用コマンド
QSVEnc/NVEncについては、おそらく画質が一番高くなるであろうオプションを試した。x264/x265はきりがないのでpresetをそのまま使用している。

なお、x264/x265では、今回入れてない--tune ssimを入れてssimに最適化したエンコをすることでさらにssim的には改善の余地があることに注意。

x264 medium
--crf

x264 veryslow
--crf --preset veryslow

x265 medium
--crf

x265 veryslow
--crf --preset veryslow

x265 medium 10bit
--crf --input-depth 10 --output-depth 10

x265 veryslow 10bit
--crf --input-depth 10 --output-depth 10 --preset veryslow

nvenc H.264
--vbrhq 0 --vbr-quality --preset quality --weightp --bref-mode each --lookahead 32 --level 5.2

nvenc HEVC
--vbrhq 0 --vbr-quality --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6

nvenc HEVC 10bit
--vbrhq 0 --vbr-quality --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6 --output-depth 10

nvenc HEVC + Bframes
--vbrhq 0 --vbr-quality --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6 -b 3

nvenc HEVC 10bit + Bframes
--vbrhq 0 --vbr-quality --preset quality --weightp --bref-mode each --lookahead 32 -c hevc --level 6 --output-depth 10 -b 3

qsv H.264
--la-icq --la-depth 60 -u 1

qsv HEVC
--icq -u 1 -c hevc

qsv HEVC 10bit
--icq -u 1 -c hevc --profile main10 --output-depth 10

vce H.264
--cqp :+2:+5 -u slow
--vbr -u slow

vce HEVC
--cqp :+2:> -u slow -c hevc
--vbr -u slow -c hevc

---

エンコード速度

---

まずは1080pのエンコード速度から。対象は実写のMPEG2 1920x1080 29.97fps 5203frame。



Rocketlake(RKL)のQSVは、Kabylakeと比べるとH.264は遅くなっている一方、HEVCは速くなっている。

一方、Icelakeとの比較では、HEVCのslowはIcelakeより速いけど、mediumのほうは遅い。Rocketlakeは32EUで、Icelakeは64EUなので、もしかして結構遅くなったりするのかと思っていたけど、そんなことはなく、まあだいたい同じくらいみたいで安心した。

まあとりたてて速いわけでもないけど、そこそこの速度でエンコードできるようだ。

---

画質比較 (実写 1080p : SSIM)

---

縦軸SSIM:Allが高いほど画質がよく、横軸ビットレートが小さいほど圧縮できているので、左上にいればいるほど良いことになる。まあ、SSIMで画質を比べることについてもいろいろあるけど、たくさんのデータをグラフにするにはそのぐらいしかないので。

VMAFはもっと速く計算できるようになるまではやらないです。

まずはQSV同士の比較から。

クリックで拡大


QSVはIcelake世代で大幅に圧縮比が向上し、高画質・高圧縮になったが、RocketlakeはIcelakeの線とほぼ重なっていて、同じぐらいのエンジンが実装されていることがわかる。CometlakeまでのデスクトップCPUには、ずっとKabylake世代のQSVが積まれていたので、デスクトップCPUとしては待ちに待った更新になっている。

一方で、Icelakeとほぼ同じということで、Icelake→Rocketlakeでは画質面での向上はないようだ(Rocketlake固有のオプション等を使えば別なのかもだが)

他のGPUやx264/x265と比較するとこんな感じ。

クリックで拡大


NVEncのほうはQSVより大幅に速いが、一方でQSVのほうが画質面ではよさそう。

RocketlakeのQSVのHEVCはSSIMベースでは、x265のmedium程度の画質はあるみたいで、GPUのEUを演算に活用するHybrid型とはいえ、ソフトウェアエンコに迫っているということでなかなかすごいことだと思う。

---

画質比較 (アニメ 720p : SSIM)

---

圧縮しやすいアニメ映像だとまた傾向が変わることもあるので確認してみた。

まずはQSV同士の比較から。

クリックで拡大


これは傾向は変わらず、RocketlakeはKabylakeから大幅に性能が向上し、こちらではIcelakeとの比較でもごくわずかに良くなっているように見える。

クリックで拡大


アニメ絵に関してはやはりソフトウェアエンコのほうが高画質・高圧縮を達成できるようで、x265とはそれなりの差がある。NVEncとの差も少し縮んでいる。

---

画質・圧縮率の高いHWエンコをデスクトップにもたらしたRocketlake

---

Icelakeの登場からだいぶたってしまったが、Rocketlakeの登場によりKabylake世代のQSVで停滞していたデスクトップCPUにやっと新世代のQSVがもたらされた。

NVEncのように非常に高速というわけではないが、IcelakeのQSV同様にそこそこの速度でHWエンコとしては画質・圧縮率の高いHWエンコとなっていると思う。ソフトウェアエンコには及ばずとも比較できる範囲内に入ってきているのはなかなかすごいことだと思う。

ただ、やはりベンチマークでも書いたようにZen3に対してRocketlakeはCPU性能が劣勢で、値段も特に安くなく、消費電力はかなり高いので、わざわざRocketlakeを選ぶのか、というのが難点。

また、逆にQSV目当てでローエンドあたりを狙うとしても、今回のRocketlakeのラインアップにはCore i3以下がなく、そして微妙にアイドル電力も高い(らしい)というのもローエンドとしては気になるところになってしまっている。

---

QSVEncの開発がはかどる

---

Rocketlake/TigerlakeのQSVには、今回チェックした既存のエンコード機能のほかに、HEVC YUV422/YUV444エンコードやAV1 HWデコードなども追加されている。

QSVEncでは5.00beta1からこのあたりの機能への対応も進めていて、今回実機が手に入ったのでこのあたりがちゃんと使えるように実装していきたい。

やはり実機があって動くと実装作業も楽しくなってくる。

IntelがRocketlakeで無理して14nmへの逆移植に挑戦してくれたおかげで、Alderlakeまで待たずとも最新世代のQSV環境と高IPCでレスポンスのよい開発環境が手に入ったので、とても個人的な理由だけど、わりとありがたかった。