Search Unity

Unity 개발자라면 누구나 사용자가 게임 플레이를 좋아하고, 어느 플랫폼에서 게임을 하든 문제없이 즐기기를 바랄 것입니다. 퍼포먼스 벤치마크를 생성하기가 보다 쉬워졌다는 소식을 전해드린다면 기분이 어떠실까요? 게임을 개발하는 방법이나 퍼포먼스에 초점을 맞춘 Unity 툴에 대해 알아보고 싶다면 이 게시물을 계속해서 읽어보시기 바랍니다!

이 게시물에서는 손쉽게 퍼포먼스 메트릭을 수집하고 이를 사용하여 벤치마크를 생성할 수 있는 몇 가지 Unity 툴을 사용하는 방법에 대해 설명해보겠습니다. 이러한 툴로는 Unity 에디터와 함께 제공되는 Unity 테스트 러너와 Unity 퍼포먼스 테스팅 확장 프로그램 및 Unity 퍼포먼스 벤치마크 리포터가 있습니다.

Unity에서 퍼포먼스 벤치마크를 사용하는 이유

Unity 개발자가 경험할 수 있는 상황을 예로 들겠습니다. 불과 얼마 전까지만 해도 프로젝트가 빠르고 원활하게 실행되다가 한두 가지 변경을 적용한 후에 씬이 눈에 띄게 느려지고, 프레임이 끊기고, 이외에도 다른 퍼포먼스 문제가 나타날 수 있습니다. 어떤 변경 사항으로 인해 이러한 퍼포먼스 저하가 발생했는지 추적하기란 어려울 수 있습니다.

여러분이 Unity 파트너라면 SDK, 드라이버, 플랫폼, 패키지 또는 다른 아티팩트에서 발생하는 퍼포먼스 변화를 파악하고 싶어하거나, 여러 버전의 Unity에서 여러분이 개발한 제품을 실행할 때 퍼포먼스 메트릭을 수집하려고 하지만, 어떻게 수집하고 비교해야 할지 막막할 수 있습니다.

위에서 예로 든 상황은 퍼포먼스 벤치마크를 설정해 놓으면 사전에 문제가 해결될 수 있는 사례들 중 일부입니다. 이제 퍼포먼스 메트릭을 수집하고, 이를 사용하여 벤치마크를 생성하고, 퍼포먼스 메트릭의 변화를 시각화할 수 있는 방법을 설명하겠습니다.

샘플 프로젝트 다운로드

설명하기 전에 먼저 UnityPerformanceBenchmark 샘플 퍼포먼스 테스트 프로젝트의 테스트 코드를 살펴보겠습니다.

GitHub에서 최신 XRAutomatedTests 릴리스를 다운로드하시기 바랍니다. PerformanceTests 하위 디렉토리에 UnityPerformanceBenchmark 프로젝트가 있습니다.

 

Unity 테스트 러너에서 퍼포먼스 테스트 작성

UnityPerformanceBenchmark 프로젝트에는 다양한 샘플 씬이 들어 있으며, 이는 Unity 퍼포먼스 테스팅 확장 프로그램을 활용하여 Unity 퍼포먼스 테스트에 사용됩니다.

먼저, Unity 테스트 러너와 Unity 퍼포먼스 테스팅 확장 프로그램을 사용하여 퍼포먼스 테스트를 작성하는 방법을 알아보겠습니다. 시작하기 전에 이 두 가지 툴에 대해 먼저 간단히 살펴보겠습니다.

Unity 테스트 러너

Unity 테스트 러너는 퍼포먼스 테스트 실행에 사용되고 있습니다. Unity 테스트 러너는 Unity 에디터에서 기본 제공하는 테스트 실행 프레임워크로서 스탠드얼론, Android 또는 iOS와 같은 타겟 플랫폼 플레이어에서 편집 모드와 플레이 모드로 코드를 테스트할 수 있습니다. Unity 테스트 러너에 익숙하지 않은 경우 Unity 테스트 러너 기술 자료를 참조하시기 바랍니다.

Unity 퍼포먼스 테스팅 확장 프로그램

Unity 퍼포먼스 테스팅 확장 프로그램은 Unity 에디터의 패키지로서, Unity 에디터 및 플레이어에서 Unity 프로파일러 마커와 비프로파일러 커스텀 메트릭을 모두 샘플링하고 집계하는 데 활용할 수 있는 API 및 테스트 사례 속성을 제공합니다. 자세한 내용은 Unity 퍼포먼스 테스팅 확장 프로그램 기술 자료에서 확인할 수 있으며, 여기에서는 몇 가지 예제만 확인해보겠습니다.

