언리얼 엔진에서 크래시가 발생하면 먼저 어떤 상황인지 파악하는 데 도움이 되는 정보를 담고 있는 크래시 리포터의 콜스택과 로그 파일을 살펴보는 것이 좋습니다. 하지만 GPU 크래시가 발생하는 경우, CPU 콜스택은 원인을 직접 가리키지 않고 GPU 크래시 발생 당시 CPU가 수행하고 있었던 작업만을 알려줍니다. 따라서 CPU 콜스택은 실용적인 정보를 제공하지 않습니다.
이 페이지의 콘텐츠에서 설명하는 내용은 다음과 같습니다.
- GPU 크래시란?
- GPU 크래시를 식별하고 조사하는 방법
- 다양한 디버깅 툴로 처음부터 끝까지 GPU 크래시를 디버그하는 방법
- 타임아웃 탐지 및 복구(Timeout Detection and Recovery, TDR) 크래시를 해결하는 방법
GPU 크래시란?
공통적으로 GPU 크래시라 칭하는 두 가지 유형의 오류가 있습니다.
- GPU 타임아웃 은 드로 또는 디스패치 실행이 너무 오래 걸릴 때 발생합니다. Windows에는 TDR 이라는 메커니즘이 있어 명령이 특정 시간 이상 걸리는 경우 GPU를 재설정합니다(디폴트 값은 2초, 아래에 있는 GPU 타임아웃 이해 및 해결 섹션 참조). 이로 인해 모든 실행 중인 애플리케이션의 모든 기존 그래픽 컨텍스트에서 '디바이스 제거됨' 오류가 발생합니다.
- GPU 페이지 폴트 는 드로 또는 디스패치에서 사용할 수 없는 GPU 메모리를 읽으려 할 때 발생합니다. 이는 CPU 명령에서 물리적 RAM에 매핑되지 않은 메모리 위치에 액세스하려 할 때 발생하는 CPU 페이지 폴트(액세스 위반 또는 세그멘테이션 폴트라고도 함)와 비슷합니다.
GPU 크래시 인식
GPU 크래시가 탐지되면 엔진은 종료되고 이와 같은 대화창을 표시합니다.

