Графический api что это

Графические API высокого и низкого уровня: различия и принцип работы

Графические API-интерфейсы — это не часть оборудования, а часть программного обеспечения, но они необходимы для рендеринга графики, представленной на нашем экране, и без них связи между приложениями и GPU / ГРАФИЧЕСКИЙ ПРОЦЕССОР было бы невозможно. В этой статье мы доступно объясняем, что такое графические API, и развенчиваем некоторые мифы, связанные с ними.

Следует учитывать, что графические процессоры не выполняют программы, а выполняют список инструкций. Но откуда взялся этот список и как он попадает в GPU?

Что такое графический API?

Графические API-интерфейсы — это то, что позволяет приложениям взаимодействовать с графическим процессором, чтобы отмечать, как он должен отрисовывать следующий кадр или его часть. Концепция основана на абстракции, которая представляет собой создание на языке программирования того, что такое графический процессор. Чтобы понять концепцию абстракции, мы предположим, что вместо графического процессора у нас подключен автомат с газировкой.

Please enable JavaScript

API машины обновления будет библиотекой со следующими функциями: подбрасывать монету, возвращать сдачу, выбирать обновление и доставлять Refreshment таким образом, чтобы программа могла взаимодействовать, эта часть API вызывается Front-End, и то, что мы делаем с ним, — это список инструкций, в графическом процессоре этот список называется DisplayList или списком экранов.

Упомянутый список экранов считывается программным обеспечением, которое является не чем иным, как драйвером видеокарты, это преобразует список в микрокод, который может понять графический процессор, и копирует его в часть Оперативная память память, к которой всегда обращается графический процессор. Чтобы прочитать список экранов, скопируйте список во внутреннюю память командных процессоров и начните рендеринг сцены или ее части с помощью инструкций из списка экранов.

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

Какие графические API существуют сегодня?

• Вулкан: Заменяет OpenGL, он используется во всех типах операционных систем, который, как говорят, не зависит от платформы, но является основным API Google.
• Металл: Графический API Apple, используемый в macOS и специально оптимизированный для архитектуры графического процессора.
• DirectX: API Microsoft для Windows и Xbox был разделен на несколько версий в зависимости от платформы, но недавно они объединили его в единую версию.
• ГНМ/ГНМХ/ГНМ++: Графический API для консолей Sony PlayStation 4 и PlayStation 5, GNMX — это высокоуровневый API, GNM — это низкоуровневый API версии на PS4 и GNM ++ на PS5.
• НВН: Графический API Nintendo Switch, который используется исключительно в этой серии консолей.
• OpenGL: API, с которого все началось, первоначально известный как IrisGL и предназначенный для рабочих станций Silicon Graphics, превратился в API для ПК, консолей и более поздних смартфонов. Я дохожу до версии 4, которая является Vulkan — это ребрендинг OpenGL 5.

Вычисления против графики

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

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

Например, может случиться так, что приложение графического дизайна использует мощность графического процессора для создания специального эффекта на фотографии только потому, что графический процессор лучше оборудован для решения этой проблемы, чем графический процессор. ЦП. Благодаря спискам вычислений вы можете сделать это, используя бесплатные ресурсы графического процессора для решения этих небольших проблем.

Графические API высокого и низкого уровня: чем они отличаются?

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

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

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

Миф о консоли и ПК

Существует миф о том, что, поскольку консоль имеет уникальное оборудование, это означает, что API-интерфейсы гораздо более оптимизированы, чем на ПК, где существует множество различных конфигураций, но на самом деле это драйвер, который мы установили, создает список экранов. Разница в том, что в консолях этот драйвер статичен и не получает обновлений производительности или изменений в течение всего коммерческого срока службы консоли.

Vulkan. Руководство разработчика. Краткий обзор

Я работаю техническим переводчиком ижевской IT-компании CG Tribe, которая предложила мне внести свой вклад в сообщество и начать публиковать переводы интересных статей и руководств.

Здесь я буду публиковать перевод руководства к Vulkan API. Ссылка на источник — vulkan-tutorial.com. Поскольку переводом этого же руководства занимается еще один пользователь Хабра — kiwhy, мы договорились разделить уроки между собой. В своих публикациях я буду давать ссылки на главы, переведенные kiwhy.