Unity 퍼포먼스 테스팅 확장 프로그램을 사용하려면 Unity 2018.1 이상이 필요합니다. UnityPerformanceBenchmark 프로젝트에서 샘플 퍼포먼스 테스트를 실행하거나, Unity 퍼포먼스 테스팅 확장 프로그램을 사용하려면 Unity 2018.1 이상 버전을 사용하시기 바랍니다.

커맨드 라인을 사용하여 샘플 프로젝트 열기

UnityPerformanceBenchmark 프로젝트는 Unity 테스트 러너 기능인 IPrebuildSetup 인터페이스를 구현합니다. 이 인터페이스에서 우리는 Unity 테스트 러너에서 테스트 실행을 수행하기 전에 자동으로 호출되는 Setup 메서드를 구현할 수 있습니다.

UnityPerformanceBenchmark 프로젝트의 IPrebuildSetup.Setup 메서드가 수행하는 첫 번째 작업은 플레이어 빌드 설정을 찾는 커맨드 라인 인자를 파싱하는 것입니다. 이 과정을 통해 우리는 다양한 플랫폼에서 동일한 Unity 프로젝트를 사용하여 퍼포먼스 테스트용 플레이어, 렌더 스레딩 모드, 플레이어 그래픽스 API, 스크립팅 구현, XR이 활성화된 설정(예: 스테레오 렌더링 경로) 및 VR SDK를 유연하게 빌드할 수 있습니다.

따라서 커맨드 라인을 통해 Unity로 UnityPerformanceBenchmark 프로젝트를 열어 Unity 테스트 러너에서 테스트 실행 시 사용할 플레이어 빌드 옵션을 전달해야 합니다.

예: Android 플레이어를 빌드하기 위해 Windows에서 UnityPerformanceBenchmark 프로젝트 실행:


여기에서는 Windows에서 Unity를 실행하여 OpenGLES3 그래픽스 API, 멀티 스레드 렌더링, 모노 스크립팅 백엔드를 사용해 Android용으로 빌드합니다.

예: iOS 플레이어를 빌드하기 위해 OSX에서 UnityPerformanceBenchmark 프로젝트 실행


여기에서는 OSX에서 Unity를 실행하여 OpenGLES3 그래픽스 API, 멀티 스레드 렌더링, 모노 스크립팅 백엔드를 사용해 iOS용으로 빌드합니다. 또한 iOS 기기에 배포하기 위해 필요한 Apple 개발자 팀 및 프로비저닝 프로필 정보도 제공됩니다.

위 예의 경우와 같이 Unity 커맨드 라인에서 UnityPerformanceBenchmark 프로젝트를 열면 IPrebuildSetup.Setup 메서드가 파싱 및 플레이어 빌드에 사용할 커맨드 라인 인자가 메모리에 들어 있습니다.

커맨드 라인에서 실행하는 이러한 접근 방식은 Unity 테스트 러너에서 테스트를 실행하기 위해 필수는 아니지만 플레이어 구성마다 별도의 테스트 프로젝트를 사용할 필요가 없다는 점에서 유용합니다.

테스트 프로젝트와 관련하여 프로젝트를 열거나 테스트만 실행하기 위한 커맨드 라인 옵션에 대해서는 wiki의 Unity 퍼포먼스 벤치마크 테스트를 실행하는 방법에서 자세히 설명했습니다. 테스트 프로젝트에서 플레이어 빌드 설정을 파싱하는 방법에 대해 자세히 알아보려면 UnityPerformanceBenchmark 테스트 프로젝트의 Scripts 디렉토리에 있는 RenderPerformancePrebuildStep.cs 파일을 확인하시기 바랍니다.

 

테스트 러너 창 열기

UnityPerformanceBenchmark를 연 후 Unity 에디터에서 Unity 테스트 러너 창을 열어야 합니다.

  • Unity 2018.1에서는Window > Test Runner로 이동합니다.
  • Unity 2018.2에서는Window > General > Test Runner로 이동합니다.

아래 이미지와 같은 Unity Test Runner 창이 열립니다.

테스트 프로젝트가 열린 Unity 테스트 러너

여기에서 Unity 퍼포먼스 테스트 항목을 볼 수 있습니다. 이 테스트는 창 왼쪽 상단에 있는 실행 버튼을 사용하여 에디터에서 직접 실행하거나, 창 오른쪽 상단의 “Run all in player” 버튼을 사용하여 실제 기기나 플랫폼에서 실행할 수도 있습니다.

디버깅 팁

IPrebuildSetup.Setup 메서드에서 코드를 디버그하려는 경우 다음을 수행합니다.

  1. Visual Studio에서 Setup 코드의 브레이크 포인트를 설정합니다.
  2. Visual Studio Tool for Unity 확장을 사용하여 Unity 에디터에 연결합니다.
  3. Unity 테스트 러너 창의 “Run All” 또는 “Run Select” 버튼을 사용하여 에디터에서 테스트를 실행합니다.
  1. 이 시점에 Visual Studio 디버거가 코드에 진입하여 필요에 맞게 디버깅을 수행할 수 있습니다.

 

