유용한 고급 프로파일링 팁

지난 6월 유니티는 Arm, Unity Accelerate Solutions 팀, Subway Surfers를 제작한 SYBO Games의 전문가와 함께 웨비나를 진행했습니다. 웨비나에서 모바일 게임의 프로파일링 팁과 전략, 낮은 성능이 비즈니스에 미치는 영향, 현재까지 30억 건의 다운로드를 기록한 인기 모바일 게임을 출시한 SYBO의 개발 과정 등을 중점적으로 다뤘습니다.

이번 포스팅에서는 웨비나에서 시간상 다룰 수 없었던 이야기를 더 자세히 소개합니다. 전체 녹화 영상은 여기에서 시청할 수 있습니다.

CPU 프로파일링에 Unity 프로파일러를 사용하는 사례는 익숙하지만, Unity 패키지로 사용할 수 있는 Profile Analyzer는 다소 생소합니다. Analyzer를 개선하거나 Profiler 핵심 툴셋에 통합할 계획이 있나요?

지금 당장은 핵심 에디터에 통합할 계획이 없습니다. 다만, 프로파일링 툴을 개선하는 과정에서 계획이 변경될 수는 있습니다.

현재 GPU Usage Profiler 모듈에 밀리초 단위처럼 백분율로 표시하는 옵션을 추가할 계획이 있나요?

좋은 아이디어입니다. 지금 시점에서 추가 여부를 확답할 수는 없지만, 앞으로 개선할 사항과 관련하여 R&D 팀과 상의했던 부분입니다.

Google Play 스토어에서 발생하는 스택 추적이 없는 'ANR(Application Not Responding, 애플리케이션 응답 없음)' 오류를 해결할 계획이 있나요?

현재로서는 스택 추적이 없는 ANR에 관해 구체적인 계획이 없지만, 향후 로드맵으로 고려할 것입니다.

Unity의 프로파일링 툴과 관련된 피드백을 제출하려면 어떻게 해야 하나요?

제품 보드와 포럼을 통해 앞으로 출시될 기능을 확인하고 피드백을 공유할 수 있습니다. 또한 프로파일링 툴을 사용하는 고객의 경험을 알아보기 위해 설문조사를 시행하고 있습니다. 이전에 프로파일링 툴을 사용해본 적이 있거나 최적화가 필요한 프로젝트를 제작하고 있다면 의견을 공유해 주세요. 설문조사는 완료하는 데 5~10분 정도밖에 소요되지 않습니다.

설문조사에 참여하면 새로운 기능의 프로토타입에 관한 논의를 비롯하여 개발 팀과 직접 의견을 나눌 수 있는 후속 인터뷰에 참여할 기회가 주어집니다.

타게팅할 저사양 기기를 정할 때 도움이 될 만한 규칙이 있나요?

많은 Unity 게임 개발자의 경험에 따르면 게임 발매일을 기준으로 출시된 지 5년 된 기기를 타게팅하면 가장 큰 사용자 기반을 확보할 수 있습니다. 하지만 더 높은 그래픽 품질을 목표로 하는 경우 3년 된 기기를 타게팅하는 경우도 많습니다. 예를 들어 시각적으로 복잡한 3D 애플리케이션은 간단한 2D 애플리케이션보다 기기 요구 사양이 더 높습니다. 이렇게 하면 '최소 요구 사양'을 더 높일 수 있지만, 초기 설치율은 줄어듭니다. 결국 비즈니스의 관점에서 결정을 내려야 합니다. 오래된 기기를 위한 개발과 지원에 드는 비용과 해당 기기에서 벌어들이는 매출을 비교해 봐야 합니다.

때로는 게임의 기술적 요구 사항에 따라 최소 타게팅 사양이 정해질 때도 있습니다. 게임을 최적화한 후에도 많은 양의 텍스처 메모리를 사용하며, 화질이나 해상도를 절대로 줄일 수 없다면 메모리가 부족한 휴대폰에 대한 지원은 배제해야 합니다. 렌더링 솔루션에 컴퓨트 셰이더가 필요한 경우 OpenGL ES 3.1, Metal, Vulkan을 지원하지 않는 드라이버가 설치된 기기는 제외해야 합니다.

