Unreal Engine 使用時の GPU クラッシュへの対処 | Unreal Engine 5.4 ドキュメンテーション

Unreal Engine でクラッシュが発生した場合、クラッシュレポータとログファイルによって生成されたコールスタックで、何が起こっているかを理解するのに役立つ情報が記載されていないかどうかを調べると思います。しかしながら、GPU クラッシュが発生した場合、CPU コールスタックではクラッシュの本当の原因が直接分かりません。ここには、GPU クラッシュが発生したときに CPU が何をしていたかの情報のみが記載されるためです。つまり、実用的な情報は提供されません。

このページの内容では、次の点について説明します。

GPU クラッシュとは？
GPU クラッシュを識別して調査する方法
さまざまなデバッグツールを使用して、GPU クラッシュを最初から最後までデバッグする方法
タイムアウト検出と復元 (TDR) のクラッシュを解決する方法

GPU クラッシュとは？

一般的に GPU クラッシュと呼ばれるエラーには 2 種類あります。

GPU タイムアウト は、描画またはディスパッチの実行に時間がかかりすぎる場合に発生します。Windows には、タイムアウト検出と復元 (または TDR) と呼ばれるメカニズムがあります。これは、コマンドの実行に一定の時間 (デフォルトは 2 秒) を超えると GPU がリセットされる機能です。詳細は、以下の「GPU タイムアウトを理解して解決する」セクションを参照してください。これにより、実行中のすべてのアプリケーションにわたるすべての既存のグラフィックコンテキストに対して「デバイスが削除されました」というエラーが発生します。
GPU ページフォールト は、描画またはディスパッチが利用できない GPU メモリを読み取ろうとしたときに発生します。これは、CPU 命令が物理 RAM にマップされていないメモリ位置にアクセスしようとしたときに発生する CPU ページフォールト (アクセス違反またはセグメンテーションフォールトとも呼ばれます) に似たものです。

GPU クラッシュを認識する

GPU クラッシュが検出されると、エンジンは終了し、次のようなダイアログが表示されます。

Unreal Engine GPU crash dialogue window.

デバッガがアタッチされている場合、デバッガはシャットダウン前にエラーを取得します。ログには次のようなエラーが追加されます。

	LogD3D12RHI: Error: CurrentQueue.Fence.D3DFence->GetCompletedValue() failed 
	at D:\UE5\Main\Engine\Source\Runtime\D3D12RHI\Private\D3D12Submission.cpp:984 
	with error DXGI_ERROR_DEVICE_REMOVED with Reason: DXGI_ERROR_DEVICE_HUNG

根本的な原因が同じであっても、障害が発生した機能とソースの場所が、クラッシュの発生箇所と異なる場合があります。エラーをキャッチした CPU コールスタックは、アプリケーションに非同期的に報告されます。したがって、こうしたコールスタックは GPU クラッシュの原因を調査する際には無関係です。

デバイス削除エラーとその他の D3D エラーは CPU コード内の同じ場所で検出される可能性があります。しかし、デバッグ方法が異なることから、これらを区別することが重要となります。たとえば、関数 VerifyD3D12Results() は両方のタイプのエラーをキャッチすることが多いため、エラーコードを確認してどのように続行するのかを決定する必要があります。GPU クラッシュではコード DXGI_ERROR_DEVICE_REMOVED が報告されますが、その他の問題では E_INVALIDARG_E_ACCESSDENIED や E_OUTOFMEMORY などの異なるコードが報告されます。

次は、GPU クラッシュではない例です。

	Fatal error: File:D:\UE5\Main\Engine\Source\Runtime\D3D12RHI\Private\D3D12Util.cpp [Line: 903] 
	Interfaces.CopyCommandList->Close() failed 
	at D:\UE5\Main\Engine\Source\Runtime\D3D12RHI\Private\D3D12CommandList.cpp:284 
	with error E_INVALIDARG
	[Callstack] 0x00007fff2671c838 UnrealEditor-D3D12RHI.dll!D3D12RHI::VerifyD3D12Result()

