퍼포먼스 확장: 언리얼 엔진 4.26의 시퀀서

 
섹션은 일반적으로 각 트랜스폼, 프로퍼티, 애니메이션이 타임라인에서 취해야 할 상태를 정의하는 키프레임 데이터와 기타 프로퍼티를 포함합니다. 게임 내에서 시퀀스를 재생할 때, 엔진은 이 모든 트랙과 섹션으로 게임 월드에서 원하는 오브젝트에 의도된 상태와 프로퍼티를 적용합니다.

4.26 이전 버전에는 각 트랙과 섹션마다 특정 시간에 평가하고 원하는 오브젝트에 프로퍼티를 적용하기 위한 모든 데이터와 로직이 담긴 자체 런타임 인스턴스가 있었습니다. 이런 인스턴스는 기존의 오브젝트 지향 패러다임을 사용하도록 설계되어 가상 API를 통해 액세스되었습니다. 이 접근법은 트랙이 적은 경우에는 무난한 퍼포먼스를 내지만, 트랙 수와 상대적 복잡성이 높아질수록 퍼포먼스가 저하됩니다. 나아가 다수의 애니메이션이나 시퀀스를 병렬로 실행하면 각 인스턴스의 파이프라인이 초기화되어 높은 퍼포먼스 비용이 누적됩니다.

많은 CPU 프로파일 데이터를 액세스할 수 있게 되면서, 가상 함수 호출의 내재적 오버헤드와 열악한 캐시 집약성으로 인해 최적화를 위한 노력의 효과가 스케일의 확장에 따라 크게 감소한다는 사실이 분명해졌습니다. 또한, 트랜스폼 트랙과 같은 트랙은 블렌딩, 일부만 애니메이팅한 트랜스폼, 상대 트랜스폼 원점, 어태치먼트, 컴포넌트 속도 등 처리해야 하는 요소들이 점점 증가하며 부담이 심해지고 있었습니다.

그래서 이런 콘텐츠를 콘솔 및 모바일 하드웨어상에서 여타 게임 시스템과 함께 실시간으로 실행하는 데 필요한 최적화를 실현하려면 보다 시스템적인 재설계가 분명히 필요했습니다.
 

속도 지향 설계

시퀀서 런타임의 새로운 토대를 살펴볼 때는 다음과 같은 설계 목표에 집중하였습니다.

확장성
새로운 런타임의 도입으로 수백 개의 트랙 및 시퀀스를 가진 콘텐츠를 제작하고 이런 콘텐츠를 전체적으로 평가하는 로직의 최적화도 가능해졌습니다. 여기에는 다음을 포함합니다.

• 활성 시퀀서 트랙의 개수로 인해 퍼포먼스가 빠르게 저하되지 않도록 데이터를 할당하고 구성합니다.
• 프레임별로 필요한 비용에 비해 필수적이지 않다고 확인된 로직과 브랜치를 완전히 제거할 수 있습니다. 가장 빠른 코드란 없습니다. 이건 시퀀서 평가 코드의 가장 표면적인 부분뿐만 아니라 모든 측면에 적용 가능합니다.
• 평가 로직은 복잡하거나 비효율적인 추상화를 통한 메모리 상호작용 없이도 일괄적으로 필요한 데이터에 직접적으로, 효율적으로, 아무런 방해 없이 액세스할 수 있어야 합니다.

동시성
평가 로직 작성은 단순해야 하고 안전하고 효율적인 방식으로 다수의 코어로 자연스럽게 확장해 나가야 하며, 상하향 종속성의 표현적 정의(예를 들어, 모든 커브의 병렬적 평가 등)를 포함해야 합니다. 이를 통해 파이프라인을 단 한 번만 구성하면 된다는 종합적인 장점 덕분에 다수의 소규모 애니메이션과 초대형 시퀀스에서 이점을 얻을 수 있습니다.

확장 가능성
핵심 시스템을 재구현하지 않아도 기본 기능에 로직을 빌드할 수 있어야 합니다. 핵심 기능과 상호작용하는 상하향 기능은 적정한 선에서 추가할 수 있어야 합니다. 여기에는 다음을 포함합니다.

