[Unity Sentis] 유니티 센티스 성능 비교 + (Feat, 성능 프로파일링과 최적화 리뷰)

---

Unity Sentis Profiling

Unity Technologies

---

서론

이전 Unity Sentis 소개 및 설치 + AdaIN 샘플 소개 글을 작성하고 나서... 바라쿠다와의 성능 비교를 같이 진행하고자 하였다. 하지만 무슨 일인지... 도저히 성능 비교가 생각대로 나오지 않아서 우선 튜토리얼 글만 작성하게 되었다.

[Unity Sentis 튜토리얼] Unity Sentis 소개 및 설치 + AdaIN 샘플 소개

 

성능 비교

 

가장 큰 목적은 유니티 AI 센티스에서 이야기하는 바라쿠다와 센티스의 성능비교이다. 바라쿠다 보다 빨라졌다고 하는데... 게임이 출시될 때도 권장 성능이 있지만 실제 유저들이 개개인의 그래픽카드로 테스트를 해보지 않는가? 동일하게 개발팀의 일방향적 의견이 아닌 내가 직접 테스트를 진행해보고 싶었다.

 

우선 이를 위해 바라쿠다로 Inference (추론)한 AdaIN 결과를 불러와 보니 다음과 같았다. Iworker를 실행하고 Output을 얻는 것까지 9.58ms가 소요되었다.

 

 

마찬가지로 Sentis를 확인해본 결과 이전의 Peek Out에서 344.20ms가 소요된 것을 확인할 수 있었다. 이는 약 36배가 느려진 것인데... 이 부분에서 막혀서 더 이상 진행을 하지 못하였다.

 

문제점

 

이 당시 나는 바라쿠다를 사용할 때 다음과 같이 Type에 ComputePrecompiled (GPU)를 사용하였다.

var worker = WorkerFactory.CreateWorker(WorkerFactory.Type.ComputePrecompiled, model)

 

하지만 이 후 센티스를 사용하면서 "이전에 바라쿠다를 사용했지?" 라고 오해를 하였고 Sentis의 CPU와 비교를 한 것이였다.

 

이 후 센티스 문서를 참고하여 GPU로 코드를 수정하였고, 그 결과 다음의 결론에 도달했다.

Enum BackendType | Sentis | 1.2.0-exp.2

 

m_Engine = WorkerFactory.CreateWorker(BackendType.GPUCompute, m_RuntimeModel);

 

 

모델 성능에 걸리는 시간이 9.58ms에서 0.42ms로 대폭 감소했다. 약 95% 성능 개선... 모델 마다 차이는 있겠지만... 단순하게 이름만 바꾼 것이 아닌 대폭적인 성능 향상이 있어서 놀랐다. 다른 프레임 및 여러 환경을 테스트해 보아도 결국 0.4~0.5ms도 센티스의 GPU 성능이 훨씬 좋다는 것을 확인할 수 있었다.

 

성능 프로파일링과 최적화 리뷰

 

업무를 하다보면 내가 알고 있는 것과 내가 아는 것을 잘 설명하는 것은 매우 다르다고 느꼈다. 그 이후 부터 책 또는 강의를 보면서 단순하게 내용적인 부분에 치중하는 것이 아닌 "왜 이러한 개요로 발표를 하실까?" 와 같은 생각을 많이 했던 것 같다. 오늘 포스팅에서는 성능 프로파일링을 리뷰해보도록 하자.

 

본 포스팅에서 다루는 리뷰는 유니티코리아 오지현 시니어 에반젤리스트님의 Dev Weeks: 성능 프로파일링과 최적화이다.

 

본론

--- 영상 서론 ---

• 타켓 플랫폼과 기능 상세의 선행 조사
  • 타겟 플랫폼이 정확하지 않은 고객들이 많았다. 미팅시 이 부분 재차 질문할것!
  • 타겟 프레임 확인도 중요하다.
  • V Sync 제한사항도 확인할 것
• 텍스쳐가 병목이 아닐 수도 있다. 추측에 의한 최적화 금지!
  • 인더스트리의 경우 CAD 모델 그리고 텍스쳐를 많이 생각하는데 텍스쳐가 100% 병목이 아닐 수도 있음
    엔비디아의 포커스 프로파일링도 볼 것!
