(Game Dev Study) Grahpics - nsight-graphics

nsight-graphics 란?

https://developer.nvidia.com/nsight-graphics

Nsight Graphics는 NVIDIA에서 제공하는 그래픽 디버깅 및 프로파일링 툴로, 게임 개발이나 그래픽 애플리케이션 개발에서 성능 최적화와 문제 해결을 돕는 도구입니다.

  • 프레임 분석: 개별 프레임을 세밀하게 분석하여 렌더링 파이프라인의 각 단계에서 발생하는 성능 병목을 파악할 수 있습니다.
  • 셰이더 디버깅: 셰이더 코드를 실시간으로 디버깅하고 성능을 분석할 수 있어, 비효율적인 셰이더나 그래픽 문제를 빠르게 찾아 해결할 수 있습니다.
  • GPU 성능 분석: GPU 사용량과 자원 분배를 분석해 성능 병목을 파악하고, 멀티스레딩 및 CPU와 GPU 간의 효율적인 작업 분배를 돕습니다.
  • 메모리 분석: GPU 메모리와 VRAM 사용을 추적하여 메모리 누수나 과도한 사용을 발견하고, 리소스 최적화를 지원합니다.
  • API 호출 추적: DirectX, Vulkan, OpenGL 등 다양한 그래픽 API 호출을 추적하여 비효율적인 패턴을 찾고 수정할 수 있습니다.
  • 프레임 리플레이: 문제가 있는 프레임을 저장하고 나중에 재생하여, 렌더링 오류나 크래시 문제를 효과적으로 디버깅할 수 있습니다.
  • 실시간 성능 모니터링: 게임 실행 중 HUD와 성능 그래프를 통해 성능 상태를 실시간으로 확인하고 최적화 포인트를 찾을 수 있습니다.

nsight-graphics으로 분석할 수 있는 것

홈페이지에서 소개하고 있는 내용을 먼저 살펴보겠습니다.

Track GPU Performance
최소한의 오버헤드로 GPU 처리량과 사용률을 분석하여 편향되지 않은 활동 데이터를 수집합니다.
캡처된 타임라인에서 중요한 성능 마커를 세부적으로 분석하고, 하드웨어 유닛의 처리량, 캐시 적중률, 메모리 처리량 등을 검사할 수 있습니다.

Analyze GPU Traces
Nsight Graphics는 캡처된 GPU 추적에 대한 자동 성능 분석을 지원합니다.
스트리밍 멀티프로세서(SM) 성능에 대한 심층 프로파일링은 여러 프레임에 걸친 셰이더 실행을 자동으로 추적하여 이루어집니다.

Debug Ray-Tracing and Shaders
레이 트레이싱 API 호출을 디버깅하고 상태를 검사할 수 있습니다. Ray Tracing Inspector는 가속 구조를 노출하여 씬의 지오메트리와 레이의 교차를 최적화하는 데 도움을 줍니다.
또한 레이 트레이싱의 효율성을 확인하여 레이 탐색 속도가 높은지 확인할 수 있습니다.

Vulkan 셰이더 디버거를 통해 셰이더 코드를 디버깅할 수 있으며, 이를 통해 렌더 파이프라인에서 실시간으로 셰이더 소스를 확인하고 직접 수정할 수 있습니다.

Profile Ray-Tracing Shaders
Nsight Graphics의 셰이더 프로파일러는 셰이더 데이터를 노출하여, 정체 현상과 그 원인을 파악할 수 있게 합니다.
실시간 셰이더 프로파일러는 실시간으로 가장 비용이 많이 드는 셰이더를 확인할 수 있습니다.
셰이더 타이밍 히트맵은 픽셀별로 셰이더 처리 시간 지연이 발생한 부분을 씬에 겹쳐 시각화합니다.

레이 트레이싱 셰이더의 프로파일링은 GPU에 대한 광범위한 지식을 요구하는 복잡한 작업이지만, 이러한 기능을 통해 프로파일링 과정을 간소화하고 직관적으로 만들 수 있습니다.

