NVEnc 7.47

- 横解像度が16で割り切れない場合にy4m読み込みをすると異常終了する可能性があった問題を修正。
ご指摘いただいた問題を修正。

- vpp-afsを高速化。

- 存在しないドライブに出力すると異常終了する問題を修正。







vpp-afsを高速化



まず効果はこんな感じで、vpp-afsで1440x1080の平均処理時間が高速化した。

NVEnc 7.46NVEnc 7.47
RTX4080198.4 us170.1 us
GTX1060793.2 us533.0 us


まあそれなりに速くはなっているけど、もともと十分高速なので、実際のエンコードで今回の高速化の効果を感じることはほぼないと思う。(フィルタよりエンコードのほうが遅いので)



やったことはシンプルで、GPUコードで絶対値を取る時にstd::absを使っていたのをfabsに置き換えただけ。

NVEnc_20240320_vpp_afs_abs_01.png



きっかけ



Nsight Computeでプロファイルを取って、実行した命令をみると、なぜか使った記憶のないFP64というのが紛れ込んでいた。

プロファイルを取ってkernel(CUDAの関数)の様子を見るとこんな感じだった。Compute Throughtputが妙に高く、Memory Throughputが妙に低い。

NVEnc_20240320_vpp_afs_abs_02_1.png

Compute Workload Analysisを見ると、なぜかFP64が上位にいる。使った記憶ないのに…。GeForceでFP64はとても遅いので、もちろん必要もないのに使うべきではない。

NVEnc_20240320_vpp_afs_abs_02_2.jpg

念のため、Memory Workloadも見てみると、Texture, shared memoryをちゃんと使えているが、あまり負荷は高くなさそうだ(Busyの値が低い)。処理の性質的に、もう少し高くてもよさそうだが…?

NVEnc_20240320_vpp_afs_abs_02_3.jpg

使用した命令の内訳。afsはビット演算を多用するのでLOP3は妥当、アドレス計算等で使うIMADも妥当。よくわからないのは上のほうにいるF2Fである。

NVEnc_20240320_vpp_afs_abs_02_4.jpg

SASSでF2Fがどこで使われているかを見ると、analyze_motion/analyze_stripeという関数の部分で使われていた。

NVEnc_20240320_vpp_afs_abs_02_5.jpg

試しにanalyze_motionを見ると、おそらくstd::absだろうなあ、と思いいたった。

NVEnc_20240320_vpp_afs_abs_02_6.png

std::absは引数がfloatの場合はfloatのオーバーロードが使われるはずだが、GPUコードだし、うまく解決されなかったのかなという感じ。まあ、そもそもデバイス用のfabsを使用すべきだ、ということでfabsに変更した。

NVEnc_20240320_vpp_afs_abs_01.png



変更後



変更後はkernelの実行時間が164.5usから51.2usに大幅に高速化した。

また、Compute Throughputが下がり、Memory Throughputが上がった。処理内容的に、このぐらいのほうが妥当なように思う。

NVEnc_20240320_vpp_afs_abs_03_1.png

Compute Workload Analysisを見ると、謎のFP64がなくなり、うまくいったことがわかる。

NVEnc_20240320_vpp_afs_abs_03_2.jpg

Memory Workloadも見てみると、転送量は変わらないが、kernelの処理時間が短くなったことで、Busyの割合が増加した。

NVEnc_20240320_vpp_afs_abs_03_3.jpg

使用した命令の内訳からはF2Fがなくなった。

NVEnc_20240320_vpp_afs_abs_03_4.jpg

実際に、analyze_motionの箇所を見ても、F2Fは発行されていないことがわかる。

NVEnc_20240320_vpp_afs_abs_03_5.jpg



ということで今回は本当に簡単なミスでGPU kernel(関数)の処理速度が全く違ってしまうという例だった(kernel単位でみると3倍高速化している)。GeForceでFP64関連命令は圧倒的に遅く完全に地雷なので可能な限り避けるべきで、今回はそれがちゃんとできていなかった。

ただ、一応ちゃんと動いてしまう分、正直見つけるのは簡単ではないようにも思う。今回みたくプロファイラでチェックしてみるのもたまにはいいかもしれない。



各フィルタの速度



参考までに1920x1080でのNVEncの主要フィルタの1フレーム当たりの平均処理時間(us)を確認してみた。フィルタの速度はパラメータでも大きく変わるけど、ここでは全部デフォルトで比較した。

GPUはRTX4080, GTX1080, GTX1060。

     フィルタ平均処理時間[単位:us]
      1920x1080 YV12 8bit