この特定のクラッシュは、D3D API 呼び出しに誤った引数を送信することによって発生します。そのため、別の方法でデバッグする必要があります。詳細は、以下の「GPU タイムアウトを理解して解決する」セクションを参照してください。

GPU クラッシュの考えられる原因

実際に GPU クラッシュが発生する理由は複数あります。

コンテンツエラー。たとえば、Nanite 以外のレンダリングパスを使用して極度に高密度なメッシュをレンダリングしようとした場合、マテリアル内のカスタム HLSL ノードで無限ループが発生した場合、特定の条件下では実行に時間がかかりすぎる Niagara GPU システムを使用した場合です。
カスタムレンダリングコード 内の同様のエラー。たとえば、レンダリング依存関係グラフ (RDG) に追加されたカスタムパス内の非常に長いループなどです。
エンジンのバグにより、ビルトインパスの実行に時間がかかりすぎたり、リソース管理が不適切でページフォールトが発生したりします。
GPU ドライバーのバグ。
GPU のオーバーヒートなど、ハードウェアの問題。
VRAM の枯渇。Windows ではビデオメモリが仮想化されています。したがって、特に複数のアプリケーションを同時に実行している場合、GPU で使用可能な量よりもはるかに多くのメモリを割り当てることが可能です。ただし、VRAM へのブロックの移動と VRAM からのブロックの移動は遅く、極端な状況では GPU タイムアウトが発生する可能性があります。
他のアプリからのクラッシュ。上記で説明したのと同様に、GPU タイムアウトにより、現在実行中のすべてのコンテキストが無効になります。そのため、別のアプリケーションがクラッシュすると、エンジンもクラッシュすることになります。

Epic Games に GPU クラッシュを報告する方法

GPU クラッシュを報告する際のガイドラインを以下に示します。これに従うことで、レンダリングチームにできるだけ多くの情報を提供できます。

GPU で利用可能な最新のドライバーバージョンを使用します。
- これにより、製造元によってすでに修正されている、既知のドライバーのバグによる可能性を排除できます。ドライバーが最新かどうかの確認は、Windows Update やベンダーのツールに頼るのは避けてください。必ずメーカーのウェブサイトを確認してください。
- AMD: https://www.amd.com/en/support
- Intel: https://www.intel.com/content/www/us/en/download-center/home.html
- Nvidia: https://www.nvidia.com/ja-jp/geforce/drivers/
レポートには完全なログを含めてください。
- 過去 10 回のエディタセッションのログは、プロジェクトディレクトリの「Saved/Logs」サブディレクトリに保存されます。クラッシュが発生した際は、そこに最新のログファイルが保存されます。
一般的なクラッシュと GPU クラッシュを区別します。
- 最新のログを調べて、DXGI_ERROR_DEVICE_REMOVED またはその他のエラーコードがないか確認します。クラッシュは、どのようなものでも報告する必要があります。しかしトリアージを行う上で、最初から GPU クラッシュを他の種類の問題と区別することが重要となります。
再現可能な GPU クラッシュのデバッグログを含めます。
- クラッシュを再現できる場合、またはある程度確実に再現できる場合は、コマンドライン引数 -gpucrashdebugging を追加してクラッシュが発生するようにします。これにより、フラグが存在する場合に、問題を識別するのに役立つ情報がエンジンログに追加されます。
- アフターマスダンプファイル が生成される場合は、これをレポートに含めることも役立ちます。これらのファイルは、NVIDIA GPU 上で実行されている場合にのみ生成されます。ログ内で「Writing Aftermath dump to: [PATH]」という行を調べて、ダンプファイルが書き込まれたかどうか、またどこに書き込まれたかを確認できます。
クラッシュを再現する方法について、できるだけ多くの情報を含めてください。
- クラッシュが起きた際に実行した手順またはアクションを含めます。さらに、可能であれば問題を単純な自己完結型プロジェクト、または Unreal Engine に含まれている Epic 独自のサンプルプロジェクトのいずれかに切り分けてください。エンジニアがこれらのクラッシュを調査して解決する際、最も効率的に行えるようになります。