Unity 퍼포먼스 테스트 예

퍼포먼스 테스트가 어떻게 작동하는지 더 잘 이해하기 위해 퍼포먼스 테스트 예시를 살펴보겠습니다.

예: Unity 퍼포먼스 테스트에서 프로파일러 마커 샘플링


이 예에서는 SpiralFlame_RenderPerformance라는 테스트 메서드를 사용합니다. 메서드 데코레이터 [PerformanceUnityTest]를 통해 Unity 퍼포먼스 테스트임을 알 수 있습니다.

UnityPerformanceBenchmark 테스트 프로젝트의 모든 테스트는 이 테스트 메서드와 동일한 패턴을 따릅니다.

  1. 테스트용 씬을 로드합니다.
  2. 테스트 메서드에서 상호작용할 수 있도록 이 씬을 활성으로 설정합니다.
  3. DynamicRenderPerformanceMonoBehaviourTest 유형의 테스트 오브젝트를 생성하고 이를 테스트 씬에 추가합니다(SetupPerfTest<T> 메서드에서 수행).
  4. 샘플 메트릭을 시작하기 전에 씬을 로드하고 씬에 테스트 오브젝트를 추가한 후 씬이 “안정화”되도록 상수 값으로 설정된 시간 동안 기다립니다.
  5. 퍼포먼스 테스트 확장 프로그램 API에서 캡처가 가능하도록 프로파일러 마커를 설정합니다.
  6. 퍼포먼스 테스트 기능에 메트릭 캡처를 시작하도록 지시합니다.
  7. 렌더링 루프 동안 테스트 오브젝트(IMonoBehaviourTest)를 yield return 문에 사용하여 메트릭을 캡처합니다.

RenderPerformanceMonoBehaviourTestBase 기본 클래스(MonoBehaviour에서 상속됨)에서 커스텀 메트릭(Unity 프로파일러 마커, framecount 또는 실행 시간 중 어느 것에도 속하지 않는 메트릭)도 샘플링해보겠습니다.

예: Monobehaviour 스크립트에서 커스텀 메트릭 샘플링





위의 예에서는 FPS와 GpuTimeLastFrame(XR이 활성화된 경우) 및 애플리케이션 시작 시간(Unity 애널리틱스가 활성화되었으며 필요한 API를 사용할 수 있는 Unity 2018.2 이상을 실행 중인 경우)이 캡처되었습니다.

IsTestFinished 프로퍼티

마지막으로, 동일한 RenderPerformanceMonoBehaviourTestBase 기본 클래스에서 프로퍼티 공개 부울 IsTestFinished를 구현한 것을 확인해보겠습니다. RenderPerformanceMonoBehaviourTestBase가 IMonoBehaviourTest 인터페이스를 구현하기 때문에 이 프로퍼티를 구현해야 합니다.

이 프로퍼티는 Unity 테스트 러너에서 테스트 중지 시점을 파악하는 데 사용되기 때문에 중요합니다. 이 값이 true일 때 테스트가 종료됩니다. Unity 테스트 러너가 테스트 실행을 중지해야 하는 시점을 결정하기 위해 원하는 로직을 구현할지 여부는 개발자가 결정합니다.

예: IsTestFinished 프로퍼티에서 커스텀 메트릭 샘플링


이 마지막 예에서는 테스트를 마쳤을 때 씬에서 렌더링된 게임 오브젝트, 삼각형 및 버텍스의 수를 캡처합니다.

SampleGroupDefinition

메트릭을 샘플링하기 위해 퍼포먼스 테스팅 확장 프로그램을 호출하는 방법의 몇 가지 예를 살펴봤습니다. 이제 이러한 호출을 구성하는 방법부터 알아보겠습니다.

Measure.* 메서드는 일반적으로 SampleGroupDefinition라는 파라미터로 구조체를 가져옵니다. 새로운 SampleGroupDefinition을 만들려면 수집하려는 샘플에 대한 몇 가지 프로퍼티를 정의해야 합니다.

예: GpuTimeLastFrame에 대해 새로운 SampleGroupDefinition 정의(샘플링 단위로 밀리초 사용) 및 최소값을 사용하여 샘플 집계

아래에 표시된 예는 GpuTimeLastFrame에 대한 SampleGroupDefinition입니다. 이러한 프로퍼티를 정의함으로써 퍼포먼스 테스팅 확장 프로그램은 GpuTimeLastFrame용 샘플을 어떻게 수집하고 집계해야 할지 알게 됩니다.