주요 고객과 타겟 시장에 대한 데이터를 살펴보는 것이 좋습니다. 예를 들어 모바일 기기 사양은 국가와 지역에 따라 매우 다를 수 있습니다. 테스트용 저사양 기기를 선택하기 전에 타겟 '예산'을 정해서 허용 가능한 벤치마킹 목표를 결정해야 합니다.

수년간 운영할 라이브 서비스 게임의 경우, 호환성을 계속해서 모니터링하고 실제 사용자 기반과 현재 시장에 출시된 기기를 모두 고려하여 타게팅 기기를 조정해야 합니다.

저사양 기기에서 테스트한 게임이 고사양 기기에서도 원활하게 실행되나요?

모든 기기에서 워크로드가 균일하다면 원활하게 실행될 수도 있습니다. 그래도 공급업체나 드라이버 버전이 다른 다양한 하드웨어를 고려해야 합니다.

그래픽이 뛰어난 게임은 일반적으로 그래픽 정확도를 단계별로 제공합니다. 정확도가 높을수록 실행 기기에 더 많은 리소스가 필요합니다. 그래픽 설정은 자동으로 이루어지지만 점차 더 많은 사용자가 직접 그래픽 설정 메뉴에서 단계(tier)를 선택하고 있습니다. 이런 방식으로 개발하는 경우 기능/워크로드 단계마다 '최소 사양' 타겟 디바이스를 하나 이상 테스트해야 합니다.

게임이 실행 중인 기기의 기능을 감지하여 그래픽스 출력을 조정하는 경우, 사양이 높은 기기에서 성능이 달라질 수 있습니다. 따라서 다양한 화질 수준에서 여러 기기로 게임을 테스트해야 합니다.

참고: 이 섹션에서는 답변의 출처에 따라 Arm 또는 유니티가 표시되어 있습니다.

특히 모바일에서 자동 화질 설정을 지원할 때 기기의 전력 범위를 감지하는 팁이 있을까요?

Arm: 일반적으로 개발자는 CPU 및 GPU 모델과 GPU 셰이더 코어 수를 기반으로 대략적인 성능 비닝(binning)을 진행합니다. 완벽한 방법은 아니지만 '어느 정도' 확실한 방법입니다. 많은 스튜디오가 배포된 기기에서 실시간 분석 정보를 수집하기 때문에 성능 비닝의 정확도가 낮은 부분에서 기기별 포함/제외 옵션으로 자동화 비닝을 보완할 수 있습니다.

앞선 질문과 관련하여 그래픽이 뛰어난 콘텐츠의 경우, 사용자가 선호하는 성능을 선택하도록 모바일에서 효과를 켜거나 끌 수 있는 설정 옵션을 제공하는 방식으로 옮겨 가는 추세입니다.

유니티: 기기 메모리와 화면 해상도는 화질 설정을 선택하는 중요한 요소입니다. 개발자는 텍스처와 관련하여 효과나 포스트 프로세싱에 사용되는 렌더 텍스처가 화면 해상도는 높으나 메모리가 충분하지 않은 기기에서 문제가 될 수 있다는 점을 알아야 합니다.

CPU, GPU, SOC, 메모리, 모바일, 데스크톱, 콘솔 등 다양한 구성을 고려했을 때 최적화해야 하는 단계 수를 줄이기 위한 기기 분류법을 추천해주실 수 있나요?

Arm: 최적화하는 그래픽스 티어 수는 게임 디자인 및 비즈니스 관점에서 화질을 최대한으로 끌어올리는 것이 게임의 가치 제안에 얼마나 중요한지에 따라 결정해야 합니다. 일부 장르의 경우 전혀 중요하지 않을 수 있지만, 어떤 장르의 사용자는 시각적 정확도에 대한 기대치가 높을 수 있습니다.

전체 시스템 메모리 용량이 같더라도 Android 기기의 모델 및 브랜드마다 텍스처 메모리 제한이 다른가요?

Arm: 일차 근사치로 전체 텍스처 메모리 용량은 공급업체와 하드웨어 세대 전반에서 비슷할 것입니다. 메모리 레이아웃과 데이터 정렬 제한으로 인해 약간의 차이가 있을 수 있기 때문에 정확하게 똑같지는 않습니다.

모바일 기기의 과열에 가장 큰 영향을 주는 것이 CPU 사용량인가요? 아니면 GPU 사용량인가요?

