rigayaの日記兼メモ帳

---

cufiltersの問題点

---

1. CUDAなのでNVIDIA GPUでしか使用できない
まあCUDAなので仕方ないのだが、Intel/AMDのGPUで使用したいとなるとOpenCLを使うことを考える必要がある。

2. 32bitのCUDAだとCUDAのフル機能が使用できない
だいぶんと前からCUDAは32bitは徐々にフェードアウトしていく感じで、いろいろな機能が64bitのみ対応になってきている。例えば、--vpp-colorspaceは32bit CUDAではnvrtcが対応していないため動かすことができなくて、64bit CUDAが必要になってしまう。

また、32bitでのコンパイル自体、CUDAの次のバージョンで対応されるか怪しくなってきている。古いCUDAを使い続けるのも手だが、それもいつかは限界が来るだろう。

---

clfiltersの問題点

---

cufiltersのNVIDIA GPUだけ、という課題を解消すべく作ったのがclfiltersで、OpenCLベースとすることで基本的にはすべてのGPUに対応できた。

ところが、これもいくつか課題があった。

1. NVIDIA GPUでOpenCLだとかゆいところに手が届かない
いくつかのIntel/AMDでは普通にサポートされている拡張機能に対応していなかったりで、これを回避するため結構NVIDIA GPU用にまわりくどい実装が必要になって、実装がややこしいうえに、処理も非効率になってしまったりした。

あとはまあ、CUDAでは細かい制御ができるけど、OpenCLだとそうはいかない、みたいなところもある。

2. 32bitプロセスであるAviutlのメモリ空間を食う
これはNVIDIA GPUに限らないけど、やはりGPUフィルタは使用するフィルタによってはそれなりにメモリを使用することがあり、貴重なAviutlのメモリ空間をかなり使用してしまっていた。ほかの処理で使えるメモリが減るのは、Aviutlが不安定化する原因にもなる。

とにかくAviutlのメモリ空間は貴重なので、エンコーダにしろフィルタにしろ、メモリ量を食うものはなるべく外に出したいという感じになってきている。

---

clcufiltersの作成

---

ということで、このあたりを課題を解消したいと思って、clcufiltersを作ってみた。

clcufiltersでは、フィルタ処理を64bitプロセスに分離して、Intel/AMD GPUではOpenCL、NVIDIA GPUではCUDAで処理を行うようにした。



こんな感じで自動的にIntel/AMD GPUはOpenCL、NVIDIA GPUはCUDAが使用される。



実装はかなりややこしくてかなり時間がかかったけど、この仕組みで

1. NVIDIA GPUでCUDAが使えるので細かい最適化が可能になる
2. 64bit対応により32bitと異なりCUDAのフル機能が使えるように
3. Aviutlのメモリ使用量を最小限に

という感じで、これまでのいろんな課題をだいぶ改善できたのではないかと思う。

ただ、プロセス間のやり取りや、追加のメモリコピーがどうしても発生するので、速度面で有利かというとおそらくそうではなく、やや遅いかもしれない。どちらかというと機能面や安定性のほうが期待できそう。

---

動作環境

---

Windows 10/11 (x64)
Aviutl 1.00 以降
Intel / NVIDIA / AMD のGPUドライバのインストールされた環境

NVIDIAドライバは452.39以降

なお、32bit OSでは使用できません。

---

使用方法

---

ダウンロードしたら、zipファイルの中身をすべてAviutlフォルダにコピーしてください。

---

いつもの注意事項

---

無保証です。自己責任で使用してください。

clcufiltersを使用したことによる、いかなる損害・トラブルについても責任を負いません。

---

その他注意事項

---

申し訳ないですが、clfiltersとcufiltersは開発終了とさせていただき、clcufiltersを後継としたいと思います。

---

ダウンロード>>

clcufiltersの詳細

---

---

以下、下記の環境でテストを実施した。

環境: Win11 x64 / i9 12900K / Arc A380 (PCIe3x4) / 5186ドライバ / QSVEnc 7.61
入力ファイル: MPEG2 1440x1080 54433frames (約30分)
オプション: --avhw --icq 23
モニタリング: HWiNFO64, エンコード速度のみQSVEnc

---

Resizable BAR Onの状況

---

まず、Resizable BAR Onの時の状況を確認。

グラフは横軸がエンコード中の実時間、縦軸が左からエンコード速度(ピンク)、GPUのクロック(水色)、右軸がMedia Usage(橙色)とCopy Engine Usage(黄色)になっている。



