MediaPipe를 ARM GBM 헤드리스에서 GPU로 구동해 FaceLandmarker 2.3배 가속

원문은 이 문제가 2021년부터 GitHub 이슈로 보고되어 왔고 legacy C++ Graph API 대상 PR이 거부된 이력이 있음을 언급해 왔다. 댓글과 반응은 이 패치의 실용성에 대해 긍정적이며 유사한 환경에서 같은 문제를 겪은 사례들이 공유되었다. 동시에 몇몇 사용자는 Jetson, RPi 등 다른 SoC의 EGL 스택 차이로 인한 추가 테스트와 포팅 작업이 필요하다고 지적했다.

• 헤드리스 ARM 보드에서 MediaPipe GPU를 사용하려면 먼저 /dev/dri/renderD128 같은 DRM 렌더 노드가 존재하는지 확인하고 존재하면 컨테이너에 /dev/dri를 마운트한 뒤 gbm_create_device 기반 초기화 경로를 적용하면 된다. 실제로 본 패치는 eglGetPlatformDisplay(EGL_PLATFORM_GBM_KHR, gbm_device, NULL) 호출과 EGL_WINDOW_BIT를 사용하는 더미 GBM surface 생성을 포함하므로 관련 라이브러리와 권한이 필요하다. 이 방식은 DISPLAY 없이도 GPU를 활성화하므로 Xvfb 같은 대체가 불필요하다.
• 벤치마크를 재현할 때는 동일한 영상 소스(예: 720p, 동일 프레임수)와 모델 구성(예: FaceLandmarker v2, blendshapes 활성화)을 사용해 평균·median·p95 수치를 비교하고 CPU와 GPU 경로에서의 병목(예: blendshapes의 CPU 실행)을 확인해야 한다. 패치 적용 후 GPU 초기화 로그에서 GBM 디바이스 생성과 EGL 초기화 성공 로그 출력을 확인하는 것이 중요한 검증 단계이다. 다른 SoC로 포팅할 때는 해당 플랫폼의 EGL 확장 지원 여부와 드라이버 백엔드를 점검해야 한다.

GBM

— GBM은 DRM 기반 그래픽 버퍼를 생성하고 관리하는 사용자 공간 라이브러리로서 DRM/KMS 드라이버와 연동해 GPU에 직접 렌더링 표면을 제공한다. GBM은 pbuffer 대신 window형 표면을 주로 지원하며, 이는 X11 없는 환경에서 EGL 초기화 경로를 달라지게 한다. 본문 맥락에서 GBM 존재 여부는 eglGetPlatformDisplay를 사용한 EGL 초기화 성공 여부와 직접적으로 연결된다.

EGL pbuffer

— EGL pbuffer는 GPU 오프스크린 렌더링용 픽셀 버퍼 표면으로서 eglCreatePbufferSurface를 통해 생성된다. 많은 EGL 구현이 pbuffer를 지원하지만 GBM 기반 구현은 pbuffer를 제공하지 않고 대신 window형 표면을 요구하는 경우가 있다. 본문에서는 pbuffer 미지원이 MediaPipe의 eglChooseConfig 실패 원인으로 규정된다.

DRM/KMS

— DRM/KMS는 리눅스 커널 레벨에서 디스플레이 파이프라인과 GPU 버퍼를 제어하는 인터페이스로서 사용자 공간에서 GBM을 통해 버퍼를 할당하고 KMS로 화면 출력을 제어한다. DRM/KMS 기반 초기화는 X11/Wayland 같은 디스플레이 서버가 없는 임베디드 환경에서 GPU를 직접 사용하기 위한 필수 경로이다. 본 패치에서 MediaPipe 초기화는 DRM/KMS+GBM 경로로 전환되어 headless 환경에서 GPU를 활성화한다.