Arm: 모바일 기기의 과열은 전적으로 콘텐츠의 영향을 받습니다. 고사양 기기의 성능을 최대로 끌어올리는 경우 CPU, GPU, DRAM은 각각 과열을 유발할 수 있습니다. 정확한 균형은 실행 중인 워크로드에 따라 달라집니다.

서멀 스로틀링이 있는 기기에서의 프로파일링에 관한 팁이 있나요? 서멀 스로틀링을 피하려면 어떤 마진을 타게팅하는 것이 좋을까요? 예를 들어 33ms 대신 20ms로 설정하는 게 좋나요?

Arm: Android 기기는 에너지 사용량을 최적화하기 위해 계속해서 주파수를 조정하기 때문에 프레임 시간으로 최적화하는 경우 불완전하게 측정되어 오인할 가능성이 있습니다. 되도록 프레임별 CPU 및 GPU 주기와 프레임별 GPU 메모리 대역폭을 모니터링하여 주파수에 독립적인 값을 얻는 것이 좋습니다. 주기 타겟은 각 기기의 칩 설계에 따라 다르기 때문에 다양한 실험을 해 봐야 합니다.

모든 최적화는 프레임 속도를 직접적으로 개선하지 않더라도 전력 소비를 관리하는 데 도움이 됩니다. 예를 들어 CPU가 게임에 주된 경로가 아니더라도 CPU 주기를 줄이면 발열 로드가 줄어듭니다.

그 외에도 메모리 대역폭을 최적화하면 가장 큰 발열 절감 효과를 볼 수 있습니다. DRAM에 액세스하는 것은 칩의 로컬 데이터에 액세스하는 것보다 훨씬 리소스 소모가 심합니다. 따라서 프로젝트 관리 삼각형(Project Management Triangle)을 고려하여 메모리의 데이터 유형을 최대한 작게 유지하는 것이 좋습니다.

유니티: CPU 클럭 주파수가 성능 지표에 미치는 영향을 줄이려면 일관된 온도에서 프로파일링하는 것이 좋습니다. 같은 온도를 유지하기 위한 몇 가지 방법이 있습니다.

• 발열 상태로 실행: 프로파일링하기 전에 안정적인 발열 상태에 도달하도록 잠시 기기를 실행합니다.
• 발열이 없는 상태로 실행: 프로파일링하기 전에 기기가 발열이 없도록 잠시 놔둡니다. 이 전략은 서멀 스로틀링이 발생하지 않을 만한 캡처를 수행하기 때문에 프로파일링 세션에 혼란과 불일치가 발생하지 않도록 합니다. 반면 긴 플레이 세션 이후 사용자가 경험하는 실제 성능보다 훨씬 나은 성능을 나타냅니다. 또한 먼저 냉각될 때까지 기다려야 하기 때문에 프로파일링 시간을 지연시킬 수 있습니다.

일부 하드웨어에서는 더 안정적인 성능 지표를 위해 클럭 주파수를 수정할 수 있습니다. 그러나 이는 사용자가 가진 대부분의 기기에 해당되지 않으며, 정확한 실제 성능과 관련이 없습니다. 기본적으로 이 방법은 지속적인 통합 설정을 사용하여 시간에 따른 코드베이스의 성능 변화를 확인하려는 경우에 사용하기 좋은 기술입니다.

Android에서의 Vulkan 및 OpenGL ES3 사용에 관한 의견을 들려주세요. Vulkan은 일반적으로 성능 면에서 더 느리지만, 많은 기기가 ES3의 다양한 기능을 지원하지 않습니다.

Arm: 최근 드라이버 및 엔진 빌드는 Vulkan 구현의 품질을 엄청나게 개선했습니다. 따라서 워크로드가 같다면 OpenGL ES와 Vulkan 사이에 성능 차이가 없어야 합니다. 혹시 발견하게 될 경우 반드시 알려 주세요. 현재 Vulkan으로 전환하는 속도가 빨라지고 있으며, 앞으로 1~2년 후에는 더 많은 사람이 Vulkan을 기본으로 채택할 것으로 생각됩니다. Vulkan의 성능이 제대로 나오지 않는 반례가 있다면 문의해 주시기 바랍니다. 많은 의견을 기다리고 있습니다.

메모리 대역폭 모니터링(RAM <-> VRAM)에 사용할 수 있는 툴은 어떤 것이 있나요?

Arm: Arm Mobile Studio의 Streamline Profiler를 사용하면 Mali GPU와 외부 DRAM(또는 시스템 캐시) 사이의 대역폭을 측정할 수 있습니다.

