Yaft 개발로 보는 Cross Platform SDK 개발기

#Softwareengineering #Middleware

카카오브레인에서 Yaft라는 사람의 얼굴, 몸을 인식하여 그에 맞추어 렌더링해주는 멀티 플렛폼 SDK를 개발하고 있습니다. 이 SDK를 개발하며 겪은 결정 사항들과 관련된 내용을 공유합니다.

발표자 : deadlock.yoon
카카오브레인 Digital Human Studio의 Deadlock입니다. C/C++ 개발자 이며, emacs를 사용하고 있습니다.

Transcript

1. 황광윤 Deadlock.Yoon 카카오브레인 Copyright 2022. Kakao Corp. All rights reserved. Redistribution or public display is not permitted without written permission from Kakao. Yaft 개발로 보는 Cross Platform SDK 개발기 if(kakao)2022
2. Yaft란?
3. Yaft란 무엇인가요? 영상 인식과 영상 효과를 위한 Cross Platform SDK 다양한 Platform (iOS, Android, Mac, Windows) 위에서 Application들에게 Yaft는 동일한 기능을 API로 제공합니다.
4. Yaft를 만들 때의 요구 사항
5. - (비교적) 빠르게 상품화 수준으로 만들 수 있을 것 - 속도가 빠를 것 (Mobile에서 real - time 구동이 가능해야 함) - Multi - platform을 지원할 것 - Android, iOS, Mac(x86_64, ARM64), Windows(x86_64) - 앱에서 쉽게 사용할 수 있을 것. (추가 그래픽스 작업 없이 쉽게 연동할 수 있을 것) - 지적 재산(모델)을 보호할 수 있을 것 - 다양한 기능 (모델들) 을 빠르게 만들 수 있을 것 - 바이너리 크기는 최대한 줄일 수 있을 것 주요 요구사항
6. - 기존 Open Source Project들을 적극적으로 고려한다. - 필요한 기능의 대부분은 이미 세상 어디엔가는 구현되어 있거나 구현 중 - Don't reinvent the wheel - Multi - Platform 지원을 하고 있는 inference 용 library와 rendering용 library가 필요함 - Inference의 경우 빠르게 기능을 구현하고 테스트할 수 있으며, 안정적인 framework가 필요함 - 다양한 기능 (모델들) 을 빠르게 만들 수 있을 것 - Rendering의 경우 PBR을 지원하며 안정적인 framework이 필요 - PBR (Physically based rendering) 요구 사항을 만족 시키기 위해 선택한 방안
7. Inference: Google’s MediaPipe Open Source Cross Platform Framework Multi Platform을 지원 Protobuf를 이용하여 ML application을 작성 실시간 영상 처리가 주요 목표 1) Google MediaPipe Project, https:/ /mediapipe.dev/ | 2) https:/ /google.github.io/mediapipe/solutions/face_mesh 2)
8. MediaPipe Graph 예제 node { calculator: "InferenceCalculator" input_stream: "TENSORS:input_tensors" output_stream: "TENSORS:detection_tensors" options: { [mediapipe.InferenceCalculatorOptions.ext] { model_path: "mediapipe/modules/face_detection/ face_detection_short_range.tflite" } } }
9. Rendering: Google’s Filament Open Source, Cross - Platform Rendering Engine Real - time, Physically Based Rendering 기본적으로 Android에 최적화를 목표로 하고 있으나 iOS, Linux, macOS, Windows 등을 지원 더 자세한 내용은 Danny의 좌충우돌 애니모지 개발기를 참고해 주세요. 1) Google Filament Project, https:/ /github.com/google/ fi lament 1)
10. 그러면 모든 문제가 해결되었나요?
11. - MediaPipe는 Bazel build system, 다른 대부분의 library는 CMake - Bazel Build System의 목표는 빌드의 결과물이 하나의 Application. Library는 상정하지 않음 - Monorepo를 통해 iOS/Android Application을 만드는 것이 목표 - Project를 시작하였을 때, Bazel 자체가 안정된 상황이 아니었기에 전체 Project는 CMake를 사용 - MediaPipe의 Bazel Build script에 extension으로 static library을 생성하도록 작업 - 불필요한 코드는 link - time optimization을 통해 제거 Build System
12. - 각 Platform 및 device마다 ML 성능이 어떻게 되는 지 알 필요가 있었음 - 대표적인 기종들을 선정하여 benchmark를 통해 성능 특성 정보를 확인 - 모든 device 에 대해 최적화하는 것은 가진 자원으로 불가능 했기에 평균적으로 빠른 backend를 선정 - Android 의 경우 OpenGL 혹은 OpenCL을 사용 시 최초 ML kernel을 compile 시 시간이 오래 걸리는 문제 - Compile된 OpenCL kernel을 cache하여 차후 실행 시 initialization 을 최소화 Inference의 속도 및 Initialization 문제
13. Inference: OpenCL/Metal이 항상 빠를까? 모델이 충분히 작을 경우 [ex) 0.53 MMAC] CPU <- > GPU 간의 upload 및 synchronization이 더 큰 overhead 결론: 현재 데이터의 위치 (CPU/GPU)와 백엔드에 따른 속도에 따라 모델을 수행할 적절한 백엔드 선택 Backend 수행 속도 CPU 337.401us OpenCL 1309.06us, 1372.9us (low precision) OpenGL 2098.95us, 1743.54us (low precision) NNAPI 2242.31us CPU - XNNPACK 158.107us Benchmarked on Google Pixel 3a with 0.53 MMAC model
14. - 각 Platform 별 CI/CD 환경 셋팅 및 테스트 - Github Actions를 통해 on - device test 환경 설정 - 각 Platform 마다 다른 언어로 API 제공 필요 - Android: Java - JavaDoc - iOS/Mac: ObjC, Swift - Xcode documentation 그 외 해결해야 할 사항들
15. 공짜 점심은 없었습니다
16. - MediaPipe의 경우, 다양한 DL 모델을 이용해 빠르게 prototyping하는 것이 목표 - protobuf를 이용해 전체 graph를 빠르게 작성할 수 있고 bazel을 통해 iOS, Android용 어플리케이션 빠르게 테스트해 볼 수 있음. - 다른 project에서 중간 library로 사용되는 것은 프로젝트의 목표로 상정되지 않음. - runtime에 dynamic 하게 graph가 생성되기 때문에 수행속도에 패널티가 있음. - Mac 및 Windows의 경우 OpenCV위에서 동작하여 image processing 속도에 한계가 있음 - Windows의 경우 experimental stage. 기존 Open Source Project의 이용만으로 충분한가? (1)
17. - Filament - 최대한 많은 device에서 빠른 속도로 3D rendering을 하기 위한 library - 대부분의 backend를 지원함 (OpenGLES, Metal, Vulkan 등) - 최대한 많은 device를 지원하기 위해 OpenGLES의 minimum version이 낮게 설정되어 있음 - OpenGLES 3.0에 맞추기 위해 Vulkan이나 Metal backend의 모든 기능을 사용하지 못함. - 두 project 모두 외부에서의 memory pool 관리를 상정하지 않음. - 최적화된 memory 관리가 어려움 기존 Open Source Project의 이용만으로 충분한가? (2)
18. - Desktop 환경에서 TFLite기반의 자체 inference framework 구현 - OpenCV를 제거하고 GPU를 이용한 image processing을 최대한 활용 - Filament (Rendering Engine) 에 우리가 필요한 기능 구현 - Danny의 좌충우돌 애니모지 개발기를 참고하세요 우리의 Use - Case에 맞추어 나가기
19. 차후 목표
20. - MediaPipe에서 벗어나 전체 기능을 자체 TFLite backend로 수행 - Global Memory management - Compile time graph optimization - Filament에 우리의 Use - Case 를 위한 수정을 하거나, 다른 solution으로 이동 - Global Memory management - PRB을 넘어 Neural Rendering을 위한 기능 구현 전체 Framework 최적화
21. Q&A * 사용된 3D asset은 Ready Player Me를 통해 제작되어 일부 수정을 거쳤습니다., https:/ /readyplayer.me/ Creative Commons Attribution - NonCommercial - ShareAlike 4.0 International