GPU クラッシュワークフローをデバッグする

GPU ドライバーはとても複雑になっていることから、バグや問題の発生がより一般的になっています。

自分のマシンで GPU クラッシュが発生している場合は、まず GPU 製造元から提供されている最新のドライバーを実行していることを確認してください。別のマシンで発生した GPU クラッシュを調査している場合、次の例のように、エンジンログにドライバーのバージョンと日付が表示されます。

	LogD3D12RHI: Found D3D12 adapter 0: NVIDIA GeForce RTX 3080 (VendorId: 10de, DeviceId: 2206, SubSysId: 38901462, Revision: 00a1)
	LogD3D12RHI:   Max supported Feature Level 12_2, shader model 6.7, binding tier 3, wave ops supported, atomic64 supported
	LogD3D12RHI:   Adapter has 10067MB of dedicated video memory, 0MB of dedicated system memory, and 130990MB of shared system memory, 3 output[s]
	LogD3D12RHI:   Driver Version: 546.17 (internal:31.0.15.4617, unified:546.17)
	LogD3D12RHI:      Driver Date: 11-9-2023

ログを確認した後、エラーに記載されている理由を特定する必要があります。これは、DXGI_ERROR_DEVICE_REMOVED などのエラーコードとは別のものであることに注意してください。理由が DXGI_ERROR_DEVICE_RESET の場合、これは別のアプリケーションによって発生したクラッシュである可能性が高いです。この場合、Unreal Engine と同時に他の 3D アプリケーションを実行しないようにする以外に対処方法はありません。理由コードを完全に信頼できるわけではありません。しかしほとんどの場合、依然としてこれをチェックする価値はあります。

ログと理由によって他の原因を排除できない場合、クラッシュの原因がコンテンツまたはエンジンのバグである可能性が考えられます。ビルドとランタイム構成によっては、ある程度の GPU クラッシュデバッグログがすでに有効になっている場合があります。「device removed error」が報告された後のログの最後を見て、デバッグログが含まれているかどうかを確認します。

DirectX 11 (DX11) での GPU クラッシュの場合、ほとんどの GPU クラッシュは対処不能です。明示的なメモリ管理がないため、理論的にはページフォールトは発生しません。ページフォールトが発生した場合、それはドライバーのバグが原因です。しかし、クラッシュの種類はアプリケーションには表示されません。クラッシュが NVIDIA GPU で発生し、アフターマスが有効になっている場合は、NVIDIA Nsight Graphics 開発者ツールからアフターマスダンプファイルを取得して、どのパスがクラッシュしたかを確認できることがあります。他の GPU ベンダーの場合、GPU クラッシュをデバッグする方法はありません。つまり、確実に再現できない限り、デバッグするための実用的な方法はありません。そうした状況では、デバッグは、どのパスが原因であるかを絞り込むまでパスを無効にし、その特定のパスがどのようにして GPU のハングを引き起こすのかを把握することにより行います。