1. Отображение на экране
2. Отрисовка

1. Изображения
2. Image view и image sampler
3. Комбинированный image sampler

9. Загрузка моделей

10. Создание мип-карт

FAQ

Политика конфиденциальности

1. Вступление

2. Краткий обзор

Предпосылки возникновения Vulkan

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

По мере развития архитектуры видеокарт в ней стало появляться все больше программируемых функций. Все новые функции необходимо было каким-то образом объединить с существующими API. Это привело к неидеальным абстракциям и множеству гипотез со стороны графического драйвера о том, как воплотить замысел программиста в современных графических архитектурах. Поэтому для повышения производительности в играх выпускается большое количество обновлений драйверов. Из-за сложности таких драйверов среди поставщиков часто возникают расхождения, например, в синтаксисе, принятом для шейдеров. Помимо этого, в последнее десятилетие также наблюдался приток мобильных устройств с мощным графическим оборудованием. Архитектуры этих мобильных GPU могут сильно отличаться в зависимости от требований по размерам и энергопотреблению. Одним из таких примеров является тайловый рендеринг, который может дать большую производительность за счет лучшего контроля над функционалом. Еще одним ограничением, связанным с возрастом API, является ограниченная поддержка многопоточности, что может привести к появлению узкого места со стороны ЦП.

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

Как нарисовать треугольник?

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

Шаг 1 — Экземпляр (instance) и физические устройства

Работа с Vulkan начинается с настройки Vulkan API через VkInstance (экземпляр). Экземпляр создается с помощью описания вашей программы и всех расширений, которые вы хотите использовать. После создания экземпляра вы можете запросить, какое оборудование поддерживает Vulkan, и выбрать один или несколько VkPhysicalDevices для выполнения операций. Вы можете сделать запрос по таким параметрам, как размер VRAM и возможности устройств, чтобы выбрать желаемые устройства, если вы предпочитаете использовать специализированные видеокарты.

Шаг 2 — Логическое устройство и семейства очередей

После того, как вы выберете подходящее hardware устройство для использования, вам необходимо создать VkDevice (логическое устройство), где вы более подробно опишете, какие возможности (VkPhysicalDeviceFeatures) будете использовать, например, рендеринг в несколько viewport-ов (multi viewport rendering) и 64-битные числа с плавающей точкой. Вам также необходимо установить, какие семейства очередей вы бы хотели использовать. Многие операции, совершаемые с помощью Vulkan, например, команды рисования и операции в памяти, выполняются асинхронно после отправки в VkQueue. Очереди выделяются из семейства очередей, где каждое семейство поддерживает определенный набор операций. Например, для операций с графикой, вычислительных операций и передачи данных памяти могут существовать отдельные семейства очередей. Кроме того их доступность может использоваться в качестве ключевого параметра при выборе физического устройства. Некоторые устройства с поддержкой Vulkan не предлагают никаких графических возможностей, однако, все современные видеокарты с поддержкой Vulkan, как правило, поддерживают все необходимые нам операции с очередями.

Шаг 3 — Window surface и цепочки показа (swap chain)

Если вас интересует не только внеэкранный рендеринг, вам необходимо создать окно для отображения отрендеренных изображений. Окна можно создать с помощью API исходной платформы или библиотек, таких как GLFW и SDL. В руководстве мы будем использовать GLFW, подробнее о которой мы расскажем в следующей главе.

Нам необходимо еще два компонента, чтобы рендерить в окно приложения: window surface ( VkSurfaceKHR ) и цепочка показа ( VkSwapchainKHR ). Обратите внимание на постфикс KHR , который обозначает, что эти объекты являются частью расширения Vulkan. Vulkan API полностью независим от платформы, поэтому нам необходимо использовать стандартизованное расширение WSI (Window System Integration) для взаимодействия с менеджером окон. Surface – это кроссплатформенная абстракция окон для визуализации, которая, как правило, создается с помощью ссылки на собственный дескриптор окна, например HWND в Windows. К счастью, библиотека GLFW имеет встроенную функцию для работы со специфичными деталями платформы.