이 SampleGroupDefinition은 동적 씬 렌더 퍼포먼스 테스트 예에 포함된 것으로, 이 정의에서는 수집된 최소값을 사용하여 샘플을 집계하도록 선택했습니다. 그런데, 중간값이나 평균처럼 보다 일반적인 집계 척도를 사용하지 않고 왜 이 방식을 사용할까요?

씬이 동적이기 때문입니다. 동적 씬에서 중간값 또는 평균 집계를 사용하면 항상 변화하는 렌더링의 특성 때문에 동일한 코드에 대해 동일한 씬을 실행할 때 신뢰성이나 일관성이 떨어집니다. 이 방식은 동적 씬에서 렌더링 메트릭의 단일 집계를 추적하려는 경우 가장 추천할 만한 방식입니다. 하지만 정적 씬에 대해 유사한 SampleGroupDefinition을 정의할 때는 당연히 중간값 집계를 사용합니다.


예: FPS에 대해 새로운 SampleGroupDefinition 정의(샘플링 단위로 none 사용) 및 중간값을 사용하여 샘플 집계(값이 증가할수록 더 좋음)

아래에 표시된 예는 FPS(초당 프레임 수)에 대한 SampleGroupDefinition입니다. FPS는 별도의 측정 단위가 없고 그냥 FPS이므로, 여기에서는 SampleUnit.None으로 지정하고, 집계 유형으로 중간값을 사용합니다. 정적 씬이므로, 예기치 않은 렌더링이 발생할 것에 대해 우려할 필요가 없습니다. 샘플 그룹에 대해 15% 한계값을 명시적으로 설정하고, FPS가 높은 것이 좋으므로 increaseIsBetter 인수에 대해 true를 전달합니다.

이 마지막 두 개의 인수는 커맨드 라인에서 실행 시 퍼포먼스 테스트 결과 .xml 파일에 수집 및 저장되고 이후에 Unity 퍼포먼스 벤치마크 리포터에서 벤치마크를 설정하는 데 사용할 수 있습니다.


테스트가 완료되면, 앞에서 활성화한 모든 메트릭 샘플이 퍼포먼스 테스팅 확장 프로그램을 통해 집계됩니다.

측정 유형

코드 예에서 다음과 같은 두 가지의 Unity 퍼포먼스 테스팅 확장 프로그램 API가 사용됩니다.

  • ProfilerMarkers
  • Custom
  • Unity 퍼포먼스 테스팅 확장 프로그램에서는 Unity에서 퍼포먼스를 측정하려는 항목과 방식에 따라 개발자의 구체적인 요구에 부합하는 다른 Measure 메서드도 제공합니다. 예를 들면 다음과 같습니다.
  • Method
  • Frames
  • Scope
  • FrameTimes
  • 다양한 Measure 메서드에 대한 자세한 내용은 Unity 퍼포먼스 테스팅 확장 프로그램 설명서에서 “Taking measurements” 섹션을 참조하시기 바랍니다.

 

Unity 테스트 러너에서 퍼포먼스 테스트 실행

지금까지 Unity 퍼포먼스 테스팅 확장 프로그램에서 Unity 테스트 러너를 사용하여 퍼포먼스 테스트를 작성하는 방법에 대한 몇 가지 예를 살펴봤습니다. 이제 이 테스트를 실행하는 방법을 알아보겠습니다.

퍼포먼스 테스트를 실행할 수 있는 두 가지 주요 방법은 다음과 같습니다.

  1. 커맨드 라인에서-runTests 옵션을 사용하여 Unity를 실행합니다. 이 방법은 퍼포먼스 테스트에서 가장 많이 사용되는 방법으로, Unity 퍼포먼스 테스팅 확장 프로그램에서 결과 .xml 파일을 생성한 다음 이 파일을 Unity 퍼포먼스 벤치마크 리포터에서 사용하여 결과를 보고 비교할 수 있습니다.
  2. 에디터 내에서 직접 실행합니다. 이는 다음과 같은 경우에 유용합니다.
    a. 나중에 사용하기 위해 결과를 캡처할 필요 없이 Unity 테스트 러너 창에서 테스트를 실행하여 결과를 보려는 경우 또는
    b. 테스트가 실행되는지 검증하려는 경우 또는 테스트 코드를 디버그해야 하는 경우

 

-runTests 커맨드 라인 옵션을 사용하여 퍼포먼스 테스트 실행

다음은 Unity 테스트 러너의 커맨드 라인에서 퍼포먼스 테스트를 실행하는 두 가지 방법의 예입니다. 이 예는 이 문서 앞부분에서 커맨드 라인에서 UnityPerformanceBenchmark 프로젝트 열기와 관련하여 사용한 것과 동일한 예를 활용했으므로 상당히 익숙하게 느껴질 것입니다.

