Asahi Linux, compressed framebuff scanout 패치(patch)를 적용해 봤습니다.

 

본 포스트는 Fedora Asahi Linux 기반 하에서 작성되었습니다. 

 

이번 포스트는 Asahi Linux Kernel의 PR #449 Allow dcp interchange to scanout interchange compressed를 적용하는 방법과 그 결과에 대한 내용을 담고 있습니다.

** CAUTION :
mesa와 linux kernel 빌드 및 source code patch에 대한 경험이 없으신 분들은 문제 발생 시, 부팅이 안되거나 GUI로 진입하지 못을 수 있습니다.  이 PR 패치는 어디까지나 개인적인 관심으로 적용해 본 것입니다.

 

 

우선, 이 PR(Pull Request)이 무엇인지를 살펴봅니다. 
이 PR은 Apple Silicon(Asahi Linux 환경)에서 GPU와 DCP(Display Control Processor) 간에 화면 출력(Scanout) 데이터를 보다 효율적으로 교환(Interchange) 하기 위한 방법에 관한 것입니다. 즉, Apple Silicon Mac의 독특한 H/W 구성에 맞게 최적화된 화면 출력 방법을 적용하는 것으로 기술적으로는 압축 타일 포맷을 사용하는 것입니다. 

그렇다면, 이 PR이 적용되지 않은 현재는 어떻게 화면을 출력하고 있을까 ? 
필자의 경우에는 wlroots 기반의 wayland compositor를 만들고 있기 때문에, 이를 기반으로 설명을 해 봅니다. 

우선 GUI 환경으로 진입을 하게 되면, 배경화면을 포함하여 window들이 각자 화면을 구성하고 그 메모리 버퍼(buffer)를 Wayland Compositor(합성기)로 보냅니다. Compositor는 각 Client들을 특정 위치에 특정 크기로 배치하라는 화면 구성(Scene Graph)을 구성한 후 이 구성도를 wlroots의 Renderer에게 전달합니다. 

Renderer는 Mesa를 경유하여 GPU에게 렌더링 명령(Draw Call)을 내립니다. GPU는 이 Draw Call에 따라 실제 연산을 수행하여 시스템 메모리에 위치한 Framebuffer에 최종 픽셀 데이터를 쏴 줍니다.  완성된 Framebuffer의 데이터를 Linux Kernel(DRM/KMS)에게 Framebuffer ID(메모리 주소)에 완성된 한 Frame의 화면이 있으니, 이를 모니터에 출력하라고 명령합니다.  그럼 Kernel은 DCP를 통해 화면을 출력 시도하고, 이 과정을 거쳐 화면에 GUI 화면이 모니터에 출력되는 것입니다. 

그런데, 현재는 Apple이 만든 최적화된 GUI 화면 출력 방식을 사용하지 못하고 있습니다. 
좀 더 단계를 구체적으로 살펴 보면,, wlroots에서 rendering을 하기 전에 mesa와 kernel에게 공통으로 알고 있는 압축 포맷이 있는지의 여부를 물어봅니다. 그런데, mesa와 linux에 압축포맷에 대한 응답이 모른다고 온다면, wlroots는 압축 포맷을 사용할 수 없고, 따라서 어쩔 수 없이 가장 원시적인 압축도 안 하고, 타일링도 없는 순수한 픽셀 배열의 포맷인 DRM_FORMAT_MOD_LINEAR 포맷을 사용하게 됩니다. 즉, GPU는 분할 압축하지 않은 상태로 메모리에 쓰고, DCP가 이를 다시 통째로 읽어 들여 처리해야 합니다. 이는 매 프레임마다 반복해야 하기 때문에, 대역폭 낭비가 극심하고 처리 지연이 발생하며 이로 인해 불필요한 전력소모를 유발하게 됩니다. 이와 같은 단점은 모니터 해상도가 높을수록, 다중 모니터를 사용할수록 커지게 됩니다. 

결론적으로 현재 Asahi Linux는 GPU acceleration 기능을 사용하고 있기는 하지만, 물리적인 화면데이터 전송 부분만큼은 최적화 기법을 사용하고 있지 않는 상태라는 것을 알 수 있으며, 동일한 H/W에서 macOS와 Asahi Linux를 비교했을 때, macOS가 화면 전환이나 에니메이션에서 보다 부드럽다고 느껴진다면 그 원인 중 하나가 될 수 있습니다. 