Export C++ Capture
CPU 부하가 적은 환경에서 프레임 분석을 수행할 수 있는 독립된 C++ 프로젝트를 생성합니다.
이를 통해 원래의 애플리케이션에 구속되지 않고 반복 가능한 고립된 분석을 수행할 수 있으며, 최적화 실험을 안전하게 진행할 수 있는 보호된 환경을 제공합니다.

요약해보면… 아래 정도겠군요.
“GPU 성능 분석, 셰이더 및 레이 트레이싱 디버깅, 실시간 프로파일링을 통해 게임 및 그래픽 애플리케이션 개발에서 최적화와 문제 해결을 돕는 도구”

살짝 사용해본 경험

  • 테스트해볼 테스트 프로그램을 찾고 실행하는데 까지 뭔가 어렵다는 느낌은 있었습니다만 실행은 해보았어요.
  • Nsight Graphics를 실행 -> Start Activity 할때 사용할 프로그램을 선택하고 실행하면 알아서 프로파일링 툴이 프로그램에 붙습니다.
  • 프레임 디버깅을 실행했을 때, 렌더링 이벤트에 따라 어떤 API들이 호출되는지 디버깅할 수 있네요. (사실 봐도 어떤 내용인지 모르겠음)
  • Draw, Command 실행 등 눈에 띄는 이벤트나 API들을 확인할 수 있었습니다.


Nvidia 예시로는 이렇게도 다 볼 수 있다는데… 툴 창에서 이것저것 더 만져봤어야하나봅니다 😂

Nvidia 그래픽카드에서 동작할 경우 그래픽스 디버깅에 사용할 수 있는 툴로 사용해볼 수 있겠네요.
(AMD 그래픽카드에서 사용할 수 있는지는 모르겠군요)
엔비디아가 하드웨어 레이 트레이싱을 밀고 있어서 이 툴에도 레이 트레이싱 디버깅과 관련한 기능이 좀 있다는 생각도 들었습니다.

짧게 살펴보고 이만 마치겠습니다 😁

가이드 문서, 자료

다른 그래픽스 분석 툴

언리얼 엔진 5 5.4 업데이트 소식

언리얼 엔진 5 소식

소개: https://www.unrealengine.com/ko/blog/unreal-engine-5-4-is-now-available?tags=games
상세 릴리스 노트: https://dev.epicgames.com/documentation/ko-kr/unreal-engine/unreal-engine-5.4-release-notes

지난 4월, 언리얼엔진 5.4 출시 이후 내용 정리는 다소 늦은 감이 있지만 공부차원에서 정리해봅니다.

주요하게 다룬 내용은 다음과 같습니다. 영상도 참고해보시면 좋을 것 같아요.
https://youtu.be/1vsb7egA7LQ?si=s1uLgP_NpQo59atK

  1. 나나이트 테셀레이션과 렌더링 개선: 나나이트 테크놀로지를 통해 실시간으로 영화 수준의 3D 퀄리티를 제공하며, 데이터 사이즈 최적화와 함께 다양한 디테일 생성이 가능해졌습니다.
  2. 렌더러 병렬성 향상: 렌더링 시간과 GPU 사용 시간 감소로 인한 컨텐츠 렌더링 부분에서의 큰 최적화로, 엔진만 업데이트해도 프레임 속도가 향상됩니다.
  3. 생동감 있는 환경 및 캐릭터: 애니메이션과 관련된 다양한 기능이 추가되어, 특히 모션 매칭 기능을 통해 자연스러운 캐릭터 이동 및 애니메이션이 가능해졌습니다.
  4. 애니메이션 데이터 및 메타 휴먼 호환: 500개 이상의 애니메이션 클립 준비 중이며, 메타 휴먼과의 호환을 통해 다양한 캐릭터 모션 제작이 가능해집니다.
  5. 사운드와 물리 엔진 개선: 메타 사운드 기능과 더불어, 물리 엔진 관련 기능의 개선을 통해 더 자연스러운 게임 환경 구현이 가능해졌습니다.
  6. 프로시저러 콘텐츠 생성(PCG) 툴의 개선: 대규모 맵 생성을 위한 PCG 기능이 향상되어, 넓은 영역을 퀄리티 저하 없이 절차적으로 채울 수 있게 되었습니다.
  7. 생산성 향상 도구: 애니메이션, 캐릭터 제작, 키프레임 작업의 유용성 향상과 함께, 컨트롤 리그와 스켈레탈 편집 기능의 강화로 생산성이 크게 개선되었습니다.
  8. 클라우드 기반 개발 지원 강화: 언리얼 클라우드 서비스와 분산 빌드 시스템을 통해 팀워크와 협업이 강화되었습니다.