예: Windows에서 Android 플레이어에 대해 UnityPerformanceBenchmark 퍼포먼스 테스트 실행

여기에서는 Windows에서 Unity를 실행하여 OpenGLES3 그래픽스 API, 멀티 스레드 렌더링, 모노 스크립팅 백엔드를 사용해 Android용으로 빌드합니다.


예: OSX에서 iOS 플레이어에 대해 UnityPerformanceBenchmark 퍼포먼스 테스트 실행

여기에서는 OSX에서 Unity를 실행하여 OpenGLES3 그래픽스 API, 멀티 스레드 렌더링, 모노 스크립팅 백엔드를 사용해 iOS용으로 빌드합니다. 또한 iOS 기기에 배포하기 위해 필요한 Apple 개발자 팀 및 프로비저닝 프로필 정보도 제공됩니다.


위의 두 가지 예를 통해 IPrebuildSetup.Setup 메서드에서 제공되는 커맨드 라인 인자를 사용하여 Unity 에디터를 열지 않고도 테스트를 실행할 수 있게 하는 서너 가지의 새로운 커맨드 라인 옵션을 보여드렸습니다.

-runTests
이 옵션은 테스트를 실행하도록 Unity 테스트 러너에게 지시합니다.

-testResults <pathToWritePerformanceTestResultsFile>
이 옵션은 Unity 테스트 러너가 퍼포먼스 테스트 결과를 저장해야 하는 .xml 파일의 이름과 경로를 명시합니다.

-logfile <pathToWriteUnityEditorLogFile>
이 옵션은 Unity 에디터가 로깅을 작성해야 할 파일의 이름과 경로를 명시합니다. 이 옵션은 선택 사항이지만 Unity 에디터 로그 파일에 신속하게 액세스하여 장애와 문제를 조사해야 하는 경우에 매우 유용할 수 있습니다.

-batchmode
이 옵션은 Unity 에디터가 헤드리스 모드로 열리도록 합니다. Unity 에디터 창을 열 필요 없이 플레이어 퍼포먼스 테스트만 실행할 때 이 옵션을 사용합니다. 이렇게 하면 자동화된 테스트 실행이 진행되는 동안 시간을 절약할 수 있습니다. 이 옵션을 사용하지 않으면 Unity 에디터가 화면에서 열린 후에 테스트를 실행합니다.

Unity에서 우리는 커맨드 라인에서 퍼포먼스 테스트를 실행하며, 많은 경우 연속 통합 시스템의 배치 모드에서 실행합니다.

예: 커맨드 라인에서 UnityPerformanceBenchmark 테스트 실행

Unity 에디터에서 퍼포먼스 테스트 실행

Unity 테스트 러너 창을 열고 플레이모드(PlayMode)를 선택하면 상단 근처에서 다음 메뉴를 볼 수 있습니다 (PlayMode 테스트는 빌드 플레이어에서 또는 에디터의 플레이모드 창에서 실행됨).

  1. Run All – 플레이모드 탭에 보이는 모든 테스트를 실행하려면 이 버튼을 클릭합니다.
  2. Run Selected – 선택한 테스트나 노드와, 그 하위에 포함된 모든 테스트를 실행하려면 이 버튼을 클릭합니다.
  3. Run all in player – Unity 에디터가 빌드 설정에서 구성된 플레이어 유형을 빌드하고 여기에서 테스트를 실행하도록 하려면 이 버튼을 클릭합니다.
중요한 요구 사항
Unity 에디터의 테스트 러너 창에서 퍼포먼스 테스트를 실행할 때 Unity 퍼포먼스 벤치마크 리포터에 필요한 결과 .xml 파일이 생성되지 않습니다.

퍼포먼스 테스트를 완료할 때 결과 .xml 파일을 생성하려면 -runTests 커맨드 라인 옵션을 사용하고 커맨드 라인에서 Unity를 실행하여 테스트를 실행해야 합니다. 하지만 -runTests 커맨드 라인 옵션을 사용하여 Unity를 실행하면 에디터가 열린 후 테스트가 실행되기 시작한다는 점을 기억해야 합니다.

결과 .xml 파일에는 테스트 실행에서 얻은 결과와 메타데이터가 포함되며, 이를 Unity 퍼포먼스 벤치마크 리포터에서 사용하여 벤치마크 결과를 생성하고 이후 테스트 실행과 비교합니다.

예: Unity 에디터에서 퍼포먼스 테스트 실행

퍼포먼스 테스트 결과 보기

에디터 내에서 이 테스트를 실행하는 경우 Unity 테스트 러너 창 하단 부근에서 각 테스트를 선택하면 집계 값을 볼 수 있습니다.

예: Unity 테스트 러너에서 퍼포먼스 테스트 샘플 집계 보기

