UDN
Search public documentation:

GameplayPerformanceOptimizationKR
English Translation
日本語訳
中国翻译

Interested in the Unreal Engine?
Visit the Unreal Technology site.

Looking for jobs and company info?
Check out the Epic games site.

Questions about support via UDN?
Contact the UDN Staff

UE3 홈 > 퍼포먼스, 프로파일링, 최적화 > 게임플레이 프로그래머의 퍼포먼스 최적화
UE3 홈 > 게임플레이 프로그래밍 > 게임플레이 프로그래머의 퍼포먼스 최적화

게임플레이 프로그래머의 퍼포먼스 최적화


문서 변경내역: Jeff Wilson 작성. 홍성진 번역.

개요


UE3 게임에서 콘텐츠나 게임 전용 퍼포먼스 문제를 추적하는 데 유용할 수 있는 툴이 여러가지 있습니다. 인피니티 블레이드: 던전 개발 과정에서 사용중인 방법을 하나 소개할까 합니다.

폭넓은 퍼포먼스 조사


첫 단계는 게임을 살펴보면서 느린 부분을 알아내는 것입니다. 가장 빠른 방법은 STAT UNIT 옵션을 켠 채 살펴보면서 게임, 렌더, GPU 가 느린 부분이 있는 지 알아보는 것입니다. 이 작업은 가급적 Test 빌드에서 하는 것이 좋습니다. GPU 시간이 안나올 수는 있지만, 총 프레임 시간이 나머지 둘 보다 크다면 그와 같다고 가정할 수 있습니다. QA 팀의 보고서를 받아 관련된 팀과 돌려보는 것도 큰 도움이 됩니다. 보고서에서 유용하게 참고해 볼 수 있을 정보라면:

  • Average FPS 평균 FPS - 날(미가공) 평균 fps 는 가끔 시네마틱과 상호작용성이 없는 부분을 제외한 것입니다. 여기 날 수치는 vsync (보통 30) 이상이라면 별로 중요하지 않습니다만, 경향을 파악하는 데 좋습니다.
  • % over 30 30 이상 비율 - 얼마만큼 기간동안 30fps 이상이었나 입니다. 가급적 높아야 할 것이며, 보통 95% 이상을 목표로 합니다.
  • Total Hitches 총 버벅임 - 100 ms 이상 걸리는 프레임 수입니다. 가급적 낮아야 할 것입니다.
  • % Bound by Game and Render 게임과 렌더로 묶인 비율 - 느린 프레임 중 몇이나 게임 또는 렌더 스레드 때문인지 입니다. 이 수치가 0 이 아니라면 무엇때문인지 조사해야 할 것입니다. GPU 에 묶인 비율은 보통 알 수 없지만, 다른 두 개의 비율 수치가 낮은데다 30 이상 비율 역시도 낮다면, 높은 GPU 시간이 아마 그 원인일 것입니다.

게임과 렌더 퍼포먼스


느린 게임플레이와 렌더링을 추적하기 좋은 툴이 둘 있습니다: 게임플레이 프로파일러통계 뷰어 지요. 게임플레이 프로파일러는 게임 스레드 프로파일링에 최적이며, 통계 뷰어는 렌더 스레드 프로파일링에 더 적합합니다. 이 두 가지 툴 모두 Release 게임 버전에서 돌려야 가장 정확한 결과를 얻을 수 있습니다. 분석에 필요한 프로파일을 수집하려면 각 툴의 UDN 문서대로 단계별로 따르거나, 앞서 말한대로 QA 팀이 필요한 환경설정 상에서 프로파일링 패스를 돌리도록 하는 방법이 있습니다. 보통 가장 비싼 프레임을 ms 로 기록합니다. 참고로 이 툴로 작성된 프레임 수치는 25% 정도 과장된 것이니, 35ms 정도 나왔다 해도 Test/Shipping 빌드에서는 30fps 가 되므로 걱정할 필요 없습니다. 보통 게임플레이 프로파일러에는 .gprof 파일, 통계 뷰어에는 .ustats 파일 디렉토리가 생성됩니다. 그러면 그 파일을 (연결 프로그램이 지정된 경우라면 그냥 더블클릭해서) 적합한 툴로 열어 보면 됩니다.

게임 스레드 프로파일링