나나이트 테셀레이션

나나이트는 원래 고해상도 메쉬를 효율적으로 처리하여 성능을 유지하면서도 세밀한 디테일을 제공하는 기술인데
5.4 버전에서 추가된 테셀레이션 기능은 이를 기반으로 더욱 세밀하게 폴리곤을 동적으로 추가하여, 특히 멀리서 보거나 낮은 LOD 단계에서도 자연스럽고 부드러운 표면을 유지하도록 합니다.

주요하게는 실시간 렌더링 성능 향상 항목으로 “기존의 테셀레이션 방식은 높은 성능을 요구했지만, 나나이트 테셀레이션은 이러한 성능 부담을 나나이트 엔진의 효율적인 처리 메커니즘을 통해 경감시킵니다.”
테셀레이션 기술을 나나이트에서 지원해서 더 고해상도 메쉬를 잘 처리해보겠다는 것으로 이해했습니다.

테셀레이션 적용 전후 예시

컴퓨터 그래픽스에서 테셀레이션이란?
GPU 파이프라인이 처리하는 기하적인 개체를 프리미티브(Primitive)라고 하는데, 하나의 프리미티브를 여러 개의 작은 프리미티브로 잘게 나누는 것을 “테셀레이션(Tessellation)”이라고 한다.
**테셀레이션(Tessellation)**은 기본적으로 3D 모델을 구성하는 폴리곤(주로 삼각형)을 더 작은 단위로 세분화하여 더욱 세밀한 디테일을 표현하는 기술. 이 과정은 그래픽 하드웨어(GPU)에 의해 수행되며, 더 정교한 모델을 만들거나 실시간 렌더링 시 고해상도 그래픽을 구현할 때 주로 사용됨.
좋은 참고 블로그 링크: https://choi-dan-di.github.io/computer-graphics/surface-tessellation/

-> 아무튼 정리해보면 나나이트를 이용할 때에 더 고해상도의 메쉬를 보여주는 업데이트

생동감 있는 환경 및 캐릭터

“이전 버전에서 실험단계 기능으로 도입되었던 모션 매칭이 이제 정식 버전으로 제공됩니다. 이 기능은 포트나이트 배틀 로얄에서 철저한 테스트를 거쳐 모바일부터 콘솔까지 모든 플랫폼에서 100개 이상의 캐릭터와 NPC에 적용되었습니다.”

이번 5.4 버전 부터 모션 매칭이 들어가면서 더 자연스러운 애니메이션 연결 동작을 구현할 수 있게되었네요.
에픽에서는 애니메이터에게 친화적인 툴세트를 만드는게 중점이었다고 합니다.

프로시저러 콘텐츠 생성(PCG) 툴의 개선

PCG 노드 그래프의 UX 개선 및 노드, 연산자 추가 등 툴 개선이 이뤄졌네요. 주요하게는…

