Перейти к содержанию

DirectX 11 в виртуалке без проброса видеокарты: как устроен Triton для QEMU

Опубликовано
  • Админы
DirectX 11 в виртуалке без проброса видеокарты: конвейер Triton + Neptune
DirectX 11 в виртуалке без проброса видеокарты: конвейер Triton + Neptune

Проброс видеокарты (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 внутри гостя и переправляет их хосту, где их уже исполняет реальная графика хоста. Гость думает, что рисует сам; на деле он диктует команды, а рисует хост.

Конвейер получается такой (он на обложке выше):

  1. Гость (Windows). Приложение зовёт DirectX 11 / DXGI как обычно.
  2. Triton — драйвер пользовательского режима (UMD). Он превращает вызовы уровня DDI (интерфейс драйвера) и байткод шейдеров DXBC обратно в вызовы DirectX API.
  3. Neptune — слой, который сериализует эти вызовы и гонит их через кольцевой буфер virtio из гостя на хост.
  4. Хост. 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): побег из виртуалки в ядро хоста.

Источники

💬 Вопрос к сообществу

Вы для графики в виртуалке используете полноценный passthrough с отдельной картой — или вам хватило бы вот такого «безжелезного» DirectX ценой части производительности? И отдельно к маководам: пробовали уже DXMT/D3DMetal, совпадает ли у вас с авторами вывод, что Apple'овский бэкенд быстрее нативного?

Featured Replies

No posts to show

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.
Примечание: Ваш пост будет проверен модератором, прежде чем станет видимым.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

Последние посетители 0

  • Ни одного зарегистрированного пользователя не просматривает данную страницу
Яндекс.Метрика

Account

Navigation

Поиск

Поиск

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.