기기 등급 또는 기기 해상도별로 그래픽 에셋을 분할해야 하나요?

Arm: 에셋을 재조정하면 최상의 결과를 얻을 수 있지만, 비용이 많이 듭니다. 해상도와 프레임 속도를 줄이거나 일부 포스트 프로세싱 이펙트 옵션을 비활성화하는 것부터 시작하는 것이 좋습니다.

개발 빌드에서 성능 지표 통계를 기록하는 가장 좋은 방법은 무엇인가요?

Arm: Arm Mobile Studio의 Performance Advisor 툴을 사용하면 Mali GPU에서 성능 지표를 자동으로 캡처하고 익스포트할 수 있습니다. 하지만 주의해야 할 점이 있습니다. JSON 보고서를 생성하려면 Professional Edition 라이선스가 필요합니다.

Unity: Unity 프로파일러를 사용하여 Rendering 모듈에서 버텍스 및 삼각형 수와 같은 일반적인 렌더링 지표를 확인할 수 있습니다. 또한 프로젝트에서 System Metrics Mali 등의 커스텀 패키지를 사용하여 Unity 프로파일러에 로우 레벨 Mali GPU 지표를 추가할 수 있습니다.

셰이더 코드 프로파일링에 추천하는 것이 있나요?

GPU 프로파일러가 필요하며 타겟 플랫폼에 따라 선택이 달라집니다. 예를 들어 iOS 기기의 경우 Xcode의 GPU 프로파일러에 셰이더 성능을 한 줄씩 분석하는 Shader Profiler가 포함되어 있습니다.

Arm Mobile Studio는 셰이더 코드와 컴퓨트 커널을 위한 정적 분석 툴인 Mali Offline Compiler를 지원합니다. 이 툴은 Arm Mali GPU 제품군에 대한 전반적인 성능 추정치와 권장 사항을 몇 가지 제공합니다.

일반적으로 프로파일링을 할 때는 게임이나 앱을 타겟 기기에서 테스트합니다. 업계에서 점점 더 많은 유형의 칩셋(Apple M1, Arm, x86 by Intel, AMD 등)을 사용하고 있는 상황에서 개발자가 적정한 시간 안에 여러 하드웨어 구성에서 프로파일링하고 문제를 정확히 집어내는 방법은 무엇인가요?

다양한 칩셋의 보급은 주로 데스크톱 플랫폼에 관한 우려 사항입니다. 콘솔 게임을 테스트할 수 있는 하드웨어 아키텍처는 제한되어 있습니다. 모바일의 경우, iOS 기기를 위한 Apple의 A Series와 Android 기기를 위한 Arm 및 Qualcomm 아키텍처가 있지만, 대표적인 모바일 디바이스 목록을 선택하는 것은 꽤 간단합니다.

데스크톱의 경우 사용할 수 있는 칩셋과 아키텍처가 매우 다양하고 Mac과 PC를 구입하는 데 비용이 많이 들기 때문에 더 까다롭습니다. 가장 좋은 방법은 할 수 있는 것을 하는 것입니다. 어떤 스튜디오도 테스트에 무한한 시간과 돈을 쏟아부을 수 없습니다. 예를 들어 Intel x86 CPU와 비슷한 사양의 AMD 프로세서를 비교할 때 일반적으로 성능 면에서 크게 다르지 않을 것이라고 예상합니다. 게임이 최소 사양 기기에서 안정적으로 실행된다면 다른 기기에서도 비슷할 것으로 예상할 수 있습니다. Unity Analytics 등의 분석 툴을 사용해서 프레임 속도, 시스템 사양, 플레이어 옵션 설정 등을 기록하여 핫스팟이나 문제가 있는 구성을 확인하는 방법도 있습니다.

더 많은 스튜디오가 정기적인 온디바이스 프로파일링에 일부 자동화된 테스트를 사용하기 시작했습니다. 여기에는 전체 팀이 다양한 타겟 기기에서 성능을 확인할 수 있는 요약 통계가 표시됩니다. 잘 설계된 테스트 씬을 사용하면 일반적으로 자동화에 적합한 기계적 프로세스를 만들 수 있기 때문에 숙련된 테크니컬 아티스트나 QA 테스터가 수동으로 빌드를 실행할 필요가 없습니다.

