한 달 만에 M4 Mac Mini용 Linux GPU 드라이버 만들기 — LLM이 뒤집은 '수년짜리 작업'의 상식

본문

GPU 드라이버 개발은 통상 수년이 걸리는 대공사로 알려져 있습니다. 저자 Cody와 Niklas는 LLM 코딩 에이전트를 투입해 이를 약 한 달 만에 해냈고, 그 결과물은 M4 Mac Mini에서 Chrome·Firefox의 WebGL과 합성(compositing)이 동작하고 Minecraft가 200fps로 실행되는 수준입니다. 이 글은 그 과정 전체 — 하이퍼바이저 기반 역공학, AGX 펌웨어 ABI 해부, Mesa 기반 사용자 공간 드라이버 구축 — 를 상세히 기록한 보고서입니다.

배경과 접근 방식

저자는 이전에 macOS를 역공학하기 위한 하이퍼바이저를 만든 바 있고, 이번에는 그것으로 '유용한 일'을 하기로 했습니다. 목표는 M4 Mac Mini와 MacBook Neo에서 동작하는 OpenGL(곧 Vulkan) 호환 드라이버입니다. 프로젝트는 현대 GPU 드라이버의 표준 구조를 따라 커널 공간과 사용자 공간으로 나뉩니다. 커널은 펌웨어와 통신하고 버퍼 할당과 스케줄링을 담당하고, 사용자 공간은 GPU가 실제로 무엇을 하는지 이해하고 버퍼를 채웁니다. 전 과정에서 Apple 바이너리는 일절 보지 않았고, 하이퍼바이저로 얻은 하드웨어 트레이스와 직접 작성한 셰이더만 사용했습니다. 필요한 Apple blob은 문서화만 받아 opaque 객체로 취급하는 클린룸 절차를 지켰고, 모든 실험은 검증 가능하도록 agx-re 저장소에 공개했습니다.

커널 공간: AGX 펌웨어 ABI 역공학

Apple Silicon에서 커널 드라이버는 하드웨어와 직접 통신하지 않고, RTKit라는 커스텀 RTOS 위에서 도는 GPU 펌웨어와 대화합니다. 문제는 이 펌웨어 ABI가 '정상적인 커널 드라이버를 반으로 잘라 절반을 펌웨어에 넣은' 기형적 구조라는 점입니다. 공유 메모리 구조체에는 펌웨어 소유 필드와 호스트 제어 필드가 뒤섞여 있고, A18 Pro의 ABI는 이미 복잡했던 M1 대비 구조체는 1.5배, 포인터는 2배에 작업 제출 절차도 훨씬 복잡합니다. Asahi Lina가 M1/M2에서 해낸 작업이 얼마나 대단했는지 새삼 드러나는 대목입니다.

방법론은 단순했습니다. 하이퍼바이저로 macOS의 동작을 관찰하고, 재생(replay)하고, 직접 재구성하는 것입니다. 흥미로운 것은 Codex가 '재생'을 문자 그대로 받아들여 첫 번째 펌웨어 이벤트('kick') 후 GPU 메모리 전체를 통째로 저장했다가 재부팅 후 그대로 복사해 kick만 실행하는 방식부터 시작했다는 점입니다. 이후 실험을 반복하며 복사하는 페이지를 점차 줄여 모든 상태를 코드로 만들어냈고, 저자는 Codex가 '하드웨어를 더 찔러볼 때'와 '트레이스를 캡처할 때'를 구분하는 감각이 좋았다고 평가합니다.

세 가지 큰 장애물이 있었습니다. 첫째, 펌웨어 기동 후 제출된 렌더 작업이 아무 일도 하지 않고 ACK·폐기되는 문제로, AGX 수명 주기 초기의 캡처를 고르라고 지시하자 단일 바이트 디스크립터 누락이 원인임을 거의 즉시 찾아냈습니다. 둘째, 유일한 '블로킹' 이슈였던 compute 작업은 GUI 경로에서 늦게 등장해 336MB짜리 재생 불가 캡처만 얻어지다가, 싱글유저 모드로 부팅해 LaunchDaemon으로 Metal 가용 직후 최소 Metal 프로그램을 실행하는 전략으로 순수 compute 트레이스를 얻어 며칠 만에 해결했습니다. 셋째, TVB(Tiled Vertex Buffer)가 부족할 때 발생하는 partial render는 GPU에 '저장 후 재개' 기능을 구현하는 것과 같아 가장 까다로웠지만, 동일한 캡처-재생 워크플로로 돌파했습니다.