Цепочка показа — это набор целей рендеринга. Ее задача — обеспечивать, чтобы изображение, которое рендерится в текущий момент, отличалось от отображаемого на экране. Это позволяет отслеживать, чтобы отображались только готовые изображения. Каждый раз, когда нам нужно создать кадр, мы должны сделать запрос, чтобы цепочка показа предоставила нам изображение для рендеринга. После того, как кадр создан, изображение возвращается в цепочку показа, чтобы в какой-то момент отобразиться на экране. Количество целей рендеринга и условий для отображения готовых изображений на экране зависит от текущего режима. Среди таких режимов можно выделить двойную буферизацию (vsync) и тройную буферизацию. Мы рассмотрим их в главе, посвященной созданию цепочки показа.

Некоторые платформы позволяют рендерить непосредственно на экран через расширения VK_KHR_display и VK_KHR_display_swapchain без взаимодействия с каким-либо менеджером окон. Это позволяет создать surface, которая представляет собой весь экран и может использоваться, например, для реализации вашего собственного менеджера окон.

Шаг 4 — Image views и фреймбуферы

Чтобы рисовать в изображение (image), полученное из цепочки показа, мы должны обернуть его в VkImageView и VkFramebuffer. Image view ссылается на определенную часть используемого изображения, а фреймбуфер ссылается на image views, которые используются как буферы цвета, глубины и шаблонов (stencil). Поскольку в цепочке показа может быть множество разных изображений, мы заранее создадим image view и фреймбуфер для каждого из них и выберем необходимое изображение во время рисования.

Шаг 5 — Проходы рендера

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

Шаг 6 — Графический конвейер (pipeline)

Графический конвейер в Vulkan настраивается с помощью создания объекта VkPipeline. Он описывает конфигурируемое состояние видеокарты, например, размер viewport или операцию буфера глубины, а также программируемое состояние, используя объекты VkShaderModule. Объекты VkShaderModule создаются из байтового кода шейдера. Драйверу также необходимо указать, какие цели рендеринга будут использоваться в конвейере. Мы задаем их, ссылаясь на проход рендера.

Одна из наиболее отличительных особенностей Vulkan по сравнению с существующими API-интерфейсами заключается в том, что почти все системные настройки графического конвейера должны задаваться заранее. Это значит, что если вы хотите переключиться на другой шейдер или немного изменить vertex layout, вам необходимо полностью пересоздать графический конвейер. Поэтому вам придется заранее создать множество объектов VkPipeline для всех комбинаций, необходимых для операций рендеринга. Только некоторые базовые настройки, такие как размер viewport и цвет очистки, могут быть изменены динамически. Все состояния должны быть описаны явно. Так, например, не существует смешивания цветов (color blend state) по умолчанию.

К счастью, поскольку процесс больше напоминает опережающую компиляцию, вместо компиляции «на лету», у драйвера появляется больше возможностей для оптимизации, а производительность оказывается более предсказуемой, так как значительные изменения состояния, например, переключение на другой графический конвейер, указываются явно.

Шаг 7 — Пул команд и буферы команд

Как уже было сказано, многие операции в Vulkan, например операции рисования, должны быть отправлены в очередь. Прежде чем отправить операции, их необходимо записать в VkCommandBuffer. Буферы команд берутся из VkCommandPool, который связан с определенным семейством очередей. Чтобы нарисовать простой треугольник, нам нужно записать буфер команд со следующими операциями:

• Начать проход рендера
• Привязать графический конвейер
• Нарисовать 3 вершины
• Закончить проход рендера

Шаг 8 — Основной цикл

После того, как мы отправили команды рисования в буфер команд, основной цикл кажется достаточно простым. Сначала мы получаем изображение из цепочки показа с помощью vkAcquireNextImageKHR . Затем мы можем выбрать соответствующий буфер команд для этого изображения и запустить его с помощью vkQueueSubmit. В конце, мы возвращаем изображение в цепочку показа для вывода на экран с помощью vkQueuePresentKHR .

Операции, отправляемые в очереди, выполняются асинхронно. Поэтому мы должны использовать объекты синхронизации — семафоры —, чтобы обеспечить правильный порядок запуска. Необходимо настроить запуск буфера команд рисования таким образом, чтобы он осуществлялся только после того, как изображение будет извлечено из цепочки показа, в противном случае может возникнуть ситуация, когда мы начнем рендерить изображение, которое все еще считывается для отображения на экране. Вызов vkQueuePresentKHR , в свою очередь, должен дождаться завершения рендеринга, для которого мы будем использовать второй семафор. Он будет уведомлять об окончании отрисовки.

