rigayaの日記兼メモ帳

---

[NVEnc.auo / NVEncC 共通]

---

・GPUのドライババージョンをチェックするように。

・CUDAの存在しない環境で、クラッシュしてしまうのを修正。

・ヘルプのささいな修正。

---

[NVEncC]

---

・高ビット深度のyuv422/yuv444をy4mから読み込むと色成分がおかしくなるのを修正。

・高ビット深度でdelogoが正常に動作しなかったのを修正。

・3.08からy4mからパイプで読み込めなくなっていたのを修正。

---

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

ソースはこちら>>

---

---

準備

---

Visual Studio Community 2017
CMake (Win32 Installer をダウンロード)
Mercurial (MSI installer かInno Setup installerのどちらかを)
nasm
適当なy4mファイル (ffmpegとかで自分で作るか、このあたりから適当に bus_cif.y4mとかで)

ffmpegでy4mを作る場合、
ffmpeg.exe -y -i <ソース動画> -an -pix_fmt yuv420p -f yuv4mpegpipe -frame 120 <出力.y4m>
とかで作れば良いと思う。

とりあえず、上記をすべてインストールする。cmake/hg/nasmにはパスを通しておき、コマンドプロンプトで

cmake
hg
nasm

が反応あるかどうかを確認する。

---

ビルド実行

---

md <x265をビルドするフォルダ>
cd /d <x265をビルドするフォルダ>
 
set TEST_MOVIE=<y4mファイルへのパス>
 
rem x265のソースをダウンロード
hg clone https://bitbucket.org/multicoreware/x265
 
rem PGOを有効
set LTCG_OPTION=PGInstrument
rem 無効にする場合はこちら
rem set LTCG_OPTION=true
  
rem ここではx64ビルド
md x265\build\vc15-x86_64
cd x265\build\vc15-x86_64
set CMAKE_VS_TYPE=Visual Studio 15 2017 Win64
set ARCH_VC=x64
  
rem x86ビルド用
rem md x265\build\vc15-x86
rem cd x265\build\vc15-x86
rem set CMAKE_VS_TYPE=Visual Studio 15 2017
rem set ARCH_VC=Win32
  
rem コンパイルオプション
rem PGOビルドには、/GLが必要
rem その他のオプションは適当 (必要ないかもしれない)
set VC_OPTIONS=/GL /MP /MT /Ox /Ob2 /Oi /Ot /Oy /GT /GF /Gy /fp:fast /D NDEBUG
  
rem PGOは/LTCG (リンク時コード生成) の一種なので
rem /INCREMENTAL:NOとしないとリンク中に警告が表示される
rem /LARGEADDRESSAWAREはx86ビルド用 (x64では単に無視される)
set VC_LINKER_EXE_OPTIONS=/INCREMENTAL:NO /LARGEADDRESSAWARE /OPT:REF /OPT:ICF
set VC_LINKER_MODULE_OPTIONS=/INCREMENTAL:NO
set VC_LINKER_SHARED_OPTIONS=/INCREMENTAL:NO
      
rem VC2017の環境設定を呼ぶ
call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat"
call "%VS150COMNTOOLS%\..\..\VC\Auxiliary\Build\vcvarsall.bat" %ARCH_VC%
 
mkdir 10bit
mkdir 8bit
 
rem 10bit用のライブラリをビルド
cd "10bit"
cmake -D STATIC_LINK_CRT:BOOL=ON ^
 -D ENABLE_SHARED:BOOL=OFF ^
 -D CMAKE_CXX_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
 -D CMAKE_C_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
 -D CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_EXE_OPTIONS%" ^
 -D CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_MODULE_OPTIONS%" ^
 -D HIGH_BIT_DEPTH:BOOL=ON ^
 -D EXPORT_C_API:BOOL=OFF ^
 -D ENABLE_CLI:BOOL=OFF ^
 -G "%CMAKE_VS_TYPE%" ..\..\..\source
 
pause
 