DirectX 12 (DX12) は、デバッグ情報のソースをいくつか提供します。1 つ目は RHI ブレッドクラム です。ここでは、エンジンは WriteBufferImmediate API を使用して GPU 上のアクティブなコマンドを追跡します。このシステムは、クラッシュが発生すると、次のようなログを出力します。

	[GPUBreadCrumb] Last tracked GPU operations:
	[GPUBreadCrumb]	3D Queue 0
	Breadcrumbs: > Frame 1979 [Active]
	Breadcrumbs: | BufferPoolCopyOps [Finished]
	Breadcrumbs: | TexturePoolCopyOps [Finished]
	Breadcrumbs: | WorldTick [Finished]
	Breadcrumbs: | SendAllEndOfFrameUpdates [Finished]
	Breadcrumbs: > GPUDebugCrash_DirectQueue_Hang [Active]
	Breadcrumbs: > ClearGPUMessageBuffer [Active]
	Breadcrumbs:   VirtualTextureClear [Not started]
	Breadcrumbs:   ShaderPrint::UploadParameters [Not started]
	Breadcrumbs:   UpdateDistanceFieldAtlas [Not started]
	Breadcrumbs:   Scene [Not started]
	Breadcrumbs:   EnqueueCopy(GPUMessageManager.MessageBuffer) [Not started]
	Breadcrumbs:   AccessModePass[Graphics] (Textures: 14, Buffers: 4) [Not started]
	Breadcrumbs:   CanvasBatchedElements [Not started]
	Breadcrumbs:   SlateUI Title = QAGame - Unreal Editor [Not started]

この特定のログは、GPU 上で実行されている 2 つのパス/シェーダーを示しています。これらには、GPUDebugCrash_DirectQueue_Hang および ClearCPUMessageBuffer の [Active] タグが付けられています。これらのシェーダーを調査して、どれがハングの原因であるかを判断する必要があります。

この特定のケースでは、問題は GPUDebugCrash_DirectQueue_Hang パスです。これは、コンソールコマンド GPUDebugCrash hang によって追加されました。これは、デバッグコードが機能することを確認するために意図的にクラッシュをトリガーする際に使用します。

次のソースは、Microsoft の Device Removed Extended Data API である DRED です。これは RHI ブレッドクラムと同様のメカニズムを使用しますが、その手のエラーが発生した際はページフォールトアドレスを報告することもできます。DRED 情報は階層的ではなく、次の例のように、アクティブなコマンドリスト内のイベントのリストのみが含まれています。

	DRED: Last tracked GPU operations:
	DRED: Commandlist "FD3D12CommandList (GPU 0)" on CommandQueue "3D Queue (GPU 0)", 4 completed of 59
		Op: 0, Unknown Op
		Op: 1, BeginEvent [EditorSelectionOutlines]
		Op: 2, BeginEvent [OutlineDepth 1679x799]
		Op: 3, BeginEvent [EditorSelectionDepth] - LAST COMPLETED
		Op: 4, ClearDepthStencilView
		Op: 5, EndEvent
		Op: 6, BeginEvent [DrawOutlineBorder]
		Op: 7, DrawInstanced
		Op: 8, DrawInstanced
		Op: 9, DrawInstanced
		Op: 10, DrawInstanced
		Op: 11, EndEvent

LAST COMPLETED マーカーは、GPU で終了した最後のコマンドを示します。それ以降のものは現在実行中の可能性があり、調査する必要があります。RHI ブレッドクラムとは異なり、アクティブなコマンドとまだ開始されていないコマンドをすぐに区別する方法はありません。

DRED には、軽量モードとフルモードの 2 つのモードがあります。軽量モードでは、エンジンによって送信されたマーカーのみが使用されます。これは、RHI ブレッドクラムが使用する情報ソースと同じです。フルモードでは、Draw、Dispatch、Barrier などのすべてのレンダリングコマンドにマーカーが自動的に挿入されます。また、エンジンによって送信されたエンジンマーカーも含まれます。このモードではより多くの情報が提供されますが、GPU のパフォーマンスへの影響が非常に大きくなります。通常、問題を追跡する際は軽量モードで十分です。