Этот краткий обзор позволяет получить общее представление о предстоящей работе по рисованию вашего первого треугольника. В реальности же шагов гораздо больше. Среди них выделение буферов вершин, создание uniform-буферов и загрузка изображений текстур — все это мы рассмотрим в следующих главах, а пока начнем с простого. Чем дальше мы будем двигаться, тем сложнее будет материал. Обратите внимание, что мы решили пойти хитрым путем, изначально встраивая координаты вершины в вершинный шейдер вместо использования буфера вершин. Такое решение связано с тем, что для управления буферами вершин сначала требуется знакомство с буферами команд.

Подведем краткий итог. Для отрисовки первого треугольника нам необходимо:

• Создать VkInstance
• Выбрать поддерживаемую видеокарту (VkPhysicalDevice)
• Создать VkDevice и VkQueue для рисования и отображения
• Создать окно, window surface и цепочку показа
• Обернуть изображения цепочки показа в VkImageView
• Создать проход рендера, который определяет цели рендеринга и их использование
• Создать фреймбуфер для прохода рендера
• Настроить графический конвейер
• Распределить и записать команды рисования в буфер для каждого изображения цепочки показа
• Отрисовать кадры в полученные изображения, отправляя правильный буфер команд и возвращая изображения обратно в цепочку показа

Концепты API

В заключение к текущей главе будет приведен краткий обзор того, как структурируются Vulkan API на более низком уровне.

Стандарт оформления кода

Все функции, перечисления и структуры Vulkan обозначены под заголовком vulkan.h , который включен в Vulkan SDK, разработанный LunarG. Установка SDK будет рассмотрена в следующей главе.

Функции имеют префикс vk в нижнем регистре, перечисляемые типы (enum) и структуры имеют префикс Vk , а перечисляемые значения имеют префикс VK_ . API активно использует структуры, чтобы предоставить параметры функциям. Например, создание объектов обычно происходит по следующей схеме:

Многие структуры в Vulkan требуют прямого указания типа структуры в члене sType . Член pNext может указывать на структуру расширения и в нашем руководстве всегда будет иметь тип nullptr . Функции, создающие или уничтожающие объект, будут иметь параметр VkAllocationCallbacks, который позволяет вам использовать собственный аллокатор памяти и который в руководстве также будет иметь тип nullptr .

Почти все функции возвращают VkResult, который является либо VK_SUCCESS , либо кодом ошибки. В спецификации указано, какие коды ошибок может возвратить каждая функция и что они обозначают.

Слои валидации

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

Поэтому Vulkan позволяет запускать расширенные проверки с помощью функции, известной как слои валидации. Слои валидации — это фрагменты кода, которые могут быть вставлены между API и графическим драйвером для выполнения дополнительных проверок параметров функций и отслеживания проблем по управлению памятью. Это удобно тем, что вы можете запустить их во время разработки, а затем полностью отключить при запуске программы без дополнительных затрат. Любой пользователь может написать свои собственные слои валидации, но Vulkan SDK от LunarG предоставляет стандартный набор, который мы будем использовать в руководстве. Вам также необходимо зарегистрировать функцию обратного вызова для получения сообщений отладки от слоев.

Поскольку операции в Vulkan расписываются очень подробно, и слои валидации достаточно обширные, вам будет намного проще установить причину черного экрана по сравнению с OpenGL и Direct3D.

Остался всего один шаг, прежде чем мы начнем писать код, и это — настройка рабочей среды.

Современные графические API-интерфейсы

терфейсов существует достаточно много, но все их можно разделить на два класса: универсальные и специализированные.

Универсальные API являются общими для всех 3D-акселераторов, а поддержка аппаратного ускорения для этих API возлагается на сами ускорители. В первую очередь здесь следует выделить Microsoft DirectX и OpenGL . Оба они используются, в основном, в программах компьютерной анимации.