커맨드 라인에서 Unity 퍼포먼스 테스트를 실행한 결과를 보려면 Unity 퍼포먼스 벤치마크 리포터를 사용해야 합니다(결과 .xml 파일을 열어도 되지만, 읽기 쉽지 않음).

Unity 퍼포먼스 벤치마크 리포터를 사용하여 결과를 보고 비교할 수 있는 방법에 대해 알아보겠습니다.

Unity 퍼포먼스 벤치마크 리포터 사용

Unity 퍼포먼스 벤치마크 리포터를 사용하면 그래픽 시각화가 포함된 html 보고서로 퍼포먼스 메트릭 베이스라인과 이후 퍼포먼스 메트릭 (Unity 테스트 러너와 Unity 퍼포먼스 테스팅 확장 프로그램을 사용하여 생성됨)을 비교할 수 있습니다.

이 리포터는 .NET Core 2.x 어셈블리로 빌드되어 다양한 .NET 지원 플랫폼(Windows, OSX 등)에서 실행할 수 있습니다. 따라서 리포터를 실행하려면 .NET Core SDK를 설치해야 합니다.

Unity 퍼포먼스 벤치마크 리포터를 실행하면 다음과 같이 dotnet 명령을 사용하여 어셈블리가 호출됩니다:


리포터를 실행한 후에는 html 보고서 및 지원하는 .css, .js 및 이미지 파일이 포함되어 UnityPerformanceBenchmark라는 디렉토리가 생성됩니다. 이 html 보고서를 열고 .xml 결과 파일에서 퍼포먼스 메트릭 캡처의 시각화 내용을 확인합니다.

커맨드 라인 옵션

–results
html 보고서에 포함할 베이스라인이 아닌 결과 .xml 파일이 하나 이상 포함되는 디렉토리의 경로입니다.

UnityPerformanceBenchmarkReporter.dll 어셈블리에 –results 값을 하나 이상 전달해야 합니다. 이 옵션이 유일하게 필수 필드가 됩니다.

이 커맨드 라인 옵션은 또한 베이스라인이 아닌 단일 .xml 결과 파일의 경로를 지정하는 데에도 사용할 수 있습니다. 뿐만 아니라 다음과 같이 옵션을 반복하여 다수의 디렉토리 또는 파일을 지정할 수 있습니다.


–baseline
다른 결과를 비교할 때 사용할 결과 .xml 파일의 경로입니다.

–reportdirpath
리포터가 퍼포먼스 벤치마크 보고서를 생성하는 디렉토리의 경로입니다. 이는 UnityPerformanceBenchmark 하위 디렉토리에 생성됩니다.

보고서 위치가 명시되지 않은 경우 UnityPerformanceBenchmarkReporter.dll이 호출된 작업 디렉토리에 UnityPerformanceBenchmark 하위 디렉토리가 생성됩니다

퍼포먼스 테스트 결과 비교

퍼포먼스 벤치마크 리포터로 몇 가지 퍼포먼스 테스트 결과를 비교해 보겠습니다.

예: VR이 활성화된 Gear VR 씬에서 구성을 변경해 가며 프레임 속도 향상 실험하기

복잡도 특성이 다음과 같은 Unity 씬이 있습니다.

  • 오브젝트 732개
  • 삼각형 95,898개
  • 버텍스 69,740개

Gear VR 씬

이 씬에 대해 Unity 퍼포먼스 테스트를 실행하여 멀티 패스 스테레오 렌더링을 사용해 60FPS 가까이 유지할 수 있는지 여부를 파악하는 데 유용한 메트릭을 샘플링했습니다. 그런 다음, 테스트 결과를 가지고 퍼포먼스 벤치마크 리포터를 실행했습니다.

그 결과, FPS가 원하는 수준의 절반인 30FPS에 가깝다는 것을 알아냈습니다.

다음으로, 싱글 패스 멀티뷰 스테레오 렌더링을 사용하여 60FPS에 어느 정도까지 근접할 수 있는지 확인하겠습니다. 구성을 변경한 후 퍼포먼스 테스트를 다시 실행하여 처음 결과와 새 결과를 비교하는 또 하나의 Unity Performance Benchmark Report를 생성합니다.

멀티 패스 스테레오 렌더링에서 싱글 패스 멀티뷰 스테레오 렌더링으로 전환한 결과

싱글 패스 멀티뷰 렌더링으로 구성을 전환한 후에 FPS가 37로 향상되었습니다. 하지만 이 씬이 Gear VR에서 심각한 프레임 손실 없이 실행되려면 60FPS에 더 가까워야 합니다.

마지막으로 씬에서 회전하는 큐브의 수를 줄인 다음에 FPS가 향상되는지 실험해보겠습니다.