コンソール変数 D3D12.TrackAllAllocations が有効になっている場合、RHI はアクティブなリソースのアドレス範囲と、過去 100 フレームにわたって解放されたリソースを追跡します。DRED も (このコンソール変数に関係なく) 同様の情報を保存します。ページフォールトが発生すると、フォールトアドレスがこの範囲のリストと比較されます。したがって、その時点でどのリソースにアクセスされていたかを報告できるようになります。以下は、RHI ブレッドクラムからの出力例です。

	PageFault: PageFault at VA GPUAddress "0x674000000"
	PageFault: Last completed frame ID: -1 (cached: 4331) - Current frame ID: 4332
	PageFault: Logging all resource enabled: No
	PageFault: Found 1 active tracked resources in 16.00 MB range of page fault address
		GPU Address: [0x674000000 .. 0x6F135FFF8] - Size: 2100690936 bytes, 2003.38 MB - Distance to page fault: 0 bytes, 0.00 MB - Transient: 0 - Name: Shadow.Virtual.VisibleInstances - Desc: Buffer 2100690936 bytes
	PageFault: Found 0 active heaps containing page fault address
	PageFault: Found 0 released resources containing the page fault address during last 100 frames

このログの場合、リソースはアクティブであったことから、考えられる原因は次のとおりです。

使用前にレジデンシーマネージャーに対して正しくマークされていなかったため、削除されました。
これはタイル化されたリソースであり、ページをマップしていません。

DRED からの出力例：

	DRED: PageFault at VA GPUAddress "0x2322884000"
	DRED: Active objects with VA ranges that match the faulting VA:
	DRED: Recent freed objects with VA ranges that match the faulting VA:
		Name: Editor.SelectionOutline (Type: Resource)

この場合、フォールトは最近解放されたリソース内に存在します。問題は、リソースを使用している保留中の GPU 作業がまだある間に、リソースが解放されたことです。

最後に、NVIDIA GPU でクラッシュが発生した場合アフターマスから情報を抽出できます。障害の種類 (タイムアウトまたは PageFault) と、エラーの原因となったパスを報告します。この場合、アフターマスから抽出された情報は RHI ブレッドクラムと同様に階層的で、シーンパス階層内のパスを示します。

	[Aftermath] Status: Timeout
	[Aftermath] Scanning 5 command lists for dumps
	[Aftermath] Begin GPU Stack Dump
	[Aftermath] 0: Frame 1456
	[Aftermath] 1: Scene
	[Aftermath] 2: RayTracingReflections 0
	[Aftermath] 3: MaterialSort SortSize=4096 NumElements=24231936
	[Aftermath] End GPU Stack Dump
	Aftermath: Writing Aftermath dump to: ../../../QAGame/Saved/Logs/UEAftermathD3D12.nv-gpudmp

アフターマスは DX11 で GPU クラッシュダンプファイルを生成します。このファイルは Nsight で開くことができます。問題の原因となったシェーダーでデバッグ情報が有効になっている場合、Nsight はソース内で問題が発生した場所を表示できます。

これらのデバッグ機能は、次のコマンドライン引数とコンソール変数によって制御されます。

デバッグ機能	コマンドラインフラグ	コンソール変数
RHI ブレッドクラム	`-gpubreadcrumbs`	`r.GPUCrashDebugging.Breadcrumbs`
フル DRED	`-dred`	`r.D3D12.DRED`
軽量 DRED	`-lightdred`	`r.D3D12.LightweightDRED`
アフターマス	`-nvaftermath`	`r.GPUCrashDebugging.Aftermath`
すべてオン	`-gpucrashdebugging`	`r.GPUCrashDebugging=1`
すべてオフ	`-nogpucrashdebugging`	—

機能ごとのコマンドラインフラグは、オプションの「=0」または「=1」引数を受け入れ、機能の状態を明示的に指定します。フラグを単独で使用すると機能が有効になるため、「=1」と同等になります。コマンドライン引数はコンソール変数よりも優先されます。

すべてをオンまたはオフにするフラグを他のフラグと組み合わせることで、特定の機能を含めたり除外したりできます。たとえば、-gpucrashdebugging -gpubreadcrumbs=0 を使用すると、RHI ブレッドクラム以外のすべてが有効になりますが、-nogpucrashdebugging -dred を使用すると、完全な DRED のみが有効になり、その他はすべて無効になります。