1. 향상된 노드 기반 그래프 시스템
PCG 툴은 기본적으로 노드 기반 그래프 시스템을 사용해 콘텐츠를 절차적으로 생성합니다.
이번 업데이트에서는 노드 인터페이스가 더욱 직관적이고 효율적으로 개선되었습니다.
개발자들은 노드를 연결하고 콘텐츠의 흐름을 정의하는 작업을 더 빠르고 쉽게 할 수 있게 되었습니다.

  • 새로운 노드 추가: 더 다양한 절차적 생성 작업을 수행할 수 있는 새로운 노드가 추가되었습니다.
    • 이를 통해 지형 생성, 오브젝트 배치 등의 작업을 더 복잡하고 정교하게 구성할 수 있습니다.
  • 개선된 노드 미리보기 기능: PCG 그래프 내에서 각각의 노드가 어떻게 작동할지를 실시간으로 미리 볼 수 있는 기능이 개선되었습니다.
    • 이를 통해 생성 과정 중 오류를 줄이고, 수정 사항을 즉각적으로 확인할 수 있습니다.

2. 속도 및 성능 향상
PCG 툴의 성능이 대폭 향상되었습니다. 복잡한 절차적 콘텐츠를 생성하는 작업에서도 이전보다 더 빠르고 효율적으로 처리할 수 있게 되었습니다.
특히 대규모 맵에서 많은 오브젝트를 절차적으로 배치할 때 성능 이슈가 크게 줄어들었습니다.

  • 멀티스레딩 최적화: PCG 시스템이 멀티스레딩을 더 효율적으로 사용하도록 최적화되어, 콘텐츠 생성 속도가 향상되었습니다.
    • 대규모 오브젝트를 생성하거나 배치할 때도 퍼포먼스 저하 없이 작업할 수 있습니다.

3. 블루프린트 및 데이터와의 통합 강화
PCG 툴은 이제 블루프린트 및 데이터 자산과 더 긴밀하게 통합되어, 개발자들이 절차적 콘텐츠를 더 유연하게 제어할 수 있게 되었습니다.
이를 통해 다양한 외부 데이터나 게임 로직을 PCG 프로세스에 쉽게 적용할 수 있습니다.

  • 블루프린트와의 상호작용: PCG에서 생성된 콘텐츠가 블루프린트를 통해 더 세밀하게 제어될 수 있으며, 이를 통해 동적으로 변화하는 콘텐츠를 게임 내에서 쉽게 적용할 수 있습니다.
  • 데이터 에셋 기반 생성: 데이터 에셋을 기반으로 콘텐츠를 생성할 수 있어, 게임 내 데이터에 맞춘 유동적인 콘텐츠 생성을 구현할 수 있습니다.

4. 더 나은 디버깅 및 프로파일링 도구
절차적 생성의 복잡성을 해결하기 위한 디버깅 및 프로파일링 도구가 강화되었습니다.
개발자는 생성된 콘텐츠의 흐름을 시각적으로 확인할 수 있으며, 특정 절차가 어떻게 실행되고 있는지 더 명확하게 분석할 수 있습니다.

  • 실시간 디버깅: 생성 과정에서 발생할 수 있는 오류나 비효율성을 실시간으로 확인할 수 있습니다.
  • 프로파일링 도구 개선: PCG 작업의 성능을 분석하고, 어디에서 병목이 발생하는지 쉽게 파악할 수 있도록 도구가 업데이트되었습니다.

5. 배치 시스템 개선
PCG 툴의 배치 시스템이 더욱 정교해졌습니다.
특히 랜드스케이프나 지형 위에 절차적으로 오브젝트를 배치하는 과정에서, 더 자연스럽고 현실적인 배치가 가능해졌습니다.

  • 랜드스케이프와의 통합 강화: 랜드스케이프(지형)와의 상호작용이 개선되어, 지형 위에 오브젝트를 절차적으로 배치할 때 더 정교한 배치가 가능합니다.
  • 배치 규칙 추가: 지형의 높이, 기울기, 텍스처 등을 기준으로 오브젝트를 배치할 수 있는 더 많은 규칙들이 추가되었습니다.