Специализированные API предназначены для работы с графическими акселераторами, построенными на определенных 3D-чипсетах; наиболее известными среди них являются Glide API – интерфейс для работы с чипами VooDoo ® ; Metal – для чипов Savage3D и т.п. Программы, написанные с использованием специализированных API, работают только на тех акселераторах, под которые создавались эти API. Большинство специализированных API предоставляет только низкоуровневый интерфейс программирования, однако в последнее время, новые версии DirectX включают интерфейсы высокоуровневой поддержки, такие как DirectX for VisualBasic , который осуществляет языковую поддержку мультимедиа-приложений, написанных в среде визуального программирования Visual Basic.

API Microsoft DirectX

API Microsoft DirectX – это набор программных интерфейсов, применяемых для решения различных задач: от программного управления аппаратным обеспечением компьютера до разработки мультимедийных приложений, использующих различные типы информации, и создания виртуальных миров.

Основная цель, которую преследовала фирма Microsoft, создавая интерфейс DirectX – превратить компьютеры, работающие под управлением операционной системы Windows, в универсальную платформу для приложений, богатых мультимедийными элементами: полноцветной графикой, видеофрагмен-

тами, трехмерной анимацией и стереозвуком. Встроенный непосредственно в ядро ОС Windows интерфейс DirectX является интегрированным сервисом

Windows 98 и Windows 2000, а также Microsoft Internet Explorer. Компоненты

DirectX могут быть также автоматически загружены на компьютер при установке современных игр и мультимедийных приложений, разработанных для ОС Windows 95. Для разработчиков DirectX представляет набор программных интерфейсов, использование которых позволяет решить две основные задачи.

Во-первых, DirectX превращает разработанные с его помощью приложения в программы, совместимые с любой версией Windows и работающие на любом компьютере, где установлена эта операционная система, независимо от типа используемого программного обеспечения. При этом подобные приложения максимально используют технические возможности компьютера, обеспечивая наивысшую производительность. Это достигается за счет сервиса, предоставляемого двумя основными компонентами DirectX: низкоуровневыми интерфейсами, входящими в состав DirectX Foundation, и высокоуровневыми интерфейсами, составляющими DirectX Media.

Во-вторых, DirectX предоставляет разработчикам возможность абстрагироваться от конкретного типа дисплейного адаптера, звуковой карты или 3Dускорителя и сосредоточиться на логике работы самой программы.

DirectX Foundation предоставляет в распоряжение разработчиков набор низкоуровневых программных интерфейсов, который обеспечивает эффективный доступ ко всем возможностям компьютера, работающего под управлением ОS Windows, реализованным на уровне аппаратного обеспечения – 3Dускорителям, звуковым картам, устройствам ввода информации. До появления DirectX разработчики, создававшие мультимедийные приложения для платформы Windows, должны были настраивать свои программы на работу с различными типами устройств и конфигураций. Теперь эта проблема устранена. DirectX Foundation содержит компонент, известный как «слой аппаратной абстракции» (Hardware Abstraction Layer, HAL), который использует программные

драйверы для обеспечения взаимодействия программных и аппаратных средств. В результате разработчики могут создавать единую версию приложения с использованием интерфейсов DirectX, не заботясь о том, чтобы оно работало на конкретных аппаратных конфигурациях. DirectX автоматически определяет технические возможности компьютера и устанавливает соответствующие параметры. DirectX также позволяет выполнять мультимедийные приложения, требующие аппаратной поддержки, отсутствующей на данном компьютере. В этом случае они программно эмулируются компонентом, который называется «слой аппаратной эмуляции» (Hardware Emulation Layer, HEL) и обеспечивает программные драйверы, работающие как недостающие устройства.

DirectX Media располагается над DirectX Foundation и обеспечивает высокоуровневые сервисы – поддержку анимации, потоковый вывод (возможность передачи и просмотра аудио- и видеоинформации по мере ее загрузки из Internet) и интерактивность. Автоматическая интеграция низкоуровневых сервисов, реализуемых DirectX Foundation, и высокоуровневых, реализованных в DirectX Media, облегчает процесс создания и воспроизведения мультимедийных элементов, позволяя разработчикам включать их в свои приложения и Web-страницы и обеспечивая тем самым недоступное ранее интерактивное мультимедийное содержимое. Кроме того, DirectX Media помогает решить задачу координации различных типов мультимедийных эффектов, облегчая синхронизацию их воспроизведения. Помимо двух указанных основных составляющих Microsoft DirectX в их состав также входят высокоуровневые компоненты, которые обеспечивают мультимедийные функции для Webприложений. К ним относятся: NetMeeting — средство для организации групповых онлайновых дискуссий и Windows Media Player — средство для передачи мультимедийного содержимого по Internet. Рассмотрим кратко основные ком-