몇 번의 시도 끝에 퍼포먼스를 55FPS까지 높일 수 있었습니다. 하지만 씬의 오브젝트의 수를 732개에서 31개로 줄여야 했습니다. 차이가 상당합니다.

퍼포먼스 최적화를 위해 다른 개선안도 고려해보겠지만 지금은 이 수치를 FPS 베이스라인으로 사용하겠습니다. 앞으로 이 기준을 벤치마크로 사용하면서, 가능하다면 개선해 보겠습니다.

VR 씬에 더 적절한 FPS 실현

벤치마크 설정 및 퍼포먼스 변화 추적

벤치마크를 설정하는 것은 프로젝트에 따라 다양한 의미가 있을 수 있습니다. Unity에서 퍼포먼스 테스트를 실행한다는 것은 이 맥락에서는 베이스라인 결과 세트, 즉 변경을 진행하면서 향후 결과와 비교할 기준이 되는 최종적으로 알려진 양호한 퍼포먼스 메트릭 세트를 설정하는 것을 의미합니다. 이러한 베이스라인 결과 세트가 벤치마크가 됩니다.

이전 섹션에서는 Gear VR에 싱글 패스 멀티뷰 스테레오 렌더링을 사용하는 구성까지 진행해보았습니다. 씬 오브젝트 수를 줄여 “허용 가능한” 수준의 FPS를 실현했습니다. 바로 이 시점에서의 테스트 결과를 벤치마크로 사용하겠습니다. 플레이어 구성을 변경해 가는 동안 이 벤치마크를 어떻게 사용할 수 있을지 예를 들어 살펴보겠습니다.

예: 퍼포먼스 벤치마크를 사용하여 구성 변경에 따른 퍼포먼스 퇴행 감지

씬에서 형상을 부드럽게 다듬기 위해 안티앨리어싱을 활성화하겠습니다. Android용 Unity의 기본 품질 설정은 안티앨리어싱을 비활성화하는 것이지만, 이를 활성화하고 나서도 Gear VR 씬에 허용 가능한 수준의 FPS를 유지할 수 있는지 알아보겠습니다.

먼저, IPrebuildSetup.Setup 메서드에서 안티앨리어싱 값을 4로 설정합니다.


다음으로, 앞에서 했던 퍼포먼스 테스트를 Gear VR이 활성화된 Android 휴대폰에서 다시 실행합니다. 그런 다음 Unity 퍼포먼스 벤치마크 리포터를 사용하여 이 새로운 실행을 새로 설정된 벤치마크 결과와 비교합니다.

안티앨리어싱을 4로 사용하도록 재구성한 후에 FPS의 퇴행 검출

안티앨리어싱을 레벨 4로 사용하도록 Unity 플레이어를 재구성한 후에 FPS가 32FPS로 떨어졌습니다. 처음에 오브젝트 732개를 사용하여 이 씬을 생성했을 때와 거의 비슷한 수준입니다.

여기에서 멈추지 않고 안티앨리어싱 값을 더 낮게 잡아 몇 번 더 실험해서 씬에서 허용 가능한 FPS 수준을 회복할 수 있는지 확인해 보겠습니다. 안티앨리어싱 값을 2로 설정해서 시도하고 마지막으로 1로 설정해 봅니다. 결과는 아래 이미지에서 확인할 수 있습니다.

씬에 허용 가능한 FPS 수준을 회복하기 위해 안티앨리어싱 값을 낮춰서 실험

이 재구성 시나리오에서는 앞에서 설정한 퍼포먼스 벤치마크를 사용하여 Unity 플레이어 설정에서 변경을 적용하면서 실험하는 과정을 통해 커밋 전에 퍼포먼스에 미치는 영향을 검증할 수 있었습니다.

FPS 배리언스가 기본값인 15% 한계값 이내로 유지되기는 하지만 안티앨리어싱을 1로 설정하여 사용하는 경우 FPS가 49로 나와 VR 활성 씬에 대해 원하는 수준인 60FPS와 꽤 차이가 납니다. 아직 이 변경 사항으로 커밋하지는 않을 생각입니다.

결론

Unity는 기본적으로 탁월한 퍼포먼스에 초점을 두고 있습니다. 하지만 Unity 엔진은 궁극적으로 사용자가 개발자의 게임을 플레이하기를 좋아하고, 플레이하는 모든 플랫폼에서 원활한 고성능 경험을 즐길 수 있도록 만드는 요소 중 일부에 불과합니다. 퍼포먼스 퇴행이 나타나지 않고 제대로 작동하는 SDK, 드라이버 또는 Unity 패키지 등은 전반적으로 모두가 양호한 성능을 경험하는 데 있어 매우 중요합니다.