PCG에서 주요한 것은 콘텐츠를 얼마나 생산성을 올릴 수 있는가,
절차적 생성을 통해 여러가지 에셋을 만들고 반복적인 작업을 덜어낼 수 있는가에 있는 것 같네요.
지금도 PCG를 하는중에 디버깅이 어렵거나 원하는 방향대로 안되는 경우가 많을거라 지속 개선이 필요하기도 합니다.

클라우드 기반 개발 지원 강화

이번 업데이트에는 클라우드 기반의 DDC(파생 데이터 캐시) 호스팅 시스템 등 개발 생산성, 관리 효율을 올리는 업데이트가 많았던 것 같습니다.

추가로 언리얼 빌드 액셀러레이터(Unreal Build Accelerator, UBA)를 선보여 분산 빌드 솔루션도 생겼네요.
그동안은 인크레디빌드나 SN-DBS를 쓰는 개발사가 많았는데 얼마나 사용하게 될지 궁금해집니다.

(Game Dev Study) Deterministic packaging

짧은 개발 공부 - 디터미니스틱 패키징, 디터미니스틱 쿠킹

언리얼 한정 이슈인지는 모르겠으나 빌드를 생성한 뒤에 패치할 때 변경된 내역에 따라 발생하는 업데이트/패치 사이즈와 연관된 내용입니다.

빌드 생성시 패키징할 때마다 애셋이 변경되지 않아도 패키지가 변경되는 경우가 있습니다.

이런 경우에 패키지가 In-deterministic(인디터미니스틱, 해석: 비결정론적)하다고 표현하고 Deterministic(해석: 결정론적)할 수 있도록 패키징 중에 어떤 일이 일어나는지 분석, 수정합니다.

패키지가 Deterministic하다면 매 업데이트 마다 빌드의 변경 내역이 줄어들고 패치 사이즈가 줄어들겠죠.

디터미니스틱(결정론적이라는 표현보다는 이렇게 표현하는게 더 좋은 것 같네요) 패키징이 안되는 이유, 인디터미니스틱하게 패키징이 되는 원인은 주로 어떤 것이 있을지 살짝 살펴보면..

(주요 원인) 매 빌드, 패키징마다 애셋, 애셋과 연관된 데이터들이 변경된다

  • 레퍼런스가 변경되었으나 패키징 과정에서 경로 해석에 따라 변경
  • 데이터테이블 데이터 중 파일 경로를 사용하는 경우, 입력된 파일 경로와 실제 파일 경로가 다르지만 대소문자 정도의 차이일 경우 해석에 따라 패키징 타임에 해석되어 패키징될 경우 변경

언리얼 커뮤니티 아티클

https://dev.epicgames.com/community/learning/knowledge-base/oDGP/unreal-engine-deterministic-builds-and-cooking

아티클에서는 Non deterministic이라는 표현을 쓰고 있는데 동일하게 패키지를 하면서 바뀌는 것의 설명이라 동일하다고 볼 수 있을 것 같네요.

에픽 게임즈가 해결해야하는 부분과 개발사가 해결해야하는 문제를 나눠서 볼 수 있는데 개발사 해결해야하는 내용 중심으로 보겠습니다.

One issue we have seen in the past is that some third party tools can cause deterministic cooking errors. One example was a code integration from a third party that added a globally unique identifier (GUID) to Primitive Components, but regenerated it each time. This caused level files to have deterministic cooking problems, and patch sizes to increase dramatically.

써드 파티 툴에 의해서 컴포넌트에 ID가 변경되는 케이스가 있었고 그에 따라 패키지가 변경되는 케이스가 있었다고 하네요.
툴, 플러그인을 사용할 경우 주의해야하는 영역이겠네요.

다른 하나가 더 있는데 항목이 길어서 요약해보면..