.gprof 파일을 열고나면 게임플레이 프로파일러 를 사용해서 문제를 찾아보기 시작할 수 있습니다. 한 가지 접근법은 그래프 위의 느린 프레임을 개별적으로 파고 들어가 보는 것입니다. 느린 프레임을 클릭하고, Frame Actor / Class Call Graph 탭과 Frame Function * 탭을 살펴봅니다. 빨강 텍스트는 STAT 정보이며, 녹색 텍스트는 스크립트 호출과 틱 시간입니다.

frame_actor.jpg

이 탭을 통해 어떤 함수 호출이 느린지, 아니면 어느 액터 또는 액터 클래스의 틱이 느린지를 알아볼 수 있습니다. 액터 틱이나 스크립트 함수가 느린 것 같지 않아 보인다면, Frame Function Summary 탭을 사용하여 어느 통계 호출이 시간을 잡아먹는지 알아보고, 프레임 함수 호출 그래프를 사용하여 그 통계가 계층구조 어디에 있는지 알아볼 수 있습니다. 느린 통계를 알아내고 나면, 언급된 문자열에 대한 소스를 검색하여, 그 통계와 그 통계를 사용하는 코드를 찾아냅니다. 여기서 힌트를 얻거나, 엔진 팀에 도움을 요청하거나 하면 되겠지요.

다른 최적화 방법은, 전체적으로 느린 함수를 전체적으로 최적화해 보는 방법입니다. 그러기 위해서는 Aggr function summary (함수 요약 집계)와 Aggr function call graph (함수 콜 그래프 집계) 뷰가 좋습니다.

aggr_func_summary.jpg

aggr_func_call_graph.jpg

개별 통계나 함수를 선택하면, 그 영역에서 느린 프레임이 있는 부분이 위 그래프에서 빨강으로 표시됩니다. 여기서는 종종 Exlusive time (제외 시간)으로 정렬하는 것이 나은데, 그러지 않으면 보통 다른 모든 틱이 포함된 World Tick Time 이 가장 높게 나오기 때문입니다. 관심 영역이 보이면 그 영역에서 프레임이 불쑥 솟은 부분을 클릭하여, 어떤 통계나 함수가 그 프레임을 느리게 만드는지 파고들어가 볼 수 있습니다.

렌더 스레드 프로파일링

통계 뷰어 는 렌더 스레드에서 틱과 스크립트 시간은 빼고 비슷한 정보를 보여줍니다. .ustat 를 열면 오른쪽에 그래프, 왼쪽에 필터 세트가 보입니다. 개별 통계가 의심되는 경우 선택하여 그에 대한 그래프를 그려 볼 수도 있습니다만, 개별 프레임부터 파고들어가는 것으로 시작하는 편이 쉽습니다. 오른편의 프레임에 우클릭하고 Open call graph 를 선택합니다. 그러면 딱 그 프레임만 파고들어가서, 빨강으로 표시되는 느린 요소를 찾아볼 수 있습니다. 하나 찾았다면 그것을 일반 그래프에 추가하여, 그 통계가 게임을 얼마나 자주 느리게 만드는지 알아볼 수 있습니다.

흔한 퍼포먼스 문제