• 개발 막바지에 하지 말 것! 그렇다고 POC 레벨의 프로젝트에서 진행할 필요는 없다.
  • POC 레벨에서는 재미만 볼 것, 인더스트리의 경우 원하는 기능대로 작동하는지만 확인
• 에디터에서의 프로파일링은 최종 결과물이 될 수 없음. 타겟 플랫폼에서 꼭 프로파일링 해볼 것
  • 모바일의 경우, 쓰로틀링 발열시 CPU 성능을 낮추는 기능이 있음 이 경우 외부 쿨러 장착 후 테스트 하기
  • 에디터는 성능 제한 또는 시뮬레이션 기능이 있음. 라이트닝 생각하자! 텍스쳐 압축시에도 그 결과를 시뮬레이션 하는 결과임 따라서 에디터는 참고용

--- 프로파일링 설명 ---

 

• 프로파일러 할 때 Profiler.BeginSammple 및 EndSample을 이용해서 코드에 따른 프로파일링 값을 볼 수 있음
• 병목 지점 찾기 이 둘은 병렬적인 형태로 일을 함.
  • CPU 병목? (CPU 바운드) Graphics.BlitDevice.Present (CPU는 일을 다 하고, GPU가 일하는 것을 기다)
  • GPU 병목? (GPU 바운드)
    
    • GPU 프로파일링은 벤더 툴을 이용하는 것이 좋다 또는 추측하는 방법...
    • 대신 Resolution Scaling을 사용하는 방법이 있음. Fillrate = 픽셀 수 x Fragment Shader x 오버드로우를 줄였을 때 성능이 개선됐다? -> 유추 가능
    • 오버드로우
      Transparent의 경우 뒤의 오브젝트를 그리고 앞에 오브젝트도 같이 그러야함. 이는 overdraw의 요소가 됨.
      실제로 간단한 오브젝트 몇개가 병목이 되지는 않음. 하지만 이펙트가 된다하면 엄청난 병목이 될 수 있음.
      Overdraw 뷰가 별도로 있는 것 기억하기!
    • PP (Post Processing)
      픽셀에 여러 효과가 들어가는 경우, 퀄리티에 부담이 됨.
• Profile Analyzer
  • Porfiler 확장 기능, 결과물을 캡쳐해서 수정전과 수정후 상황을 비교할 수 있음.

--- 메모리 프로파일러 ---

 

안드로이드에서는 매우 중요 실제 가상메모리 시스템이 PC와 같이 작동하지 않기 때문

 

• 부분적으로 빈 텍스쳐가 메모리를 크게 잡아먹을 경우
  • Atlas 기능 사용하기 
  • ETC 사용할 때 OpenGL 버전 확인
    
    
• 오디오 클립 올릴 때 Load Type 체크해야 함 Decompress On Load는 작은 효과음
  
  
• Mesh가 메모리를 많이 잡아 먹을 경우
  
  • Read/Write Enabled 끄기 (최신 버전에서는 꺼져 있음)
    • API를 통해서 Mesh에 접근해야 하는 경우 켜기 -> GPU 및 CPU에 데이터가 올라감. Mesh Deformation을 제외한 경우에 모두 꺼줄 것

--- Texture Compression ---

 

• 대부분의 경우 텍스쳐가 문제가 됨. PNG, JPG는 하드 데스크에서 용량을 아끼기 위해서 사용, GPU에서 읽을 수 있는 전용 포맷으로 사용해야 함 (ETC, ASTC 등)
  
  
• PVRTC (2개의 대표 색상을 뽑아서 decoding 진행) 4x4 pixel
  
  
• ETC (Base color, per-pixel luminance 즉 색상과 밝기로 사용) 4x4
  
  
• POT (Power of 2) 2D의 N승....으로 꼭 해야함 아니면 빈공간 생성
  
  
• ASTC -> Block 크기 가변형으로 설정 가능 (4x4, 5x5, 6x6, 8x8)

--- Frame Debugger ---

 

DrawCall이 많을 경우 확인할 수 있음. 각각의 프레임이 어떻게 그려지는지 확인 가능