Проброс видеокарты (GPU passthrough) годами был единственным честным способом получить в виртуальной машине настоящую 3D-графику: отдаёшь физическую карту гостю целиком, хост её больше не видит. Работает, но цена высокая — нужна вторая GPU или готовность лишиться ускорения на хосте, плюс возня с IOMMU и VFIO. 8 августа 2026 команда UTM представила Triton — драйвер, который приносит DirectX 11 в QEMU-гостя вообще без проброса карты. Разберём, как это устроено и где тут подвох, потому что подвох, как всегда, есть.
Кому интересно. Тем, кто гоняет Windows в виртуалке на Linux или Mac — ради старой игры, приложения под DirectX или просто рабочего окружения, где хочется, чтобы рабочий стол Windows композитился аппаратно, а не рисовался процессором. И тем, кому в homelab нужна графика в VM, но отдавать под это отдельную GPU не хочется.
Идея: не пробрасывать железо, а пересылать API-вызовы
Passthrough отдаёт гостю саму карту. Triton идёт другим путём — он перехватывает вызовы DirectX внутри гостя и переправляет их хосту, где их уже исполняет реальная графика хоста. Гость думает, что рисует сам; на деле он диктует команды, а рисует хост.
Конвейер получается такой (он на обложке выше):
- Гость (Windows). Приложение зовёт DirectX 11 / DXGI как обычно.
- Triton — драйвер пользовательского режима (UMD). Он превращает вызовы уровня DDI (интерфейс драйвера) и байткод шейдеров DXBC обратно в вызовы DirectX API.
- Neptune — слой, который сериализует эти вызовы и гонит их через кольцевой буфер virtio из гостя на хост.
- Хост. QEMU (форк UTM) принимает virtio-команды,
virglrendererих десериализует, и настоящая реализация DirectX на хосте рендерит кадр.
Изящество — в выборе уровня перехвата. Triton работает на стыке DDI и API: одно преобразование DDI → API вместо промежуточной интерпретации байткода, как в некоторых других решениях. Меньше слоёв — меньше мест, где ломается совместимость.
Одна задача — три хостовых бэкенда
Дальше самое интересное: «настоящий DirectX на хосте» — это ведь абстракция, у хоста своя графика. Поэтому у Triton три разных бэкенда под разные платформы, и ведут они себя по-разному.
| Бэкенд | Платформа хоста | Как транслирует | Нюанс |
|---|---|---|---|
| DXVK | Linux (Vulkan) | D3D11 → Vulkan | самый «свободный» путь, опирается на зрелый DXVK |
| DXMT | macOS, нативный ARM64 | D3D11 → Metal напрямую | нативно под Apple Silicon |
| D3DMetal | macOS (Apple Game Porting Toolkit) | через фреймворк Apple | только x86_64, требует Rosetta |
Контринтуитивный результат из статьи: D3DMetal обгоняет DXMT по скорости даже работая через эмуляцию Rosetta. То есть «нативный» бэкенд оказывается не самым быстрым — Apple’овский фреймворк портирования игр вылизан лучше. Хороший повод не доверять интуиции «нативное = быстрее» и мерить руками.
Про D3DMetal есть важное ограничение, и оно не техническое, а лицензионное. Фреймворк D3DMetal.framework от Apple разрешён к использованию только для «разработки, тестирования или оценки видеоигр» и с запретом на коммерческое распространение. UTM прямо отмечает: у CrossOver (коммерческий Wine) есть отдельное соглашение с Apple на бандл D3DMetal — у остальных его нет. Так что «самый быстрый» бэкенд — заодно и самый юридически связанный.
Где честно признаются в шероховатостях
Это ранний проект, и авторы это не скрывают — что для разбора ценнее любых обещаний. Слабые места по их же словам:
- Реконструкция метаданных DXBC — «самый слабый и подверженный ошибкам» компонент. Драйвер восстанавливает заголовки
DXContainer, которых хостовый рендерер ждёт, из сырого байткода шейдера — методом проб. - Общие текстуры на macOS ограничены линейным форматом (через
shm_open()+MTLBuffer), что неэффективно по памяти при большом их количестве. - Синхронизация — заборы (fences) эмулируются на стороне CPU с опросом, а это добавляет задержку на каждый кадр.
- Сами Windows-драйверы авторы помечают как «очень нестабильные», предназначенные для тестирования.
Отдельно про производительность: в анонсе нет числовых бенчмарков. Есть скриншоты — Crash Bandicoot Trilogy на Windows 11 ARM64, прогоны FireStrike на обоих macOS-бэкендах, работающий композитинг рабочего стола Windows (DWM) поверх DXVK. Это доказывает, что «оно рисует», но не отвечает на вопрос «сколько FPS». Пока это демонстрация работоспособности, а не готовое к играм решение — держите ожидания в узде.
Как это соотносится с тем, что было
Чтобы Triton встал на своё место, полезно сравнить с соседями по задаче — тоже из разбора авторов:
- GPU passthrough — даёт максимум производительности и совместимости, но требует отдельной карты (или лишает хост ускорения) и настройки VFIO. Triton эту цену убирает ценой производительности и стабильности.
- Подмена DLL — CPU-блиттинг при композитинге окон, ограниченная совместимость, копирование файлов под каждое приложение.
- Venus (проброс Vulkan) — на macOS требует трансляции через MoltenVK и, по словам авторов, менее стабилен, чем прямой путь через Direct3D.
- Подход VirtualBox с промежуточным байткодом — лишний транспорт, задержки и баги трансляции.
Правильная рамка ожиданий: Triton — это не замена passthrough для тех, кому нужен максимум, а способ получить рабочий DirectX 11 в виртуалке там, где отдельной GPU нет и не будет. Для homelab это интересно тем, что впервые появляется вменяемый безжелезный путь к 3D в гостевой Windows на обычном хосте. Но на сегодня это ранний, местами нестабильный проект, а на macOS ещё и с лицензионной оговоркой на самый быстрый бэкенд. Пробовать — да; ставить в прод и ждать игрового FPS — рано.
Что стоит унести
- Triton приносит DirectX 11 в QEMU-гостя без проброса видеокарты, пересылая API-вызовы на хост через
virtio(связка Triton + Neptune +virglrenderer). - Три бэкенда: DXVK (Linux/Vulkan), DXMT (macOS ARM64) и D3DMetal (macOS, через Apple GPTK) — причём последний быстрее даже под Rosetta, но лицензионно ограничен.
- Проект ранний: реконструкция DXBC хрупкая, синхронизация через CPU добавляет задержку, драйверы помечены как нестабильные, публичных бенчмарков нет.
- Компоненты открыты (форки QEMU/virglrenderer/DXMT), кроме проприетарного
D3DMetal.frameworkот Apple.
Связанные темы форума: Proxmox VE 9.2 официально на ARM64: разбираем три мифа, Zapscape (CVE-2026-64561): побег из виртуалки в ядро хоста.
Источники
- Блог UTM — Introducing Triton: DirectX 11 Driver for QEMU, 8 августа 2026 (первоисточник: архитектура, бэкенды, ограничения, лицензия, скриншоты).
Вы для графики в виртуалке используете полноценный passthrough с отдельной картой — или вам хватило бы вот такого «безжелезного» DirectX ценой части производительности? И отдельно к маководам: пробовали уже DXMT/D3DMetal, совпадает ли у вас с авторами вывод, что Apple’овский бэкенд быстрее нативного?