문제 추적에 일반적으로 사용되는 툴로, 과거에 무엇이 느렸나 알아두면 도움이 됩니다. 작년 한 해에 있었던 문제를 정리해 보면 이정도이며, 결과는 사안별로 달라질 수 있습니다:

  • 플랫폼 전용 문제 - 이런 문제는 보통 통계 시간 중 게임이나 렌더가 높게 나타나면서 세부적인 내용은 알 수 없는 식으로 나타납니다. 여기에는 셰이더 컴파일, 오디오 문제, 메모리 지연(stall) 등과 같은 문제도 포함됩니다. 어느 통계가 느린지 알아내고나면 플랫폼-전용 네이티브 프로파일러를 사용하거나 엔진팀에 도움을 요청하거나 해야 할 것입니다.
  • 스크립트 호출 부하 - 게임플레이 프로파일러에서 빠르게 드러나는 것으로, 보통 게임플레이 로직을 조절하거나 느린 함수를 네이티브로 옮기는 식으로 쉽게 고칠 수 있는 문제입니다.
  • GC 시간 - GC MarkGC Sweep 는 종종 게임플레이 프로파일러/통계 뷰어에서 주기적인 오랜 지연으로 나타납니다. -NoVerifyGC 없이 Release 모드로 실행했을 때는 훨씬 오래 지연되니, 그것부터 확인해 보십시오. 이러한 지연을 완벽히 없앨 수는 없지만, GC 가능 오브젝트의 수를 최적화시키는 것이 주요 목표입니다. 스타트업 패키지에 더욱 많은 것을 옮기고 오브젝트 수를 줄이는 것도 괜찮구요.
  • 길찾기와 선 검사 - 길찾기(Pathfind) 호출과 선 검사는 보통 게임 스레드에서 느리게 나타납니다. 가장 쉬운 최적화 방법은 일을 줄이는 것이죠. 게임플레이 코드에서 중복된 길찾기와 선 검사를 줄이도록 해 보십시오.
  • DLE 틱 시간 - 특정 씬에 다이내믹 라이트 인바이언먼트(DLE) 틱 시간이 매우 높은 경우가 종종 있습니다. DLE 가 꼭 필요한 오브젝트에만 허용되도록 설정되었는지 확인하고, 다이내믹 라이팅이 필요치 않은 액터의 DLE 에 bDynamic 을 설정하지 않도록 합니다. 모바일에선 라이트매스에는 써도 다이내믹 오브젝트에는 쓰고싶지 않은 라이트에 대해 Dynamic Composite 옵션을 끄는 등, 보다 적극적인 최적화가 필요할 수 있습니다.
  • 파티클 시간 - 개별 파티클 시스템의 틱 비용은 종종 비쌉니다. 게임플레이 프로파일러에서 비싼 파티클 시스템을 찾아내고, 아티스트더러 최적화를 요청할 수 있습니다. 아니면 게임플레이 로직을 적게 스폰하도록 바꿀 수도 있습니다. 예를 들어 한 번의 공격으로 10 명의 적이 죽은 경우, 한 프레임에서 죽는 적은 두 마리까지만 사망 파티클을 스폰하도록 하는 것입니다. Update Bounds time 은 고정 바운드가 필요한 파티클 시스템을 나타내며, DLE 업데이트 시간은 필수적이지 않은 라이트 업데이트를 하고 있음을 나타냅니다. 이 문제는 콘텐츠와 게임에 따라 판이하게 달라지니, 자세한 것은 ParticleTickStats 를 살펴 보십시오. 또한 파티클이 너무 많으면 렌더 스레드의 Particle update time 으로 나타나며, LOD 나 컬링을 통해 보이는 파티클의 수를 줄여 해결할 수 있습니다.
  • 사망과 폭발 - 사망과 폭발은 여러가지 이유로 느린데, 보통 컴포넌트 업데이트, 파티클 스폰, 로직과 AI 업데이트 등등 때문입니다. 일부 엘리먼트를 다음 프레임으로 미루(defer)거나, 사망이 한 번에 많이 발생한다면 아예 없애는 것도 좋습니다.
  • 컴포넌트 업데이트 시간 - 스켈레탈 메시같은 특정 컴포넌트는 업데이트하는 데 오래 걸릴 수 있습니다. 그럴 때는 컴포넌트의 유형을 살펴봐서 단순한 컴포넌트형으로 바꿀 수 있는지 알아봐야 할 것입니다. (예를 들어 스켈레탈 메시 100 개 보다는, 버텍스 애니메이션이 들어간 스태틱 메시 100 개가 훨씬 쌉니다.)
  • 인터프 액터 업데이트 시간 - 인터프 액터는 DLE 시간과 이동 시간 둘 다에 있어 업데이트 비용이 매우 비쌀 수 있습니다. 한 가지 흔한 해결 방법은, 레벨 디자이너더러 게임플레이 오브젝트가 아닌 것에 "침입 금지(don't encroach)" 마킹을 하도록 하여, 느린 충돌 검사를 하지 않도록 하는 것입니다.
  • 반투명 그리기 - 반투명 오브젝트는 렌더 스레드, 특히 파티클같은 경우 매우 느릴 수 있습니다. 서로 겹치는 반투명 오브젝트를 너무 많이 사용하지는 않는지, 반투명 오브젝트를 적극적으로 LOD 처리해 주고 있는지 아티스트에게 확인시켜야 할 것입니다.
  • 뭐가 너무 많아! - 보통 아티스트와 레벨 디자이너는 화려한 것을 좋아하여 게임에 이것저것 많이 넣기를 좋아합니다. 보통 적의 수가 (10 마리 이상) 많거나 보이는 메시 수가 엄청나다면 느려질 수밖에 없으며, 이럴 때는 콘텐츠 측면의 최적화를 해 줘야 합니다.