上記のデバッグ機能を使用する場合は、次のパフォーマンスへの影響を考慮してください。

RHI ブレッドクラムと軽量 DRED の GPU パフォーマンスコストは、無視できないレベルになる可能性があることから、エンジンのデフォルト設定では、デバッグ ビルドと開発ビルドでのみ有効になります。
完全な DRED はパフォーマンスに大きな影響を与えるため、すべてのビルド構成でデフォルトはオフに設定されています。
アフターマスにはパフォーマンスコストがかかりません。これは、サポートされている GPU では常に有効になっています。

これらのデフォルト設定はプロジェクトごとに変更できます。

GPU のメモリ不足問題を解決する

GPU のメモリが不足すると、クラッシュが発生する可能性があります。クラッシュが発生するかどうかは、使用されている RHI に大きく依存します。一部は他のものより復帰しやすく、OOM イベントの場合でもクラッシュせず動作が遅くなるだけの場合もあります。

Windows タスクマネージャー の [Performance (パフォーマンス)] タブを開くと、メモリ不足のクラッシュが発生する理由を把握できます。ここで、GPU を選択し (1)、その使用可能なメモリと現在消費している量を確認できます (2)。

Windows Task Manager - Performance tab showing available GPU memory versus current consumption.

使用可能なメモリと現在の消費量を含む、GPU の現在の統計を表示する Windows タスクマネージャー。

プロジェクトを開いて実行すると、使用可能な GPU メモリと消費されている GPU メモリの量を確認できます。使用可能なメモリの制限に近づいている場合、クラッシュの原因はそれである可能性が最も高いです。この場合、次のことを試してください。

大量の GPU メモリを消費している可能性がある他のプログラムを閉じる。
低解像度のテクスチャ、低解像度のメッシュ、シーン内のオブジェクトを減らすカリングなどを使用してシーンを単純化する。
低い画面解像度を使用する。
- エディタで作業している間は、レベルビューポートの [Screen Percentage (スクリーン比率)] を使用すると、より低い解像度でレンダリングできます。
エディタでの作業中に複数のビューポートを開いている場合、1 つを残してすべて閉じる。
Niagara やレイトレーシングなどの主要な機能を無効にしない。
- これらのコンポーネントをバイパスすると、多くのことが変更されます。それにより、GPU クラッシュの原因を誤解してしまう可能性があります。

GPU タイムアウトを理解して解決する

CPU が何かを計算するために GPU にコマンドを送信すると、CPU はタイマーを設定して、GPU が操作を完了するのに必要な時間をカウントします。CPU が操作に時間がかかると判断した場合 (デフォルトでは、Windows では 2 秒)、ドライバがリセットされ、GPU クラッシュが発生します。これは、TDR イベント (またはタイムアウト検出および回復) と呼ばれます。

TDR イベントをトリガーするような量の作業をエンジンが GPU に送信しないようにするのが理想的です。代わりに、エンジンがタスクを小さなチャンクに分割して、TDR を回避できるような状態にする必要があります。これらのタイプのイベントを回避するには、Windows レジストリを編集して、タイムアウトが発生するまでの時間を長くします (「TDR イベントを解決する方法」については、以下の手順を参照してください)。

ハードウェアレイトレーシングを使用した TDR イベント

ハードウェアレイトレーシングはとりわけ負荷が重く、有効にすると TDR イベントをトリガーする可能性が高くなります。一部の高負荷なレイトレーシングパス (非常に高い解像度でのレイトレーシンググローバルイルミネーションなど) は、レンダリングに時間がかかり、TDR イベントをトリガーする可能性があります。

最も負荷の重いレイトレーシングパス (グローバルイルミネーションと反射) では、次のコンソール変数を使用して、単一のパスではなくタイルでパスをレンダリングできます。

r.RayTracing.GlobalIllumination.RenderTileSize
r.RayTracing.Reflections.RenderTileSize