エンコード速度(ピンク)は安定して430fps程度を維持できている。Media Usage(橙色)は100%に貼り付いていて、フル稼働していることが確認できる。意外なことにGPUのクロック(水色)は1400MHzで安定していて、Maxの2450MHzには到達していない。

---

Resizable BAR Offの状況

---

次に、Resizable BAR Offの状況を確認してみよう。



なかなかややこしい感じになっている。

エンコード速度(ピンク)は報告いただいた通り、最初だけ極めて速いものの、10秒程度で落ち込んで300fpsを切り、さらにしばらくすると100fps程度まで低下してしまう。その後、270fps前後と100fps前後をいったり来たりしている。

この300fps弱と100fps程度のエンコード速度差は、グラフから明らかにGPUのクロック(水色)と連動していることがわかる。また、Media Usage(橙色)は、最初以外は40～50%をうろうろしていて、エンコーダを十分に活用できていない。

Arc A380でGPUクロックが600MHzというのは最低クロックなので、この状態では高速にエンコードできず、さらにエンコーダ使用率も低迷することで速度が出なくなっていることがわかる。

不可解なのはCopy Engine Usage(黄色)で、最初の10秒以後は30～40%前後の使用率がある。これはResizable BAR Onのときはほぼずっと0%だったので、Resizable BAR Off特有の現象で、このあたりになんらかのボトルネックになっているなにかがあるのかもしれない。ただ、今回はhwデコードをしているので、コピー…といってもなにを…? という感じ。入力のMPEG2のデータの転送が遅い、とかだともうどうしようもない気がする。

ともかく、Resizable BAR Offだと

・Media Engineの使用率が低い(がなぜかCopy Engineは中途半端に高い)
・そのせいか、GPUクロックも低下し、GPUクロックが下がると明らかにエンコードも遅くなる

ことがわかった。

---

QSVEnc 7.61で回避

---

Resizable BAR Offの状況から、エンコード速度を上げるには

1. Media Engineの使用率を上げる
2. GPUクロックが下がらないようにする

のどちらかしかない。

Media Engineの使用率を上げるのが正攻法だが、Resizable BAR OffでMedia Engineの使用率がhwデコードでも下がる原因はまだよくわからないので、すぐにはどうしようもなさそう。

そこで、2.のGPUロックが下がらないようにすることを考えてみた。

基本的にはGPUの負荷が低いとGPUクロックが低下する傾向にある。

そこで、OpenCLで短時間の適当な計算して、定期的にわずかな負荷(デフォルトでは0.01%程度)をかけることにしてみた。QSVEnc 7.61ではdGPUでは(いくつかの条件を満たせば)自動的にこの機能がオンになり、速度低下を回避する。

QSVEnc 7.61での結果がこちら。



GPUのクロック(水色)が1400～2450MHzで推移し、600MHzまで低下することがなくなった。その結果、エンコード速度(ピンク)が270fps前後を安定して維持できるようになって、100fpsまで低下するようなことがなくなった。(やや不安定ではあるけど)

なお、デフォルトではこの機能はdGPU(Arc GPU)でOpenCLフィルタを使わない場合のみ有効。

強制的に有効にしたい場合は、"--avoid-idle-clock on"を指定してください。

また、逆に不要なので無効にしたかったり、わずかでも負荷を減らしたい場合は"--avoid-idle-clock off"を指定してください。

---

あとはそれでもResizable BAR Offだとまだかなり遅いのは事実。なぜこれほど効率が低下するのか、ということが本質ではあるので、そっちも調べて対策していきたいが、いまのところ難しそう。

---

※Aviutl向けには、Aviutl_QSVEnc_7.xx.zip をダウンロードしてください。
QSVEnc ダウンロード>>

QSVEncの導入

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

---

---

ということで、forkさせていただいて、Visual Studio 2019/2022 + CUDA 11～12でビルドできるようにしてみた。(fork版はこちら)

Visual Studio 2019か2022とCUDA11-12がインストールされていれば、一応問題なくビルド自体はできるはず。(CUDA10はC++17が使えないので対応せず)

ビルドにはsubmoduleも必要なので、下記コマンドでソースコードをダウンロードする必要がある。

git clone --recursive https://github.com/rigaya/AviSynthCUDAFilters.git

---

以前は再ビルドした時の課題として、KNNEDIを最近のCUDAでビルドして動かすとフリーズしてしまうということを書いた。具体的には、エンコード開始後GPU 使用率100%のままフリーズしてしまった。

