Tyr의 미래, Arm Mali 하드웨어용 Rust GPU 드라이버
Source: Hacker News
Did you know…?
LWN.net은 구독자 지원 출판물이며, 전체 운영을 유지하기 위해 구독자에 의존합니다. 구독을 구매하여 LWN을 계속 운영할 수 있도록 도와주세요.
Tyr 팀은 2025년에 Arm Mali 하드웨어용 Rust GPU 드라이버를 만들겠다는 목표를 가지고 시작했지만 보여줄 것이 거의 없었습니다. 연말이 되자 우리는 Linux Plumbers Conference (LPC)에서 SuperTuxKart(3‑D 오픈소스 레이싱 게임)를 실행할 수 있었습니다. 우리의 프로토타입은 Arm, Collabora, 그리고 Google이 공동으로 만든 결과물이며, 행사 기간 내내 원활히 동작했고 성능도 플레이어들에게 충분히 만족스러웠습니다.
다행히도 우리는 정확히 적절한 시점에 속도를 낼 수 있었습니다: Dave Airlie가 Maintainers Summit에서 DRM 서브시스템이 새 C 드라이버를 허용하지 않고 Rust 사용을 요구하는 시점이 “약 1년 정도 남았다”는 발표를 했습니다. 이제 2026년을 위한 가능한 로드맵을 제시하고, 이 작업을 모두 업스트림으로 가져갈 때입니다.
Tyr로 무엇을 달성하려고 하는가?
Miguel Ojeda가 올해 LPC에서 발표한 강연에서는 Rust가 Linux 커널에서 어떻게 사용되고 있는지를 요약했으며, Android용 익명 공유 메모리 서브시스템(ashmem)과 같은 드라이버가 수백만 사용자에게 빠르게 배포되고 있음을 보여주었습니다. 전화 시장에서 Mali의 점유율이 매우 높기 때문에 이 분야를 지원하는 것은 Tyr의 자연스러운 목표이며, 그 다음으로 Mali가 탑재된 다른 임베디드 플랫폼들을 지원하고자 합니다.
동시에 우리는 업스트림을 놓치지 않아야 합니다. 목표는 Nova Rust GPU 드라이버와 함께 진화하고, 향후 새롭게 등장할 수 있는 모든 드라이버에 유용한 생태계를 구축하는 것입니다. 프로토타입은 Arm Mali용 Rust 드라이버가 허용 가능한 성능으로 구현될 수 있음을 증명하기 위한 것이었지만, 이제 코드를 반복적으로 개선하고 필요에 따라 리팩터링해야 합니다. 이를 통해 실수를 교정하고 업스트림 드라이버에 적합한 설계를 확정할 수 있습니다.
현재 존재하는 것과 아직 없는 것
- Tyr 드라이버의 한 버전이 6.18 커널 릴리스에 병합되었지만, 몇몇 핵심 Rust 추상화가 빠져 있어 실제로 할 수 있는 일은 제한적입니다.
- 다운스트림 브랜치(아직 메인라인 커널에 포함되지 않은 Tyr의 부분)에는 최신 프로토타입이 보관되어 있습니다; 데스크톱 환경과 게임을 실행할 정도로 충분히 동작하지만, 아직 해결해야 할 전력 소비 및 GPU 복구 문제 등이 남아 있습니다.
- 이 프로토타입은 우리의 업스트림 작업을 안내하고 다양한 설계를 실험하는 용도로 활용될 것입니다.
Tyr와 같은 커널 모드 GPU 드라이버는 Vulkan이나 OpenGL과 같은 그래픽 API를 구현하는 훨씬 큰 사용자 모드 드라이버를 지원하는 작은 구성 요소입니다. 사용자 모드 드라이버는 하드웨어에 독립적인 API 호출을 GPU 전용 명령으로 변환하여 래스터화 과정에서 사용할 수 있게 합니다. 커널의 책임은 다음과 같습니다:
- 애플리케이션 간 하드웨어 자원 공유,
- 격리와 공정성 보장,
- 하드웨어를 정상적으로 운영( GPU 메모리 제공, 작업 완료 시 알림, 사용자 공간에서 작업 간 의존 관계를 기술할 수 있는 방법 제공)
우리의 강연(YouTube 영상)에서는 이 내용을 LPC 2025에서 자세히 다루었습니다.
작동하는 프로토타입이 있다고 해서 실제 사용에 적합하다는 뜻은 아닙니다. 누락된 부분을 빠르게 살펴보면 그 이유가 명확합니다.
- 전원 관리 – Mali GPU는 보통 전력이 제한된 모바일 기기에 탑재됩니다. 에너지 절약과 열 관리가 사용자 경험에 매우 중요하지만, 현재 Tyr에는 전원 관리나 주파수 스케일링 코드가 전혀 없습니다. 이를 지원할 Rust 추상화도 아직 제공되지 않고 있습니다.
- GPU 복구 – GPU가 멈출 경우 시스템은 가능한 한 정상적으로 동작해야 합니다; 그렇지 않으면 사용자는 모든 작업을 잃게 됩니다. 우리의 프로토타입에는 GPU 복구 코드가 전혀 없습니다. 이 두 항목은 배포 가능성을 위한 필수 조건이며, 배터리를 급격히 소모하거나 시스템을 크래시시키는 드라이버는 절대 출시될 수 없습니다.
이와 더불어 Vulkan이 Tyr 위에서 올바르게 구현될 수 있어야 하며, 그렇지 않으면 Vulkan 드라이버(PanVK)와의 드롭‑인 호환성을 달성하지 못할 위험이 있습니다. 이를 위해서는 C 드라이버 대신 Tyr를 사용했을 때 Vulkan Conformance Testing Suite를 통과해야 합니다. 이 목표를 달성하면 현재 지원하고 있는 Mali‑G610 외에 더 많은 GPU 모델을 지원하는 작업을 자신 있게 진행할 수 있습니다.
마지막으로 우리는 벤치마킹에 주력하여 Tyr가 C 드라이버와 동등한 성능을 유지하면서 Rust의 안전성 보장을 누릴 수 있는지 확인할 것입니다. 복잡한 게임을 허용 가능한 성능으로 실행한 사례가 이미 있기 때문에, 지금까지는 결과가 긍정적입니다.
어떤 Rust 추상화가 누락되어 있나요?
- Graphics Execution Manager (GEM) shmem objects – Lyude Paul의 GEM shmem 객체 작업은 독립적인 비디오 RAM이 없는 시스템을 위한 메모리 할당에 필요합니다. 이는 GPU가 더 큰 시스템‑온‑칩에 패키징되어 시스템 메모리를 공유해야 하는 Tyr에 특히 관련됩니다.
- Lock‑free buffer region sharing – 잠금 없이 GPU 버퍼의 겹치지 않는 영역을 공유하는 방법에 대한 미해결 질문이 있습니다. 이는 가능하면 타입 시스템에 인코딩되고 컴파일 시점에 검증되길 바랍니다.
- GPUVM support – 최신 커널 드라이버는 사용자 모드 드라이버가 자체 GPU 주소 공간을 관리하도록 허용해야 합니다. DRM 생태계에서는 이것이 GPUVM 에 위임되며, 해당 하드웨어가 제공하는 주소 공간을 관리하는 공통 코드를 포함합니다.
이러한 요소들은 앞서 언급한 전원 관리 및 복구 메커니즘과 함께, Tyr을 2026년에 프로덕션‑레디, 업스트림‑레디 상태로 만들기 위한 로드맵의 핵심을 이룹니다.
# Rust GPU Driver Progress – Tyr메모리 격리 및 GPUVM
- 최신 CPU는 강력한 메모리 격리 기능을 제공하며, GPU 펌웨어는 메모리 내 특정 섹션의 배치에 대해 유사한 제어를 기대합니다.
- Alice Ryhl은 다음 작업을 진행 중입니다:
- GPUVM을 위한 Rust 추상화.
- 메모리 격리를 구현하는 IOMMU 페이지 테이블을 조작하기 위해 필요한
io-pgtable추상화.
이러한 노력은 DRM 서브시스템을 위한 최초의 Rust 추상화를 개척한 Asahi Lina의 이전 작업을 기반으로 합니다.
해결되지 않은 DRM 디바이스 초기화 문제
현재 코드는 드라이버의 프라이빗 데이터를 초기화하기 위해 drm::Device 인스턴스를 반환해야 합니다.
하지만 일부 드라이버는 그 프라이빗 데이터를 구성하기 위해 drm::Device가 필요해, 순환 의존성이 발생하고 이를 만족시킬 수 없습니다.
- Tyr가 영향을 받는 이유:
- GEM shmem API를 통해 GPU 메모리를 할당하려면
drm::Device가 필요합니다. - Tyr의 프라이빗 데이터 중 일부 필드는 GEM 객체를 저장해야 합니다(예: 펌웨어 파싱 및 부팅을 위해).
- GEM shmem API를 통해 GPU 메모리를 할당하려면
Paul Lyude는 타입 시스템에 디바이스 상태를 인코딩하는 drm::DeviceCtx를 도입함으로써 이 문제를 해결하고 있습니다.
Status: 대부분의 로드맵이 GEM shmem, GPUVM, io‑pgtable, 그리고 디바이스 초기화 문제 때문에 여전히 차단된 상태입니다.
또한 Nova 팀의 작업을 통합할 기회가 있습니다:
이 구성 요소들이 마련되면 GPU 펌웨어를 빠르게 부팅하고, 작업 제출 논의가 시작될 때까지 추가적인 장애물 없이 진행할 수 있을 것으로 기대됩니다.
Source: …
Fence Handling & Synchronization
펜스는 GPU 드라이버가 작업 실행이 끝났을 때 신호를 보내는 동기화 프리미티브입니다. 올바른 처리가 매우 중요합니다:
- 펜스를 완료하는 경로는 신중하게 주석을 달아야 합니다; 그렇지 않으면 시스템이 교착 상태에 빠질 수 있습니다.
- 신호 전달 경로에서는 안전한 락만 사용해야 합니다.
- DMA 펜스는 반드시 유한한 시간 내에 신호를 보내야 합니다; 그렇지 않으면 시스템의 다른 부분이 영원히 차단될 수 있습니다.
- 이러한 경로에서의 메모리 할당은
GFP_ATOMIC을 사용해야 합니다. 다른 플래그로 할당하면 메모리 압박 상황에서 축소기가 실행될 수 있으며, 이는 해당 작업 자체가 트리거한 작업을 기다리게 만들 위험이 있습니다.
이 모든 내용은 커널 문서에 정리되어 있습니다:
Current prototype: 이러한 제약을 무시하고 있어 메모리 압박 상황에서 무작위로 교착 상태가 발생할 수 있습니다.
Fix: 드라이버의 중요한 섹션을 체계적으로 검증합니다. 이를 우아하게 수행—가능하면 Rust의 타입 시스템을 활용하는 방안—은 아직 논의 중입니다.
미래를 내다보며
작업 제출 로직 재고
기존 설계는 drm_gpu_scheduler 사용을 전제로 하지만, 이제는 장애물이 되고 있습니다:
- 일부 드라이버는 이제 작업을 스케줄링하기 위해 GPU 펌웨어에 의존합니다.
drm_gpu_scheduler는 해결하기 어려운 수명 관리 문제에 시달리고 있습니다.
X.Org Developer’s Conference 2025에서 대안을 논의했습니다. Rust에 대한 새로운 합의는 다음과 같은 새로운 컴포넌트를 만드는 것입니다:
- 작업이 GPU 링 버퍼에 배치될 자격을 얻기 전에 작업 의존성이 충족되었는지 확인합니다.
- 작업이 준비되면 스케줄링을 펌웨어에 넘깁니다.
이 컴포넌트는 자체적으로 작업을 스케줄링하지 않으므로 **JobQueue**라는 이름이 붙을 가능성이 높습니다. 이 이름은 의존성이 충족되면 작업이 투입되고 제거되는 큐를 의미합니다.
- Philip Stanner가
JobQueue작업을 주도하고 있습니다.
C 드라이버 상호 운용성
이 계획은 이전 기사에서 설명한 기법을 사용해 C 드라이버용 API를 공개하는 것을 포함합니다. 이는 C 드라이버에서 사용할 수 있는 최초의 Rust 커널 컴포넌트가 될 수 있으며, 커널 내 Rust의 이정표를 세우고 C–Rust 간의 원활한 상호 운용성을 보여줍니다.
Tyr를 테스트베드로 활용
Tyr는 새로운 설계의 테스트베드로 활용될 수 있습니다:
- 프로토타입에서 기존
drm_gpu_scheduler를JobQueue로 교체할 수 있다면, Nova와 같은 더 복잡한 드라이버에 대한 접근 방식을 검증할 수 있습니다. - 이 주제에 대한 논의는 계속될 것입니다.
Summary
- Progress: GPUVM, IOMMU 페이지 테이블, 그리고 디바이스‑state 인코딩을 위한 Rust 추상화에서 큰 진전이 있었습니다.
- Blockers: GEM shmem, GPUVM, io‑pgtable, 그리고 DRM 디바이스‑initialization 사이클.
- Next Steps: Nova 매크로 통합, 펜스 처리 해결,
JobQueue개발, 그리고 C‑driver API 공개. - Outlook: Tyr는 지난 해에 상당한 진전을 이루었으며 2026년 및 그 이후에도 계속 발전할 준비가 되어 있습니다.