• 현재 프레임의 모든 데이터가 파이프라인의 어떤 지점에서든 분명하게 표시되면서 변경 가능해야 합니다.
• 안정적으로 종속성을 관리합니다.

이런 설계 목표와 시퀀서의 문제 영역은 다음과 같은 이유로 인해 자연스럽게 데이터 지향 설계 법칙을 고려하게 되었습니다.

• 시퀀서의 주요 데이터는 동질적이며 순차적 배치가 가능합니다.
• 일반적으로 각 데이터 변환 로직이 매우 독립적이며 컨텍스트에 구애받지 않습니다(예를 들어 커브의 f(x) 실행 등).
• 제어 및 데이터 플로가 매우 선형적이며, 순환 또는 재귀적 종속성이 없습니다(예를 들어 이미 계산된 값의 재계산이 필요한 로직이 없음).
• 초기 구성과 최종 프로퍼티 설정자에만 스레딩 제한이 있습니다.

4.26 버전에서는 시퀀서의 기반이 되는 런타임이 재설계되면서 엔티티 컴포넌트 시스템 패턴 기반의 평가 프레임워크를 통한 캐시 효율적이고 투명한 방식으로 평가 데이터를 내놓게 되었습니다. 내부에서 템플릿이라고 부르는 트랙 인스턴스에는 더 이상 평가가 필요하지 않습니다(하지만 레거시 런타임은 여전히 새 시스템과 함께 실행됩니다). 대신 각 트랙 유형별 데이터와 로직이 분리됩니다. 엔티티는 이제 소스 트랙 데이터와 관련된 컴포넌트 파트를 나타내며, 시스템은 특정 컴포넌트 또는 컴포넌트 조합과 관련된 단일 로직 데이터 변형을 나타냅니다. 이제 시스템에서 쿼리와 일치하는 모든 데이터를 일괄 실행합니다. 덕분에 모든 트랜스폼 프로퍼티를 캐시 효율적으로 적용하거나 한 번의 가상 함수 호출만으로 모든 플로트 채널을 평가할 수 있게 되었으며, 애니메이션이 적용되는 트랜스폼 프로퍼티의 수에 상관없이 캐시 누락이 거의 발생하지 않습니다.

그 결과 4.26 버전부터는 마이그레이션된 트랙 유형에 대한 시퀀서의 대규모 콘텐츠 평가 오버헤드가 획기적으로 감소하였습니다.

또한, 이런 접근법 덕분에 여러 시퀀스나 위젯 애니메이션에 대한 평가 데이터가 한데 통합되어, 실행되는 전체 애니메이션 세트의 최적화 가능성이 더욱 커졌습니다. 이로 인해 예전보다 더 많은 위젯 애니메이션을 동시 실행하는 것이 가능해졌으며, 필요에 따라 다수의 개별 애니메이션이나 시퀀스를 함께 블렌딩할 수도 있습니다.

파이프라인 예시
모든 트랜스폼 트랙의 평가에 쓰이는 파이프라인 예시를 하나 살펴보겠습니다. 시퀀서의 트랜스폼 트랙은 키프레임 채널 1~9개의 컴포짓 플로트, 즉 X/Y/Z 위치, 롤/피치/요(Yaw) 회전, X/Y/Z 스케일로 구성됩니다. 오브젝트에 트랜스폼을 적용하려면 우선 현재 시점에 이 커브들을 평가한 다음, 그 결과로 'USceneComponent::SetRelativeTransform'을 호출해야 합니다. 4.26 이전에는 이 채널 데이터가 템플릿 오브젝트에 복사되었는데, 템플릿 오브젝트는 최대 9개의 채널과 각 채널을 평가하고 오브젝트에 적용할 로직을 포함했습니다.

새로운 접근법은 다음과 같은 이유로 인해 획기적으로 개선되었습니다.

• 문제, 데이터, 인스트럭션 캐시 집약성이 개선되었으며 스케일에 따라 훨씬 더 빠른 속도를 보여줍니다.
• 가상 함수 호출의 수가 개별 트랙 수가 아닌, 활성 시스템 유형에 따라 확장됩니다.
• 전체 데이터 규모가 아니라 컴포넌트 데이터의 조합 수에 비례하여 캐시 누락이 발생합니다.
• 최적화가 각 트랙에 제한되지 않고 전체 데이터 세트에 걸쳐 발생할 수 있습니다.
• 로직에 특별한 변화 없이, 파이프라인의 일부가 동시에 수행될 수 있습니다.