저사양 기기에서는 발생하지 않는 성능 문제가 고사양 기기에서 발생하는 경우를 본 적이 있나요?

흔한 경우는 아니지만, 그런 경우도 있습니다. 주로 프로젝트 구성 방식에 문제가 있을 때 발생합니다. 예를 들어 고사양 기기에서 복잡한 셰이더나 고해상도 텍스처를 사용하는 등 GPU나 메모리에 추가적인 부하를 주는 경우입니다. 고사양 모바일 디바이스나 콘솔이 고해상도 스크린이나 4K TV 출력 등을 장점으로 내세우는 경우도 있지만, 추가적인 최적화 없이는 GPU 성능이나 메모리가 부족할 수 있습니다.

현재 버전의 C# 잡 시스템을 사용하는 경우, 워커 스레드 수나 CPU 코어 수에 따라 확장/축소되는 잡 예약 오버헤드가 있는지 확인해야 합니다. 이 경우 결과적으로 4코어나 8코어 CPU보다 64코어 이상 Threadripper™에서 더 느리게 실행되는 코드가 될 수 있습니다. 이 문제는 향후 Unity 버전에서 해결될 예정이며, 현재는 JobsUtility.JobWorkerCount를 설정하여 잡 워커 스레드 수를 제한하는 방법을 추천합니다.

적당한 프레임 예산을 설정하기 위한 몇 가지 지침을 공유해 주세요.

대부분의 경우 프레임 예산에 관해 이야기할 때 프레임의 전체 시간 예산에 관해 이야기합니다. 1000/타겟 fps(초당 프레임 수)를 계산해서 프레임 예산을 구할 수 있습니다. 30fps의 경우 33.33ms, 60fps의 경우 16.66ms, 120Hz의 경우 8.33ms 등입니다. 모바일의 경우 각 프레임 사이에 칩의 온도가 내려갈 수 있도록 이 숫자를 약 35% 줄입니다. 매우 구체적이고 예측 가능한 시스템이나 타임 슬라이싱을 많이 사용하는 프로젝트를 제외한다면 여러 기능이나 시스템에 대한 구체적인 하위 예산을 구하기 위해 예산을 나누는 것은 조금 지나칠 수 있습니다.

기본적으로 프로파일링은 가장 큰 병목 지점을 찾아 성능을 최대한 개선하는 과정입니다. '물리에 1.2ms가 걸리는데 예산은 1ms밖에 안 된다'고 생각하지 말고 프레임을 확인해서 '렌더링에 6ms가 걸리고, 이 부분이 프레임에서 메인 스레드 CPU 비용이 가장 큰 부분인데, 이를 어떻게 줄일까?'를 생각해 보시기 바랍니다.

초기에 자주 프로파일링하는 것이 여전히 일반적이지 않다고 여기는 사람들이 많습니다. 그런 이유가 무엇일까요?

게임을 제작하여 출시하고 홍보 및 관리까지 하는 것은 여러모로 어려운 일입니다. 개발자가 주의를 기울여야 할 부분은 언제나 산재해 있기에 프로파일링을 제쳐두기 쉽습니다. 프로파일링을 해야 한다는 사실은 알고 있지만, 툴에 익숙하지 않고 툴을 배울 시간도 없다고 느낄 수 있습니다. 아니면 성능 최적화보다는 기능을 완성하는 데 급급하여 워크플로에 프로파일링을 어떻게 추가해야 할지 알 수 없을 때도 있습니다.

버그나 기술적 부채와 마찬가지로 성능 문제는 프로젝트의 개발 주기의 후반보다는 초기에 해결하는 것이 더 저렴하고 위험도 줄어듭니다. 유니티는 프로파일링 툴과 기술에 익숙하지 않은 개발자를 위해 이를 쉽게 설명하는 데 중점을 두고 있습니다. 프로파일링을 이해하기 쉽도록 하기 위해 유니티는 프로파일링 전자책, 관련 블로그 포스팅, 웨비나를 제공합니다.

Unity 프로파일러에서 딥 프로파일링을 사용할 때 계측에서 특정 메서드를 제외하거나 특정 메서드만 포함하도록 하는 방법이 있나요? async/await 작업이 많을 때 스택 추적이 많이 발생하는데 딥 프로파일링 중 클라이언트와 프로파일러 모두 속도가 느려지지 않도록 하려면 어떻게 해야 하나요?

