Babylon.js, 네이티브 렌더 패스 명령을 묶어 보낸다

draw를 합치는 대신 전달 비용을 줄입니다

한국시간 2026년 10월 29일 공개된 Babylon.js 9.33.0에는 네이티브 호스트를 위한 WebGPU 렌더 명령 스트림 배치 처리가 들어갔습니다. 핵심은 JavaScript와 네이티브 사이를 명령마다 왕복하는 비용입니다. 드로우 순서를 바꾸거나 여러 물체를 하나의 draw로 합치는 최적화는 아닙니다.

PR #19075는 파이프라인·버퍼·바인드 그룹 설정과 그리기 명령을 재사용 가능한 배열에 기록하고 한 번에 전달하는 구조를 설명합니다. 호스트가 제공자를 설치하고 명령을 받는 기능을 구현해야 사용됩니다. 일반 웹 페이지가 버전만 올리면 자동으로 같은 네이티브 경로를 쓰는 방식은 아닙니다.

순서를 유지하는 경계가 중요합니다

명령을 모으더라도 뷰포트·가위 영역·가림 쿼리 같은 상태 변경과 렌더 패스 종료 전에는 앞선 작업을 먼저 제출해야 합니다. 그렇지 않으면 쿼리가 닫힌 뒤 그리기가 기록되는 등 관찰 결과가 달라질 수 있습니다. 전달 횟수뿐 아니라 실행 순서 보존이 이 변경의 중요한 조건입니다.

프로토콜 버전 불일치나 기록 실패 때 직접 제출로 돌아가는 경로도 마련됩니다. 다만 실제 네이티브 디코더의 자원 소유권과 부분 실패 처리까지 모든 호스트에서 같다고 가정할 수는 없습니다. 호스트 구현과 계약을 확인해야 하는 영역입니다.

후속 버전의 기본 경로 수정도 함께 보세요

11월 5일 한국시간 공개된 9.33.3에는 PR #19076의 후속 수정이 포함됐습니다. 제공자가 없을 때 임시 명령을 만들었다가 다시 실행하는 대신 직접 인코더 경로를 유지하고, 배치 상태는 제공자가 처음 설치될 때 늦게 할당합니다.

따라서 9.33.0의 초기 설명만 읽고 현재 기본 브라우저 경로를 판단하면 정확하지 않습니다. 후속 PR은 네이티브 전송 규약 자체는 바꾸지 않았으며, 모든 분기 비용이 사라지거나 반드시 FPS가 오른다고 주장하지도 않습니다. 이 글은 최초 도입과 이후 보완을 구분해 정리했습니다.

측정은 전달 횟수와 프레임 시간을 나눕니다

원 PR의 특정 네이티브 시험에서는 브리지 호출 수가 크게 줄었지만, 수직 동기화에 묶인 환경의 FPS는 거의 같았습니다. 후속 PR의 브라우저 비교 역시 변동이 커서 신뢰할 만한 장면 전체 속도 향상을 주장할 수 없다고 명시합니다. 호출 감소율을 그대로 프레임 개선율로 옮길 수 없는 이유입니다.

프로젝트에서는 같은 장면과 출력 조건으로 CPU 제출 시간, GPU 시간, 브리지 호출 수를 따로 기록해 보세요. 제공자 사용 여부와 폴백 발생도 확인해야 측정 대상을 알 수 있습니다. 이 점검은 문서에 근거한 제안이며, 사용자 환경에서 직접 측정한 성능 수치는 아닙니다.

출처

• Babylon.js 9.33.0 공식 릴리스
• PR #19075 · 구현 범위와 검증 보고
• PR #19076 · 구현 범위와 검증 보고
• 9.33.3 릴리스 · 직접 제출 경로의 후속 수정 포함