GPUを落とさない
ための実装

まえがき

展示用ノートPC（RTX 5070 Laptop）で、シーンロードの約6秒後に毎回のように出ていたダイアログ。「回復不能なエラーなのでエディタを終了します」で締めくくられる

本編の第4章で、RVMの推論をONNX RuntimeのCUDA EPからTensorRTの直接呼び出しへ移した経緯を書いた。あれで推論そのものは動くようになった。ところが展示用のノートPCで通しの体験を回すと、今度は上の画面が出るようになった。Unityの描画バックエンドであるDirect3D 11^[1]が「デバイスがリセットされた」と言って、アプリごと落ちる。推論のエラーではない。GPUそのものが一度死んで、Windowsが生き返らせた、という意味のメッセージである。

この現象はTDR^[2]（Timeout Detection and Recovery）と呼ばれる。WindowsはGPUに投げた仕事が既定で2秒応答しないと、ドライバごとGPUをリセットする。リセットされた側のアプリから見ると、それまで持っていたテクスチャもバッファも全部無効になり、Unityはこれを回復不能として終了する。「重い描画をすると起きる」とダイアログには書いてあるが、実際に重い描画をしていたわけではない。GPUが2秒黙り込む原因は別のところにあった。この補遺は、その原因を取り違えながら追い詰め、最終的に「スパイクを起こさない構造」に落ち着くまでの記録である。

犯人を取り違える

症状には特徴があった。落ちるのはいつも、チュートリアルからメインシーンへ切り替わった直後、ログに「Native Init() returned status=0」、つまり姿勢推定RTMPoseの初期化が成功したと出た直後だった。展示ビルドではRVMはすでにTensorRTで動いている。この時点でONNX RuntimeのCUDA EPを読み込んでいるのはRTMPoseだけだった。CUDA EPは、行列演算ライブラリのcuBLASとニューラルネット演算ライブラリのcuDNNという、合わせて1GBを超えるDLL群を引き連れてくる。それをシーンの真ん中、つまりUnityの描画スレッドが同じGPUに毎フレーム命令を積んでいる最中に読み込む。GPUメモリ（VRAM）が足りなくなればWDDMは他のリソースをシステムメモリへ退避させ、その退避のあいだ描画のPresent（描き上がった映像をヘッドセットへ送り出す命令）は止まる。2秒を超えればTDRになる。筋は通っていた。

最初にやったのは、時間をずらすことだった。RTMPoseの初期化をシーンロードから最低6秒待たせ、ONNX Runtimeのグラフ最適化レベル（モデルを読み込むときに演算をまとめたり並べ替えたりする最適化の強さ。ALLが最大）もALLからBASICへ下げた。セッション（読み込んだモデルと実行環境をまとめたオブジェクト）を作るだけで、GPUの命令列を止めるほど重かったからである。あわせて、体験の開始をRTMPoseの準備完了から切り離した。一人称のゲームプレイはQuestのハンドトラッキングだけで成立するので、姿勢推定を待つ理由がなかった。これで落ちる回数は減ったが、消えてはいない。スパイクの位置が6秒後ろへ動いただけで、スパイク自体はそこにあった。

次にやったのは、犯人と目していたCUDA EPを消すことだった。RTMPoseもRVMと同じくTensorRTの直接呼び出し（ONNX Runtimeを介さず、TensorRTのSDKを自分のコードから直接使う経路）に載せ替え、ビルドからcuBLAS・cuDNN・onnxruntime_providers_cuda（CUDA EP本体のDLL）を一切同梱しないようにした。展示PC側の検証スクリプトも、これらのDLLがプラグインフォルダに残っていたら失敗するようにした。これで解決したと思って展示PCで3回回したところ、2回落ちた。