지금까지 보다 손쉽게 퍼포먼스 메트릭을 수집하고 이를 사용하여 벤치마크를 생성하는 데 도움이 되는 Unity 퍼포먼스 테스팅 확장 프로그램 및 Unity 퍼포먼스 벤치마크 리포터라는 Unity 툴을 소개했습니다. 퍼포먼스가 중요한 작업에 어떠한 도움이 되는지 실험을 통해 알아보실 것을 권장합니다.

지금까지 살펴본 내용을 요약하면 다음과 같습니다.

  • Unity 테스트 러너를 사용하여 프로파일러 및 기타 메트릭을 샘플링하기 위한 퍼포먼스 테스트를 작성하는 방법
  • Unity 테스트 러너를 사용하여 퍼포먼스 테스트를 실행할 수 있는 몇 가지 방법
  • Unity 퍼포먼스 벤치마크 리포터를 사용하여 퍼포먼스 메트릭을 분석 및 비교하고, 반복 실행을 통해 퍼포먼스 테스트 결과를 향상하는 방법

이러한 메트릭의 베이스라인을 설정하고 이 베이스라인을 사용하여 씬, 게임, SDK, 드라이버, 패키지 또는 다른 Unity 통합 기능에 대한 벤치마크를 생성하면 변경이 미치는 영향을 효과적으로 파악할 수 있습니다. 행운을 빕니다!

이 작업에 함께 참여하여 브레인스토밍과 실험, 개발 및 반복 작업에 도움을 주신 Unity 동료분들께 감사의 마음을 전합니다.

  • Qi Jiang
  • Sakari Pitkänen
  • Gintautas Skersys
  • Benjamin Smith

13 코멘트

코멘트 구독

코멘트를 달 수 없습니다.

  1. This is really cool and I’ve got my setup working pretty nicely. Is there any way to specify baseline values for each metric without having to produce an xml file using the tool? Having to fudge it so you get roughly the right numbers by turning stuff off seems like a really roundabout way of setting targets. I’m working on a project that has very hard limits on draw calls and frame time so would like to just set those manually somewhere.

  2. How can we, the Unity community, contribute performance tests that you’ll include in your test suite?

    1. Hi Peter, if you have a good idea for test contribution, please first take a look at this doc in the root of the test repository: https://github.com/Unity-Technologies/XRAutomatedTests/blob/2018.2/CONTRIBUTIONS.md

      Thanks for considering adding to the performance test suite.

  3. Hey, Thanks for the article, very excited to try to get this setup. Unfortunately when I try to run the tests from batch mode Unity closes almost immediately and I hit this error in logs:

    [Package Manager] Server::Kill — Server was shutdown
    Cleanup mono
    debugger-agent: Unable to listen on 37
    [usbmuxd] Stop listen thread
    [usbmuxd] Error:
    [usbmuxd] Listen thread exiting

    Before any tests are run.

    If I open the project manually and run the tests they all work fine but it means I’m unable to produce the results.xml, any idea what might be causing this?

    Unity 2018.2.7f1, OSX Mojave

    1. Hi Matt –

      Thanks so much for giving this a spin. I’m sorry you’re hitting some snags along the way, but would like to help see if we can get them resolved.

      In the article, I mention launching the tests without the “-runTests” and “-batchmode” arguments. When you do this, you can then launch the tests from the Unity Test Runner and if there are other issues, it’s more visible from the Console output, etc. Would you mind giving that a try, and then see if anything more obvious in the way of errors come to the surface?

      Also, I’m curious, just so I can try to repro the condition, which platform and configuration you’re trying to build the player for.

      Good luck, and hope to hear back.

  4. Also, there’s a typo on the “Unity test runner” documentation page: https://docs.unity3d.com/Manual/PlaymodeTestFramework.html
    The command line argument is called runTest but it should be runTests (as shown in the examples). Please fix this :)

    1. Hi Lior, thanks for noticing and reporting this discrepancy. I’ve notified the team about the documentation error.

    2. Hi Lior, we’ve updated the documentation to use the correct command line argument. Thanks!

  5. Paragraph about debugging IPrebuildSetup.Setup is written twice.

    1. Thank for the catch, Lior. Should be updated now.

  6. What about real users performance?
    It will be cool see it in analytics

  7. I am sorry to comment here about this but please fix the bug that Unity stuck and EditorOverhead takes up 99.8% of process when Profiler is opened.
    https://forum.unity.com/threads/2017-3-editor-overhead-performance-degradation.509821/
    It exist in many versions including LTS builds.

    1. Hi Ren –
      Shanti addressed several of the comments in the forum post you linked to: https://forum.unity.com/threads/2017-3-editor-overhead-performance-degradation.509821/

      Please take a look at his response as it may help to understand some of the issues you’re seeing.