프로젝트 측 로직으로 인해 비결정적 쿠킹 문제가 발생할 수 있습니다. 예를 들어, C++에서 직렬화된 변수에 결과가 저장되는 비결정적 행동을 가진 블루프린트 노드를 정의하고, 이를 블루프린트 구성 스크립트에서 호출하는 경우가 있습니다. 이러한 스크립트는 쿠킹 과정 중에 실행되므로, 주의를 기울이지 않으면 각 쿠킹마다 행동이 달라질 수 있고, 결과적으로 자산이 달라지며 패치 크기가 인위적으로 증가할 수 있습니다. 이를 피하기 위해, 구성 스크립트에서 호출할 필요가 없는 블루프린트 노드를 구성 스크립트에 배치하지 않도록 표시할 수 있습니다. C++에서 구성 스크립트 호출 가능 노드를 정의할 때는 신중하게 접근해야 합니다.

요약해도 긴 내용이네요. 스크립트에 랜덤한 로직이 있을 경우 패키징하는 과정에서 달라질 수 있으니 주의해야한다는 내용이겠습니다.
(랜덤 seed를 사용하는 스크립트라거나 패키징 과정에서 변경될 수 있는 값을 참조하는 변수가 있거나..)

짧은 공부 정리

  • 디터미니스틱한 패키지, 빌드를 만들고 싶다면 빌드 과정에서 랜덤 요소나 변경될 요소를 없애야 한다.
  • 패키지 변경 사항은 패키지를 만들고 비교하고 변경된 패키지에서 어떤 부분에 변경이 있었는지 분석, 수정한다.
  • 프로젝트 에셋에 대부분 문제 원인이 있겠지만 엔진이나 툴에도 원인이 있을 수 있다. (플러그인 GUID 변경 케이스)

What is PVS Studio

PVS Studio

https://pvs-studio.com/en/
“PVS‑Studio is a static analyzer on guard of code quality, security (SAST), and code safety”
홈페이지에 적혀있는 문구 그대로 보면 코드 정적 분석 툴로 코드 퀄리티와 보안을 위해 사용할 수 있는 툴입니다.

C, C++과 Java 코드를 분석하는 툴로 다른 정적 분석 툴로는 Cppcheck, Clang Static Analyzer, SonarQube 등이 있습니다.
PVS Studio는 클라우드 제품은 없어보이고 설치형 프로그램으로 CI에 붙여서 사용하거나 코드 에디터에 설정하고 사용할 수 있습니다.

PVS-Studio for Visual Studio-PVS Studio blog

정적 코드 분석 툴로 TS(TypeScript)나 자바스크립트 앱을 제작할때 사용하는 TSLint, ESLint와 비슷하다고 볼 수 있겠네요.
실제로 빌드 및 프로그램이 실행할 때에 문제가 없을 수는 있지만 정적 코드 분석 결과 문제가 있을 요소는 미리 수정하는게 좋겠죠.

PVS Studio 기본 설명

https://youtu.be/4Fy-JTYzEs0

사실 기본 설명은 위에 정적 코드 분석 툴 정도로 다 설명이 될 수 있다고 생각합니다.
정적 코드 분석 -> 분석 코드 Warning 확인 -> 수정 -> 코드 개선의 흐름이 정적 코드 분석 툴을 사용하는 흐름이겠죠.

분석 코드 Warning 몇가지를 살펴보고 넘어가겠습니다.
Warnings: https://pvs-studio.com/en/docs/warnings/

  • V501. Identical sub-expressions to the left and to the right of ‘foo’ operator.
    • 왼쪽, 오른쪽 동일한 표현식이 있음. -> “유의미한 표현식을 사용하지 않았네. 수정해라” warning으로 볼 수 있겠네요.
  • V502. The ‘?:’ operator may not work as expected. The ‘?:’ operator has a lower priority than the ‘foo’ operator.
    • ? 연산자의 활용이 적절하지 않게 되어있음. 말 그대로 ? 연산자가 적절히 사용되었는지 확인하고 수정하라는 warning.
  • V503. Nonsensical comparison: pointer < 0.
    • 포인터 비교가 잘못된 코드가 있음. 포인터가 아닌 다른 것을 비교해야한다는 warning으로 이해할 수 있습니다.