Python 프로토타입에서 완전한 Rust 커널 드라이버로 옮기는 데는 사흘이 걸렸습니다. drm-shim을 Rust로 재작성해 동기 드라이버를 만들고, 프론트엔드와 제출 경로를 순차적으로 비동기화한 뒤 배치 제출 같은 최적화를 적용하는, 통상적인 엔지니어링 절차였습니다. 저자는 Codex가 코드가 안 될 때 하이퍼바이저로 전체 주소 공간을 캡처해 정상 샘플과 비교하는 체계적 디버깅을 적극 활용했다고 밝힙니다.

사용자 공간과 Mesa

A18 Pro 사용자 공간은 새 디스크립터 포맷과 새 ISA를 가진 M1/M2와는 다른 GPU입니다. 1단계에서 Claude가 Metal 프로그램들을 분석해 디스어셈블러·어셈블러를 만들었지만, 임의 프로그램을 컴파일할 만큼의 이해에는 이르지 못했습니다. 2단계에서는 두 가지 접근이 갈렸습니다. 하드웨어 이해를 우선해 스펙을 쓰고 LLM에게 구현을 시키려 한 저자의 방식은 '완전성' 명목으로 잡무에 시간을 쓰며 지체됐고, Mesa를 먼저 구축하며 필요한 부분만 역공학한 Niklas의 'Mesa first' 방식이 훨씬 빨랐습니다. 저자는 Codex의 한계를 '지나치게 꼼꼼함(pedantic)'으로 진단합니다.

한편 비트를 직접 건드리는 실험으로 Metal이 노출하지 않는 하드웨어 기능 — 단일 명령어 64비트 덧셈, 128x 이방성 필터링(Metal 상한은 16x), 행렬 유닛의 새 모드, uniform_mov의 7비트 immediate — 도 발견했습니다. Mesa 개발은 Khronos CTS가 사실상 '채점 기준'을 제공하고 Gallium↔AGX 변환만 하면 되는 구조라 LLM 작업에 유리했고, NIR→AGX ISA 컴파일러는 향후 Vulkan 드라이버에도 재사용됩니다. 결과물은 Mesa와 Linux 커널 드라이버, 사용자 공간 RE 문서로 공개됐습니다.

남은 과제

Vulkan 1.4, OpenGL 4.6, OpenGL ES 3.2, OpenCL 3.1, Proton 경유 Direct3D 12, 레이 트레이싱이 목표입니다. Mesa 업스트리밍은 Asahi UAPI를 그대로 써 정책 문제는 없지만, '최초의 완전 LLM 작성 GPU 드라이버'라는 점에서 더 높은 검증 기준을 예상합니다. 커널 드라이버는 아직 업스트림되지 않은 M1/M2 드라이버 선행을 기다려야 해 시간이 더 걸릴 전망입니다. 부록에서 저자는 GPT-5.6 Sol과 GPT-6 Astra가 펌웨어 ABI RE에서 압도적이었다고 밝히되, 과도한 보안 제한 때문에 1분마다 스크린샷을 비교해 진행이 멈추면 '/goal resume'을 입력하는 데몬까지 만들었다는 일화를 공개합니다. 또한 M5는 사용자 공간이 부분 역공학, 펌웨어 ABI는 완전 역공학된 상태라고 덧붙입니다.

Hacker News 반응

• @Agingcoder — 이게 실제로 작동한다는 게 블랙 매직 수준으로 믿기지 않으며, 무엇이 가능한지에 대한 자신의 멘탈 모델이 아직 따라가지 못했다고 놀라워합니다.
• @porphyra — Asahi Linux의 최대 고충이 M3 이상에서 GPU 가속이 없다는 점인데 Asahi는 엄격한 no-AI 정책을 갖고 있어 이 성과가 업스트림될 수 없으며, 앞으로 AI 보조 포크들이 주도권을 잡을 것이라 전망합니다.
• @varispeed — GPT-6 Astra가 너프된 뒤로는 Gemini 다음가는 수준으로 떨어졌고 Sol만 아직 유지된다고 평가를 깎습니다.
• @ADevWithAnIdea — 전혀 동의할 수 없다며 경험은 각자 다르다고 반박합니다.
• @hypercube33 — Claude 모델은 본인 자격증명으로 자기 VM에 ssh 로그인하는 것조차 가드레일에 막혔다며 모델 너프 논의에는 맥락이 필요하다고 지적합니다.

원문: Hacker News / 번역·요약: Trawling