예를 들어 위 예시의 ‘플로트 채널 평가’ 시스템은 현재 프레임의 모든 플로트 채널을 병렬적으로 평가할 수 있으며, 여기에 각 플로트 채널이 어떤 프로퍼티에 애니메이션을 부여하는지 또는 어떤 방식으로 조합 또는 적용되었는지는 아무런 상관이 없습니다.

나아가 다수의 트랜스폼을 단일 오브젝트로 블렌딩하는 것처럼 중간 데이터 변형을 도입하는 작업이 훨씬 더 간단하고 세분화되었습니다.

4.26 이전 버전에 이런 기능은 모든 프로퍼티 유형에 대한 모든 입/출력을 저장 및 처리하는 전용 클래스에 구현되어 있었습니다. 하지만 소규모 할당 최적화 및 다이내믹 디스패치의 비용으로 스토리지 및 CPU 오버헤드가 발생하기도 했습니다. 또한, 블렌딩 코드 경로를 고려한 방식으로 프로퍼티 적용을 구현해야 했으며, 이로 인해 블렌딩이 아닌 일반 코드 경로를 더욱 복잡하게 만들고 저하시켰습니다.

메모리 레이아웃

시퀀서 메모리에서 평가 데이터가 어떤 모습인지 좀 더 자세히 살펴보겠습니다. 레이아웃 데이터 접근법을 다양하게 시도해 보면서 메모리 크기, 캐시 효율성, 재할당 비용 그리고 동시 액세스 등을 적절히 조율한 끝에 다음과 같은 데이터 모델에 정착하였습니다.

엔티티는 일괄적으로 엔티티 할당으로 그룹화되며, 각 할당에는 최소 하나 이상의 엔티티가 포함됩니다. 결정적으로 할당 내의 모든 엔티티에는 정확히 똑같은 수와 유형의 컴포넌트가 있습니다. 특정 엔티티로부터 컴포넌트가 추가 또는 제거된다면, 이는 다른(또는 새로운) 할당으로 이주됩니다. 할당은 준비된 커패시티에 따라 크기가 유동적으로 변하면서, 메모리 할당(malloc) 호출 없이도 새로운 엔티티가 추가될 수 있도록 합니다(필요한 것은 컴포넌트 데이터의 초기화뿐입니다).

보시다시피 동일한 유형의 모든 컴포넌트는 한 할당 내에서 순차적으로 배치됩니다. 컴포넌트 A, B, C를 포함한 할당에 대한 결과는 AAA..A, BBB..B, CCC..C의 레이아웃으로 나타나며 각 유형은 캐시 라인에 정렬됩니다. 이런 방식으로 데이터를 정리하면 엔티티의 ID에 전혀 영향을 미치지 않고 엔티티 데이터의 위치를 제어할 수 있으며, 각 컴포넌트 배열에 대한 읽기 및 쓰기 액세스도 제어 가능할 뿐 아니라(지금으로선 뮤텍스(mutex) 방식이지만, 나중에 충돌이 문제가 될 경우 특화된 스케줄러로 확장될 수도 있음) 유형 간의 패킹을 잘 유지할 수 있습니다. 시스템에서 컴포넌트 A 및 B에 대한 모든 컴포넌트 데이터가 필요하다면 비트 마스크에 따라 결정되는 할당 유형만 확인하면 됩니다. 이를 통해 시스템은 수천 개가 될 수도 있는 내부 엔티티가 현재 필요한 유형과 일치하는지 즉각적으로 파악할 수 있습니다.

이런 패턴 일치 접근법은 데이터 변형 로직을 데이터의 구성으로부터 완전히 분리하여, 시스템이 스케일의 확장에도 퍼포먼스를 유지하면서 관련 없는 부분과는 상관 없이 다양한 컴포넌트 데이터 조합에도 병렬 작업을 할 수 있게 해 줍니다. 위 예시를 더욱 확장하고자 트랜스폼 원점을 기준으로 트랜스폼 트랙을 만들 수 있는 시스템을 추가하는 일은 굉장히 간단하며 핵심 트랜스폼 시스템에 대한 무리한 변경이 필요하지 않습니다.