ここでようやく、DLLの読み込みが犯人ではなかったと分かった。残っていたのは、TensorRTのエンジンをplanファイルからGPUへ展開する「デシリアライズ」と、GPU上で走る小さなプログラム（カーネル）を初めて読み込むときのコストだった。どちらも「初回だけ重い仕込み」で、ONNX Runtimeを消しても残る。どちらもONNX Runtimeを消しても消えない。ついでに一つ、自分で仕込んだ悪化要因も見つけた。CUDA EPを使っていた頃の設定を引きずって、CUDAモジュール（カーネルをまとめたもの）の読み込み方式をEAGER（起動時に全部読む）にしていた。cuDNNの網羅的なアルゴリズム探索が初回推論に集中していた頃はそれが正しかったが、TensorRTではNVIDIA自身がLAZY^[1]を推奨している。planには、実際の入力サイズでは一度も呼ばれないカーネルの変種まで入っている。それを全部、初期化の瞬間に読み込むのは、まさに軽くしたい瞬間を自分で重くしていたことになる。LAZYへ戻し、環境変数に上書きされないよう3か所のコードで明示的に設定した。

スパイクを起こさない構造にする

重い処理を軽くする方向には限界がある。planのデシリアライズは、どうやっても数百ミリ秒から秒のオーダーでGPUを占有する。それなら、起きる時刻を選べばよい。参加者がイントロ画面でSTARTを押すまでの間、GPUはロゴを描いているだけでほとんど暇である。この時間に、あとで必要になるものを全部作っておき、ネイティブプラグイン（DLL）の中に保持しておく。シーンが始まって映像が来たら、作り直すのではなく保持してあるものを引き取る。これが現在の構造で、mppc_vision_prewarmという名前のワーカーがイントロ画面の裏で4段階を進める。画面の左下に「GPU vision warm-up n/4」と出ているのがそれである。

難しかったのは、RVMもRTMPoseも「どのD3D11デバイス（Unityが使っているGPUのハンドル）を使うか」を、Unityから最初の映像テクスチャが渡されて初めて知る設計だったことである。映像が届く前には、そもそも相手が分からない。そこでプリウォームは、D3D11デバイスが載っているアダプタからCUDA側のデバイス番号を逆引きして先に作っておき、あとで本番の初期化が来たときに「同じデバイス・同じplan・同じ入力サイズ」であることを確認してから引き渡す。条件が一つでも合わなければ引き渡さず、従来どおりその場で作る。安全側に倒した設計だが、この「合わなければ黙って作り直す」が後で罠になった（第4章）。

もう一つ、エンジンのプリウォームだけではTDRは止まらなかった。RTMPoseに渡す入力用のメモリ（D3D11側で作ったUAV付きバッファ^[1]）をCUDA側からも読めるように登録する処理（cudaGraphicsD3D11RegisterResource）が、まだ描画中のGPU上で走っていたからである。この登録は、D3D11とCUDAが初めて握手するときにだけ起きる重い手続きで、デシリアライズと同じ種類のスパイクを作る。前処理リソースの構築を関数に切り出し、プリウォームの第3段階で先に作って登録し、本番の初期化はそれを受け取るだけにした。

あわせて、体験のループ構造も変えた。以前は参加者が一人終わるたびにRVMとRTMPoseをシャットダウンし、次の参加者で初期化し直していた。これでは参加者のたびにスパイクの機会を作っていることになる。現在はワーカーとエンジンをプロセスの寿命いっぱい常駐させ、シーンの切り替えではpause/resumeするだけにしている。pauseはフレームの受け入れを止めるだけで、GPU上の資源（エンジン、バッファ、CUDA登録）には触らない。

この構成に切り替えてから、展示PCでの検証は3セッション、うち1セッションはRVMと姿勢推定を有効にしたまま5000フレーム以上を回して、例外（C#側のエラー）ゼロ、CUDA相互運用エラー（map / 登録の失敗）ゼロ、TDRゼロだった。

D3D11とCUDAの取り合いを止める

プリウォームを展示PCで試した夜に、もう一つ別種の問題が見つかった。症状は「たまにきれいなCUDA相互運用エラーで止まり、たまにエラーログを一行も残さずTDRで落ちる」。タイミングで結果が変わるというのは、典型的な競合の症状である。