調べてみると、新たにビルドしたKNNEDIでは、nnedi3_kernel.cuのkl_prescreeningという関数でフリーズしていることがわかった。また、RTX4080ではフリーズするが、GTX1060ではフリーズしないこと、さらにオリジナルのCUDA8.0のビルドではRTX4080でもフリーズしないことも考えると、CUDA 9.0で追加された__xxx_sync系の関数のあたりが一番怪しそう。

調べてみると、warp内(32スレッド)で条件の成立不成立の異なるif文の中で__shfl_up_syncがフルマスクで使われている箇所があった。

__xxx_sync系の関数は、適用するマスクのスレッドがif文の条件分岐の結果、その関数を実行しないとフリーズしてしまうとされている。(参考 → https://developer.nvidia.com/blog/using-cuda-warp-level-primitives/)

おそらくここかなあという感じで、フルマスクでなく適切なマスクを使用するように修正すると、無事フリーズは解消することができた。(→具体的な変更はこちら)

---

ただ、前の記事で書いたもう一つの問題は未解決。

現行のAmatsukaze付属のKFMDeint.avsiにはis120というオプションがあり、KFMSwitchなる関数でこれを指定している。おそらく120fps精度でtimestampを計算するオプションなのかなあと思う。

が、ソースコード(AviSynthCUDAFiltersのほう)のKFMSwitchのほうにはis120オプションがなく、これをコンパイルしてもエラーで終了してしまう。

AviSynthCUDAFiltersのほうのKFMDeint.avsiにはたしかにis120オプションはないので、どこかにタイミングでAmatsukaze付属のものだけ更新されたのかもしれないが、なんともいえない。探し切れていないだけ?

is120が実際の計算で具体的になにをやっているのかも私にはよくわからない…

ということで、まだ再ビルドしたもので動かせるようになるまでの道のりは遠そう。

---

最近のやたらと大きいGPUに慣れると本当に小さく見える。



Low Profile対応ということで、HDMI 1基とmini DPが2基ついている。

---

今回は、Ryzen PCに取り付けてみたけど、ドライバをインストールするとすんなり認識された。

GPU-Zの表示はこんな感じ。Ryzen PCの一番下のPCIeスロットに接続したのでPCIe 4x2接続。Resizable Barは有効になっている。

---

QSVエンコード速度比較

---

簡単にQSVEncで、
・A310 LP
・A380
・i3 N305
でエンコード速度を比較してみた。

比較対象の詳細はこんな感じ。

	Ryzen9 7950X	i9 12900K	N305
コア数	16C/32T	8P+8E/24T	8C/8T
メモリ	DDR5-6000	DDR4-3600	DDR5-4800
メモリ容量	32GBx2	16GBx2	16GB
マザー	MSI Pro X670-P WIFI	MSI Mag Z690 TOMAHAWK	Beelink EQ12 Pro
GPU1	RX7900	RTX4080
GPU2	RX5500XT	Arc A380
GPU3	Arc A310 LP	GTX1060
OS	Win11	Win11	Win11

比較条件は下記の通り。

QSVEnc 7.57
入力: MPEG 1440x1080i 29.97fps 約30分
オプション: -c hevc --output-depth 10 -u best --icq 26 --weightb --weightp --b-pyramid --tff --vppdeinterlace normal

---

結果

---

A380が371.95fpsなのに対し、A310 LPが364.11fpsとほぼ変わらない速度でエンコードできた。

内蔵GPUでエンコードしているN305と比べるとかなり高速だ。

---

終わりに

---

A310はA380と比べると演算器とメモリが少しづつカットされているが、エンコードに関してはほぼその影響を感じず、A380と同じぐらいの速度が出せるみたいで、エンコーダはなかなか優秀。

もちろん、演算器を使う重いフィルタとかを使うと差が出てくるかもしれないけど、軽めのフィルタならさほど変わらないようだった。

難点はGPUが小さい代償というか、ファンが回り始めるとうるさいかもしれない点。ファンが4000回転超えてくるとちょっと気になるぐらいの音はする感じだった。(音量はさほど出なくても回転数が高いのでやや目立つ)

あとA380に対する懸念点はどちらかというとメモリ容量かもで、もちろんfullHD程度ならA310の4GBメモリで十分だけど、4Kだったりすると気になってくることがあるかもしれない(A380はメモリ6GB)。

とはいえ、これで1.5万円前後なので、QSVなので画質も比較的良好だし、1スロットLow Profileで安価に手に入るものとしてはいい感じの性能な気がする。Ryzen PCでQSVができるようになるのはかなりありがたいと思う。