AMD GPU를 쓰는 리눅스 사용자에게 RADV는 이미 낯설지 않은 이름이다. Mesa 프로젝트가 개발해 온 이 오픈소스 Vulkan 드라이버는 지난 몇 년 사이 리눅스 그래픽 스택의 핵심 축으로 자리 잡았고, 사실상 AMD 하드웨어의 표준 Vulkan 구현으로 통한다. AMD 스스로도 자사의 PAL(Platform Abstraction Library) 기반 대안을 접고 오픈소스 역량을 Mesa 쪽으로 몰아주면서 이 흐름에 힘을 실었다. 문제는 윈도우다. 윈도우에서 AMD 사용자는 여전히 폐쇄형 독점 드라이버 하나에만 의존해야 한다. Collabora가 최근 공개한 실험적 작업은 바로 이 간극을 겨냥한다. 리눅스에서 검증된 RADV를 윈도우로 이식해, 같은 오픈소스 코드베이스를 양쪽 플랫폼에서 굴리자는 것이다.
오픈소스 드라이버가 윈도우에서 동작한다는 것은 단순한 상징 이상의 실익을 갖는다. 플랫폼을 넘나드는 공통 코드베이스, 손쉬운 디버깅과 실험, 수정 사항의 빠른 반영, 그리고 게임 개발자를 비롯한 커뮤니티가 직접 문제를 보고하거나 개선에 기여할 수 있는 통로가 열린다. 한쪽에서 고친 버그가 운영체제와 무관하게 모두에게 이득이 되는 구조다. 실무 관점에서 이는 벤더의 릴리스 주기에 묶이지 않고 문제를 추적할 수 있다는 뜻이기도 하다.
리버스 엔지니어링 위에 쌓은 토대
이번 작업은 Faith Ekstrand가 앞서 닦아 둔 기반 위에 서 있다. 그는 RADV를 윈도우에서 돌릴 수 있는지를 처음 탐색해 XDC 2024에서 결과를 발표했다. 핵심은 윈도우 10부터 도입된 WDDM2 인터페이스가 서드파티 드라이버에 훨씬 나은 토대를 제공한다는 점이다. WDDM2는 사용자 모드 드라이버(UMD)가 운영체제 및 커널 모드 드라이버(KMD)와 어떻게 상호작용하는지에 대한 명확한 모델을 정의한다. 그러나 함정이 있다. 상당수의 D3DKMT 호출은 벤더별로 의미가 정해지는 불투명한 사설 데이터(private data) 블롭을 실어 나른다. 결국 UMD와 KMD는 긴밀하게 결합돼 있고, 이 인터페이스는 문서화돼 있지 않다.
이 벽을 넘기 위해 Faith는 wddm2-pdd-re라는 도구로 일부 D3D12 애플리케이션의 WDDM2 호출과 사설 데이터 내용을 기록했다. 이 방식으로 어댑터 정보 조회, 버퍼 할당, 큐 생성, 명령 제출에 필요한 만큼의 사설 인터페이스를 역설계해 냈고, 최종적으로 화면에 회전하는 3D 모델을 띄우는 데 성공했다. "가능하다"는 것을 입증한 셈이다.
가능성에서 실사용으로
Collabora의 이번 단계는 그 실마리를 이어받아 세 방향으로 밀어붙였다. 하드코딩된 값을 줄여 여러 하드웨어를 지원하는 유연성, WSL에서 벗어나 네이티브 윈도우로 동작하는 이식성, 그리고 deqp-vk 테스트 2분 만에 죽던 상태를 넘어서는 안정성이다. 명령 스트림 처리와 동기화를 개선했고 스파스 바인딩, 테셀레이션, 태스크 셰이더 지원과 GPU 속성의 동적 질의 등을 추가했다. 아직 적합성(conformance) 인증을 통과한 수준은 아니지만 성공률은 크게 올랐고, 무엇보다 첫 게임 실행에 도달했다. 카운터 스트라이크 2를 -vulkan 인자로 렌더러를 바꿔 구동할 수 있으며, 누구나 시도해 볼 수 있다.
과정은 이식·역설계 프로젝트 특유의 난관을 동반했다. 실험 대상이 11세대 하드웨어(RX 7900 XT)로 바뀌자 Faith가 쓰던 10세대(RX 7800 XT)에서의 결과가 한동안 재현되지 않았다. 아키텍처 변화 탓에, 표면을 하드코딩된 색으로 지우는 것보다 조금이라도 복잡한 작업을 시키면 곧바로 멈춰 버렸다. 윈도우에서 이런 행(hang)을 디버깅할 도구가 없던 탓에, 팀은 역설계 유틸리티를 명령 스트림·레지스터·셰이더 코드까지 덤프할 수 있는 완전한 WDDM2 로깅 계층으로 끌어올려야 했다. 컴파일러도 애를 먹였다. Mesa는 주로 GCC와 Clang을 기준으로 개발돼 왔는데, MSVC는 enum을 부호 있는 32비트 값으로 해석하는 등 다른 컴파일러와 다르게 처리해 예상 밖의 동작을 낳았다. D3DKMTEscape처럼 벤더 전용 훅으로 불투명 데이터를 또 실어 나르는 지점도 있었지만, 다중 GPU 렌더링 같은 고급 기능에 쏠려 있어 당장은 무시해도 안전한 것으로 판단됐다.
남은 과제와 현실적 한계
제품화의 가장 큰 물음표는 독점 커널 드라이버와의 인터페이스다. 자체 KMD를 만드는 것은 현실적 선택지가 아니어서 AMD의 커널 드라이버와 통신해야 하는데, 지금은 역설계로 알아낸 사설 자료구조에 의존하고 있어 본질적으로 취약하다. 더구나 UMD와 KMD는 한 쌍으로 함께 배포되며 하위 호환성 보장이 없어, 드라이버 버전이 바뀌면 이 구조가 예고 없이 달라질 수 있다. 안정적이고 유지보수 가능한 윈도우 지원이 되려면 이 관계를 떠받칠 견고한 토대가 필요하다는 뜻이다.
화면 표시(presentation) 쪽에도 상당한 작업이 남아 있다. Jesse Natalie가 Dozen 드라이버 맥락에서 윈도우용 WSI 작업을 일부 했지만, RADV는 현재 느린 CPU 경로만 지원한다. 성능을 높이려면 DXGI 스왑체인을 써야 하고 이는 D3D12에서 이미지를 가져오는 또 다른 불투명 메타데이터 문제를 부른다. 궁극의 목표인 무복사(zero-copy) 스왑은 GPU 병목이 아닌 애플리케이션에서 최대 3배 성능 향상을 가져올 수 있지만, 이미지 공유 제약 때문에 AMD와 마이크로소프트의 직접 참여가 필요할 전망이다. 결국 이번 성과의 진짜 메시지는 '완성'이 아니라 '설득'에 가깝다. 오픈 Vulkan 드라이버가 윈도우에서 갖는 가치를 실물로 보여줌으로써, 안정적 토대를 향해 AMD와 마이크로소프트를 포함한 이해관계자 모두를 움직이려는 것이다. 코드는 공개 브랜치에 올라와 있으며, 이번 단계 작업은 밸브(Valve)의 후원을 받았다.