Что лучше vulcan api или opengl. Vulkan API (glNext) от Khronos Group
Относительно недавно вышел новый Vulkan API - можно сказать, наследник OpenGL, хотя основан Vulkan на API Mantle от AMD.
Конечно, развитие и поддержка OpenGL не прекратилось, а также в свет вышел и DirectX 12. Что там с DirectX 12 и почему его поставили только на Windows 10 - я, к сожалению (а может и к счастью) не знаю. Но вот кроссплатформенный Vulkan меня заинтересовал. В чём же особенности Vulkan и как правильно его использовать я постараюсь рассказать вам в этой статье.
Итак, для чего нужен Vulkan и где он может быть использован? В играх и приложениях, работающие с графикой? Конечно! Вычислять, как это делает CUDA или OpenCL? Без проблем. Обязательно ли для этого нам нужно окно или дисплей? Конечно нет, вы можете сами указать, куда транслировать ваш результат или не транслировать его вообще. Но обо всём по порядку.
Оформление API и основы
Пожалуй, стоит начать с самого простого. Так как над Vulkan API работали Khronous Group , синтаксис весьма похож на OpenGL. Во всём API есть префикс vk. К примеру функции (порой даже с очень длинными названиями) выглядят так: vkDoSomething(...), имена структур или хэндлов: VkSomething, а все константные выражения (макросы, макровызовы и элементы перечислений): VK_SOMETHING. Также, есть особый вид функций - команды, которым добавляется префикс Cmd: vkCmdJustDoIt(...).Писать на Vulkan можно как на C, так и на C++. Но второй вариант даст, конечно же, больше удобства. Есть (и будут создаваться) порты на другие языки. Кто-то уже сделал порт на Delphi, кто-то желает (зачем?) порт на Python.
Итак, как же создать рендер контекст? Никак. Здесь его нет. Вместо это придумали другие вещи с другими названиями, которые даже будут напоминать DirectX.
Начало работы и основные понятия
Vulkan разделяет два понятия - это устройство (device ) и хост (host ). Устройство будет выполнять все команды, отправленные ему, а хост будет их отправлять. Фактически, наше приложение и есть хост - у Vulkan такая терминология.Для работы с Vulkan нам понадобится хэндлы на его экземпляр (instance ), и может быть даже не один, а также на устройство (device ), опять же, не всегда может хватать одного.
Vulkan может быть легко загружен динамически. В SDK (разработали LunarG), если был объявлен макрос VK_NO_PROTOTYPES и загружать библиотеку Vulkan своими руками (не линковщиком, а определёнными средствами в коде), то прежде всего нужна будет функция vkGetInstanceProcAddr, с помощью которой можно узнать адреса основных функций Vulkan - те которые работают без экземпляра, включая функцию его создания, и функции, которые работают с экземпляром, включая функцию его разрушения и функцию создания устройства. После создания устройства можно получить функции, которые работают с ним (а также его дочерними хэндлами) через vkGetDeviceProcAddr.
Интересный факт: в Vulkan всегда нужно заполнить определённую структуру данными, чтобы создать какой-либо объект. И всё в Vulkan работает примерно таким образом: заранее подготовил - можно использовать часто и с высокой производительностью. В информацию об экземпляре можно также поместить информацию о вашем приложении, версии движка, версии используемого API и другую информацию.
Слои и расширения
В чистом Vulkan нет сильных проверок входящих данных на правильность. Ему сказали что-то сделать - он сделает. Даже если это приведёт к ошибке приложения, драйвера или видеокарты. Это сделали ради производительности. Тем не менее, можно без проблем подключить проверочные слои , а также расширения к экземпляру и/или устройству, если это необходимо.Слои (layers)
В основном, предназначение слоёв - проверить входящие данные на ошибки и отслеживать работу Vulkan. Работают они очень просто: допустим, вызываем функцию, и попадает она в самый верхний слой, заданный при создании устройства или экземпляра ранее. Он всё проверяет на правильность, после этого передаёт вызов в следующий. И так будет, пока дело не дойдёт до ядра Vulkan. Конечно же, можно создать собственные слои. Например, Steam выпустила слой SteamOverlay (хотя и не знаю, что он вообще делает). Тем не менее, слои будут молчать, но не доведут до краха приложения. Как узнать, правильно ли всё сделано? Для этого есть специальное расширение!Расширения (extensions)
Как следует из названия, они расширяют работу Vulkan дополнительным функционалом. Например, одно расширение (debug report) будет выводить ошибки (и не только) со всех слоёв. Для этого нужно будет указать необходимую Callback функцию, а что делать с информацией, поступившей в эту функцию - решать уже вам. Учтите, что это Callback и задержка может вам дорого обойтись, особенно если выводить всю полученную информацию прямиком в консоль. После обработки сообщения, можно указать, передавать ли вызов функции дальше (в следующий слой) или нет - так можно избежать критических ошибок, но постараться работать дальше с менее опасными ошибками.Есть также и другие расширения, о некоторых я расскажу позже в этой статье.
Устройство
Vulkan разделяет понятия физического устройства и логического. Физическим устройством может быть ваша видеокарта (и не одна) или процессор, поддерживающий графику. Логическое устройство создаётся на основе физического: собирается информацию о физических устройствах, выбирается нужное, подготавливается другая необходимая информация и создаётся устройство. Может быть несколько логических устройств на основе одного физического, но вот объединять для единой работы физические устройства (пока?) нельзя.Итак, что же за информацию мы собираем? Это, конечно же, поддерживаемые форматы, память, возможности и, конечно же, семейства очередей.
Очереди (queue) и семейства очередей (queue family)
Устройство может (или не может) делать следующие 4 вещи: рисовать графику, производить разные вычисления, копировать данные, а также работать с разреженной памятью (sparse memory management). Эти возможности представлены в виде семейств очередей: каждое семейство поддерживает определённые (может быть все сразу) возможности. И если идентичные семейства были разделены, Vulkan всё равно представит их как одно семейство, чтобы мы не так сильно страдали с кодом и выбирали нужное семейство.После того, как вы выбрали нужное (или нужные) семейства, из них можно получить очереди. Очереди - это место, куда будут поступать команды для устройства (потом устройство их будет брать из очередей и выполнять). Очередей и семейств, кстати, не сильно много. У NVIDIA обычно 1 семейство со всеми возможностями на 16 очередей. После того, как вы закончили с подбором семейств и количеством очередей, можно создавать устройство.
Команды, их исполнение и синхронизация
Все команды для устройства помещаются в специальный контейнер - командный буфер. Т.е. не существует ни одной функции в Vulkan, которая сказала бы устройству сделать что-либо сразу, и при завершении операции вернуть управление приложению. Есть только функции заполнения командного буфера определёнными командами (например, нарисовать что-либо или скопировать изображение). Только после записи командного буфера на хосте мы можем его отправить в очередь, которая, как уже известно, находится в устройстве.Командный буфер бывает двух видов: первичный и вторичный. Первичный отправляется прямо в очередь. Вторичный же не может быть отправлен - он запускается в первичном. Записываются команды в таком же порядке, в каком были вызваны функции. В очередь они поступают в таком же порядке. А вот исполнятся они могут почти в «хаотичном» порядке. Чтобы не было полного хаоса в приложении разработчики Vulkan предусмотрели средства синхронизации.
Теперь, самое важное: хост не ожидает завершения исполнения команд и командных буферов. По крайней мере до того момента, пока не укажете это явным способом. После отправления командных буферов в очередь управление сразу возвращается приложению.
Есть 4 примитива синхронизации: забор (fence), семафор (semaphore), событие (event) и барьер (barrier).
Забор самый простой метод синхронизации - он позволяет хосту ожидать выполнение определённых вещей. Например, завершения выполнения командного буфера. Но используется забор редко.
Семафор - способ синхронизации внутри устройства. Никак нельзя посмотреть его состояние или подождать его на хосте, нельзя также ждать его внутри командного буфера, но можем указать, какой семафор должен подать сигнал при завершении исполнения всех команд буфера, и какой семафор ждать перед тем, как начать выполнение команд в буфере. Только ждать будет не весь буфер, а его определённая стадия.
Стадии конвейера (pipeline stages) и зависимости исполнения
Как уже было сказано, не обязательно команды в очереди будут исполнятся по порядку. Если быть точнее, то последующие команды не будут ждать завершения предыдущих. Они могут выполнятся параллельно, или исполнение предыдущей команды может завершиться намного позже последующих. И это вполне нормально. Но некоторые команды зависят
от исполнения других. Вы можете разделить их на два берега: «до» и «после», и также указать, какие стадии берега «до» должны обязательно выполнится (т.е. команды могут завершиться не полностью или не все), прежде чем начнут выполняться указанные стадии команд берега «после». Например, отрисовка изображения может приостановиться, чтобы сделать определённые вещи, а потом снова продолжить делать рисовать. Также может быть и цепочка зависимостей, но не будем уходить глубоко в леса Сибири Vulkan.
События - элемент «тонкой» настройки. Подать сигнал можно как с хоста, так и с устройства, ждать можно также и на устройстве, и на хосте. Событие определяет зависимость двух сетов команд (до и после) в командном буфере. И для события есть также специальная псевдо-стадия, которая позволяет ждать хост.
Барьер опять может быть использован только в устройстве, а ещё точнее - в командном буфере, объявляя зависимости первого и второго сета команд. Также можно дополнительно указать барьеры памяти, которые бывают трёх видов: глобальный барьер, барьер буфера и барьер изображения . Они не дадут ненароком прочитать данные, которые в данный момент записываются и/или наоборот, в зависимости от указанных параметров.
Конвейеры
Ниже показаны два конвейера Vulkan:
Т.е. в Vulkan есть два конвейера: графический и вычислительный . С помощью графического, мы, конечно же, можем рисовать, а вычислительный… вычислять. Что же ещё? Результаты вычислений могут потом отправится в графический конвейер. Так можно с лёгкостью сэкономить время на системе частиц, например.
Изменить порядок или изменить сами стадии конвейера нельзя. Исключение составляют программируемые стадии (шейдеры). Также можно отправлять разновидные данные в шейдеры (и не только) через дескрипторы.
Для конвейера можно создать кэш, который может быть использован (снова и снова) и в других конвейерах и даже после перезапуска приложения.
Конвейер необходимо настроить и ассоциировать с командным буфером, прежде чем последний будет использовать команды конвейера.
Наследование конвейеров
Так как конвейер, это фактически вся информация о том, как нужно работать с поступающими данными, то смена конвейера (а это информация о шейдерах, дескрипторах, растеризации и прочее) может дорого обойтись по времени. Поэтому разработчики предоставили возможность наследования конвейера. При смене конвейера на дочерний, родительский или между дочерними уйдёт меньше затрат производительности. Но это также и удобство для разработчиков, как например ООП.
Проход отрисовки, графический конвейер и фреймбуфер
Итак, получаем следующую матрёшку:Для того, чтобы можно было использовать команды отрисовки, нужен графический конвейер. В графическом конвейере необходимо указать проход отрисовки (Render Pass ), который содержит информацию о подпроходах (subpass ), их зависимостей друг от друга и прикреплениях (attachment ). Прикрепление - информация о изображении, которое будет использоваться во framebuffer"ах. Framebuffer создаётся специально для определённого прохода отрисовки. Чтобы начать проход, нужно указать как сам проход (а также, если нужно, подпроход), так и framebuffer. После начала прохода можно рисовать. Можно также переключаться между подпроходами. После того, как рисование завершено, можно завершить проход.
Управление памятью и ресурсы
Память в Vulkan распределяется хостом и только хостом (за исключением swapchain). Если изображение (или другие данные) нужно поместить в устройство - выделяется память. Сначала создаётся ресурс определённых размеров, затем запрашивается его требования к памяти, выделяется для него память, затем ресурс ассоциируется с участком этой памяти и только потом можно копировать в этот ресурс необходимые данные. Также, есть память, которая может быть непосредственно изменена с хоста (host visible), есть локальная память устройства (память видеокарты, например) ну и также другие виды памяти, по своему влияющие на скорость доступа к ним.В Vulkan можно также написать своё распределение памяти хоста, настроив Callback функции. Но учтите, что требования к памяти, это не только её размер, но и выравнивание (alignment ).
Сами ресурсы бывают двух видов: буферы (buffers ) и изображения (images ). И те и другие разделяются по назначению, но если буфер - просто коллекция различных данных (вершинный, индексный или буфер констант), то изображение всегда имеет свой формат.
Наставление тем, кто пишет на Vulkan
Выделяйте участок памяти, в который можете поместить сразу несколько ресурсов. Количество выделений ограничено, и вам может не хватить. Зато количество ассоциаций не ограничено.
Шейдеры
Vulkan поддерживает 6 видов шейдеров: вершинный , контроль тесселяции , анализ тесселяции , геометрический , фрагментный (он же пиксельный ) и вычислительный . Написать их можно на читаемом SPIR-V, а потом собрать в байт код, который в приложении мы запечатаем в модуль, т.е. создадим shader-модуль из этого кода. Конечно же, мы можем написать его на привычном GLSL и потом конвертировать в SPIR-V (транслятор уже есть). И, конечно же, вы можете написать свой транслятор и даже ассемблер - исходники и спецификации выложены в OpenSource, ничто не мешает написать вам сборщик для своего High Level SPIR-V. А может кто-то уже написал.Байт код потом транслируется в команды, специфичные для каждой видеокарты, но делается это намного быстрее, чем из сырого GLSL кода. Подобная практика применяется и в DirectX - HLSL сначала преобразуются в байт код, и этот байт код может быть сохранён и потом использован, чтобы не компилировать шейдеры снова и снова.
Окна и дисплеи
А закончит эту статью рассказ о WSI (Window System Integration) и цепочке переключений (swapchain). Для того, чтобы выводить что-либо в окно или на экран - нужны специальные расширения.Для окон это базовое расширение плоскости и расширение плоскости, специфичной для каждой из систем (win32, xlib, xcb, android, mir, wayland). Для дисплея (т.е. FullScreen) нужно расширение display, но в целом и то и другое используют расширение swapchain.
Цепочка переключений не связана с графическим конвейером, поэтому простой Clear Screen выходит без настройки всего этого. Всё достаточно просто. Есть определённый движок показа (presentation engine), в котором есть очередь изображений. Одно изображение показывается на экран, другие дожидаются своей очереди. Количество изображений мы также можем указать. Есть также несколько режимов, которые позволят дождаться сигнала вертикальной синхронизации.
Метод работы примерно таков: мы запрашиваем индекс свободного изображения, вызываем командный буфер, который скопирует результат из Framebuffer в это изображение, и отправляем команду о отправки изображения в очередь. Звучит легко, но с учётом того, что потребуется синхронизация - всё чуточку сложнее, так как единственное, чего ожидает хост - это индекс изображения, которое вскоре будет доступно. Командный буфер ждёт сигнала семафора, который будет свидетельствовать о доступности изображения, и потом сам подать сигнал через семафор о том, что выполнение буфера, в следствии и копирование, завершено. И изображение действительно поступит в очередь по сигналу последнего семафора. Всего два семафора: о доступности изображения для копирования и о доступности изображения для показа (т.е. о завершении копирования).
Кстати говоря, я проверил, что один и тот же командный буфер действительно отправлялся в очередь несколько раз. Можете подумать сами, что это значит.
В этой статье я попытался рассказать о наиболее важных частях Vulkan API, но многое всё ещё не рассказано и это вы можете узнать сами. Стабильного вам FPS и приятного кодинга.
Введение
Если вы столкнулись с проблемой низкого FPS в DOOM и вам хочется ее исправить, то вы пришли как раз по адресу.
Магическая штука Vulkan API поднимает FPS в среднем на 15-25 кадров (зависит от конфигурации вашего компа), превращая некомфортные 20-30 FPS в совершенно играбельные 50-60.
ВНИМАНИЕ! ПРЕЖДЕ ЧЕМ ВЫПОЛНЯТЬ ДЕЙСТВИЯ, ОПИСАННЫЕ В РУКОВОДСТВЕ, НЕОБХОДИМО УБЕДИТЬСЯ, ЧТО ВАШ КОМПЬЮТЕР СООТВЕТСТВУЕТ ХОТЯ БЫ МИНИМАЛЬНЫМ СИСТЕМНЫМ ТРЕБОВАНИЯМ!
Что такое Vulkan API?
Что это вообще за зверь и как ему удается так ощутимо повысить производительность?
Vulkan API - графический интерфес программирования, созданный для отображения 3D и 2D графики на ваших мониторчиках. Проще говоря, эта шняга использует ресурсы вашего компа для построения графики в играх. OpenGL и DirectX из той же оперы.
Почему он дает такой прирост к FPS? Я, конечно, могу начать вам рассказывать о супер-пупер технологиях, использующихся в нем, но для простоты просто скажу, что он использует компьютерное железно намного эффективнее, чем его предшественник OpenGL.
Как мне его включить?
Все очень просто, начнем с первого шага:
Шаг первый:
Обновите драйвера вашей видеокарты до последней возможной версии. Если не знаете, как это сделать - спросите у , потому что инструкции по их обновлению довольно длинные, да и руководство совсем не про это.
Шаг второй:
Запускаем сам DOOM. Заходим в Параметры>Расширенные и в пункте "Графический API" выбираем "Vulkan API" вместо "OpenGL". Перезапускаем игру.
Шаг третий:
Заходим в игру и радуемся повышению производительности!
ВАЖНО:
Повышение производительности очень сильно зависит от характеристик вашего компа. На моей конфигурации прирост составил аж 30 FPS, у кого-то может оказаться намного меньше, а кто-то вообще не почувствует разницы. Да и вообще, глупо ожидать от тостера хотя бы 30 FPS с Vulkan"ом, если он на минималках едва 10 выдает.
Игра не запускается после включения Vulcan API, что делать?
Причина один:
Вы не обновили драйвера, либо скачали не ту их версию. Перекачиваем более новую/стабильную версию.
Причина два:
Ваша видеокарта не может в Vulkan API. Такое тоже может случиться, но вероятность довольно мала. Если видеокарта подходит под минимальные требования - она точно может работать с Vulkan API. Если нет - откатываем игру к настройкам по умолчанию и мучаемся с OpenGL"ом
Как откатить игру обратно до OpenGL, если ничего не работает?
Если игра после перехода на Vulkan отказывается запускаться - вот способ перехода обратно на OpenGL:
Первым делом нужно зайти в папку сохранений, она находится по этому пути:
C:\Users\<имя_пользователя>\Saved Games\id Software\DOOM\base
Далее находим в ней файл DOOMConfig.local
и открываем его блокнотом.
Ищем параметр r_renderapi
и меняем в его значении 1
на 0
(1 - VulkanAPI, 0 - OpenGL)
Сохраняем файл и закрываем его. Теперь игра должна запуститься.
Огромное спасибо пользователю arikuto за найденную инструкцию!
Не забудьте оценить руководство или оставить свою критику/пожелания!
Видимо, многие пользователи, в частности, всех тех, кто предпочитает использовать компьютер для установки и шаг, что современные требовательные игры, знают, что в настройках графики можно использовать специальные средства для ускорения вывода изображения и улучшить качество изображения OpenGL или DirectX. Что лучше использовать для полного использования скрытых ресурсов компьютерной системы и добиться максимальной производительности? Этот вопрос довольно спорный, и ответить однозначно на пользу одной платформы, как правило, не представляется возможным, поскольку все зависит от целей, которые ставит перед собой пользователь или разработчик, а также от каждой конкретной ситуации, что отчасти может быть связано с "железной рукой" компьютера в виде графического ускорителя, поддержка программного обеспечения в виде драйверов и некоторые другие аспекты. Постарайтесь понять, что лучше OpenGL или DirectX, - ссылаясь на официальные источники информации, и на основе мнений пользователей и разработчиков программного обеспечения, которые можно заказать поддержку этих технологий. Что такое OpenGL и DirectX?
Начнем с того, что среди пользователей существует ошибочное мнение, что эти два, описаны компонент диаграммы двигателей. Отсюда возникают вопросы о том, какой двигатель лучше, OpenGL или DirectX?
Дело в том, что двигатели этой платформе только частично, поскольку они являются исключительно программное обеспечение, которое позволяет взаимодействовать программного ядра программы (игры) с оборудования, установленного (чаще всего с аудио-и видео -, звуковые карты), через свои контроллеры, которые выполняют роль посредников. На самом деле, OpenGL и DirectX являются частью интерфейса программирования приложений с набора библиотек классов, определений, структур, констант и функций, используемых для обеспечения работы внешних программных продуктов, установленных в операционной системе. Для чего используются эти технологии
Естественно, довольно часто можно найти и вопросы о том, какой тип графика лучше, OpenGL или DirectX? Такой подход отчасти неверно, так как можно идти не только об участии ресурсы видеокарты, но звук, или любого другого "железа", так и виртуальных устройств мультимедиа. Но чаще всего действительно речь идет о графических ускорителей. Необходимо четко понимать, что выбор в пользу "моста", что обеспечивает взаимодействие видеокарты установленной игры или любой другой программы, где это необходимо, в зависимости от того, обязательным является такая поддержка.
В современных играх сложных текстур и оттенков человек мне динамичных сцен эта помощь очень нужна. Но проблема в том, что не все графические ускорители могут правильно использовать эту поддержку. В этом случае, все зависит от драйверов. Будь то карты, что является современным, но, что старый директор (drivers) вы не сможете использовать все те возможности, которые изначально были заявлены производителем. Тем не менее, в большинстве игр или программ для работы с мультимедиа (например, для обработки видео), очень часто, и придется выбирать, какой тип поддержки установить в настройках противопоставление с одной платформы на другую (в английском языке это, как правило, выглядит как "OpenGL vs DirectX"). Основные отличия DirectX и OpenGL
Что касается основных отличий, не вдаваясь в технические аспекты работы, сразу можно отметить, что платформа, совместимая с DirectX, - это эксклюзивные разработки корпорации Майкрософт, предназначенный для использования исключительно в системах Windows и на Xbox, и OpenGL это свободно распространяемую кроссплатформенную технологий, применимых в других операционных системах, в том числе на мобильных устройствах). Лицензией GNU, что позволяет любому желающему внести в компоненты этого API собственные изменения и дополнения по его улучшению, с целью повышения производительности одинаковые карты, а улучшения DirectX, что ожидать, по мере выхода новых версий платформы. В этом случае, даже с самых новых драйверов при использовании старых версий мост графические ускорители не дают заявленных производителем показателей. Основные преимущества и недостатки
Говоря о том, что лучше OpenGL или DirectX 11 (12), стоит отметить, что первая платформа предназначена только для графики, а вторая может использоваться в целом для все, что относится к мультимедиа (графика, в этом случае, отвечает за компонент Direct3D).
Кроме того, многие из экспертов отмечает, что в очень высокой степени выбор в пользу моста может зависеть от типа видеокарты. Но, если подходить к сравнению с открытым сознанием, считает, что в отношении охвата платформ выглядит лучше, OpenGL, DirectX, но выигрывает в плане того, что готов в программного продукта как класса Plug&Play. Тем не менее, не следует забывать, что набор инструментов DirectX последних версий, и уже доступна на OpenGL, а вот обратной поддержки нет. OpenGL или DirectX: что лучше для игр?
Что касается игр, то и здесь нельзя дать однозначного ответа. Так, например, очень часто можно встретить отзывы о том, что графические чипы из серии Radeon 9800 лучшие результаты в тестах показывают на базе DirectX, а карты GeForce серии 5XXX – при использовании OpenGL. Но DirectX представляет собой явное преимущество.
Потому что мост OpenGL изначально создавался для других платформ, с ним в Windows, вы можете получить все виды ошибок, и вот DirectX позволяет вполне приемлемой и наслаждайтесь игрой, даже на относительно устаревших компьютерах без каких-либо торможений (например, игра Age Of Empires).
Это и наоборот. Так, например, некоторые пользователи отмечают, что DOOM 3 на картах серии Radeon X1XXX с использованием OpenGL, просто "летает", и Half-Life 2, очень часто "тормозит". Но здесь, по-видимому, все зависит от драйверов.
Но, в конце концов, если игра поддерживает использование обеих технологий, то лучше увидеть, каким будет результат работы видеокарты при использовании каждого режима по отдельности. Само собой разумеется, что достижение оптимальной производительности и собственные платформы, и драйверы графических ускорителей должен быть обновлен до последней версии. Что лучше для BlueStacks: DirectX или OpenGL?
Довольно часто можно найти и вопросы, касающиеся использования одной из самых популярных эмуляторов для Android-систем под названием BlueStacks. Какую платформу вы предпочитаете в BlueStacks - OpenGL или DirectX? Увы, и здесь не возможно дать четкий ответ.
Однако анонимный считается, что в случае установки через этот эмулятор в игры, то лучше использовать OpenGL, и вот, если игра будет тормозить, тогда придется переключиться на DirectX. Но, повторимся, все это относится только к графике игры. В случае профессиональной обработки и обработки видео придется достаточно серьезно экспериментировать. Рекомендации разработчикам
Наконец, если говорить о том, что лучше OpenGL или DirectX для разработчиков, который только начинает освоение этих технологий и делает первые шаги, большинство специалистов в этой области, отмечают, что сначала лучше ознакомиться с принципами работы и инструментами набора DirectX, так как эта платформа выглядит для новичка, самый простой, и для нее постоянно публикуются хорошие комплекты для разработки, предназначенная для облегчения адаптации программного обеспечения к "железу", и затем перейти к изучению OpenGL.
Кроме того, многое может зависеть и от того, что конечная цель, будьте готовы и какова функциональность каждой платформы, которая будет использоваться в каждом конкретном случае (только графики, только звук или какие-то Объединенные решения). Краткие выводы
В общем, как уже стало ясно, однозначного вывода в пользу одного или другого компонента сделать, и трудно. Среди этих платформ будет в постоянной конкуренции. Иногда, новая версия DirectX, его параметров, впереди OpenGL, но по мере устаревания, а также регистрацию в OpenGL какой тип инноваций начинает воспроизведение. В целом, выбор должен отталкиваться исключительно от общеизвестного принципа, что истина познается в сравнении. Попробуйте и то и другое! Только после получения конкретных результатов, и для каждого конкретного случая и будет ясно, к какой чаше весов по вашему выбору.
На минувшей неделе был представлен API Vulkan, о широкой поддержке которого заявили AMD и NVIDIA. Новый графический интерфейс разрабатывал Khronos Group, консорциум, основанный в 2000 году. Khronos Group отвечает за разработку и поддержку открытых стандартов в сфере мультимедийных приложений на разных платформах и устройствах. Консорциум поддерживают AMD и NVIDIA, а также многие другие компании.
На минувшей неделе была ратифицирована финальная версия 1.0 API Vulkan. AMD и NVIDIA представили соответствующие бета-драйверы. AMD заранее выпустила бета-версию Radeon Software еще 14 февраля. NVIDIA представила драйвер GeForce 356.39, который тоже ориентирован на поддержку API Vulkan.
Подход API Vulkan очень похож на API Mantle. Суть заключается в том, чтобы разработчики получили более глубокий доступ к «железу», чтобы выжать из него максимум. Такой подход позволяет максимально избежать существующих «узких мест». С другой стороны, разработчики должны точно знать, что они делают – например, при работе с памятью. Интерфейс OpenGL не так популярен, как DirectX, но позволяет выжать больше.
Интерфейс API Vulkan в версии 1.0 поддерживается под Windows 7, Windows 8.1, Windows 10, Android и Linux. Разработчики игр пока что не объявили о поддержки в конкретных играх, но здесь стоит дождаться Games Developer Conference, которая будет проводиться с 14 по 18 марта в Сан-Франциско. Из игровых движков пока есть информация о Source 2, который уже поддерживает API Vulkan. Процесс отладки облегчается поддержкой Valve, LunarG и Codeplay.
The Talos Principle
Хорошо, но какая игра или движок поддерживают API Vulkan? Игра The Talos Principle разрабатывалась компанией Croteam, которая и в прошлом была известна поддержкой многих графических API. И в последней итерации игра The Talos Principle не стала исключением – она поддерживает DirectX 9, DirectX 11, OpenGL и теперь Vulkan. Для студии разработчиков Vulkan является пробным шаром, хотя API Vulkan доступен в версии 1.0, поддержка пока находится в бета-стадии. На добавление поддержки разработчики Croteam затратили порядка трех месяцев. Но универсальный характер API позволяет вскоре представить вариант Linux.
API Vulkan теоретически совместим с несколькими платформами – но пока что тесты и сравнения можно провести только под Windows, причем здесь имеются свои ограничения. Реализация пока остается на очень раннем этапе. Путь рендеринга DirectX 11 совершенствовался многие годы, поэтому потенциала для оптимизации здесь уже нет. Здесь ситуация больше зависит от разработчиков драйверов, а именно AMD и NVIDIA. Игра The Talos Principle стала первой с поддержкой Vulkan. Поэтому пока нет возможности сделать сравнительный тест для оценки хорошей или плохой реализации поддержки.
Новые технологии первое время реализуются в примерах, подготовленных производителями. В случае DirectX 12 акцент был выставлен на Draw Calls, тот же тест 3DMark DirectX 12 опирается только на измерение производительности Draw Calls, игры DirectX 12, подобные Star Wars, тоже пытаются задействовать подобную нагрузку. Но The Talos Principle не так сильно зависит от высокой скорости Draw Call, чтобы низкоуровневый API дал большую разницу.
Поддержка API Vulkan версии 1.0 находится на ранней стадии, то же самое касается драйверов AMD и NVIDIA. Оба драйвера, по сути, относятся к бета-версиям, именно так их рассматривают производители GPU. Здесь обычно нет новых улучшений производительности или поддержки новых технологий, так что мы получаем шаг назад. Но как только определенный уровень разработки будет достигнут, драйверы обоих разработчиков GPU получат поддержку Vulkan в финальной версии. Когда это произойдет – не совсем понятно. Но пока ключевые приложения не используют Vulkan и игры с поддержкой API находятся в состоянии бета-версии, так что разработчики GPU могут спокойно дорабатывать свои драйверы.
Для тестов мы взяли нашу тестовую систему для видеокарт. Драйверы видеокарт AMD и NVIDIA мы уже описали выше. В настройках мы выставили максимальный уровень графики, но при этом протестировали и низкие разрешения вплоть до 1.280 x 720 пикселей, чтобы увеличить производительность Draw Call.
Тест The Talos Principle - 1.280 x 720 пикселей
Тест The Talos Principle - 2.560 x 1.440 пикселей
Тест The Talos Principle - 3.840 x 2.160 пикселей
Как можно видеть по результатам, API Vulkan дает существенный прирост по сравнению с OpenGL. Но до производительности DirectX 11 новый API не дотягивает. Тому есть несколько причин. С одной стороны, разработка под Vulkan находится в ранней стадии. Это касается и самого API, и драйвера, и игры The Talos Principle. По сравнению с OpenGL новый интерфейс позволяет освободить часть ресурсов и избежать «узких мест». Но DirectX много лет совершенствовался до текущего уровня. В любом случае, потенциал у API Vulkan очень хороший.
Если погрузиться в детали, то визуальных отличий между API Vulkan и DirectX 11 мы не обнаружили. Так что путь рендеринга очень хорошо адаптирован. У текущей реализации The Talos Principle видеокарты с 2 Гбайт памяти получают падение производительности, вероятно, из-за не самой эффективной работы с памятью. Как и Mantle и DirectX 12, API Vulkan может обращаться к ресурсам памяти на более глубоком уровне – сей факт можно рассматривать как преимущество, но он может стать и недостатком, если разработчики не смогут эффективно использовать память.
Несколько разочаровала ошибка в текущем драйвере NVIDIA, из-за которой после каждого теста приходилось перезагружать систему. Без перезагрузки игра «вылетала». Хотя с драйвером AMD мы не обнаруживали подобной ошибки.
Нынешняя реализация API Vulkan кажется обещающей. Пока что для игр на настольных ПК она будет не такой актуальной, поскольку рынок DirectX 11 и 12 очень велик, и по сравнению с тем же DirectX 12 затраты на реализацию могут быть слишком велики, а отдача слишком мала. Но если игры необходимо запускать на разных платформах с разными аппаратными требованиями, Vulkan может сыграть важную роль. В любом случае, следует дождаться реакции со стороны разработчиков игр, иначе мы получаем проблему курицы и яйца, из которой сложно выйти.