디버거가 연결되면 디버거가 종료되기 전에 오류를 가져옵니다. 로그에는 다음과 비슷한 오류가 포함됩니다.
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
기본 원인은 같더라도 실패 함수와 소스 위치는 크래시마다 다를 수 있습니다. 애플리케이션에 비동기식으로 보고되므로 GPU 크래시의 원인을 조사하는 데 있어 오류가 발견된 CPU 콜스택은 영향을 미치지 않습니다.
디바이스 제거됨 오류와 다른 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 크래시가 발생하는 데에는 다음과 같은 여러 가지 이유가 있습니다.
- 콘텐츠 오류 의 예시로는 비나나이트 렌더링 경로를 사용한 초고밀도 메시 렌더링 시도, 머티리얼의 커스텀 HLSL 노드에서의 무한 루프, 또는 특정 조건에서 나이아가라 GPU 시스템이 실행에 너무 오랜 시간이 걸리는 것이 있습니다.
- 커스텀 렌더링 코드 의 비슷한 오류로 커스텀 패스의 매우 긴 루프가 렌더 종속성 그래프(Render Dependency Graph, RDG)에 추가되는 것이 있습니다.
- 기본 패스 실행 시간이 너무 길어지도록 하는 엔진 버그, 또는 페이지 폴트를 유발하는 잘못된 리소스 관리.
- GPU 드라이버 버그.
- GPU 과열과 같은 하드웨어 문제.
- VRAM 소진. 비디오 메모리는 Windows에서 가상화되므로 특히 여러 애플리케이션을 동시에 실행할 때 GPU에서 사용 가능한 것 이상으로 할당하는 것이 가능합니다. 하지만 VRAM 안팎으로 블록을 이동하는 속도는 느리고, 극단적인 상황에서 GPU 타임아웃을 유발할 수 있습니다.
- 다른 앱에서의 크래시. 위에 설명한 것과 비슷하게 GPU 타임아웃은 현재 실행 중인 모든 것을 무효화하기에 다른 애플리케이션이 크래시를 유발하면 엔진에서도 크래시가 발생합니다.
에픽게임즈로 GPU 크래시를 어떻게 보고하나요?
GPU 크래시를 보고할 때 렌더링 팀으로 가능한 많은 정보를 제공할 수 있도록 몇 가지 가이드라인이 마련되어 있습니다.
- GPU에 사용 가능한 최신 드라이버를 사용하세요.
- 제조업체에서 이미 수정한 드라이버 버그를 방지하는 데 도움이 됩니다. 드라이버가 최신 상태인지 확인하는 데 있어 Windows 업데이트나 벤더 툴에 의존하지 마세요. 항상 제조업체 웹사이트를 확인하세요.
- 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/en-us/geforce/drivers/
- 보고 시 전체 로그를 포함하세요.
- 마지막 10개 에디터 세션의 로그가 프로젝트 디렉터리의
Saved/Logs
하위 디렉터리에 보관됩니다. 크래시 발생 시 가장 최근의 파일이 로그가 됩니다.
- 마지막 10개 에디터 세션의 로그가 프로젝트 디렉터리의
- GPU 크래시와 일반 크래시를 구분하세요.
- 최근 로그를 살펴보고
DXGI_ERROR_DEVICE_REMOVED
또는 다른 오류 코드가 언급되어 있는지 확인하세요. 모든 크래시가 보고되어야 하지만 분류를 위해 처음부터 다른 문제와 GPU 크래시를 구분하여 식별하는 것이 중요합니다.
- 최근 로그를 살펴보고
- GPU 크래시 재현이 가능하도록 디버그 로그를 포함하세요.
- 어느 정도 확실하게라도 크래시 재현이 가능한 경우 명령줄 실행인자
-gpucrashdebugging
를 추가하고 크래시 발생을 트리거하세요. 이를 통해 플래그가 있을 때 문제를 식별하는 데 유용한 정보가 엔진 로그에 추가됩니다. - Aftermath 덤프 파일 이 생성된 경우 보고에 포함하는 것이 유용합니다. 이 파일은 NVIDIA GPU에서 실행할 때에만 생성됩니다. 로그에서 'Writing Aftermath dump to: [PATH]' 줄을 찾아 덤프 파일이 쓰여진 위치를 확인하세요.
- 어느 정도 확실하게라도 크래시 재현이 가능한 경우 명령줄 실행인자
- 크래시 재현 방법에 관하여 가능한 한 많은 정보를 포함하세요.
- 크래시 재현으로 이어진 단계 또는 작업을 포함하세요. 추가로 문제를 단순하고 자체적인 프로젝트로, 또는 언리얼 엔진에 포함된 에픽의 자체 샘플 프로젝트로 격리할 수 있다면 엔지니어가 크래시를 조사하고 해결하는 데 도움이 될 수 있습니다.
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
인 경우 다른 애플리케이션에 의해 크래시가 발생했을 가능성이 높으니 언리얼 엔진과 동시에 다른 3D 앱을 실행하지 않도록 하는 것 외에 별도로 필요한 조치가 없습니다. 이유 코드를 완전히 신뢰할 수는 없지만 대부분의 경우에는 확인할 가치가 있습니다.
로그와 이유로 다른 원인을 배제할 수 없는 경우 크래시 유발에 콘텐츠 또는 엔진 버그를 의심할 수 있습니다. 빌드와 런타임 환경설정에 따라 어느 정도의 GPU 크래시 디버그 로깅이 이미 활성화되어 있을 수 있습니다. '디바이스 제거됨 오류'가 보고된 이후 로그의 끝을 살펴보고 디버그 로깅이 포함되어 있는지 확인합니다.
DirectX 11(DX11) 관련 GPU 크래시의 경우 대부분이 조치를 취할 수 없습니다. 명시적 메모리 관리가 없으므로 페이지 폴트는 이론상 불가능합니다. 페이지 폴트가 발생한 경우 드라이버 버그가 원인입니다. 하지만 크래시 유형이 애플리케이션에 표시되지 않았습니다. NVIDIA GPU에서 크래시가 발생하고 Aftermath가 활성화된 경우 Aftermath 덤프 파일을 NVIDIA Nsight Graphics 개발자 툴에서 열어 어떤 패스에서 크래시가 발생했는지 확인할 수 있습니다. 다른 GPU 벤더의 경우 GPU 크래시를 디버그할 방법이 없는데, 안정적으로 재현이 가능한 경우를 제외하면 에픽게임즈에서 디버그할 방법이 없습니다. 이 경우 디버그 방법은 의심스러운 패스를 찾아낼 때까지 패스를 비활성화하고, 특정 패스가 어떻게 GPU 행을 유발할 수 있는지 이해하는 것입니다.
DirectX 12(DX12)는 여러 가지 디버그 정보 소스를 제공합니다. 첫 번째는 RHI Breadcrumb 입니다. 여기에서 엔진은 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]
태그가 표시되어 있습니다. 이러한 셰이더를 조사하여 무엇이 행(hang)을 유발하는지 확인해야 합니다.
이 경우 문제는 GPUDebugCrash_DirectQueue_Hang
패스입니다. 디버그 코드가 작동하는지 확인하기 위해 의도적 크래시를 트리거하는 데 사용되는 콘솔 명령 GPUDebugCrash hang
에 의해 추가되었습니다.
다음 소스는 Microsoft의 Device Removed Extended Data API, 즉 DRED 입니다. RHI Breadcrumb과 비슷한 메커니즘을 사용하지만 이 유형의 오류가 발생할 때 페이지 폴트 주소를 보고할 수도 있습니다. 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 Breadcrumb과 달리 활성인 명령과 아직 시작되지 않은 명령을 당장 구분할 방법은 없습니다.
DRED에는 Lightweight 와 Full 모드가 있습니다. Lightweight 모드는 엔진에서 보내는 마커만을 사용하고, 이는 RHI Breadcrumb에서 사용하는 것과 같은 정보 소스입니다. Full 모드는 모든 렌더링 명령(예: Draw, Dispatch, Barrier 등)에 마커를 삽입하는 동시에 엔진에서 보내는 엔진 마커를 포함합니다. Full 모드는 더 많은 정보를 제공하지만 GPU의 퍼포먼스에 더 큰 영향을 미칩니다. 문제를 추적하는 데 있어 Lightweight 모드로도 대체로 충분합니다.
콘솔 변수 D3D12.TrackAllAllocations
가 활성화되면 RHI는 활성 리소스에 대한 주소 범위와 마지막 100개 프레임에서 사용 가능한 리소스를 추적합니다. DRED는 또한 (콘솔 변수와 무관하게) 비슷한 정보를 저장합니다. 페이지 폴트가 발생하면 이 범위 목록에서 폴트 주소를 비교하고, 그에 따라 어떤 리소스가 당시에 액세스되고 있었는지 보고할 수 있습니다. 다음은 RHI Breadcrumb의 출력 예시입니다.
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에서 발생할 때 Aftermath에서 정보를 추출할 수 있습니다. 이 정보는 폴트의 유형(Timeout 또는 PageFault)은 물론 오류가 트리거된 패스를 보고합니다. 여기에서는 Aftermath로부터 추출된 정보가 RHI Breadcrumb과 유사하게 계층형이고, 씬 패스 계층구조의 경로를 보여줍니다.
[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
Aftermath는 DX11에서 GPU 크래시 덤프 파일을 생성하고, 이는 Nsight에서 열 수 있습니다. Nsight는 문제를 유발한 셰이더에서 디버그 정보가 활성화된 경우 문제가 발생한 소스 위치를 보여줄 수 있습니다.
이러한 디버깅 기능은 다음 명령줄 실행인자와 콘솔 변수로 제어됩니다.
디버깅 기능 | 명령줄 플래그 | 콘솔 변수 |
---|---|---|
RHI Breadcrumbs | -gpubreadcrumbs |
r.GPUCrashDebugging.Breadcrumbs |
Full DRED | -dred |
r.D3D12.DRED |
Lightweight DRED | -lightdred |
r.D3D12.LightweightDRED |
Aftermath | -nvaftermath |
r.GPUCrashDebugging.Aftermath |
Everything ON | -gpucrashdebugging |
r.GPUCrashDebugging=1 |
Everything OFF | -nogpucrashdebugging |
— |
기능별 명령줄 플래그는 선택적으로 =0 또는 =1 실행인자를 수락하여 기능의 상태를 명시적으로 지정합니다. 플래그만 사용하면 기능이 활성화되므로 '=1'과 동일합니다. 명령줄 실행인자가 콘솔 변수보다 우선합니다.
특정 기능을 포함 또는 제외하기 위해 Everything ON 또는 OFF를 전환하는 플래그를 다른 플래그와 결합할 수 있습니다. 예를 들어 -gpucrashdebugging -gpubreadcrumbs=0
을 사용하면 RHI Breadcrumb을 제외한 모든 게 활성화되고, -nogpucrashdebugging -dred
는 Full DRED만 활성화하고 나머지는 비활성화합니다.
위 디버깅 기능을 사용할 때 다음과 같이 퍼포먼스에 미치는 영향을 고려하세요.
- RHI Breadcrumb과 Lightweight DRED는 무시할 수 없는 GPU 퍼포먼스 비용이 발생할 수 있기에 엔진 디폴트 세팅에 따르면 디버그 및 개발 빌드에서만 이를 활성화합니다.
- Full DRED는 퍼포먼스에 상당한 영향을 미치기에 모든 빌드 환경설정에서 기본적으로 비활성화됩니다.
- Aftermath는 퍼포먼스 비용이 없고 항상 지원되는 GPU에서 활성화됩니다.
이러한 디폴트 세팅은 각 프로젝트에서 변경될 수 있습니다.
GPU 메모리 부족 문제 해결하기
GPU 메모리가 부족하면 크래시가 발생할 가능성이 있습니다. 메모리 부족은 사용하는 RHI에 따라 크게 좌우됩니다. 어떤 RHI는 특히 회복력이 있기 때문에 OOM 이벤트 발생 시 중단되는 것이 아니라 느려지기도 합니다.
메모리 부족 크래시가 발생할 수 있는 이유를 이해하려면 먼저 Windows 작업 관리자 의 성능 탭을 확인해야 합니다. 우선 GPU를 선택(1)하고 가용 메모리와 현재 소모되고 있는 메모리를 확인(2)합니다.

GPU의 가용 메모리와 현재 메모리 소모량을 비롯한 현재 상태가 표시되어 있는 Windows 작업 관리자.
프로젝트를 열고 실행하면 가용 메모리 대비 얼마나 많은 GPU 메모리가 소모되는지 확인할 수 있습니다. 가용 메모리 한계치에 가까워졌다면 메모리 부족이 크래시의 원인일 가능성이 높습니다. 이 경우 아래 방법을 시도해 보시기 바랍니다.
- GPU 메모리를 많이 소모할 수 있는 다른 프로그램을 닫습니다.
- 저해상도 텍스처 사용, 저해상도 메시 사용, 컬링을 통한 씬 오브젝트 줄이기 등의 방법으로 씬을 간소화합니다.
- 화면 해상도를 낮춥니다.
- 에디터에서 작업하는 동안 레벨 뷰포트의 화면 퍼센티지(Screen Percentage) 를 사용하여 저해상도로 렌더링할 수 있습니다.
- 에디터에서 작업하는 동안 여러 뷰포트가 열려 있다면 하나만 남기고 모두 닫습니다.
- 나이아가라, 레이 트레이싱 등 주요 기능을 비활성화하는 것은 피합니다.
- 이러한 컴포넌트를 우회하면 많은 변경 사항이 발생하기 때문에 GPU 크래시의 원인과 관련해 유효하지 않은 결론이 도출될 수 있습니다.
GPU 타임아웃 이해 및 해결하기
CPU는 GPU에게 컴퓨팅 명령을 전송할 때 타이머를 설정해서 GPU가 연산을 완료하는 데 필요한 시간을 측정합니다. 연산에 소요되는 시간이 너무 길어지면 CPU는 드라이버를 초기화하고, GPU 크래시가 발생하게 됩니다. Windows의 디폴트 타임아웃 시간은 2초입니다. 이 현상을 TDR 이벤트 또는 타임아웃 감지 및 복구라고 합니다.
이상적으로 엔진이 GPU에 TDR 이벤트가 발생할 정도의 작업량을 전송해서는 안 됩니다. 대신 엔진은 TDR을 피하기 위해 작업을 작은 청크로 분할할 수 있어야 합니다. Windows 레지스트리를 편집하여 타임아웃이 발생하기까지 걸리는 시간을 늘리면 TDR 이벤트를 방지할 수 있습니다. 자세한 방법은 아래의 TDR 이벤트 해결 방법을 참조하시기 바랍니다.
하드웨어 레이 트레이싱과 TDR 이벤트
하드웨어 레이 트레이싱은 특히 비용이 높기 때문에 활성화 시 TDR 이벤트를 유발할 가능성이 더 높습니다. 아주 높은 해상도의 레이 트레이싱 글로벌 일루미네이션처럼 비용이 높은 일부 레이 트레이싱 패스는 렌더링에 소요되는 시간이 길어 TDR 이벤트를 유발할 수 있습니다.
글로벌 일루미네이션, 리플렉션 등 비용이 가장 높은 레이 트레이싱 패스의 경우에는 아래와 같은 콘솔 변수를 사용하여 패스를 하나의 패스가 아닌 여러 타일로 렌더링할 수 있습니다.
r.RayTracing.GlobalIllumination.RenderTileSize
r.RayTracing.Reflections.RenderTileSize
패스의 크기가 0보다 크면 패스가 N x N 픽셀 크기의 타일로 렌더링되고, 각 타일은 별도의 GPU 명령 버퍼로 제출됩니다. 이 방법을 사용하면 타임아웃 감지 없이 높은 퀄리티로 렌더링을 수행할 수 있습니다.
TDR 이벤트 해결 방법
TDR 이벤트를 피하는 방법 중 하나는 Windows 레지스트리 키를 편집하여 Windows가 TDR 이벤트를 발동시키기까지 걸리는 시간을 늘리는 것입니다. 이 가이드에서는 두 개의 레지스트리 키를 새로 생성합니다. 바로 TdrDelay 및 TdrDiDelay 입니다.
-
TdrDelay
는 타임아웃 한계치를 설정합니다. 이 레지스트리 키는 GPU에서 프로세싱과 메모리(VRAM)를 처리하는 GPU 스케줄러의 선점 요청이 지연되는 시간을 초 단위로 나타냅니다. -
TdrDdiDelay
는 운영체제(OS)에서 스레드가 드라이버를 빠져나가는 데 주어지는 시간을 설정합니다. 이 시간이 지나면 타임아웃 딜레이 오류가 발생합니다.
레지스트리 키에 대한 자세한 정보는 TDR 레지스트리 키에 대한 Microsoft 문서를 참조하세요.
Windows 운영체제에서 레지스트리 키를 변경하면 예상하지 못한 결과로 Windows 전체를 다시 설치해야 할 수 있습니다. 이 튜토리얼에 따라 레지스트리 키를 추가하거나 편집하는 경우 이러한 문제가 발생하지 않지만, 만약을 대비해 미리 시스템을 백업해 두는 것을 권장합니다. 에픽게임즈는 시스템 레지스트리 수정에 따라 발생하는 시스템 손상에 대해 책임지지 않습니다.
그래픽 드라이버에는 두 개의 레지스트리 키를 추가해야 합니다. 아래 단계에 따라 레지스트리 키를 추가합니다.
-
Windows 운영체제 검색창에 실행(run) 을 입력합니다. 실행 애플리케이션을 엽니다.
-
검색 필드에 'regedit' 를 입력합니다. 예(OK) 를 누르면 레지스트리 편집기가 열립니다.
-
레지스트리 편집기 왼쪽에 있는 GraphicsDrivers 섹션으로 이동합니다. 위치는
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
입니다.이미지를 클릭하면 최대 크기로 볼 수 있습니다.
GraphicsDrivers 폴더에 레지스트리 키를 추가합니다. 하위 폴더에 추가하지 않도록 유의하세요. 올바른 폴더를 선택해야 합니다.
-
추가해야 하는 레지스트리 키는
TdrDelay
입니다. 레지스트리 키가 이미 존재한다면 키를 더블클릭한 후 편집합니다. 레지스트리 키가 없다면 오른쪽 패널을 우클릭하고 새로 만들기(New) > DWORD(32비트) 값(DWORD (32-bit) Value) 을 선택합니다. -
단위 는 10진수 로 설정합니다. TdrDelay의 값(Value) 은 60 으로 설정합니다. 확인 을 클릭해 완료합니다.
-
두 번째로 추가할 레지스트리 키는
TdrDdiDelay
입니다. 레지스트리 키가 이미 존재한다면 키를 더블클릭한 후 편집합니다. 레지스트리 키가 없다면 오른쪽 패널을 우클릭하고 새로 만들기 > DWORD(32비트) 값 을 선택해 생성합니다. -
단위 는 10진수 로 설정합니다.
TdrDdiDelay
의 값 은 60 으로 설정합니다. 확인 을 클릭해 완료합니다. -
이제 레지스트리에
TdrDelay
와TdrDdiDelay
가 추가되었습니다.이미지를 클릭하면 최대 크기로 볼 수 있습니다.
-
레지스트리 편집기를 닫습니다.
-
컴퓨터를 재시작하면 변경 사항이 적용됩니다.
위 레지스트리 키를 추가하면 60초가 지나야 Windows가 애플리케이션의 프로세스에 너무 오랜 시간이 걸린다고 판단합니다.
이 방법은 렌더링으로 인한 GPU 크래시를 피하는 데 효과적이지만 모든 크래시를 해결해 주지는 않습니다. 한 번에 너무 많은 데이터를 처리하려고 하면 타임아웃 딜레이에 설정한 시간과 관계없이 GPU 타임아웃이 발생할 수 있습니다. 이 해결책은 그래픽 카드의 처리 시간을 좀 더 확보해 주기 위한 용도로만 만들어졌습니다.