поненты DirectX Foundation. К ним относятся Microsoft DirectDraw, Direct3D (режимы Immediate и Retained ) , DirectInput , DirectMusic , DirectSound ,

DirectSound 3D и DirectPlay . Эти программные интерфейсы системного уровня

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

Microsoft Direct3D представляет собой интерфейс для работы с 3Dвидеокартами. Архитектура Direct3D представлена на рисунке 1.5.

Рисунок 1.5 – Архитектура Direct3D

Direct3D поддерживает два режима работы – Immediate Mode и Retained Mode . В режиме Immediate Mode Direct3D обеспечивает разработчикам аппаратную поддержку игровых и мультимедийных приложений в среде Microsoft Windows. Он позволяет добиться аппаратной независимости, поддерживает переключаемую Z-буферизацию и Intel ММХ-архитектуру процессоров. В этом режиме основные графические примитивы реализуются напрямую, без использования буферов выполнения (execute buffers).

Режим Retained Mode облегчает создание и анимацию трехмерных миров, поддерживая две новые функции: интерполяторы анимации со смешением цветов, плавными перемещениями объектов и множеством различных видов трансформации, а также последовательное заполнение сеточной структуры 3D-

объектов (meshes), позволяющее осуществлять их постепенную загрузку с удаленных серверов. Это дает возможность разработчикам эффективно использовать трехмерную графику, освобождая их от необходимости прямого управления структурами объектов на низком уровне.

Следует отметить, что Direct3D-приложения общаются с графическими устройствами одинаково, вне зависимости от режима. Они могут использовать или не использовать программную эмуляцию перед обращением к HAL. Реально Direct3D тесно интегрирован с компонентом DirectDraw, поэтому на рисунке 1.2 слой аппаратной абстракции HAL обозначен как DirectDraw/Direct3D HAL. Direct3D осуществляет Z-буферизацию и рендеринг поверхностей, а их непосредственное отображение выполняет DirectDraw. СОМ-интерфейс Direct3D является интерфейсом к DirectDraw.

DirectDraw — это менеджер управления памятью, обеспечивающий базовый набор функций для графических и мультимедийных приложений, работающих на платформе Windows. В отличие от традиционной Windows-графики DirectDraw использует прямой доступ к дисплейной памяти и графическим устройствам, обеспечивая при этом полную совместимость с Windowsприложениями.

На рисунке 1.6 показано взаимодействие между DirectDraw, компонентом ядра операционной системы GDI (Graphics Device Interface), слоем аппаратной абстракции (Hardware Abstraction Layer, HAL), и слоем аппаратной эмуляции

(Hardware Emulation Layer, HEL). Как видно, DirectDraw существует независи-

мо от GDI и оба интерфейса обладают возможностью прямого доступа к графическим устройствам через аппаратно-независимые слои. В отличие от GDI DirectDraw no возможности использует аппаратные функции. Если конкретное устройство не поддерживает требуемых функций, DirectDraw пытается их эмулировать, используя HEL. DirectDraw поддерживает работу с большим числом дисплейных адаптеров — от простых мониторов до сложных профессиональных устройств. Работая на уровне графических поверхностей, DirectDraw служит

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

▷ Directx 12 против вулкана: борьба за лучший графический движок?

В настоящее время для мира ПК существует два первоклассных графических API, которые авторитетно управляют рынком. По этой причине мы предлагаем вам сравнение DirectX 12 Vs Vulkan.

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

Низкоуровневый графический API и «накладные расходы на драйвер»

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

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

И DirectX 12, и Vulkan 1.1 — это API-интерфейсы, ориентированные на разработку игр и приложений, которые требуют помощи современных графических движков. В то же время они являются API-интерфейсами, поддерживаемыми драйверами наиболее важных разработчиков графических чипсетов, и, следовательно, быстрым и экономичным способом доступа к их функциям без необходимости знать их дизайн на очень низком уровне.