RTX4080GTX1080GTX1060
colorspace82.9221.3441.9
cspconv19.951.686.6
afs224.2355.8658.6
nnedi794.12312.74499.1
yadif142.3252.2487.1
transform23.542.577.3
convolution3d73.0237.1482.6
smooth229.3821.61682.8
denoise-dct852.73238.86113.4
knn233.9606.91267.9
pmd229.3562.41136.8
resize(720p)142.8611.11297.4
resize(1440p)525.32394.75064.5
edgelevel58.9155.5215.5
warpsharp146.4479.9974.8
curves45.9165.6276.3
tweak8.324.046.6
deband60.0127.1215.3
cspconv22.439.368.0


フィルタごとの速度差とか、GPUごとの速度差がなんとなくわかると思う。



※NVEnc 6.00から導入方法が変更されていますのでご注意ください。
※Aviutl向けには、Aviutl_NVEnc_7.xx.zip をダウンロードしてください。
ダウンロード>>

NVEncの導入
NVEncCオプション一覧>


スポンサーサイト



コメントの投稿

非公開コメント

NVEncCの出力bit深度について

いつも数々のツールをありがとうございます.

最近気づいたのですが,NVEncCでmain10を指定しても出力ファイルのbit深度が8bitになっています.エンコード結果で確認したところ,version 7.31まで(ログが残っていないので日時で推測)は10bitになっています.表示だけの問題のようにも思いますが,いちおうご報告まで.

Re: NVEncCの出力bit深度について

出力ビット深度についてですが、設定画面の1枚目のタブにに出力ビット深度の項目があると思いますので、まずはそちらで設定していただないでしょうか。

よろしくお願いいたします。

Re: NVEncCの出力bit深度について

返信ありがとうございます.

使用環境を書かずに投稿してしまい失礼いたしました.AviUtlではなくAmatsukaze 9.1.3で使っていますので,hevcエンコードのプロファイルでmain10を指定しているだけの状況です.試しにNVEncC 7.31と現versionで同じファイルをエンコードしてみたところ,出力ファイルサイズはほとんど変わりませんでした.ただMediaInfoやTMSR6での映像情報がそれぞれ10bitと8bitになっています.

以上,よろしくお願いいたします.

Re: Re: NVEncCの出力bit深度について

大変失礼いたしました。すみませんが、それでは"--output-depth 10"を付けていただけないでしょうか。

--output-depthでの制御に変更となった経緯としましては、AV1に対応した際、AV1では8bit/10bitともにmain profileのため、--profileで出力ビット深度を制御することができず、新たに--output-depthオプションを新設したものです。

このとき、HEVCについて、--profileと--output-depthの両方で制御できるとややこしくなると思い、--output-depthでの制御に一本化したのですが、互換性が失われた点については申し訳ありませんでした。

お手数ですが"--output-depth 10"をお試しいただければと思います。

Re: NVEncCの出力bit深度について

"--output-depth 10"で無事出力ビット深度の表示がが10bitになりました.ありがとうございました.

*今度rigayaさんのAmatsukaze改造版も試してみたいと思います.
プロフィール

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先: rigaya34589@live.jp
github twitter

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutl 出力プラグイン
x264guiEx 3.xx
- x264を使用したH264出力
- x264guiExの導入紹介動画>
- x264guiExの導入
- x264guiExのエラーと対処方法>
- x264.exeはこちら>

x265guiEx
- x265を使用したH.265/HEVC出力
- x265guiExの導入>
- x265.exeはこちら>

QSVEnc + QSVEncC
- QuickSyncVideoによるHWエンコード
- QSVEnc 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC
- NVIDIAのNVEncによるHWエンコード
- NVEnc 導入/使用方法>
- NVEncCオプション一覧>

VCEEnc + VCEEncC
- AMDのVCE/VCNによるHWエンコード
- VCEEnc 導入/使用方法>
- VCEEncCオプション一覧>

svtAV1guiEx
- SVT-AV1によるAV1出力
- svtAV1guiExの導入>
- SVT-AV1単体はこちら>

VVenCguiEx
- VVenCによるVVC出力
- VVenCguiExの導入>

ffmpegOut
- ffmpegを使用した出力
- ffmpegOutの導入>


○Aviutl フィルタプラグイン
自動フィールドシフト (ミラー)
- SSE2~AVX512による高速化版
- オリジナル: aji様

clcufilters 
- OpenCL/CUDAのGPUフィルタ集
- 対応フィルタの一覧等はこちら

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX512対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX512による高速化版
- オリジナル: まじぽか太郎様

PMD_MT
- SSE2~AVX512による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
Amatsukaze改造版
- AmatsukazeのAV1対応版

tsreplace
- tsの映像のみを置き換えて圧縮

rkmppenc
- Rockchip系SoCのhwエンコーダ

fawutil
- FAW(FakeAACWave)⇔aac変換
- 二重音声の取り扱いにも対応

x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定
- これまでの測定結果はこちら

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)
SVT-AV1 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR