Linux 7.2가 출시되었습니다! 전력 관리, M3·M4·M5 지원, 비디오 디코딩, 직접 스캔아웃 및 업스트리밍에 관한 Asahi Linux의 최신 진행 상황을 전합니다.
Linux 7.2가 출시되었습니다! 정말 빠르네요. 또 한 번의 Asahi Linux 진행 보고로 들어가 봅시다. 오늘도 흥미로운 발전 소식이 많이 준비되어 있으니, 차 한 잔을 준비하고 즐겨 주세요.
Apple Silicon 플랫폼의 전력 관리 인프라는 복잡합니다. 책임은 SMC, PMGR, PMP를 포함한 여러 하드웨어 블록에 나뉘어 있으며, 이들은 모두 이전에 이 블로그에서 다룬 적이 있습니다. 이 블록들을 지원하는 일은 전력 사용에 중요하지만, 배터리 수명을 개선하는 데 가장 큰 장애물 중 하나는 애플리케이션 코어 자체였습니다.
CPU 코어를 “잠재우는” 방법은 여러 가지이며, 각각 특정한 상황에서 사용해야 합니다. ARM CPU 코어를 잠재우는 가장 기본적인 방법은 Wait For Interrupt(WFI) 명령을 사용하는 것입니다. 이 명령은 인터럽트 소스의 인터럽트로 깨어날 때까지 코어가 작업을 멈추도록 지시합니다. 코어가 어떠한 코드도 실행하지 않게 하므로 전력을 절약하지만, 코어는 전원이 켜진 상태를 유지하며 매우 빠르게 작업을 재개할 수 있을 만큼의 상태를 보존합니다. 따라서 WFI는 일반적으로 실행 중인 시스템에서 코어를 대기 상태로 두는 데에만 사용됩니다. Apple 코어에는 상태를 잃는 대가로 코어의 더 많은 부분을 끄는 “깊은” WFI 모드가 있습니다. 우리의 다운스트림 cpuidle 드라이버는 WFI를 이 모드로 설정하고, 코어 상태를 저장한 뒤 WFI 루프를 실행하는 방식으로 작동합니다.
이와 같은 공급업체별 전력 관리 특이점은 꽤 흔합니다. 다행히 커널 유지보수자에게는 이를 처리하는 표준 방식이 있습니다. 바로 Power State Coordination Interface입니다. PSCI는 운영체제가 시스템 펌웨어가 구현한 정의된 CPU 코어 전력 관리 함수 집합을 호출할 수 있도록 하는 표준 인터페이스를 정의하며, 여기에는 코어를 절전 상태로 준비하는 기능도 포함됩니다.
Linux 커널 내부에 공급업체별 전력 관리 우회책이 난립하는 일을 피하기 위해, arm64 아키텍처별 코드를 유지보수하는 이들은 업스트림 하드웨어가 반드시 전력 관리에 PSCI를 사용해야 한다고 규정했습니다. 따라서 Apple 전용 cpuidle 드라이버는 업스트림에 올릴 수 없습니다. 그렇다면 우리는 왜 여전히 이를 사용하고 있을까요?
PSCI는 커널에서 펌웨어로 호출을 전달하는 “통로”를 정의합니다. 현재 커널에서 지원하는 두 통로는 더 높은 Exception Level로 실행을 넘기는 데 사용되는 SMC(Secure Monitor Call)와 HVC(Hypervisor Call) 명령입니다. Linux 커널은 EL2에서 실행될 것으로 예상하므로, PSCI 호출은 EL3에서 실행 중인 펌웨어로 실행을 넘겨야 합니다. 하지만 Apple 코어는 EL3를 구현하지 않습니다…
커널이 이미 EL2에서 실행 중이고 EL3에 대화할 펌웨어도 없으므로, 우리는 다소 난처한 상황입니다. 실행을 넘길 EL3가 없기 때문에 Linux는 SMC 또는 HVC 명령을 실행할 수 없고, 이는 PSCI를 사용할 수 없다는 뜻입니다. CPU 코어를 적절히 전력 관리하는 일은 배터리 수명과 효율에 매우 중요하므로, 현 상태는 결코 만족스러울 수 없습니다. 빠르고 지저분한 해결책 하나는 m1n1이 커널을 EL1에 올리고 EL2에 PSCI 구현을 두는 것입니다. 이론적으로는 작동하겠지만, 가상화 같은 수많은 아키텍처 기능도 망가뜨릴 것입니다. 우리가 할 수 있는 다른 방법이 분명히 있을 겁니다…
생각해 보면 m1n1은 거의 Apple Silicon용 자체 펌웨어와 같습니다. mBoot(구 iBoot)가 이를 EL2에서 시작하고, m1n1은 일을 마친 뒤 자신에게 연결된 페이로드로 점프합니다. m1n1은 자신을 위해 메모리를 예약하지 않고 상주해야 하는 코드도 없으므로, 페이로드는 그 메모리를 회수하고 덮어쓸 수 있습니다.
프로덕션 Asahi Linux 시스템에서 m1n1은 커널을 직접 올리는 대신 U-Boot를 올립니다. 이는 U-Boot의 UEFI 구현을 이용하여 배포판과 사용자가 원하는 표준 UEFI 부트로더(GRUB, systemd-boot 등)를 사용할 수 있게 하기 위해서입니다. UEFI는 Runtime Services라는 또 다른 기능도 제공합니다. 과거 BIOS 인터럽트가 했던 것처럼, UEFI Runtime Services는 운영체제가 시스템 펌웨어에서 비롯된 코드에 접근할 방법을 제공합니다.
Arm이 공개한 PSCI 표준을 읽어 보면, 의도적으로 특정 통로를 언급하지 않고 API를 정의하며 SMC와 HVC는 예시로만 열거한다는 점을 알 수 있습니다. 이를 넓게 해석한다면, 명세가 다른 통로도 허용한다는 결론을 내릴 수 있습니다…
이를 위해 Sven은 UEFI Runtime Service 기반 PSCI 통로를 구현하는 작업을 해 왔습니다. m1n1의 메모리 영역을 다른 펌웨어 영역처럼 분리하면, 커널이 같은 Exception Level에서 실행 중이더라도 PSCI 서비스를 위해 m1n1로 다시 호출할 수 있게 됩니다. Sven은 이미 m1n1이 메모리를 예약하고 PSCI 구현을 남겨 두도록 수정했으며, 이를 사용할 수 있게 하는 커널 패치는 이미 RFC로 메일링 리스트에 올라와 있습니다!
cpuidle 상황이 아주 최근까지 진전이 없었다는 점을 고려하면, 이 영역의 작업을 촉발한 사건이 있었으리라 짐작할 수 있습니다. 그 추측은 맞습니다.
ARM 명세는 WFI 루프에 있는 코어가 모든 상태를 보존해야 한다고 규정합니다. Apple Silicon의 기본 모드는 그렇지 않습니다. M1부터 M3 계열 SoC에서는 코어별로 chicken bit를 사용해 상태 보존을 설정할 수 있습니다.
언급할 가치가 없는 여러 이유로 Apple은 이제 mBoot에서 각 코어의 chicken bit를 설정한 뒤 M4 계열부터 이를 제어하는 레지스터를 잠급니다. 그 결과 m1n1이 해야 할 일이 아주 조금 줄어들어 우리의 삶은 다소 쉬워졌지만, 저수준 CPU 동작을 세밀하게 조정할 수 없다는 뜻이기도 합니다. 특히 M4에서는 WFI를 호출하면 코어가 상태를 잃고 그 코어에서 실행 중이던 것이 충돌하므로 문제가 됩니다.
Yurkea는 M4 초기 지원 작업 중 이를 발견했고, 유휴 루프 동작을 구성할 수 있는 커널 명령줄 매개변수를 추가했습니다. 이 매개변수는 단순한 무연산 루프를 포함하여, 커널이 유휴 루프에서 코어를 어떻게 대기시킬지 알려 줄 수 있게 합니다. 이는 cpuidle 드라이버가 로드되기 전인 초기 커널 초기화 중 M4 기기가 충돌하는 것을 막습니다. 드라이버가 제어를 넘겨받으면 WFI를 실행하기 전에 손실될 상태를 저장합니다. 이를 활성화하는 패치는 이미 linux-next에 있습니다.
Apple은 플랫폼 보안에 관한 평판을 매우 중요하게 여깁니다. 이에 따라 자사 생태계의 취약점을 악용하는 일을 가장 정교한 공격자를 제외하면 실현 불가능하게 만드는 기능에 많은 엔지니어링 노력을 투입합니다. 그중 하나가 Secure Page Table Monitor, 즉 SPTM입니다.
전통적으로 운영체제 커널은 메모리 관리를 직접 담당했습니다. 여기에는 메모리 할당 처리, 물리 주소에 대한 가상 매핑, MMU/IOMMU 관리가 포함됩니다. 이러한 작업을 담당하는 코드의 취약점은 공격자에게 플랫폼 전체 주소 공간에 대한 접근을 허용할 수 있습니다. 다시 말해, 끝장입니다.
당연히 메모리 관리 코드는 공격자의 매우 흔한 표적이며, 그 업무 자체가 근본적으로 안전하지 않기 때문에(애플리케이션은 거의 무엇이든 임의로 할당받길 원할 수 있습니다) 이를 올바르게 잠그는 일은 믿을 수 없을 만큼 어렵습니다.
수년 전 Apple은 XNU에 Page Protection Layer를 도입했습니다. PPL은 Apple의 하드웨어 보안 기능을 사용하여 페이지 테이블 관리를 하드웨어 수준에서 커널의 나머지 부분과 격리합니다. 이는 매우 잘 작동했지만, 공격자들은 결국 PPL 내부에서 시스템 전체에 접근할 수 있는 방법을 찾아냈습니다.
Apple은 과거 IOMobileFramebuffer에서도 비슷한 문제를 겪었습니다. 이전 블로그 글에서 언급했듯, Apple은 IOMFB를 IOMMU 뒤의 DCP 펌웨어 안에 넣음으로써 이 문제를 대부분 해결했습니다. 정의된 IPC 함수 집합을 거치는 경우를 제외하면 macOS 사용자 공간이나 XNU 어느 쪽에서도 이에 도달할 수 없습니다. 이 접근법에서 영감을 받아 PPL은 결국 SPTM으로 발전했습니다. SPTM은 PPL을 Apple의 Guarded Execution Framework(GXF) 내부에 배치합니다. GXF는 표준 ARM64 EL1 및 EL2와 병렬로 실행되는 Exception Level 집합입니다(GL0는 없습니다). GXF에는 CPU가 GL1 또는 GL2에서 코드를 실행할 때 사용하는 맞춤형 페이지 테이블 권한 체계인 SPRR도 포함됩니다.
현대적인 Apple Silicon 기기가 시작되면 iBoot 또는 mBoot는 구성된 부트 페이로드가 XNU 이미지인지 감지합니다. 그렇다면 먼저 SPTM을 GL2에 로드합니다. այնտեղ서 SPTM은 페이지 테이블과 메모리 관리를 설정하고, 해당 기능의 제어를 GL2에 잠급니다. 이후 XNU는 또 다른 IPC 프로토콜을 사용해 SPTM과 통신하며 실행됩니다. XNU가 SPTM에 성공적으로 연결할 수 없다면, 초기화 초기에 패닉을 일으키고 시스템을 멈춥니다.
이는 우리에게 문제가 됩니다. m1n1 하이퍼바이저 아래에서 XNU를 실행하려 하면 SPTM이 로드되지 않았으므로 충돌합니다. mBoot가 m1n1을 XNU 바이너리로 취급하도록 구성하면, m1n1은 필요한 방식으로 메모리를 관리할 수 없으므로 충돌합니다.
M4 이상에서 XNU에 SPTM이 필수이므로, 하이퍼바이저는 이 기기들에서 완전히 작동 불능 상태가 되었습니다. 하지만 우리는 포기할 줄 모르므로, 이것은 _이다_가 아니라 _되었습니다_입니다!
SPTM 자체는 특별할 것이 없습니다. 여러 보조 프로세서용 OS별 펌웨어 블롭과 같은 사전 부팅 디렉터리에 있는 ARM64 Mach-O 바이너리입니다. 즉 이론적으로는 m1n1이 이미 하이퍼바이저 아래에서 이를 로드하고, 그 옆에 XNU를 로드한 다음, 둘 다 관찰할 수 있습니다! 하지만 SPTM은 SPRR가 활성화된 GL2 안에서 반드시 실행되어야 합니다. 둘이 어떻게 작동하는지 알기만 한다면 말이죠…
Asahi Linux가 처음 시작될 무렵 Sven이 SPRR와 GXF를 리버스 엔지니어링한 작업 덕분에, 그는 최근 m1n1 하이퍼바이저가 이들을 에뮬레이션하도록 가르칠 수 있었습니다! 이를 통해 Apple의 SPTM 블롭을 XNU가 기대하는 정확한 방식으로 로드하고, XNU 바이너리에 약간의 수술을 한 뒤 로드하여 M1부터 M3에서 할 수 있었던 것처럼 MMIO 접근을 감시할 수 있습니다! Sven이 이를 달성한 복잡한 세부 사항 때문에 이 기기들에서 추적은 더 느리지만, 사용할 수 없을 정도는 아닙니다. 이는 앞으로도 한동안 새 하드웨어의 초기 지원을 계속할 수 있게 해 줄 것입니다!
M3 계열 기기에 Asahi Linux를 지원하는 작업도 진전되고 있습니다.
웹캠 이미지 신호 프로세서는 M3 Max에서만 초기화 메시지 하나가 건너뛰어진 것을 제외하면 거의 바뀌지 않았습니다. chaos_princess가 Linux 드라이버에 이를 지원하도록 추가했으며, 이로써 내장 웹캠이 있는 모든 M3 계열 기기에서 완전한 웹캠 지원을 활성화했습니다.
내장 마이크도 조금 바뀌었습니다. M3 계열 기기에 새로 들어간 것은 새 계수 집합과 훨씬 더 큰 초기화 메시지를 요구하는 “고주파” 데시메이터입니다. 다시 한번 chaos_princess는 이를 순식간에 해결하여, 장착된 모든 M3 계열 기기에 마이크 지원을 제공했습니다.
USB Type-C 포트를 통해 USB3, DisplayPort, Thunderbolt 연결을 협상하는 하드웨어 블록인 ATCPHY도 약간 바뀌었습니다. TSMC의 N3 공정 노드로 전환하면서 초기화 시 새로운 튜너블 순서가 필요해졌습니다.
Apple이 단지 변화를 위해 대대적인 아키텍처 변경을 피할 것이라는 우리의 가설은 대체로 맞았지만, 물론 몇 가지 그런 변화를 마주쳤습니다…
기본 M3 계열까지의 모든 M1 기기는 CD3217(또는 ACE2)이라는 Apple 전용 Texas Instruments USB 포트 컨트롤러를 사용했습니다. 이는 I2C 버스에 연결되어 USB 기기를 꽂을 때 해당 기기와 협상합니다. M3 Pro/Max부터 Apple은 ACE3로 전환했습니다. ACE3는 대신 SPMI 버스를 사용하므로 추가 리버스 엔지니어링이 필요했습니다. mildsunrise와 chaos_princess의 합동 노력 덕분에, ACE3는 I2C를 통해 주소 지정되는 대신 SPMI 인터페이스로 감싸졌을 뿐 CD3217과 거의 같은 레지스터 집합을 갖는다는 사실을 발견했습니다. SPMI 인터페이스와 ACE3 자체는 이제 모두 Asahi Linux에서 작동하며, 모든 M3 계열 기기에 USB 3.0 및 Thunderbolt 지원을 제공합니다.
우리가 예상했던 대규모 변화는 GPU와 디스플레이 컨트롤러 양쪽의 펌웨어 ABI였습니다. AGX와 DCP 양쪽의 펌웨어는 특정 macOS 버전과 짝지어지므로, Apple은 릴리스 간 인터페이스 안정성을 유지할 걱정을 할 필요가 없습니다. 이는 각 하드웨어 세대에 특정 macOS 버전을 “대상으로 삼는” 중요한 이유입니다. M3 계열 기기는 macOS 14.8.3에 있는 ABI를 대상으로 하며, DCP 지원은 이제 M1 및 M2에 사용하는 기존 macOS 13.5 ABI와 거의 기능 동등성에 도달했습니다!
이미 M3에서 달성한 이정표에 더해 이 모든 진전이 이루어진 만큼, 공식 릴리스를 내놓을 준비가 거의 되었다는 소식을 기쁘게 알려 드립니다! 앞으로 몇 주 안에 이에 관해 더 말씀드릴 예정이니, 계속 지켜봐 주세요!
M3에서만 도움을 주는 데 만족하지 않고, Yureka는 M4와 초기 M5 지원 작업까지 하고 있습니다. M4의 WFI 문제 외에도, 이 SoC들은 macOS 15.x 펌웨어 번들의 Apple NVMe 컨트롤러 펌웨어에서 호환성을 깨는 변경을 겪었습니다. Yureka와 Sven은 변경 사항을 조사하고 m1n1과 Linux 양쪽에 구현하기 위해 함께 작업했으며, 이제 M4와 M5에서 NVMe가 작동합니다! Yureka는 Linux가 버스의 기기를 열거할 수 있는 상태까지 PCIe를 작동시키고, CPU 코어가 둘 이상 활성화된 경우 부팅 직후 Linux가 충돌하던 문제도 수정했습니다. M4와 M5에서는 아직 다른 많은 것이 작동하지 않으므로 Asahi Installer에서 이들을 활성화할 준비는 아직 되지 않았지만, 늘 그렇듯 적절한 때에 더 말씀드리겠습니다.
지난번에는 Apple Video Decoder, 즉 AVD의 초기 지원을 발표했습니다. 이 하드웨어 블록은 M1과 M2에서 H.264(AVC), H.265(HEVC), VP9 비디오 디코딩을 가속하며, M3 기기 이상에서는 AV1 디코딩도 가속합니다. 이후 sofus가 AVD 지원을 더욱 다듬어, 이제 Asahi Linux가 지원하는 모든 기기에서 AVC, HEVC, VP9가 대부분 안정적으로 작동합니다! 이제 데스크톱 통합을 고려하는 단계에 이르렀고, 여기부터 일이 까다로워집니다…
AVD 하드웨어는 근본적으로 상태 비저장 방식입니다. 즉 인코딩된 프레임을 받아 비디오 버퍼로 바꾸기만 합니다. 하드웨어는 비트스트림 파싱, 디코딩 세션 추적 또는 디코딩 파이프라인의 다른 어떠한 관리도 하지 않습니다. 이는 이러한 디코더를 염두에 두고 설계된 V4L2 Stateless API와 잘 맞습니다. 이 API는 10년도 더 전에 업스트림 커널에 처음 들어왔지만, 임베디드 기기를 대상으로 하는 특수 소프트웨어 밖에서 사용자 공간의 채택은 더뎠습니다. GStreamer는 V4L2 Stateless를 기본적으로 지원하지만, FFmpeg와 이를 사용하는 모든 소프트웨어는 트리 밖 패치 없이는 지원하지 않습니다. 웹 브라우저 같은 데스크톱급 소프트웨어는 역사적으로 VA-API, NVDEC, VDPAU에 집중해 왔습니다. 최근에는 데스크톱의 노력이 Vulkan Video로 옮겨가기 시작했습니다. 이로 인해 V4L2 Stateless는 데스크톱 소프트웨어에서 시작도 하기 전에 사실상 버려졌습니다.
하지만 모든 희망을 잃은 것은 아닙니다. VA-API는 AMD와 Intel이 비디오 가속 하드웨어에 채택하면서 데스크톱급 소프트웨어에서 이제 거의 보편적입니다. V4L2 Stateless 하드웨어가 그러한 소프트웨어에서 쓸모없어지는 것을 막기 위해 Bootlin은 VA-API에서 V4L2 Stateless로 변환하는 계층을 작성했습니다. 안타깝게도 이는 꽤 오랫동안 방치되어 이제 패치 없이는 빌드되지 않지만, sofus가 이를 포크하여 AVD용으로 작동하는 상태로 만들었습니다. 이 변환 계층을 설치하고 로그인 세션에 환경 변수를 설정하면, VA-API 지원을 구현한 소프트웨어는 이제 AVD를 사용하여 비디오 디코딩을 가속할 수 있습니다! 이는 아직 Fedora Asahi Remix에 기본으로 포함되지 않으며 Firefox의 비디오 디코딩 샌드박스에서는 작동하지 않지만, 곧 배포 가능한 무언가를 마련할 수 있기를 바랍니다.
전통적으로 하드웨어 가속 비디오 디코딩의 이점은 CPU 부하 감소였습니다. 이것만으로도 물론 매우 중요하지만, 비디오 디코딩 중에는 전력과 시간이 낭비되는 다른 부분도 있습니다. 먼저 CPU가 디코딩된 프레임 데이터를 GPU 메모리로 복사해야 합니다. 이후 GPU는 컴포지터의 지시에 따라 그 프레임을 장면에 합성해야 합니다. 최종 렌더링된 장면은 다시 디스플레이 컨트롤러의 메모리로 복사되어야 하며, 디스플레이 컨트롤러는 장면을 스캔아웃하도록 프로그래밍되어야 합니다. 이 모든 일은 재생 중인 비디오의 프레임 속도로 이루어져야 합니다.
우리는 이보다 더 잘할 수 있습니다. Linux의 DMA 서브시스템은 여러 기기 간에 메모리 영역을 공유하는 것을 지원합니다. 이 맥락에서 이는 같은 프레임버퍼 데이터를 한 영역에서 다른 영역으로 여러 번 복사하는 일을 없앨 수 있게 합니다. 단, 체인의 모든 하드웨어 블록이 같은 프레임버퍼 형식을 지원할 때만 가능합니다. 바로 여기서 일이 까다로워집니다.
프레임버퍼는 온갖 형식과 크기로 존재합니다. 예를 들어 비디오 데이터는 20세기의 아날로그 비디오 저장 및 방송 표준에서 영감을 얻은 반평면Y’CbCr 형식으로 거의 항상 저장되고 전송됩니다. 여기에 그래픽 하드웨어는 거의 언제나 어떤 형태의 특수 주소 지정을 사용합니다. 픽셀은 메모리에서 서로 “다음”에 있지 않으며, 캐시 미스와 기타 성능 문제를 줄이기 위해 대신 타일링됩니다. 게다가 프레임버퍼는 흔히 압축되기도 하여 메모리 사용량과 버스 부담을 더 줄입니다.
즉, 하드웨어 블록 간 프레임버퍼 복사를 제거하는 일은 간단하지 않습니다. 각 하드웨어 블록은 프레임버퍼의 픽셀 형식, 주소 지정 방식 및 적용된 압축에 합의해야 합니다. 이에 합의할 수 없다면 소프트웨어에서 복사와 변환을 수행해야 합니다.
그런 “공유” 프레임버퍼를 그냥 “원시” 픽셀 데이터로 만들 수는 없는지 물을 수도 있습니다. 원시 8비트 ARGB 픽셀 데이터를 담은 1920x1080 프레임버퍼를 생각해 봅시다. 이는 66 MiB를 조금 넘는 데이터입니다. 4K에서는 214 MiB에 약간 못 미치는 크기로 불어납니다. 복사에 따른 추가 비용이 없더라도, 이 정도 데이터를 초당 30, 60, 165 또는 240 프레임으로 읽고 쓰는 일은 메모리 버스에 막대한 부담을 주며, 따라서 엄청난 전력 소모를 유발합니다. 어떻게든 무한한 성능과 효율을 지닌 메모리 버스를 갖추더라도, 체인의 각 하드웨어 블록은 이 정도 데이터량을 처리할 충분한 로컬 캐시 또는 버스 밖 RAM과 처리 성능을 갖춰야 합니다. 이는 실현 불가능합니다.
다행히 하드웨어 공급업체도 이에 동의하며, 대부분의 디스플레이 하드웨어 “계열”은 같은 주소 지정 및 압축 체계를 지원하도록 구현하여 이 문제를 해결합니다. 이 덕분에 3D 엔진, 디스플레이 컨트롤러, 비디오 가속기는 거대한 자체 로컬 캐시를 두거나 메모리 버스를 계속 두드리지 않고도 메모리 효율적인 프레임버퍼를 공유할 수 있습니다. Linux에서는 각 드라이버가 지원하는 형식을 선언하고, 소프트웨어 스택의 여러 부분이 공유 버퍼에 사용할 공통 형식을 협상하고 합의합니다. 다행히 Apple은 여기에서는 너무 다르게 생각하지 않았습니다. 대체로는요.
Apple 하드웨어는 두 가지 주요 주소 지정 및 압축 형식을 사용합니다. GPU의 이름을 딴 AGX와 Interchange입니다. AGX 형식은 AGX 내부에서만 독점적으로 사용되는 반면, Interchange 형식은 DCP와 AVD도 지원합니다. macOS에서 이는 AVD와 AGX 양쪽의 프레임버퍼를 직접 스캔아웃할 수 있게 하며, Quartz(macOS 컴포지터)는 일상적인 많은 상황에서 기회적으로 거의 아무것도 하지 않도록 선택할 수 있습니다. 비디오가 재생 중이고 다른 일이 없다면 GPU는 완전히 꺼질 수 있고, 컴포지터는 AVD가 생성하는 새 프레임을 DCP가 표시하도록 보장하기만 하면 됩니다. 게임이나 애플리케이션이 전체 화면이라면 컴포지터는 해당 애플리케이션 자체 프레임버퍼의 주소를 DCP에 전달하고 자체 렌더링 활동을 모두 비활성화할 수 있습니다. 좋은 소식은 Asahi Linux에서도 이를 재현할 수 있는 길을 이제 잘 닦아 가고 있다는 점입니다!
Alyssa와 Lina가 마련한 토대 덕분에 AGX 드라이버에는 이미 Apple의 Interchange 프레임버퍼 형식에 대한 기본 지원이 있었고, 단지 아직 연결되지 않았을 뿐입니다. Oliver Bestmann과 저는 DCP 커널 드라이버 및 Asahi와 Honeykrisp Mesa 드라이버 양쪽에서 Interchange 지원을 연결하고 활성화하는 일을 자원했습니다. DCP에 Y’CbCr 및 오버레이 평면 지원을 가져온 기존 작업과 결합되어, 이는 AGX 렌더링 프레임버퍼를 DCP로 직접 스캔아웃할 길을 열었습니다! AVD 지원도 진행 중이며, sofus는 현재 Interchange 형식 버퍼를 출력할 수 있는지 조사하고 있습니다.
이 모든 것이 환상적인 소식이지만, 아직 이를 사용자에게 배포할 준비는 되지 않았습니다. KDE Plasma의 컴포지터인 Kwin은 AGX와 DCP가 구분된 하드웨어 블록이므로 우리의 구성을 “다중 GPU”로 간주합니다. 따라서 DMA-BUF API를 사용하는 직접 스캔아웃은 현재 완전히 비활성화되어 있습니다. Kwin 개발자들은 이 상황을 개선하기 위해 활발히 작업하고 있으며, 우리의 경우와 같은 구성에서 직접 스캔아웃은 Plasma 6.8부터 Kwin에서 활성화될 수 있습니다!
늘 그렇듯 계속해서 패치를 업스트림에 올리고 있습니다. 최근 몇 달간 진전은 느려졌고, 심지어 우리가 후퇴한 것처럼 보일 수도 있습니다. 이는 이미 대부분을 업스트림에 올렸기 때문입니다! 남은 것 대부분은 아직 업스트림에 올릴 수 없는 대규모 작업(GPU, DCP 등)이거나, 업스트리밍 적체의 대부분을 해소한 덕분에 이제야 작업할 수 있었던 새로운 기능입니다. 그렇지만 트리에는 여전히 자잘한 것들이 남아 있습니다. 최근 업스트림된 패치에는 speakersafetyd가 작동하도록 하는 것과 관련된 여러 I2S 주변장치 변경, SMC 기반 hwmon 드라이버를 활성화하는 Devicetree 패치, 그리고 물론 macOS 27이 도입한 모든 SMC 펌웨어 인터페이스 변경에 대한 수정이 포함됩니다.
자주 읽는 분들은 최근 블로그 글에 새로운 이름이 많이 나타나는 것을 알아차렸을 것입니다. GitHub Sponsors와 Open Collective 후원자들의 아낌없는 지원 덕분에, 이분들이 지금까지 마법 같은 작업을 하는 데 필요한 하드웨어를 제공할 수 있었습니다. AVD 지원, M4 초기 지원, 그리고 우리가 준비 중인 다른 멋진 기능들은 모두 여러분 덕분에 가능합니다.
James Calligeros · 2026-08-26