MSBuild /property:Configuration="Release";WholeProgramOptimization=%LTCG_OPTION% x265.sln
copy /y Release\x265-static.lib ..\8bit\x265-static-main10.lib
 
rem 8bit用のライブラリをビルド
cd "..\8bit"
cmake -D STATIC_LINK_CRT:BOOL=ON ^
    -D ENABLE_SHARED:BOOL=OFF ^
    -D CMAKE_CXX_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
    -D CMAKE_C_FLAGS_RELEASE:STRING="%VC_OPTIONS%" ^
    -D CMAKE_EXE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_EXE_OPTIONS%" ^
    -D CMAKE_MODULE_LINKER_FLAGS_RELEASE:STRING="%VC_LINKER_MODULE_OPTIONS%" ^
    -D EXTRA_LIB:STRING="x265-static-main10.lib" ^
    -D LINKED_10BIT:BOOL=ON ^
    -G "%CMAKE_VS_TYPE%" ..\..\..\source
  
rem 情報収集用の実行ファイルを作成 (PGInstrument)
MSBuild /p:Configuration=Release;WholeProgramOptimization=%LTCG_OPTION% x265.sln
 
rem PGOビルドをしない場合はこれで終了
if "%LTCG_OPTION%" == "true" goto FINISH
  
rem 情報収集用にx265を実行(8bit)
release\x265.exe --crf 23 --preset medium -o nul "%TEST_MOVIE%"
release\x265.exe --crf 23 --preset slow --amp --weightb -o nul "%TEST_MOVIE%"
 
rem 情報収集用にx265を実行(10bit)
release\x265.exe --crf 23 --input-depth 8 --output-depth 10 --preset medium -o nul "%TEST_MOVIE%"
release\x265.exe --crf 23 --input-depth 8 --output-depth 10 --preset slow --amp --weightb -o nul "%TEST_MOVIE%"
  
rem 作成されたプロファイルをもとに
rem 最適化された実行ファイルを作成 (PGOptimize)
MSBuild /p:Configuration=Release;WholeProgramOptimization=PGOptimize x265.sln
 
:FINISH
rem これで終了
rem 8bit\release\x265.exeが最適化された実行ファイル

これで終わり。

---

[NVEnc.auo / NVEncC 共通]

---

・CPU使用率を低減。特に、HWデコーダ使用時のCPU使用率を大きく削減。
下に書いたCUDAのスケジューリングモードの設定を、従来の"auto"から"sync"にしたことによるもの。--cuda-schedule autoにすると従来までの動作になる。

・CUDAのスケジューリングモードを指定するオプションを追加。(--cuda-schedule <string>)
主に、GPUのタスク終了を待機する際のCPUの挙動を決める。デフォルトはsync。

- auto ... CUDAのドライバにモード決定を委ねる。
- spin ... 常にCPUを稼働させ、GPUタスクの終了を監視する。復帰のレイテンシが最小となり、最も高速だが、1コア分のCPU使用率を常に使用する。
- yield ... 基本的にはspinと同じだが、他のスレッドがあればそちらに譲る。
- sync ... GPUタスクの終了まで、スレッドをスリープさせる。わずかに性能が落ちるかわりに、特にHWデコード使用時に、CPU使用率を大きく削減する。

・CPU/GPU間の同期のとり方を調整。

・実行時のCUDAのバージョンをログに表示するように。

---

[NVEncC]

---

・helpの表示がおかしかった箇所を修正。

・エンコード終了時に進捗表示のゴミが残らないように。

・NVMLを使用してGPU使用率などの情報を取得するように。
x64版のみ。x86版では、バックグラウンドでGPU-Zが起動していれば、同様の情報を取得できる。

ただ、これは、このプロセスのGPU使用率ではなく、システム全体のGPU使用率であることに注意。

---

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

ソースはこちら>>

---

---

まず演算器から。
http://users.atw.hu/instlatx64/GenuineIntel0050654_SkylakeX_InstLatX64.txt

この情報とかから推測すると…