Низкоуровневый API, такой как этот, позволяет работать с аппаратным обеспечением с очень легким уровнем интерпретации, который позволяет разработчику лучше использовать аппаратное обеспечение, достигая лучших результатов с точки зрения производительности и эффективности, а также позволяет другим подсистемам освобождаться от дополнительной нагрузки. В мире ПК или мобильных телефонов он меньше зависит от общего процессора системы.

Два API, о которых мы поговорим сегодня, можно считать низкоуровневыми API, и обе разработки привели к все меньшей и меньшей зависимости от ЦП системы при достижении лучших результатов на уровне производительности и доступа к большему количеству графических функций. застав. Это два действующих API, которые ежегодно получают обновления, чтобы поддерживать их в соответствии с ожиданиями широкой общественности и разработчиков.

Низкоуровневые API напрямую влияют на другую вычислительную концепцию, которую мы называем «издержками драйвера», иными словами, это вторичные ресурсы, которые нам необходимы для выполнения определенных типов операций на компьютере. В случае графики это относится к дополнительным ресурсам, которые требуются графической карте для своей работы, и в этом случае это в основном центральное время обработки ЦП. Низкоуровневые API, которые мы здесь опишем, уменьшают эту зависимость, и фактически она стремится к 0.

Microsoft DirectX

DirectX возникает как необходимость стандартизации различных мультимедийных подсистем Windows и заменяет WinG для Windows 3.1. Он принят в Windows 95 как дополнительный пакет, и его вторая версия, DirectX 2.0, становится фундаментальным компонентом Windows 95 OSR2.

В DirectX мы находим несколько независимых API, таких как Direct3D, который действительно является рассматриваемым, DirectDraw, DirectMusic, DirectPlay и DirectSound. DirectX был способом назвать общие достижения во всех этих суб-API. Это API для Windows, но он также используется для разработки игр на консолях Xbox, поэтому мы можем считать его многоплатформенным API, но не бесплатным, как в случае с Vulkan.

DirectX 12, его последняя версия, работает с нами с 2014 года и не стоит на месте, а несколько месяцев назад она получила важные улучшения, такие как подпрограмма Direct RayTracing (DXR), которая была включена в обновленную версию Windows 10, выпущенную в октябре 1809 года.

Низкоуровневые API, такие как DirectX 12, имеют фундаментальное преимущество, которое заключается в уменьшении накладных расходов драйвера. Программисты теперь имеют возможность разрабатывать поведение графического процессора в своих программах и лучше управлять ресурсами графического процессора, особенно используя преимущества распараллеливания процессов. Это включает в себя лучшую поддержку нескольких графических процессоров в одной системе, даже если они не от одного производителя.

Они могут выполнять различные типы операций, обычно «целочисленные» или «с плавающей запятой», используя возможности совместимой графики, а также разделяя сложные операции на более простые, обрабатывая их параллельно на этих больших шинах. Хорошим примером является то, как AMD или Nvidia теперь могут обрабатывать 16-битные операции на своих 32-битных шинах, что значительно повышает эффективность их графики.

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

В настоящее время DirectX 12 неожиданно доступен для Windows 7 и Windows 10, и хотя он не является напрямую совместимым с Xbox One, правда состоит в том, что практически 90% его функциональных возможностей используется для ПК, различия минимальны и это позволило Разработчики быстро адаптируют свои компьютерные игры для Xbox One и наоборот.

Вулкан из Хроноса

Vulkan является развитием низкоуровневого API OpenGL и поддерживается корпорацией Khronos. В мире ПК они играют второстепенную роль по сравнению с DirectX 12, но его различные адаптации к различным платформам, таким как Android, сделали его эталоном графики для мобильности. Он также совместим с Linux, являющимся отличной альтернативой игре в бесплатных системах.

Его большим достоинством является его высокая производительность параллельной обработки, который чрезвычайно эффективен в современных процессорах и графических процессорах, обеспечивает низкое использование первых и большое использование аппаратных средств последних. Он специально разработан для того, чтобы использовать преимущества многоядерных процессоров, обеспечивающих превосходное распределение нагрузки в процессорах этого типа, на самом деле он намного эффективнее для большего количества ядер, которые мы можем предоставить.