이번 PR은 바로 이 부분을 최적화 하는 PR입니다.
즉, Apple Silicon의 DCP가 사용하고 있는 타일/압축 방식을 사용할 수 있도록 mesa와 linux driver를 패치하는 것입니다. 

이 패치를 적용하게 되면, wlroots에서 rendering을 하기 전에 mesa와 linux kernel에 압축방식을 확인할 수 있고, 따라서 tiled/compressed framebuffer를 사용하여 매우 효율적으로 화면을 출력할 수 있게 되는 셈입니다. 즉, GPU는 화면을 고속으로 분할 압축하기만 하고 해당 메모리 주소가 어디인지만 wlroots에게 통보해 주면, wlroots가 kernel에게 출력할 화면데이터의 주소만 kernel 쪽으로 통보하게 됩니다. 그럼 DCP는 해당 주소를 직접 참조하여 하드웨어 기반으로 압축을 해제하여 화면에 출력하는 zero-copy 출력을 하게 됩니다. 

이 PR을 적용함으로써 얻게 되는 장점은 메모리 대역폭 소모 감소로 인해 전체 frame rate가 안정화 될 수 있으며, 압축 해제 단계 생략 및 고속 클리어를 통한 렌더링 지연이 감소되며, 통합 메모리의 데이터 이동 최소화로 지연 발생이 낮아지고, 발열 및 에너지 소모를 줄일 수 있게 됩니다.

 

patch 적용 방법

이 PR을 적용하려면, 아래에 첨부하는 두 개의 patch 파일을 각각 mesa 와 linux kernel(fairydust) 소스코드에 각각 적용한 후, 각각을 빌드하여 업데이트하고 재 부팅하면 됩니다. 

mesa.patch

0.01MB

linux.patch

0.00MB

 

mesa 패치는 아래를 참고합니다.

   # Navigate to the mesa source code directory
   cd mesa

   # Test applying the patch (dry run)
   patch -p1 --dry-run < mesa.patch

   # If there are no errors, apply the patch for real
   patch -p1 < mesa.patch

   # How to revert the patch if a problem occurs
   patch -p1 -R < mesa.patch

   # If the patch is successful:
   # A "patching file ..." message will be printed. If it fails, it will print "FAILED" or "Hunk failed".

 

linux의 경우에도 linux 소스코드 디렉터리에서 동일한 방식으로 적용합니다. (linux.patch 사용). Asahi Linux Fairydust 브랜치의 빌드 및 적용 방법에 대한 정보는 여기를 참조하시기 바랍니다. 

적용되었는지의 여부는 wayland log로 확인을 할 수 있는데, 

위의 스샷에서 볼 수 있듯이, GBM buffer allocation 메시지에서 modifier unknown, 이라고 표시되면서, 0x0C000000003 으로 표시가 되는지를 확인하면 됩니다.  패치 이전에는 modifier LINEAR 와 0x......0 와 같이 끝이 3 이 아니고 0으로 표시됩니다. 

참고로 필자의 경우에는 M1 mac mini (8/256) 모델을 사용하고 있으며, 단일 4K 외장 모니터를 사용하고 있으며, wlroots 기반의 wayland compositor를 자체적으로 만들어 사용하고 있습니다. 따라서, 다른 mac 모델, 다중 모니터 및 macbook의 내장모니터 사용 시, 그리고 본인이 사용하는 compositor 혹은 Desktop Edition 등에서 문제가 발생할 수도 있으며, 이는 필자가 검증할 수 없는 환경이라는 점을 유의하시기 바랍니다. 

 

- - - - - - - - - 

patch 및 mesa, linux kernel 이 문제없이 되었다면, 재 부팅하면 됩니다. GUI로 진입할 때 화면 전체가 magenda 색상으로 깜빡거린 후 진입을 하게 됩니다. GUI 운영 자체에 문제는 없습니다. 

PR로 등록이 되었고, Asahi Team의 담당자분께서 검토를 하고 있는 만큼, 차기 Asahi Linux kernel에 적용될 수 있을 것으로 예상됩니다. 물론 mesa와 linux kernel 에 둘 다 upstream 되어야 하는 만큼 시간은 꽤 걸릴 수도 있습니다.