Windows 11 環境で RTX 5090 を 2 枚（デュアル構成）にしたところ、Blender でレンダリングを実行したタイミングで不定期にクラッシュしました。発生時には、
- Blender – Unsupported Graphics Card Configuration
A graphics card and driver with support for OpenGL 4.3 or higher is required. Plugging all monitors into your primary graphics card might resolve this issue. Installing the latest driver for your graphics card could also help.
というメッセージが出て終了することがありました（GPU 自体は当然 OpenGL 4.3 以上対応のはずなのに、です）。
イベントログ上では Blender 側が ucrtbase.dll で 0xc0000005（アクセス違反）で落ちる記録（Application Error 1000 / WER 1001）が残ることがあり、また WER 側には LiveKernelEvent（WATCHDOG/141 など）が出ることもありました。一方で、典型的な TDR（Display 4101）や nvlddmkm 153 が常に出る、という形ではありませんでした。
この問題が厄介だったのは、再現性が安定しない点です。ある時は同じシーンで通り、再起動を挟むと同じ操作で落ちる、という挙動になりました。
以下、いろいろChatGPTと相談しながら試した記録を記事にしています。
環境の特徴
今回のポイントは「デュアル GPU」だけではなく、モニタが複数枚で、両方の GPU に接続せざるを得ない構成だったことです。私の環境は6モニタなので、RTX 5090 は出力が 4 ポートのため物理的に全モニタを片方の GPU に集約することができません。
この前提があると、Windows と NVIDIA ドライバが「どちらの GPU で OpenGL コンテキストを作るか」を自動判定する場面で、意図しない選択が起きる余地が増えます。
切り分けで試したこと（うまくいかなかった／決定打にならなかったもの）
以下を試しました。
1) 片方ずつの GPU でレンダリング
Blender 側でデバイスを片方だけ有効にしてレンダリングし、さらに両方を有効にしてレンダリングも実施しました。両方を有効にした場合は、レンダリング時間が約半分（例：1分20秒→40秒程度）まで短縮し、計算自体は 2 枚使えていることが確認できました。ここから「2 枚構成そのものが常に破綻する」という状況ではないと判断しました。
2) OCCT などで GPU 負荷テスト（PL 制限含む）
Afterburner で 2 枚とも Power Limit を 80% にした状態でも OCCT の 3D 負荷を継続でき、電力・温度・安定性の観点では致命的な兆候は見えませんでした。さらに、Blender のレンダリング時間が PL 80% と 100% で大差が出ないケースもあり、少なくとも「PL が原因で Blender が落ちる」という説明は成立しにくい状況でした。
3) Blender の設定・インストールを疑う（ポータブル ZIP / config 削除）
ポータブル版を使い、C:\Users\<User>\AppData\Roaming\Blender Foundation\Blender の設定を削除し、起動直後のデフォルトシーンでも試しました。しかし、それでも落ちる時は落ちました。したがって、特定アドオンや設定の破損だけが原因とも言い切れませんでした。
4) CPU レンダリングでも同様に落ちることがある
レンダリングを CPU に切り替えても落ちることがありました。ここが非常に重要で、これにより「CUDA/OptiX の計算部分だけの問題」ではなく、Blender が動作するための描画系（≒OpenGL 側）での問題を強く疑う方向に寄りました。
5) DDU → 最新 Studio Driver をオフラインでクリーンインストール
セーフモードで DDU を使い、LAN ケーブルを抜いてオフラインで Studio Driver を入れ直しました。一時的に改善したように見えましたが、再起動後に再発しました。つまり、これは「やる価値はあるが、今回の決定打ではなかった」という位置づけでした。
6) iGPU を無効化
iGPU（AMD Ryzen 内蔵 GPU）をデバイスマネージャで無効化し、再起動しましたが、問題は継続しました。よって今回の主因が iGPU の混在だと断定するのは難しい状態でした。
最終的に効いた対策（解決策）
NVIDIA コントロールパネルで、グローバル設定の 「OpenGL レンダリング GPU （OpenGL rendering GPU）」 を
- Auto（自動）→ 特定の RTX 5090（メイン側）に固定
へ変更したところ、Blender のエラーが止まり、少なくとも同一条件での再現ができなくなりました。現状、これが最も説明力の高い「解決策」になりました。
理屈
1) Blender は「UI/ビューポート＝OpenGL」で動いている
Blender は UI とビューポート描画を OpenGL で行います。したがって「レンダリングボタンを押した瞬間」に落ちたように見えても、その瞬間に OpenGL が関与する処理は十分にあり得ます。たとえば、レンダリング開始時には進捗 UI 更新、レンダー結果の表示領域の更新、描画コンテキストの再初期化、ウィンドウ移動・モニタ跨ぎに伴うコンテキスト再確立などが起こり得ます。
また、CPU レンダリングでも落ちることがあった点は、「計算（CUDA/OptiX/CPU）ではなく、表示系（OpenGL）起点のクラッシュ」が混ざっている説明と整合します。
2) デュアル GPU + 複数モニタでは「どの GPU が OpenGL を担当するか」が揺れます
モニタが複数で両方の GPU に接続されていると、アプリのウィンドウがどのモニタ上にあるか、OS がどのアダプタを優先として扱うか、ドライバの自動判定がどう働くか、という条件が絡みます。
この自動判定が不安定だったり、特定条件で誤った GPU を選ぶ（あるいは OpenGL コンテキスト作成が失敗する）と、アプリ側は「OpenGL 4.3 以上が必要」という“能力不足に見えるエラー”として落ちることがあります。実際には GPU の能力不足ではなく、OpenGL コンテキストが期待どおりに作れなかったことが本質です。
そこで OpenGL rendering GPU を固定すると、OpenGL の担当 GPU がブレなくなり、コンテキスト作成・維持の条件が安定します。今回の改善はこの説明が最も自然です。
3) 「固定していないほうの GPU 接続モニタでも落ちない」理由
この挙動も矛盾ではありません。OpenGL rendering GPU を固定した場合、ウィンドウがどの GPU に接続されたモニタ上にあっても、OpenGL の実処理は指定 GPU で行われる（または少なくとも指定 GPU を優先）という形になります。そのため「非指定側モニタで操作したら必ず落ちる」ということにはなりません。
どちらの 5090 を指定するべきか
基本的には、次の方針が合理的です。
- メインモニタが接続されている GPU（普段の UI を担当している側）を指定する
- もし OC 版と無印があり、さらに PCIe のリンク条件などが良い側が明確なら、その「条件が良い側」を指定する
OpenGL は UI/ビューポートの体感にも関わるため、普段使いの滑らかさや安定性の観点では「メイン側に寄せる」判断が筋が通ります。
これで CUDA / OptiX のレンダリングは 2 枚使えるのか
使えます。OpenGL rendering GPU の設定は、主に OpenGL の描画担当を決める設定です。一方、Blender の CUDA / OptiX レンダリングは、Blender 側の「使用デバイス設定」で 2 枚とも有効にしていれば、基本的に両方を使います。
実際にタスクマネージャー上で 2 枚とも使用率が上がっている観測があるなら、「計算に使われている」という理解で問題ありません。
グローバル固定のデメリット（起こり得ること）
グローバル固定は運用が楽で、今回のように「Auto の揺れが原因」っぽいケースでは有効です。一方、理屈上のデメリットは次の通りです。
- OpenGL を使う他アプリでも、その指定 GPU に OpenGL が寄るため、用途によっては負荷が偏る可能性があります
- ごく稀に、特定アプリが「表示している GPU と同じ GPU で OpenGL したい」前提で作られている場合、挙動が変わる可能性があります（この種の問題は一般には多くありませんが、可能性としては残ります）
ただし、挙げられている主要アプリ（Premiere Pro / After Effects / Photoshop / DaVinci Resolve）は、実務上は DirectX/CUDA 側が中心で、OpenGL rendering GPU の固定が直撃するケースは多くありません。したがって、「まずグローバルで固定して安定を取る」という判断は現実的です。
もし将来、特定アプリだけ違和感が出た場合は、その時点で「グローバルは Auto に戻し、Blender（blender.exe）だけプログラム設定で固定する」という運用に切り替えると、影響範囲を最小化できます。
まとめ
今回の問題は、GPU 性能不足ではなく、デュアル GPU + 複数モニタ構成における OpenGL 担当 GPU の自動選択が不安定で、Blender の OpenGL コンテキストが破綻する瞬間があった、という整理が最も整合します。
DDU やドライバクリーンインストール、iGPU 無効化は「やるべき切り分け」ではありますが、決定打は NVIDIA コントロールパネルで OpenGL rendering GPU を固定することでした。これにより、Blender の UI/ビューポート（OpenGL）経路が安定し、レンダリング開始時のクラッシュが止まりました。
コメント