・基本的にはSkylakeと変わらない
・変わったのはAVX512
・port0+1にあった256bit演算器を束ねてAVX-512として使える
・port5にあった演算器は(原則)512bit演算器に拡張された
・ついでに浮動小数のadd/sub/mul/fmaはport5に512bit演算器を追加
・port0だけだった一部のSIMD命令は256bitx2回に分けて実行 (div/sqrt/rcp)
・512bit gatherが(相対的に)速い
・512bitでもクロスレーンはレイテンシ3cycle

例外はあると思うけど、大雑把に推測するとこんな感じ?

		Haswell	Skylake	Skylake-X
FP	add/sub	256bit x1	256bit x2	256bit x2 + 512bit x1
	mul/fma	256bit x2	256bit x2	256bit x2 + 512bit x1
	div/sqrt/rcp	256bit x1	256bit x1	256bit x1
Int	and/or/xor/andn	256bit x3	256bit x3	256bit x2 + 512bit x1
	add/sub	256bit x2	256bit x3	256bit x2 + 512bit x1
	adds/subs	256bit x2	256bit x2	256bit x2
	mul	256bit x1	256bit x2	256bit x2
	min/max/cmp abs/shift	256bit x1	256bit x2	256bit x2
	sad	256bit x1	256bit x1	512bit x1
	shuffle/perm alignr/broadcast	256bit x1	256bit x1	512bit x1
	blend	256bit x1	256bit x1 ?	256bit x2 + 512bit x1 (EVEXのみ)
	rotate	-	-	256bit x2 ?
	ternlog	-	-	256bit x2 + 512bit x1 ?

※↑ただの推測です

もうだいぶ前の、比較的おとなしめで微妙な性能向上にとどまったSkylakeの拡張は、これを見越してのことだったのかなあ、というのがなんとなくわかる気がする。

AVX512の恩恵があるものとないものがはっきり…。FPのadd/mul/sub/fmaは2倍、Intのadd/sub/and/or/xor/andnなどは1.33倍、shuffleは2倍といった速度向上がある一方で、まるで速度が上がらないものも…。vpternlog(論理3入力演算)がうまく使えれば論理演算はもっと性能上がりそう。

とまあ、AVX512まわりは結構頑張ってる感じだけど、そのほかのAVX512未使用の性能は順当にSkylakeを10コアにした感じの模様で、クロックの向上もあってそれなりの性能向上は期待できるみたい。

問題は、性能向上と一緒に発熱量も向上してしまったことで、とにかく多くのベンチマークの記事を見てもたいてい「熱い」って書いてあってなんだかなあ、という印象。どうもAVX512を使わなくても熱いようなので、AVX512のせいだけじゃないみたい。単にクロックを上げすぎたのか、あるいはL2/L3あたりの改造が裏目に出たのか…。

そのうえ、理解に苦しむ事にはんだじゃなくてグリスなので、より高温になってさらに消費電力が増える、という状態になっている気がする。

PCWatch …わりと当たり石 ? 「比較的おとなしい温度」
ascii … 「それほどでもない」 70℃以下におさまる
4.gamer … 「故障が気がかりになるレベル」,「莫大な消費電力はちょっと引くレベル」
tomshardware … 「グリスでさえなければ優秀だった」、「20℃の冷風を送風すれば良い」
guru3d … 「一瞬TDP=140Wという数字が信じられなかった」
techspot … 本格水冷すれば、結構行ける
AnandTech … CPU性能は優秀
PCWorld … 優秀だが、ThreadRipperと比べないと…?

もうレビューごとの違いが面白すぎてそれだけでお腹いっぱいになりそう…。

そもそもコア数が多くて、AVX512を載せて、さらにクロックを引き上げているSkylake-Xが熱くなることは(ここまでとは思わなかったけど)わかりきっているのに、これをグリスにしようとしたのは本当に正気じゃない気がする…。

ついでにマザーまで熱くなるらしい…。寿命が短そうで怖い。

18コア版まで出揃うのを待ってから、冬に暖房機として買うのがよいのかしら…。