Vulkan можно использовать не только напрямую. На его основе можно реализовать другой графический API.

В этом случае приложение продолжает обращаться к привычному API, например Direct3D или Glide, а специальный программный слой переводит эти вызовы в операции Vulkan.

Схема выглядит так:

Старое приложение → Direct3D/Glide → API translator → Vulkan → Vulkan implementation/ICD → GPU

Для приложения Vulkan при этом может вообще оставаться невидимым.

Direct3D → Vulkan

Один из наиболее известных вариантов такого подхода — перевод Direct3D в Vulkan.

Приложение вызывает функции Direct3D и передаёт ему параметры в соответствии с моделью этого API. Translator принимает эти вызовы и должен сопоставить их с возможностями Vulkan.

Например, приложение может попросить Direct3D:

• создать текстуру;
• создать vertex buffer;
• установить состояние рендеринга;
• загрузить shader;
• выполнить draw call.

Translator анализирует эти операции и создаёт соответствующие Vulkan-ресурсы и команды.

Упрощённо:

Direct3D texture → Vulkan Image

Direct3D buffer → Vulkan Buffer

Direct3D shader → Vulkan shader/pipeline

Direct3D draw call → Vulkan command

При этом соответствие не всегда является прямым «один вызов → один вызов». Direct3D и Vulkan имеют разные модели управления ресурсами, состояниями, синхронизацией и pipeline.

Поэтому translator должен не просто переименовать функции, а реализовать поведение исходного API средствами Vulkan.

Glide → Vulkan

Похожий принцип можно применить к старому API Glide.

Изначально Glide был рассчитан на графическое оборудование 3dfx Voodoo. Современная видеокарта напрямую не предоставляет этот старый интерфейс.

Translator может перехватить вызовы Glide и преобразовать их в современную графическую модель.

Схема:

Старая игра → Glide → translator → Vulkan → современный GPU

Например, старое приложение может запросить:

• создание текстуры;
• установку режима смешивания;
• настройку фильтрации;
• отправку геометрии;
• выполнение рендеринга.

Translator представляет эти операции через Vulkan.

Однако здесь возникает дополнительная сложность: старый API создавался под конкретную архитектуру Voodoo, а Vulkan рассчитан на совершенно другой класс устройств.

Поэтому реализация должна не только переводить команды, но и воспроизводить ожидаемое приложением поведение старого API.

Какую роль играет DXVK

DXVK — пример API translator, который реализует Direct3D 8/9/10/11 поверх Vulkan.

Для старой Windows-игры это выглядит примерно так:

Игра → Direct3D → DXVK → Vulkan → Vulkan implementation/ICD → GPU

Игра не переписывается под Vulkan.

Она продолжает использовать Direct3D, а DXVK подменяет соответствующую часть графического стека и выполняет работу через Vulkan.

Это особенно важно для старых игр: приложению не обязательно знать, что конечный GPU работает через Vulkan.

Кроме DXVK существуют и другие проекты, использующие Vulkan как основу для реализации или переноса возможностей других графических API. Их конкретная архитектура и поддерживаемые API могут сильно различаться.

Чем API translation отличается от обычной Vulkan-обёртки

Разница определяется направлением работы.

У обычного Vulkan wrapper:

Разработчик → wrapper → Vulkan

Разработчик знает, что использует Vulkan, и получает более удобный интерфейс для работы с ним.

У API translator:

Приложение → другой API → translator → Vulkan

Приложение работает не с Vulkan, а с другим API.

Поэтому Vulkan wrapper обычно отвечает на вопрос:

Как сделать работу с Vulkan удобнее?

А translator отвечает на другой вопрос:

Как реализовать API X, используя Vulkan?

Это принципиально разные задачи, даже если внутри обе технологии вызывают одни и те же Vulkan-функции.

Чем translation отличается от эмуляции Voodoo

Эти понятия особенно легко перепутать при работе со старыми играми.

Translation преобразует команды одного API в команды другого.

Например:

Glide → Vulkan

При этом реальная современная видеокарта выполняет работу через свой Vulkan-драйвер.

Эмуляция Voodoo ставит перед собой другую задачу — воспроизвести поведение старого оборудования или его программной модели.

Условно:

Игра → Glide → эмуляция Voodoo → виртуальная Voodoo → современный GPU

Эмулятор должен учитывать особенности эмулируемой системы, а не только переводить графические вызовы.

Поэтому перевод API и эмуляция аппаратуры могут давать похожий конечный результат — старая программа работает на новом компьютере, — но достигают его разными способами.

Почему старый API может работать через современный GPU

Современная видеокарта не обязана физически поддерживать старый API.

Важнее другое: у неё есть современный драйвер, предоставляющий Vulkan.

Translator становится промежуточным уровнем, который знает правила старого API и умеет представить их средствами Vulkan.

Получается цепочка:

Старая программа

↓
Старый API

↓
Translator

↓
Vulkan

↓
Vulkan-драйвер

↓
Современный GPU

Программа думает, что продолжает работать со знакомым API.

Translator выполняет необходимое преобразование.

Vulkan передаёт команды современному драйверу.

Драйвер уже работает непосредственно с конкретной видеокартой.

Именно поэтому старое программное обеспечение может использовать современный GPU без физического наличия старого графического ускорителя.

При этом translator не делает старый API «современным» автоматически. Если между старой моделью и Vulkan есть существенные различия, их приходится обрабатывать внутри самого translator.