Allocation 호출 스택을 활성화해서 관리되는 할당(Unity CPU 프로파일러 타임라인 뷰에 마젠타색으로 표시됨)으로 이어지는 전체 호출 스택을 확인할 수 있습니다. 또한 코드 전체에 ProfilerMarkers를 사용하여 오랜 시간 실행되는 메서드와 프로세스를 수동으로 계측할 수 있습니다. 현재 애플리케이션의 특정 부분에서 딥 프로파일링을 자동으로 활성화하거나 프로파일링을 완전히 비활성화하는 방법은 없습니다. 하지만 수동으로 ProfilerMarkers를 추가하고 필요할 때 Allocation 호출 스택을 활성화하면 딥 프로파일링을 사용하지 않고도 문제가 되는 부분을 심층적으로 분석할 수 있습니다.

Unity 2022.2부터 IgnoredByDeepProfilerAttribute를 사용하여 Unity 프로파일러가 메서드 호출을 캡처하지 않도록 할 수도 있습니다. IgnoredByDeepProfiler 속성을 클래스, 구조체, 메서드에 추가하기만 하면 됩니다.

Unity의 딥 프로파일링과 관련된 더 자세한 정보는 어디에서 확인할 수 있나요?

딥 프로파일링은 Profiler 기술 자료에 설명되어 있습니다. 프로파일링 정보를 가장 심층적으로 다루는 Unity 게임 프로파일링 완벽 가이드 전자책도 제공하고 있으며, 전자책에는 관련 기술 자료와 기타 리소스에 대한 링크가 포함되어 있습니다.

딥 프로파일링이 할당 프로파일러에만 유용하며, 결과가 너무 왜곡되어 게임에서 문제를 찾는 데는 유용하지 않다는 것이 사실인가요?

딥 프로파일링을 사용해서 관리되는 할당의 구체적인 원인을 찾을 수 있지만, Allocation 호출 스택을 사용하면 전반적으로 더 적은 오버헤드로 같은 작업을 수행할 수 있습니다. 동시에 딥 프로파일링은 하나의 특정 ProfilerMarker가 오래 걸리는 이유를 빠르게 조사하는 데 유용합니다. 스크립트에 수많은 ProfilerMarkers를 추가하고 게임을 다시 빌드하는 것보다 딥 프로파일링을 활성화하는 것이 훨씬 편리하기 때문입니다. 하지만 성능을 상당히 왜곡하기 때문에 일반적인 프로파일링에 사용하면 안 됩니다.

모든 VBlank에 VSync를 설정할 가치가 있나요? VSync를 비활성화하면 제작한 모바일 게임이 매우 낮은 fps로 실행됩니다.

모바일 기기는 드라이버/하드웨어 수준에서 VSync를 강제로 활성화하기 때문에 Unity의 화질 설정에서 VSync를 비활성화해도 플랫폼에서 달라지는 것은 없습니다. 지금까지 VSync를 비활성화하는 것이 성능에 부정적인 영향을 주는 경우는 없었습니다. VSync를 활성화한 상태에서 프로파일을 캡처해 보고 VSync를 비활성화한 상태에서 같은 씬을 캡처해 보시기 바랍니다. 그리고 Profile Analyzer를 사용하여 캡처를 비교해서 성능이 다른 이유를 확인하시기 바랍니다.

메인 스레드가 GPU를 기다리고 있는 상황인지 확인하려면 어떻게 해야 하나요?

이 내용은 Unity 게임 프로파일링 완벽 가이드에서 다루고 있습니다. Unity Frame Timing Manager로 성능 병목 현상 감지 블로그에서도 더 자세한 내용을 확인할 수 있습니다.

일반적으로 대표적인 징후는 렌더 스레드가 GPU를 기다리는 동안 메인 스레드가 렌더 스레드를 기다리는 것입니다. 구체적인 마커 이름은 타겟 플랫폼과 그래픽스 API에 따라 다르지만, 이름이 'PresentFrame'이나 'WaitForPresent' 등인 마커를 찾으면 됩니다.

프로파일링에서 메모리 누수를 확실하게 찾을 수 있는 프로세스가 있나요?

Memory Profiler를 사용하여 메모리 스냅샷을 비교하고 누수가 있는지 확인할 수 있습니다. 예를 들어 메인 메뉴에서 스냅샷을 찍고 게임을 시작했다가 종료하고 다시 메인 메뉴로 돌아가서 두 번째 스냅샷을 찍으면 됩니다. 두 스냅샷을 비교하면 게임의 오브젝트/할당이 메모리에 계속 남아 있는지 확인할 수 있습니다.