パスのタイルサイズが 0 より大きい場合、これらのパスは N x N ピクセルタイルでレンダリングされ、各タイルは個別の GPU コマンドバッファとして送信されます。これにより、タイムアウト検出をトリガーすることなく、高品質のレンダリングが可能になります。

TDR イベントを解決する方法

TDR イベントを回避する 1 つの方法として、Windows レジストリキーを編集して、Windows が TDR イベントをトリガーするまでに必要な時間を増やすことがあります。このガイドでは、TdrDelay と TdrDiDelay という 2 つの新しいレジストリキーを作成します。

TdrDelay はタイムアウトのしきい値を設定します。これは、プロセッシングとメモリ (VRAM) を処理する GPU スケジューラからの割り込み要求を GPU が遅延させる秒数です。
TdrDdiDelay は、オペレーティングシステム (OS) がドライバから離れることをスレッドに対して許可する時間を設定します。設定した時間が経過すると、タイムアウト遅延エラーが発生します。

レジストリキーの詳細については、「Tdr レジストリキー」に関する Microsoft のドキュメントを参照してください。

Windows オペレーティングシステムのレジストリキーを変更すると、予期しない結果になり、Windows の完全な再インストールが必要になる場合があります。このチュートリアルに記載されているレジストリキーの追加または編集により、そういった結果になるわけではありませんが、作業を進める前にシステムのバックアップを作成することをお勧めします。Epic Games では、システムレジストリの変更によってシステムに生じたいかなる損害に対しても、一切責任を負いません。

グラフィックドライバに 2 つのレジストリキーを追加する必要があります。レジストリキーを追加するには、次の手順を実行します。

Windows オペレーティングシステムの検索バーに「run」と入力します。Run アプリケーションを開きます。
検索フィールドに「regedit」と入力します。[OK] をクリックして、レジストリ編集ツールを開きます。
レジストリ編集ツールの左側にあるナビゲーションの [GraphicsDrivers] セクションに移動します。これの場所は Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers です。

画像をクリックすると拡大表示されます。

レジストリキーは「GraphicsDrivers」フォルダに追加する必要があります。その子フォルダではありません。正しいフォルダを選択していることを確認します。
必要なレジストリキーは、TdrDelay という名称です。このレジストリキーがすでに存在する場合は、ダブルクリックして編集します。まだない場合は、右側のペインで右クリックして、[New (新規)] > [DWORD (32-bit) Value (DWORD (32 ビット) 値)] を選択します。
[Base (基数)] を [Decimal (10 進数)] に設定します。[TdrDelay] の [Value (値)] を「60」に設定します。[OK] をクリックして終了します。
TdrDdiDelay という 2 つ目のレジストリキーが必要です。このレジストリがすでに存在する場合は、ダブルクリックして編集します。まだない場合は、右側のペインで右クリックし、[New (新規)] > [DWORD (32-bit) Value (DWORD (32 ビット) 値)] を選択して作成します。
[Base (基数)] を [Decimal (10 進数)] に設定します。TdrDdiDelay の [Value (値)] を「60」に設定します。[OK] をクリックして終了します。
レジストリに TdrDelay および TdrDdiDelay の両方が含まれていることを確認します。

画像をクリックすると拡大表示されます。
レジストリエディタを閉じます。
これらの変更を反映させるためにコンピュータを再起動します。

これらのレジストリキーを追加したことで、Windows は、アプリケーションのプロセスに時間がかかりすぎていると判断するまで、60 秒間待機するようになります。

これはレンダリングに起因する GPU クラッシュを抑える適切な方法であるものの、これですべてのクラッシュが解決されるわけではありません。一度に非常に多くのデータを処理しようとすると、タイムアウト遅延をどんなに長く設定しても、GPU がタイムアウトする可能性があります。この解決策は、グラフィックカードに若干の追加時間を提供することのみを目的としています。