Filament 1.80.1, Vulkan 파이프라인 캐시를 다음 실행까지 보관합니다

첫 장면을 다시 준비하는 비용

Filament 1.80.1이 한국시간 11월 12일 공개됐습니다. 눈여겨볼 변화는 Vulkan 파이프라인 캐시를 앱 실행 사이에 보관하는 기능입니다. 파이프라인은 셰이더와 렌더링 상태를 묶어 GPU가 그리기에 사용할 형태로 준비한 결과입니다. 첫 장면에서 이 준비가 몰리면 로딩이 길어질 수 있습니다.

기존 Vulkan 백엔드는 실행할 때 빈 캐시로 시작하고 종료 때 없앴습니다. 이번 변경은 플랫폼의 블롭 저장·조회 기능을 연결해 이전 실행의 캐시를 다시 사용합니다. 실행 중 같은 파이프라인을 재사용하는 것에서 한 걸음 더 나아간 변화입니다.

버전만 올리면 켜지지는 않습니다

공식 변경 설명에 따르면 영속화 기능은 기본적으로 꺼져 있습니다. backend.vulkan.enable_pipeline_cache_persistence 기능 플래그를 활성화하고 Platform::setBlobFunc로 저장·조회 함수를 연결해야 합니다. Vulkan은 엔진 생성 시 캐시를 읽으므로 콜백 설정을 엔진 생성보다 먼저 끝내야 합니다.

저장된 데이터도 무조건 믿지 않습니다. 장치 식별 정보와 파이프라인 캐시 UUID 등을 대조하고 맞지 않으면 빈 캐시로 시작합니다. 드라이버가 캐시를 받아들이지 못해도 빈 상태로 다시 생성하는 경로가 있습니다. 다른 기기의 캐시 파일을 복사하면 그대로 빨라진다고 기대해서는 안 됩니다.

종료할 때만 저장하지 않는 이유

모바일 앱은 정상 종료 절차 없이 사라질 수 있습니다. 그래서 구현은 새 파이프라인 생성이 잠잠해진 뒤 캐시 저장을 예약하고, 정상 종료 때도 저장을 시도합니다. 평상시 저장은 컴파일러 작업 스레드에서 처리해 드라이버 스레드의 파일 쓰기 부담을 피하도록 구성됐습니다.

이 동작은 저장 콜백이 실제로 실행 간 데이터를 유지할 때 의미가 있습니다. 메모리에만 두고 프로세스와 함께 잃어버리는 구현이라면 다음 실행에서 읽을 자료가 남지 않습니다. 캐시 파일의 용량과 저장 실패 처리도 적용 시 함께 점검할 부분입니다.

수치는 재실행 조건을 붙여 읽습니다

공식 PR은 Google TV Streamer에서 첫 장면 준비까지의 시간이 약 5.38초에서 3.69초로 줄었다고 보고합니다. 같은 앱의 캐시 없는 첫 실행과 캐시가 남은 후속 실행을 비교한 값입니다. 반면 Pixel 7에서는 컴파일 CPU 비용이 줄어도 장면 준비 시간이 달라지지 않았다고 설명합니다.

따라서 모든 기기의 로딩 시간이 같은 비율로 줄어든다는 뜻은 아닙니다. 캐시를 처음 만드는 실행과 평상시 프레임 비용도 별개의 문제입니다. 이 글에서는 공식 구현과 보고를 검토했으며 해당 기기에서 직접 벤치마크하지 않았습니다.

적용할 때 확인할 세 가지 실행

실무에서는 캐시를 지운 첫 실행, 캐시를 보관한 재실행, 업데이트 후 캐시가 거부되는 실행을 나누어 비교하는 편이 좋겠습니다. 동일한 장면과 기기에서 준비 시간, 컴파일 CPU 시간, 파일 크기를 함께 기록하면 효과와 비용을 구분하기 쉽습니다. Filament를 직접 사용하는 프로젝트라면 이번 기능을 시험할 근거가 생겼지만, 다른 엔진에도 자동으로 적용되는 변경은 아닙니다.

출처와 이미지

• Filament 1.80.1 공식 릴리스: 공개 버전과 기능 포함 여부.
• Vulkan 캐시 영속화 공식 PR #10519: 설정 순서, 기본값, 기기별 측정 조건.
• 1.80.1 VulkanPipelineCache 구현: 캐시 검사와 저장 경로.
• 썸네일은 MIRO가 제작한 개념도입니다. CC BY 4.0에 따라 저작자와 출처를 표시하고 변경 여부를 밝혀 재사용할 수 있습니다.