原因は、RTMPoseの初期化がバックグラウンドスレッドで、Unityの描画スレッドと同じD3D11デバイスを排他制御なしに触っていたことだった。D3D11のデバイスコンテキスト（命令を積む窓口）は、本来スレッドセーフではない（複数のスレッドから同時に使うことを想定していない）。UnityはID3D11Multithread^[1]を有効にしてこの窓口を排他制御しているが、そのロックは「取りに来た側」しか守らない。推論のたびに行う所有権の受け渡し（map / unmap。このメモリを今からCUDAが使う、使い終わって返す、という宣言）には、すでにこのロックをかけていた。ところが初期化時のデバイス問い合わせやリソース登録には、かけていなかった。描画スレッドがPresentしている最中に、別スレッドがロックを取らずに同じデバイスのリソースを登録しにいく。運がよければエラー、運が悪ければドライバがGPUごと止まる。初期化側も同じロックで囲み、ついでにエラーの中身をcudaGetErrorString（CUDAのエラーコードを説明文にする関数）とGetDeviceRemovedReason（D3D11デバイスが消えた理由を返す関数）から文字列として取り出し、Unity側に「ステータス -2011」という数字ではなく理由が読める形で返すようにした。

「ドライバとCUDAの不整合」と一言で呼んでいたものは、実際には二つに分けられる。一つは同じデバイスを複数スレッドが同時に触る問題で、これは上のロックの取り決めで止まる。もう一つは作った環境と使う環境のバージョンが違う問題で、TensorRTのplanファイルはビルドしたGPUの世代（アーキテクチャ）とドライバのバージョンに縛られている。別のPCで作ったplanを持ち込むと、動かないならまだしも、動いたふりをして遅かったり不安定だったりする。だからplanは展示PC上でprepare_rvm_tensorrt.ps1とprepare_rtmpose_tensorrt.ps1で作る手順にし、リポジトリには置かない。ビルド自体も、TensorRT版ではONNX RuntimeのCUDA EPとその依存DLLを同梱しないようCMakeで切り、古いDLLがプラグインフォルダに残っている状態を検証スクリプトが弾く。「消したはずのものが残っていて別の経路で読み込まれる」というのは、第1章で3回中2回落ちたときにも疑った類の混乱で、これを構造的に起きなくしておきたかった。

レビューで残りを潰す

ここまでの変更を本線に取り込んだあと、差分約6000行を改めてレビューにかけた。ここから先はコードの細部に入るので、第5章まで飛ばしてもらっても構わない。方針として、展示までは1〜4行で済む局所的な修正だけを入れ、状態機械の統合やファイル分割のような設計変更は展示後に回すことに決めた。動いている構成をいじる方が、残っているバグより危ないからである。見つかったものの中で、体験に直接響くものを挙げる。

一番上の項目は、素直に言って恥ずかしい。第2章で「5000フレーム回してTDRゼロ」と書いたが、その検証のとき、RVM側のプリウォームは実は空振りしていたことになる。TDRが出なかったのは、第3章のロックとLAZY、それに姿勢推定側のプリウォーム（こちらは偶然両方が同じパスの作り方だった）が効いていたからで、RVM側はまだライブでデシリアライズしていた。安全側に倒した「合わなければ作り直す」設計は、失敗しても症状として現れないので、こういう見落としを隠す。修正は2行だが、見つけるのに人間1人とAI 3体のレビューが要った。

運用側のガード

コードで潰せるものは潰したうえで、当日それでも起きたときの判断をランブックに書いた。判断材料はすべてPlayer.logの特定の行にしてある。

特に最初の項目は、第4章の教訓そのものである。プリウォームが効いているかどうかは、画面上は何も変わらない。効いていなくても体験は始まるし、TDRが出るかどうかは確率の問題になる。だから「効いている証拠」を数値で決めて、当日の朝に見る。

あとがき

本編の第4章は「動かない推論を動かす」話だったが、この補遺は「動いている推論がGPUを道連れにしないようにする」話である。やったことを一行で言えば、重い処理を軽くしたのではなく、重い処理が起きる時刻と場所を選び直した、というだけになる。イントロ画面という誰も見ていない時間に全部済ませ、シーン中は引き取るだけにする。D3D11とCUDAが同じデバイスを触る瞬間は必ず同じロックを通す。planはそのPCで作る。消したはずのDLLは検証で弾く。

そして、その構造が本当に効いているかは、動いている画面を見ても分からなかった。「落ちなくなった」は「直った」の証拠にならない、というのがこの補遺の一番の教訓かもしれない。パスの区切り文字1つで空振りしていたプリウォームは、ログの1行を基準に決めておかなければ、展示当日まで空振りし続けていたはずである。