В разработке 3D-приложений, видеоигр и систем виртуальной реальности наступает новый этап. Совместными усилиями разработчики сделали важный шаг на пути к унификации кода и более эффективному использованию аппаратных ресурсов. Консорциум Khronos Group, насчитывающий более ста компаний, официально представил первую версию открытого кроссплатформенного API под названием Vulkan (ранее – GLNext). Он обеспечивает непосредственный контроль над ГП и ЦП, устраняя «узкие места» и повышая общую производительность.
На форумах часто можно увидеть однотипные вопросы о том, раскроет ли процессор X видеокарту Y и какая конфигурация при одинаковом бюджете будет производительнее в конкретных приложениях. Он возникает из-за того, что современные ГП обладают большей производительностью, чем ЦП того же уровня и поколения. В играх и других 3D-приложениях временами возникают ситуации, когда на ЦП приходится большая нагрузка, а ГП простаивает. Например, процессор обсчитывает взаимодействие игроков и объектов, а видеокарта ждёт от него данные, чтобы отрисовать следующий кадр. Из-за несбалансированности нагрузки возникают задержки, а динамичная игра может превратиться в покадровое слайд-шоу даже с мощной видеокартой.
Указанные проблемы характерны для платформы PC и практически незнакомы владельцами игровых консолей. Разработчики консольных игр всегда знают детальные спецификации приставок и могут выполнять глубокую оптимизацию кода с учётом их особенностей. Компьютеры, ноутбуки, планшеты – это зоопарк не только из разных конфигураций, но и принципиально отличных архитектур. При создании игр для столь разношёрстной платформы приоритетом становится универсальность кода, что негативно сказывается на скорости его исполнения.
Разработчики операционных систем по-разному пытаются решить проблему низкой эффективности кода сторонних приложений. Microsoft начала искать пути оптимизации графических вычислений давно, однако реальная поддержка низкоуровневых операций появилась только в DirectX 12. Этот API доступен лишь в одной ОС – Windows 10. В свою очередь, положение Apple оказалось ближе к таковому у производителей игровых консолей. Когда одна и та же компания выпускает мобильные процессоры и софт, его согласованной работы добиться куда легче. Тем не менее, пути оптимизации самой разработки игр и приложений у Apple далеко не исчерпаны. В iOS 8 появился Metal API, также ориентированный на использование низкоуровневых операций.
Остальные крупные компании предпочитают действовать совместно и в рамках открытых стандартов. Появившийся 16 лет назад консорциум Khronos Group объединил более ста производителей, включая таких кровных друзей, как AMD, Nvidia и Intel. В своё время консорциум явил на свет открытые стандарты OpenGL, OpenCL, OpenCV и многие другие.
По сравнению с OpenGL, Vulkan даёт разработчикам возможность использовать низкоуровневые операции без ущерба для переносимости кода. С помощью Vulkan на разных платформах можно достичь почти такого же сбалансированного алгоритма, как на специализированных игровых консолях. Этот API помогает эффективнее использовать аппаратные возможности дискретных видеокарт и интегрированных графических чипов в 2D и 3D-режимах.
Подобно DirectX 12, Vulkan поддерживает прямой доступ к памяти GPU. Дополнительно Vulkan снижает зависимость скорости отрисовки от качества драйверов. За счёт трансляции кода шейдерных программ в промежуточный двоичный формат, их компиляцию можно выполнять уже на этапе разработки, а не во время запуска 3D-приложения.
Vulkan разрабатывается с середины 2014 года. В его основу легли графические библиотеки другого низкоуровневого API – AMD Mantle. Компания AMD также выступала в роли редактора официальных спецификаций. Помимо них Khronos group опубликовала ряд тестов, демонстрирующих преимущество нового API. Все они доступны на портале GitHub.
«У Vulkan есть огромный потенциал, – говорит Дин Секулик (Dean Sekulic), программист Croteam. – Если сказать о нём в одном предложении, то с появлением Vulkan завершилось давнее противостояние между борцами за производительность и переносимость кода. Сейчас мы портируем на него The Talos Principle в подтверждение новой концепции разработки».
Компания Valve спонсирует создание открытого SDK LunarG с поддержкой API Vulkan. Однако несмотря на открытые спецификации, доступные инструменты разработки, возможность глубокой оптимизации кода и другие преимущества, Vulkan ещё какое-то время будет редко используемым API. Большинство игроделов останутся верны DirectX 11/12 и OpenGL. Куда проще повысить системные требования или снизить качество графики, чем осваивать новые способы разработки. Понимая это, консорциум Khronos Group стремиться обеспечить поддержку Vulkan не только в новых ОС и графических решениях, но и на морально устаревших системах.
Сейчас Vulkan поддерживается в среде Windows (начиная с седьмой версии), Linux, SteamOS и Android. В ближайшее время ожидается добавление поддержки ОС Tizen от Samsung. Бета-версии драйверов с поддержкой API Vulkan уже выпустили AMD и Nvidia . На очереди Intel, Qualcomm, ARM и другие производители, входящие в консорциум Khronos Group. Демонстрацию Vulkan на графическом чипе ARM Mali можно увидеть в ролике ниже.
В настоящее время Vulkan можно протестировать на видеокартах с графическими чипами Nvidia GeForce GT 630 и выше, AMD Radeon HD 7700 и новее. Также API Vulkan поддерживает гибридные процессоры AMD с графическим ядром Radeon HD 8500 – 8900 и R2 – R9. Встроенная графика десктопных и мобильных процессоров Intel поддерживается Vulkan начиная с семейства Core пятого поколения.
В полной мере возможности нового API раскроются перспективными графическими процессорами Nvidia серии Pascal и AMD с архитектурой GCN четвёртого поколения. Соответствующие видеокарты предположительно войдут в серию GTX 1xxx и Radeon Rx 400. По неофициальным данным начало их продаж планируется на второй квартал 2016 года.
Тестовый стенд № 2 на базе платформы Intel Soket 2011
Тестовый стенд № 3 на базе платформы Intel Soket 1155
Тестовый стенд № 4 на базе платформы AMD Soket AM3 +
Тестовый стенд № 5 на базе платформы Intel Soket 1150
Все видеокарты тестировались на максимальном качестве графики программой MSI Afterburner. Целью теста является определить, как ведут себя видеокарты от различных производителей при одинаковых условиях. Ниже приведено видео тестового отрезка:
Наши видеокарты тестировались при разрешениях 1920х1080, 2560х1600 и 3840х2160 при максимальных настройках качества графики, допустимых Doom. AMD CrossFireX и SLI игрой в полной мере не поддерживаются и в тесте мы их не активировали. CrossFireX мы даже рекомендуем отключить, так как при его активации производительность падает в разы.
Тестирование при максимальных настройках качества 1920х1080 API OpenGL
Тестирование при максимальных настройках качества 1920х1080 API Vulkan
При данных настройках приемлемый показатель FPS показали видеокарты уровня Radeon R7 370 или GeForce GTX 750 Ti.
Тестирование при максимальных настройках качества 2560x1440 API OpenGL
При данных настройках приемлемый показатель FPS показали видеокарты уровня Radeon R7 370 или GeForce GTX 750 Ti. Radeon HD 7950 или GeForce GTX 770 .
Тестирование при максимальных настройках качества 2560x1440 API Vulkan
При данных настройках приемлемый показатель FPS показали видеокарты уровня Radeon R7 370 или GeForce GTX 750 Ti. Оптимальными решениями станут Radeon R7 370 или GeForce GTX TITAN.
Тестирование при максимальных настройках качества 3840х2160 API OpenGL
При данных настройках приемлемый показатель FPS показали видеокарты уровня Radeon R9 290 или GeForce GTX 970. Оптимальными решениями станут видеокарты уровня Radeon R9 290X или GeForce GTX 980.
Тестирование при максимальных настройках качества 3840х2160 API Vulkan
При данных настройках приемлемый показатель FPS показали видеокарты уровня Radeon R9 380X или GeForce GTX 970. Оптимальными решениями станут видеокарты уровня Radeon R9 290 или GeForce GTX 970.
По данным результатам можно сделать несколько выводов. Видекарты AMD в API Vulkan дают существенный прирост быстродействия, а NVIDIA минимальный(семейство Kepler вообще уходит в минус), видимо необходимо подождать новых драйверов.
Так же стоит отметить, что API Vulkan может рационально использовать лишь память видеокарты, и если игра потребляет больше, то производительность видеокарт падает до неиграбельного уровня...
Тестирование потребляемой игрой видеопамяти проводилось программой MSI Afterburner. За показатель брались результаты на топовых видеокартах от AMD и NVIDIA при разрешениях 1920х1080 и 2560х1440 с различными настройками сглаживания.
Тестирование при максимальных настройках качества memory GPU
Рекомендуемым объёмом использования видеопамяти для разрешения 1920х1080 станет 3076 мб видеопамяти, для разрешения 2560х1440 - 3076 мб видеопамяти и для разрешения 3840х2160 около 4096 мб видеопамяти.
Тестирование процессорозависимости мы провели на 16 моделях базовых конфигураций, которые актуальны на сегодняшний день. Тест проводился в тех местах, где значение видеокарты для игры минимально и её загрузка составляла менее 99%, в этот раз при разрешении 1920х1080.
Тестирование при максимальных настройках качества 1920х1080 API OpenGL
Тестирование при максимальных настройках качества 1920х1080 API Vulkan
Производительность процессоров в игре при использовании API Vulkan не только возрастает, но и позволяет избавиться от проблем, когда производительность падала из-за избытка процессорных ядер.
Doom задействует до 16 вычислительных потоков, но полностью использует лишь 4 ядра.
Тест проводился на базовой конфигурации Core i 7 5960Х@4.6 ГГц c количеством предустановленной памяти 32 GB DDR4 2400 MGz. За показатель бралась вся используемая оперптивная память. Тест оперативной памяти на всей системе проводился на различных тестовых стендах без запуска постороних приложений(браузеров и т.п.).
Тестирование потребления игрой ОЗУ при различных настройках качества
Как мы видим объём потребляемой оперативной памяти в Doom находится в пределах 3000 мегабайт.
Тестирование потребления системой ОЗУ
При наличии системы с 6-мя гигабайтам Doom потребляет все 5.5 гигабайт ОЗУ. При наличии системы с 8-ми гигабайтами потребление ОЗУ всей оперативной памяти составило 6 гигабайта. С системой на 16 гигабайт потребление общей памяти составило почти 7 гигабайт. И при наличии 32 гигабайт оперативной памяти система потребляет 7.2 гигабайта ОЗУ.
Относительно недавно вышел новый Vulkan API - можно сказать, наследник OpenGL, хотя основан Vulkan на API Mantle от AMD.
Конечно, развитие и поддержка OpenGL не прекратилось, а также в свет вышел и DirectX 12. Что там с DirectX 12 и почему его поставили только на Windows 10 - я, к сожалению (а может и к счастью) не знаю. Но вот кроссплатформенный Vulkan меня заинтересовал. В чём же особенности Vulkan и как правильно его использовать я постараюсь рассказать вам в этой статье.
Итак, для чего нужен Vulkan и где он может быть использован? В играх и приложениях, работающие с графикой? Конечно! Вычислять, как это делает CUDA или OpenCL? Без проблем. Обязательно ли для этого нам нужно окно или дисплей? Конечно нет, вы можете сами указать, куда транслировать ваш результат или не транслировать его вообще. Но обо всём по порядку.
Писать на Vulkan можно как на C, так и на C++. Но второй вариант даст, конечно же, больше удобства. Есть (и будут создаваться) порты на другие языки. Кто-то уже сделал порт на Delphi, кто-то желает (зачем?) порт на Python.
Итак, как же создать рендер контекст? Никак. Здесь его нет. Вместо это придумали другие вещи с другими названиями, которые даже будут напоминать DirectX.
Для работы с Vulkan нам понадобится хэндлы на его экземпляр (instance ), и может быть даже не один, а также на устройство (device ), опять же, не всегда может хватать одного.
Vulkan может быть легко загружен динамически. В SDK (разработали LunarG), если был объявлен макрос VK_NO_PROTOTYPES и загружать библиотеку Vulkan своими руками (не линковщиком, а определёнными средствами в коде), то прежде всего нужна будет функция vkGetInstanceProcAddr, с помощью которой можно узнать адреса основных функций Vulkan - те которые работают без экземпляра, включая функцию его создания, и функции, которые работают с экземпляром, включая функцию его разрушения и функцию создания устройства. После создания устройства можно получить функции, которые работают с ним (а также его дочерними хэндлами) через vkGetDeviceProcAddr.
Интересный факт: в Vulkan всегда нужно заполнить определённую структуру данными, чтобы создать какой-либо объект. И всё в Vulkan работает примерно таким образом: заранее подготовил - можно использовать часто и с высокой производительностью. В информацию об экземпляре можно также поместить информацию о вашем приложении, версии движка, версии используемого API и другую информацию.
Итак, что же за информацию мы собираем? Это, конечно же, поддерживаемые форматы, память, возможности и, конечно же, семейства очередей.
После того, как вы выбрали нужное (или нужные) семейства, из них можно получить очереди. Очереди - это место, куда будут поступать команды для устройства (потом устройство их будет брать из очередей и выполнять). Очередей и семейств, кстати, не сильно много. У NVIDIA обычно 1 семейство со всеми возможностями на 16 очередей. После того, как вы закончили с подбором семейств и количеством очередей, можно создавать устройство.
Командный буфер бывает двух видов: первичный и вторичный. Первичный отправляется прямо в очередь. Вторичный же не может быть отправлен - он запускается в первичном. Записываются команды в таком же порядке, в каком были вызваны функции. В очередь они поступают в таком же порядке. А вот исполнятся они могут почти в «хаотичном» порядке. Чтобы не было полного хаоса в приложении разработчики Vulkan предусмотрели средства синхронизации.
Теперь, самое важное: хост не ожидает завершения исполнения команд и командных буферов. По крайней мере до того момента, пока не укажете это явным способом. После отправления командных буферов в очередь управление сразу возвращается приложению.
Есть 4 примитива синхронизации: забор (fence), семафор (semaphore), событие (event) и барьер (barrier).
Забор самый простой метод синхронизации - он позволяет хосту ожидать выполнение определённых вещей. Например, завершения выполнения командного буфера. Но используется забор редко.
Семафор - способ синхронизации внутри устройства. Никак нельзя посмотреть его состояние или подождать его на хосте, нельзя также ждать его внутри командного буфера, но можем указать, какой семафор должен подать сигнал при завершении исполнения всех команд буфера, и какой семафор ждать перед тем, как начать выполнение команд в буфере. Только ждать будет не весь буфер, а его определённая стадия.
Стадии конвейера (pipeline stages) и зависимости исполнения
Как уже было сказано, не обязательно команды в очереди будут исполнятся по порядку. Если быть точнее, то последующие команды не будут ждать завершения предыдущих. Они могут выполнятся параллельно, или исполнение предыдущей команды может завершиться намного позже последующих. И это вполне нормально. Но некоторые команды зависят
от исполнения других. Вы можете разделить их на два берега: «до» и «после», и также указать, какие стадии берега «до» должны обязательно выполнится (т.е. команды могут завершиться не полностью или не все), прежде чем начнут выполняться указанные стадии команд берега «после». Например, отрисовка изображения может приостановиться, чтобы сделать определённые вещи, а потом снова продолжить делать рисовать. Также может быть и цепочка зависимостей, но не будем уходить глубоко в леса Сибири Vulkan.
События - элемент «тонкой» настройки. Подать сигнал можно как с хоста, так и с устройства, ждать можно также и на устройстве, и на хосте. Событие определяет зависимость двух сетов команд (до и после) в командном буфере. И для события есть также специальная псевдо-стадия, которая позволяет ждать хост.
Барьер опять может быть использован только в устройстве, а ещё точнее - в командном буфере, объявляя зависимости первого и второго сета команд. Также можно дополнительно указать барьеры памяти, которые бывают трёх видов: глобальный барьер, барьер буфера и барьер изображения . Они не дадут ненароком прочитать данные, которые в данный момент записываются и/или наоборот, в зависимости от указанных параметров.
Т.е. в Vulkan есть два конвейера: графический и вычислительный . С помощью графического, мы, конечно же, можем рисовать, а вычислительный… вычислять. Что же ещё? Результаты вычислений могут потом отправится в графический конвейер. Так можно с лёгкостью сэкономить время на системе частиц, например.
Изменить порядок или изменить сами стадии конвейера нельзя. Исключение составляют программируемые стадии (шейдеры). Также можно отправлять разновидные данные в шейдеры (и не только) через дескрипторы.
Для конвейера можно создать кэш, который может быть использован (снова и снова) и в других конвейерах и даже после перезапуска приложения.
Конвейер необходимо настроить и ассоциировать с командным буфером, прежде чем последний будет использовать команды конвейера.
Наследование конвейеров
Так как конвейер, это фактически вся информация о том, как нужно работать с поступающими данными, то смена конвейера (а это информация о шейдерах, дескрипторах, растеризации и прочее) может дорого обойтись по времени. Поэтому разработчики предоставили возможность наследования конвейера. При смене конвейера на дочерний, родительский или между дочерними уйдёт меньше затрат производительности. Но это также и удобство для разработчиков, как например ООП.
Для того, чтобы можно было использовать команды отрисовки, нужен графический конвейер. В графическом конвейере необходимо указать проход отрисовки (Render Pass ), который содержит информацию о подпроходах (subpass ), их зависимостей друг от друга и прикреплениях (attachment ). Прикрепление - информация о изображении, которое будет использоваться во framebuffer"ах. Framebuffer создаётся специально для определённого прохода отрисовки. Чтобы начать проход, нужно указать как сам проход (а также, если нужно, подпроход), так и framebuffer. После начала прохода можно рисовать. Можно также переключаться между подпроходами. После того, как рисование завершено, можно завершить проход.
В Vulkan можно также написать своё распределение памяти хоста, настроив Callback функции. Но учтите, что требования к памяти, это не только её размер, но и выравнивание (alignment ).
Сами ресурсы бывают двух видов: буферы (buffers ) и изображения (images ). И те и другие разделяются по назначению, но если буфер - просто коллекция различных данных (вершинный, индексный или буфер констант), то изображение всегда имеет свой формат.
Наставление тем, кто пишет на Vulkan
Выделяйте участок памяти, в который можете поместить сразу несколько ресурсов. Количество выделений ограничено, и вам может не хватить. Зато количество ассоциаций не ограничено.
Для окон это базовое расширение плоскости и расширение плоскости, специфичной для каждой из систем (win32, xlib, xcb, android, mir, wayland). Для дисплея (т.е. FullScreen) нужно расширение display, но в целом и то и другое используют расширение swapchain.
Цепочка переключений не связана с графическим конвейером, поэтому простой Clear Screen выходит без настройки всего этого. Всё достаточно просто. Есть определённый движок показа (presentation engine), в котором есть очередь изображений. Одно изображение показывается на экран, другие дожидаются своей очереди. Количество изображений мы также можем указать. Есть также несколько режимов, которые позволят дождаться сигнала вертикальной синхронизации.
Метод работы примерно таков: мы запрашиваем индекс свободного изображения, вызываем командный буфер, который скопирует результат из Framebuffer в это изображение, и отправляем команду о отправки изображения в очередь. Звучит легко, но с учётом того, что потребуется синхронизация - всё чуточку сложнее, так как единственное, чего ожидает хост - это индекс изображения, которое вскоре будет доступно. Командный буфер ждёт сигнала семафора, который будет свидетельствовать о доступности изображения, и потом сам подать сигнал через семафор о том, что выполнение буфера, в следствии и копирование, завершено. И изображение действительно поступит в очередь по сигналу последнего семафора. Всего два семафора: о доступности изображения для копирования и о доступности изображения для показа (т.е. о завершении копирования).
Кстати говоря, я проверил, что один и тот же командный буфер действительно отправлялся в очередь несколько раз. Можете подумать сами, что это значит.
В этой статье я попытался рассказать о наиболее важных частях Vulkan API, но многое всё ещё не рассказано и это вы можете узнать сами. Стабильного вам FPS и приятного кодинга.
Прежде чем говорить о деталях и тонкостях Vulkan API, думаю нужно сказать несколько слов о том, что же это такое и с чем его едят. Если сравнивать Linux с Windows, то Vulkan(который, все еще находится в разработке) это Directx, набор библиотек, для улучшения быстродействия в основном в компьютерных играх. Как известно, на платформе Linux, можно запускать игры с помощью , PlayOnLinux или коммерческой версии . Но не все игрушки запустятся и будут работать как следует, а все из-за проклятого API Directx.
Забыл сказать, что для производительности в играх для.nix платформ используется OpenGL, аналогичное программное обеспечение, как Directx для Windows. Так вот, Vulkan API, как сообщают разработчики из компании Nvidia (которые, в свою очередь, так же заинтересованы в реализации этого проекта) Vulkan API, будет дополняться устаревшим OpenGL. В свою очередь, это означает, что менее ресурсозатратные объекты, будут обрабатываться именно с помощью OpenGL, а когда приходит время , то тут в дело будет вступать новый проект.
Почему же этот проект, поддерживают, очень солидные компании, среди которых, Intel, AMD, Nvidia и др. В чем же прелесть, нового API? Здесь нужно показать видео, которое наглядно покажет, что же он из себя представляет на практике...
Как можно было увидеть из видеоматериала выше, Vulkan API, очень хорошо, управляет многозадачностью процессора, что в свою очередь позволяет, эффективно управлять графическим процессором, тем самым, нагрузка распределяется равномерно, что показывает очень хороший результат в производительности. В то время как в OpenGL, вся нагрузка идет на центральный процессор, и FPS, заметно проседает, в Vulkan API все сделано с умом, нагрузка распределена и FPS, все же проседает, но гораздо реже.
К сожалению, точная дата выхода, пока неизвестна, также держатся в секрете какие, игры, получат поддержку нового API. В свою очередь, компания AMD (которая сейчас очень активно сотрудничает с разработчиками) намекнула, что они работают над новой игрой, которая будет использовать Vulkan API, либо какая-то игра будет портирована.
Забыл упомянуть, что новый проект будет кроссплатформенным и даже Android, будет работать с ним.
Дальнейшие новости о проекте Vulkan API, будут известны с 14 по 18 марта, во время конференции The Game Developers Conference (GDC).
Все мысли по поводу Вулкана, оставляем в комментариях. Очень интересно узнать, станет ли Linux, игровой платформой или же Windows, снова придумает, что-нибудь сверхъестественное.
Перевод, комментарии: alfabuster, специально для сайта
На минувшей неделе был представлен 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.
Хорошо, но какая игра или движок поддерживают 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 может сыграть важную роль. В любом случае, следует дождаться реакции со стороны разработчиков игр, иначе мы получаем проблему курицы и яйца, из которой сложно выйти.