스레딩

이제 읽고 쓸 수 있는 컴포넌트의 유형 관련 로직을 정의할 수 있게 되었으니, 컴포넌트 데이터에 대한 업스트림 및 다운스트림 종속성도 정의할 수 있습니다. 이를 통해 이런 데이터 변환을 올바른 비동기 태스크 그래프에 안전하게 자동 디스패치할 수 있게 되었습니다. 다수의 복잡한 키프레임 커브를 가진 콘텐츠처럼 규모가 큰 데이터 세트를 평가할 때, 이런 커브의 평가는 이제 다른 계산과 함께 비동기 실행이 가능하여 플랫폼에서 허용하는 동시성을 활용할 수 있습니다. 이건 컨텍스트 변경이나 스레드 선점의 잠재적 비용이 합리적일 때만 이로운 효과를 볼 수 있으나, 시퀀서의 스레드 세이프 설계는 이런 결정을 내부적으로 내리거나 사용자의 재량에 따라 결정할 수 있게 해 줍니다.

시퀀서로 작업하는 프로그래머를 위한 보다 포괄적인 아키텍처 해설은 앞으로 더 자세하게 공개될 예정입니다.
 

구형 런타임 시스템으로부터 4.26을 향한 비헤이비어 변화

일반적으로는 비헤이비어상의 어떤 변화도 체감되지 않을 것입니다. 스포너블(spawnable), 어태치먼트, 트랜스폼, 그 외 기타 프로퍼티는 전부 이전과 똑같이 작동하게 됩니다. 하지만 아래와 같이 비헤이비어에 아주 미묘한 변경 사항이 있습니다.

• 주어진 유형의 활성 시퀀스가 이제 전부 동시에 평가됩니다. 4.26 이전에는 두 개의 개별 활성 시퀀스가 동일한 오브젝트에서 동일한 프로퍼티의 애니메이션을 제작한다면 각각 별개로 평가되어야 하기 때문에 프로퍼티의 제어권을 두고 충돌이 일어납니다. 4.26에서는 이런 시퀀스가 함께 평가되면서 서로 자연스럽게 블렌드됩니다. 앞으로는 더욱 확장되어 시퀀스 상호간 블렌드나 오버라이드에 대한 제어도 가능해집니다.
  • 모든 활성 위젯 애니메이션이 이제 함께 평가됩니다.
  • 모든 활성 레벨 시퀀스가 이제 함께 평가됩니다.
• 시퀀스나 위젯 애니메이션의 수동 재생, 정지 또는 위치 설정은 더 이상 해당 함수의 호출에서 시퀀스를 동시에 재평가하지 않습니다. 그 대신 시퀀스 플레이헤드의 재생 및 이동 요청이 다음 프레임까지 연기될 수 있습니다.
  • 이 기능을 특정 시퀀스에서 비활성화하려면 시퀀스의 비동기 평가 옵션을 비활성화하면 되며, 퍼포먼스 비용이 듭니다. 이 경우 동기 재평가를 강제하면서 앞서 (1)에서 설명했던 블렌딩 비헤이비어가 비활성화됩니다.

 

• 시퀀스 평가 관련 재진입을 일으키는 이벤트 트랙(타 시퀀스 재생, 재생 상태 변경, 플레이헤드 이동 등)은 이제 사후 평가 위치로 제한됩니다(즉, 더 이상 PreSpawn이나 PostSpawn에서 허용되지 않습니다). 이는 이제 새 이벤트 트랙의 기본 설정입니다. 4.26 이전에는 이벤트 트랙이 기본적으로 PostSpawn으로 설정되었습니다. 기존 트랙은 계속 PostSpawn 설정을 유지하지만, 새 트랙은 이제 PostEval이 기본 설정입니다.

 
이 정보가 재미있으면서도 유익하길 바랍니다. 시퀀서에 대해 더 자세히 알아보려면 툴의 문서 페이지를 확인하세요.