위 처럼 Warning에 따라 수정하고 코드를 개선할 수 있는 서비스로 이해해볼 수 있겠습니다.

https://stackshare.io/stackups/pvs-studio-vs-sonarqube
stackshare라는 서비스의 장단점 비교 서비스를 보았을 때 SonarQube와 인지도 차이가 크지만
PVS Studio도 C++ 개발하거나 게임 개발에 사용해볼만한 프로그램으로 사용되긴하는 것 같습니다. 😃
(SonarQube가 인지도가 높아 PVS Studio랑 어떤 차이가 있는지 확인차 살펴보았는데 PVS Studio는 인지도가 역시 낮았네요)

PVS Studio 가이드 문서 살펴보기

공식 가이드 문서: https://pvs-studio.com/en/docs/
블로그: https://pvs-studio.com/en/blog/posts/

마무리

게임 개발을 하면서 코드 분석툴은 어떤 것들이 있고 그중에 PVS Studio는 뭘까 싶어 한번 찾아보게되었네요.
기본적으로 PVS Studio는 정적 코드 분석 툴로 분석한 코드는 개발자들이 확인하고 개선해나가야하는 중간 도우미 같은 친구이긴합니다.
Warning을 다 해결한다고 다 좋은 코드는 아니지만 안정성, 품질을 신경쓰고 있는 코드로 볼 수는 있겠다는 생각이듭니다.

FileOpenLog, FileOpenOrder란?

FileOpenLog, FileOpenOrder

참고 문서: https://docs.unrealengine.com/4.27/ko/Basics/Projects/Packaging/

언리얼 엔진에서 패키지 생성 및 로딩하는 것과 연관이 있는 내용입니다.

참고 문서에서 언급한 내용으로는 아래와 같습니다.

“로드 시간 단축을 위해서는 .pak 파일 순서를 잘 지정하는 것이 중요합니다. .pak 파일 최적의 순서를 지정하는 데 도움을 드리기 위해, UE4 에서는 데이터 애셋의 필요 순서를 알아내어 더욱 빠른 로딩 패키지를 제작하기 위한 툴 세트가 제공됩니다. 개념적으로, 이 프로세스는 프로파일 주도형 최적화와 비슷합니다.”

언리얼 서밋 세션도 있어서 참고해보면,
https://youtu.be/KJUVH_KzLj8?si=QRG7h2Mim5f0KGOD&t=2135

테스트 빌드를 실행할 때에 -fileopenlog 파라미터를 적용해서 실행하고 로그 파일을 빌드시 사용하는 것 입니다. (파일은 {project}/Build/WindowsNoEditor/FileOpenOrder/ 에 위치함)

이 최적화는 Disk보다는 Flash Drive에서 효과적이라고 하네요.
(예시: Disk=HDD, Flash Drive=SSD, USB 드라이브)

언리얼 서밋 세션에서 공유한 예시 수치로는 5.9s → 4.6s, 약 23%가 감소한 수치를 보여줬습니다.
로그를 얻기 위해 실제 유저가 플레이하는 것 처럼 플레이하더라도 많은 게임 데이터를 포함해서 플레이를 하기는 어렵기에 어느정도 감안하고 최적화한다고 봐야할 것 같네요.

마무리

FileOpenLog라는 용어가 일반적인 용어일 줄 알았는데 실제로 사용하는 곳은 언리얼엔진 정도인 것 같습니다.
파일오픈로그(오더) 용어 그대로 파일이 열리는 순서를 최적화해서 로딩 시간을 개선하는 방법, 방법을 위한 파일 정도로 이해하면 좋을 것 같네요.