История Vulkan восходит к году после DirectX 12, и Khronos, которая является некоммерческой компанией, поддерживает ее так же часто или чаще, как Microsoft со своим собственным API. Он основан на API Mantle, который AMD разработала для своей архитектуры GCN, и это был еще один низкоуровневый API для сокращенного «драйвера служебных данных». AMD пожертвовала свои разработки Khronos, и это является основой одного из лучших графических API на рынке.

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

Vulkan также представляет низкоуровневые улучшения API для Android и других платформ.

Его последняя версия, Vulkan 1.1, представленная в конце 2018 года, добавляет важные улучшения, такие как поддержка HLSL, которая является альтернативой DirectX 12 для управления шейдерными операциями без предварительной компиляции, лучшей совместимостью с DirectX 12 (для многих подпрограмм). кроме графики), явная поддержка систем с несколькими GPU независимо от производителя и, конечно же, поддержка RayTracing.

Сильные и слабые стороны DirectX 12 против Vulkan

В дополнение к уже описанным общим функциям, таким как лучшее использование аппаратного обеспечения, больший контроль над ним и лучшее использование распараллеливания как GPU, так и CPU, эти два API также добавляют возможность выполнения общих вычислительных операций с графическими чипами с которые совместимы. Это позволяет совместимым графическим движкам, уже несколько поколений, иметь возможность выполнять сложные математические операции, которые могут использоваться программами всех видов, в том числе без графических компонентов.

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

Оба API имеют отличную поддержку от великих графических разработчиков, и AMD, и Nvidia стремятся предложить этим API соответствующие драйверы для достижения обоих, предлагая своим пользователям последние улучшения и повышая производительность и стабильность игр, использующих один. или другой API.

«Затраты на драйверы» у обоих очень низкие, на самом деле, как вы увидите в наших тестах, между ними почти нет различий, что также является признаком важной оптимизации драйверов обоих производителей.

Мы ограничили частоту кадров до 120 кадров в секунду для демонстрации Driver Overhead. В Dota 2 потребление CPU существенно снижается при том же FPS.

Единственное более очевидное отличие состоит в том, что Vulkan несколько меньше зависит от процессора, с более низким средним потреблением, и что он также гораздо более открыт для различных платформ, включая Windows и Linux и его гомогенизацию с OpenGL ES, которая является его мобильной версией, он продвигается дальше, объединяя платформы, на которых он движется.

DirectX 12 поддерживает разработчиков, которые, похоже, находят в этом API идеальную экосистему для сокращения своих затрат, поскольку он даже имеет отличную интеграцию в такие же фреймворки, как.NET Framework, где он объединяет тысячи чудес. с небольшой потерей производительности.

Разница в производительности в играх с двойным API

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

Тест драйвера 3DMark. Результатов в миллионах запросов, чем больше, тем лучше.

Пепел одиночества. Результаты в FPS, чем больше, тем лучше.

Странная бригада. Результаты в FPS, чем больше, тем лучше.

Мы суммируем лучшие аппаратные руководства, которые должны вас заинтересовать:

• Лучшие процессоры на рынке Лучшие материнские платы на рынке Лучшие оперативные памяти на рынке Лучшие графические карты на рынке Лучшие SSD на рынке Лучшие корпуса или корпуса для ПК Лучшие источники питания Лучшие радиаторы и жидкостные кулеры

Как видите, результаты ровные, и мы видим различия между программами за и против одной и другой. Это оставляет нас с вопросом о том, что лучше, и ответ ясен, это зависит от программы и от того, как ее разработчик знает или хочет воспользоваться ее преимуществами. Осталось подумать, что в каждой игре разработчики будут использовать именно тот API, который наилучшим образом использует преимущества нашей графики, хотя очевидно, что оба варианта кажутся более чем компетентными. Что вы думаете о нашей статье о Directx 12 против Vulkan ? Мы хотим знать ваше мнение!

Lumberyard — графический движок Amazon

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

Графический движок Crytek v Crytek включает поддержку Vulkan и DirectX Raytracing.

Crytek продемонстрировал возможности своего нового графического движка CryEngine V с демонстрацией впечатляющей видеоигры Hunt: Shodown.

Rtx вещательный движок nvidia представляет новый движок для стримеров

Компания утверждает, что RTX Broadcast Engine использует ядра Tensor, имеющиеся в ее графических процессорах RTX.