Skia를 위한 컴파일러 스타일 드로잉 최적화 — 2D 래스터화 의미론으로 검증합니다

AI 요약

2D 래스터화(rasterization)는 애플리케이션이 그린 결과를 바탕으로 각 픽셀의 색상을 결정하는 과정입니다. Skia, CoreGraphics, Direct2D 같은 그래픽 라이브러리는 그리기, 블렌딩(blending), 렌더링을 효율적으로 처리하도록 고도로 최적화되어 있습니다. 그러나 라이브러리 자체가 빠르더라도 애플리케이션이 라이브러리에 전달하는 연산의 순서가 비효율적이면 전체 성능이 떨어질 수 있습니다. 연구진은 Google Chrome처럼 Skia와 함께 개발되고 최적화된 프로그램에서도, 가장 많이 방문되는 상위 100개 웹사이트를 대상으로 비효율적인 명령 시퀀스가 여전히 나타난다고 설명합니다.

■ 문제의 핵심: 복잡하고 불투명한 실행 의미론

이러한 비효율성을 자동으로 제거하기 어려운 이유는 래스터화 라이브러리의 의미론(semantics)과 실행 모델이 복잡하고 직관적으로 파악하기 어렵기 때문입니다. 특정 연산을 다른 연산으로 바꾸려면 화면에 보이는 결과가 항상 동일하게 유지되는지 확인해야 하며, 캔버스 상태(canvas state), 레이어 스택(layer stack), 블렌딩, 색상 필터(color filter) 같은 요소들이 서로 영향을 줄 수 있습니다. 따라서 단순히 연산 수를 줄이거나 특정 호출을 제거하는 방식만으로는 변환의 정확성을 보장하기 어렵습니다.

연구진은 이 문제를 해결하기 위해 Skia 2D 그래픽 라이브러리를 위한 형식 의미론(formal semantics)인 μSkia를 제안합니다. μSkia는 Lean에서 기계화(mechanize)되어 있으며, Skia 프로그램이 어떤 그래픽 결과를 만들어내는지를 형식적으로 표현하고 검증할 수 있도록 합니다. 의미론은 관심사를 분리하고 확장성을 확보하기 위해 세 개의 계층(strata)으로 나뉩니다. 이 구조는 캔버스 상태와 레이어 스택, 블렌딩과 색상 필터처럼 서로 다른 기능을 한 모델 안에서 다루면서도 각 부분의 역할을 분리하는 데 사용됩니다.

■ Chrome에서 발견한 네 가지 최적화 패턴

연구진은 μSkia를 이용해 Google Chrome이 생성하는 Skia 코드에서 네 가지 하위 최적화 패턴을 식별했습니다. 각 패턴에 대해서는 원래 연산 시퀀스를 대체하는 새로운 코드를 작성했으며, μSkia를 통해 대체 전후의 동작이 동일하다는 사실을 검증했습니다. 이 과정에서는 단순히 일반적인 경우의 동작만 확인한 것이 아니라, 변환이 성립하려면 충족되어야 하는 여러 까다로운 부수 조건(side condition)도 함께 식별했습니다. 즉, 최적화가 특정 캔버스 상태나 레이어 구성, 블렌딩 조건에서만 안전하게 적용되는지까지 형식적으로 다룹니다.

논문은 과거 Skia 코드에 존재했던 불필요한 saveLayer() 호출 제거와 같은 최적화 작업을 현대적인 방식으로 확장한 사례로도 연결됩니다. 커뮤니티의 Skia 기여자들은 SkRecord 시스템이 이러한 최적화에 적합한 기반을 제공했으며, 이번 작업이 Lean을 사용해 이를 형식적으로 검증했다는 점을 높이 평가했습니다.

■ 성능 평가와 엔드투엔드 검증

연구진은 위 패턴을 적용하는 고성능 Skia 최적화기를 구현했습니다. 상위 100개 웹사이트에서 수집한 99개 Skia 프로그램에 적용한 결과, Skia의 가장 현대적인 GPU 백엔드와 비교해 래스터화 속도가 18.7% 향상되었습니다. 최적화에 걸리는 시간은 최대 32μs로 측정되었습니다. 연구진은 이 속도 향상이 다양한 웹사이트, Skia 백엔드, GPU에 걸쳐 지속된다고 설명합니다.

이 결과는 오프라인에서 프로그램을 분석한 뒤 실행 시점에 큰 비용을 추가하는 방식이 아니라, 매우 짧은 최적화 시간 안에 실제 그래픽 작업의 성능을 개선할 수 있음을 보여줍니다. 또한 이 연구는 최적화 결과가 빠르다는 사실만 측정하는 데 그치지 않습니다. 최적화기가 생성한 변환 추적 정보(optimization trace)를 다시 μSkia 의미론으로 불러오고, Lean에서 변환을 검증함으로써 최적화가 의미론적으로 유효한지 엔드투엔드(end-to-end)로 확인합니다. 따라서 성능 측정과 변환의 정확성 검증을 하나의 흐름으로 연결합니다.

■ Hacker News 반응

• @mtklein — 전직 Skia 기여자로서 읽기에 정말 엄청나게 멋진 글입니다. SkRecord 시스템을 작성할 때 염두에 두었던 바로 그런 종류의 최적화이며, 여러분이 nanobench를 활용할 수 있어서 기쁩니다. 당시에는 적용할 수 있는 작은 최적화가 몇 가지뿐이었고, 대부분 불필요한 saveLayer() 호출을 제거하려고 했습니다. Lean을 사용해 현대적인 방식으로 구현된 모습을 보니 정말 멋집니다.

• @pavpanchekha — 감사합니다. SkRecord 시스템은 이런 최적화를 수행하기에 완벽했습니다. 그것 없이는 이 프로젝트가 가능하지 않았을 것이라고 생각합니다.

• @pavpanchekha — nanobench는 단지 좋은 벤치마킹 도구였기 때문만이 아니라, 우리가 올바른 대상을 측정하고 있다는 확신을 주었기 때문에 큰 도움이 되었습니다. 무언가를 더 빠르게 만드는 일은 쉽지만, 그것이 정말 올바른 대상인지 아는 일은 어렵습니다. 프로젝트에 그런 도구가 미리 포함되어 있으면, 그렇지 않았다면 쉽게 잘못 판단했을 까다로운 질문에 많은 답을 얻을 수 있습니다.

• @mtklein — 성능에 관한 자체 질문에 답할 때 저희도 그렇게 느꼈습니다. 작업이 중요한지 알려면 도구가 필요했고, 그 도구가 그런 초점을 계속 유지하도록 도와주었습니다. 저는 더 이상 Skia 팀에 있지는 않지만, Skia 팀에 오신 것을 환영합니다. nanobench를 사용한다면 이제 진짜배기입니다. :) 질문이 있다면 연락할 수 있도록 같은 사용자 이름의 @gmail.com 주소를 사용하고 있습니다. 시간이 꽤 지났지만, 좋은 목적이라면 기억을 되살려 도움을 드리겠습니다.

• @bhargavkk — 저는 이 논문의 제1저자입니다. 친절한 말씀에 정말 감사드립니다. Skia 코드베이스를 빌드하고 개발하기 쉽게 만들어준 모든 Skia 기여자에게도 매우 감사하게 생각합니다. 저 역시 nanobench의 소스 코드를 읽으며 성능 벤치마킹에 대해 많은 것을 배웠습니다.

원문: arXiv / 번역·요약: Trawling