VR/AR을 비롯한 모바일 기기용으로 DOTS 시스템을 위해 코드 일부를 최적화하고 수정하는 것이 합리적인가요? 프로젝트에서 이 시스템을 사용하나요?

이제 많은 게임 프로젝트가 DOTS(Data-Oriented Technology Stack, 데이터 지향 기술 스택)의 일부를 사용하고 있습니다. NativeContainer, C# Job System, Mathematics, Burst 컴파일러 는 DOTS를 완벽 지원하는 패키지로, 최적의 병렬화된 고성능 C#(HPC#) 코드를 작성하여 프로젝트의 CPU 성능을 개선하는 데 바로 사용할 수 있습니다.

일부 프로젝트는 Entities 및 관련 패키지인 Hybrid Renderer, Unity Physics, NetCode 등도 사용하고 있습니다. 그러나 현재 이 패키지들은 실험 단계이며, 이를 사용하려면 어느 정도의 기술적 위험을 감수해야 합니다. 여전히 개발 단계에 있는 API나 불완전한 기능을 사용해야 하며, Unity의 ECS(Entity Component System, 엔티티 컴포넌트 시스템)를 최대한 활용하기 위해 DOD(Data-Oriented Design, 데이터 지향 설계)를 학습하는 시간도 상당히 소요됩니다. 유니티 엔지니어인 Steve McGreal이 작성한 DOD 기초와 ECS 성능 개선 팁 등이 포함된 DOTS 베스트 프랙티스를 참고하세요.

SetPass 호출이나 셰이더 복잡도에 대한 제한은 어떻게 설정하나요? 미리 제한할 수도 있나요?

렌더링은 복잡한 과정이며 최대 SetPass 호출 수나 셰이더 복잡도에 대한 지표를 절대적으로 제한할 수 있는 실질적인 방법은 없습니다. 하나의 콘솔 기기와 같은 고정된 하드웨어 플랫폼에서도 렌더링하려는 씬의 종류와 프레임 동안 CPU 및 GPU에서 어떤 다른 작업이 발생하는지에 따라 제한이 달라집니다.

그렇기 때문에 프로파일링을 '초기에 자주' 해야 하는 것입니다. 팀에서는 제작 초기에 '버티컬 슬라이스(vertical slice)'를 만들곤 합니다. 이러한 버티컬 슬라이스는 일반적으로 최종 게임의 비주얼 수준으로 제작된 짧은 게임플레이 데모입니다. 이때 처음으로 렌더링을 프로파일링하고 어떤 최적화와 어떤 제한이 필요할 것인지 파악할 수 있습니다. 새로운 영역이나 다른 주요 비주얼 콘텐츠를 추가할 때마다 프로파일링 프로세스를 반복해야 합니다.

성능 최적화에 대해 알아볼 수 있는 추가 리소스를 소개합니다.

블로그

• 모바일 게임 성능 최적화: 그래픽스와 에셋에 관한 전문가 팁
• 모바일 게임 성능 최적화: 물리, UI, 오디오 설정에 관한 전문가 팁
• 모바일 게임 성능 최적화: Unity 최고의 엔지니어가 전하는 프로파일링, 메모리, 코드 아키텍처에 관한 전문가 팁
• 전문가가 알려주는 콘솔용 게임 그래픽스 최적화 팁
• Unity 2021 LTS의 프로파일링 사용하기

사용법 소개 페이지

• 프로파일링 및 디버깅 툴
• Unity에서 메모리를 프로파일링하는 방법
• 게임 성능 프로파일링 베스트 프랙티스

전자책

• 콘솔 및 PC 게임 성능 최적화
• 모바일 게임 성능 최적화 팁
• Unity 게임 프로파일링 완벽 가이드

Unity Learn 튜토리얼

• Android Studio로 Android 빌드에서 CPU 성능 프로파일링하기
• 프로파일링 애플리케이션 – Made with Unity

더 전문적인 기술 콘텐츠가 곧 공개될 예정입니다. 유니티에서 다뤘으면 하는 주제가 있다면 언제든 포럼에 공유해 주세요. 전체 웨비나 녹화 영상도 확인해 보세요.