UTM 개발팀은 2026년 7월 24일 QEMU용 Windows 그래픽 드라이버 Triton을 공개했다. VirtIO를 통해 Direct3D 호출을 호스트로 전달하는 Neptune과 결합해, QEMU 가상 머신에서 DirectX 11 경로를 구성하는 것이 목표다. 핵심은 게임 실행 파일 옆에 DLL을 끼워 넣는 우회가 아니라 Windows 그래픽 드라이버가 원래 맡는 DDI(Device Driver Interface)를 구현했다는 데 있다.
가상화 그래픽의 병목은 GPU 명령을 한 번 옮기는 데서 끝나지 않는다. Windows 데스크톱에서는 애플리케이션, Direct3D·DXGI 시스템 라이브러리, 사용자 모드 드라이버(UMD), 커널 모드 드라이버(KMD), 가상 장치가 층을 이룬다. Triton은 UMD와 KMD를 구현하고, KMD가 VirtIO 장치와 통신한다. Neptune은 그 뒤에서 DirectX 호출을 직렬화해 게스트와 호스트의 경계를 넘긴다.
왜 애플리케이션별 DLL 교체로는 부족한가
기존 접근은 d3d11.dll과 dxgi.dll을 게임 실행 파일 옆에 두고 애플리케이션별로 불러오게 하는 방식이다. 일부 게임을 돌릴 수 있지만, Windows의 DWM(Desktop Window Manager)은 그 프레임을 GPU 자원이 아니라 이미지로 보게 되어 CPU 복사를 거칠 수 있다. 시스템 DLL 자체를 바꾸기도 어렵고, 애플리케이션마다 파일을 배치해야 하며, 이런 변경을 감지하는 안티치트가 있는 게임에서는 적용 범위가 더 좁아진다.
DDI 드라이버는 이 위치를 바꾼다. 애플리케이션은 Windows가 제공하는 d3d11.dll과 dxgi.dll을 그대로 사용하고, 시스템 런타임이 정리한 명령을 UMD에 전달한다. DXGI는 어댑터와 스왑체인을 다루며 UMD·KMD를 잇는다. 즉 창 합성, 백버퍼, 화면 전환처럼 개별 게임 DLL 방식이 비켜 가던 경로를 그래픽 스택 안에서 다룰 기반이 생긴다.
Triton은 DDI 호출을 왜 다시 DirectX 호출로 바꾸나
Neptune은 이미 Direct3D API 호출을 전달하는 프로토콜을 갖고 있다. Triton은 Windows 런타임에서 내려온 DDI 호출을 대응하는 API 호출로 되돌려 Neptune에 넘기는 방향을 택했다. D3D11의 많은 호출은 핸들을 장치 핸들에 매핑하고 API·DDI 열거형 차이를 맞추는 수준으로 연결할 수 있다. 호스트에서 별도의 중간 바이트코드를 해석하는 단계를 두지 않아도 되는 구조다.
이는 VirtualBox의 공개 DirectX 11 UMD와 대비된다. VirtualBox는 DDI 호출을 중간 바이트코드로 만들고 호스트에서 다시 DirectX API 호출로 해석한다. UTM 팀은 그 변환과 해석 단계를 추가하면 호환성 오류가 들어갈 지점도 늘어난다고 판단했고, 라이선스도 QEMU·virglrenderer와 맞지 않아 코드를 가져오지 않았다. 대신 구현된 DDI 프로토타입 목록과 DXBC 서명 처리 방식은 최소 구현 범위를 파악하는 데 참고했다.
셰이더에서는 ‘그대로 전달’만으로 끝나지 않는다
가장 까다로운 지점은 DXBC다. FXC는 HLSL 셰이더를 DXBC 바이트코드와 입력·출력 서명 같은 메타데이터를 담은 DXContainer로 컴파일한다. 애플리케이션이 ID3D11Device::CreateVertexShader를 호출할 때는 전체 컨테이너를 넘기지만, d3d11.dll이 Triton UMD의 pfnCreateVertexShader를 부를 때는 SHDR 바이트코드 부분만 전달한다.
따라서 Triton은 바이트코드를 호스트로 바꾸지 않고 보낼 수 있어도, 호스트 DirectX 렌더러가 기대하는 컨테이너 메타데이터를 바이트코드에서 다시 구성해야 한다. 이 작업은 셰이더를 다른 언어로 번역하는 것보다 범위는 작지만, 서명 필드가 맞아야 한다는 별도 호환성 과제를 남긴다.
호스트 렌더러까지 이어지는 다음 과제는 무엇인가
Linux 호스트에서는 DXVK가 Direct3D 11을 Vulkan으로 변환한다. macOS에서는 DXMT가 Direct3D 11을 Metal로 직접 변환하는 경로와 Apple Game Porting Toolkit의 D3DMetal을 감싸는 경로를 다룬다. 두 경로 모두 Wine 중심으로 출발했기 때문에, 서로 다른 렌더러 프로세스 사이에서 데스크톱 합성에 필요한 공유 텍스처와 GPU 펜스를 처리하는 일이 남아 있다. UTM 팀은 D3DMetal이 성능상 유리하다고 적었지만 배포 라이선스는 UTM 번들에 맞지 않는다고 밝혔다.
이 프로젝트는 단순히 “가상 머신에서 게임 하나를 실행했다”는 시연보다 Windows 그래픽 드라이버의 책임을 어디까지 재현해야 하는지 보여 준다. Triton은 DirectX API를 애플리케이션 단에서 흉내 내는 대신, DDI·VirtIO·호스트 렌더러를 하나의 연속된 경로로 묶는다. 다만 UTM은 현재 드라이버가 매우 불안정하므로 중요한 VM에는 설치하지 말라고 안내한다. 이 경로가 안정되면 QEMU의 Windows 게스트에서 데스크톱과 게임 그래픽을 다루는 방식도 개별 호환성 패치에서 드라이버·가상 장치 조합으로 이동하게 된다.
출처: UTM Blog, “Introducing Triton: DirectX 11 driver for QEMU” (2026-07-24)