Vulkan в играх что это
Что означает появление технологии Vulkan для пользователей
На минувшей неделе стало известно о глобальном релизе графических драйверов, которые отныне поддерживают новый низкоуровневый API Vulkan. Первыми, кто обратил внимание на эту новость, стали геймеры с настольными компьютерами, поскольку Vulkan в первую очередь затрагивает работу графической составляющей и со временем должен заменить морально устаревший стандарт OpenGL ES. Последний дебютировал ещё в те времена, когда компьютеры работали на одноядерных процессорах и большинство пользователей даже не задумывались о многоядерных высокопроизводительных устройствах. Однако всё меняется, и число доступных ядер в настольных и мобильных процессорах уже приближается к дюжине. Для максимально эффективного использования их потенциала и была начата работа над новым API.
В общем представлении Vulkan должен принести улучшенный игровой и пользовательский опыт, а также более высокое качество игр, в том числе на Android. По сравнению с традиционными OpenGL и Direct3D, Vulkan предоставляет возможность реализовать многопоточность и более эффективно использовать центральный процессор. Технология изначально основана на разработке от AMD под названием Mantle, однако вскоре идея была подхвачена консорциумом Khronos Group, в который сегодня входит больше 100 членов по всему миру. Vulkan версии 1.0 был выпущен для Windows, Linux и Android. Особенно большое влияние Vulkan окажет именно на мобильную платформу, поскольку предоставит разработчикам прямой доступ к GPU для полного контроля над его работой. Можно ожидать не только повышение качества изображения, но и уменьшение энергопотребления при том же результате.
Что означает появление технологии Vulkan для пользователей
NVIDIA уже опубликовала необходимые образы для разработчиков, чтобы те могли адаптировать их к нынешним Android-планшетам с чипами NVIDIA, однако сегодня их доля на рынке мизерна. Среди Khronos Group мелькают имена известных производителей, в частности, Google, Samsung, Sony, Qualcomm, Huawei и некоторых других, однако как скоро они начнут внедрять Vulkan, сказать довольно сложно. Хочется верить, что Google сделает Vulkan приоритетной разработкой для Android, однако пока что об этом официально ничего не сообщается.
Vulkan-tutorial. Урок 1.1 — Вступление
В связи с тем, что у меня не так много времени для ресерча каких-то новых штук и написания статей о них, я решил перевести серию уроков по Vulkan. Надеюсь, что мои переводы будут кому-то полезны и не очень плохого качества. Для начала обучения — прошу под кат.
Автор оригинала дал свое согласие на перевод. Также, когда я доперевожу все статьи и у меня будет время отформатировать их для github, он добавит русский перевод на свой сайт.
В этой части не будет ничего технического, так как я решил сохранить структуру оригинала. Будет рассказано немного о Vulkan, структуре уроков, ссылки на книги и тд.
Часть 1. Вступление
Часть 2. Первый треугольник
Часть 3. Vertex buffer
Часть 4. Uniform Buffer
Часть 6. Буфер глубины
Часть 7. 3D Модели
Часть 8. Mipmaps
Часть 9. Multisampling
Описание
В этих уроках вы научитесь основам Vulkan API. Vulkan это новый API созданный компанией Khronos group (создатели OpenGL), он предоставляет улучшенную абстракцию для программирования графики на современных видеокартах. Новый интерфейс поможет лучше описать как ваше приложение будет работать с графическим процессором, что потенциально может увеличить производительность и уменьшить неожиданные ситуации, связанные с поведением драйвера по сравнению с существующими API, такими как OpenGL и Direct3D. Идеи, лежащие в основе Vulkan, аналогичны идеям Direct3D 12 и Metal, но Vulkan имеет одно неоспоримое преимущество — полную кросс-платформенность, что позволяет разрабатывать приложение одновременно под Linux, Windows и Android.
Взамен, вам придется работать с менее абстрактным и более сложным API. Каждая мелочь, связанная с API, будет настраиваться вами с нуля, включая создание начального буфера кадров и управление памятью для объектов (буферы, текстуры и тд.). Драйвер будет меньше вас ограничивать, а это означает, что вам придется проделать больше работы, чтобы обеспечить правильное поведение вашего приложения.
Вывод — Vulkan не для всех. Он создан для программистов, которым нужно больше производительности, несмотря на более сложный и кропотливый процесс написания приложения. Если вы заинтересованы разработкой игр больше, чем программированием компьютерной графики, то вы можете и дальше использовать OpenGL или DirectX, в любом случае они по-прежнему поддерживаются и не будут вытеснены Vulkan(ом) в ближайшее время. Как альтернативу, можно использовать какой-то игровой движок (Unreal Engine, Unity и тд.), который будет использовать Vulkan, но предоставит вам свою высокоуровневую абстракцию над базовым API.
Теперь давайте рассмотрим что вам надо для изучения Vulkan:
Рекомендую обновить драйвера на видеокарту.
В этой серии уроков от вас не требуется знания OpenGL или DirectX, но предполагается, что вы знакомы с основами 3D графики. Например, тут не будет объясняться математика, лежащая в основе перспективной проекции. Для понимания основ компьютерной графики рекомендую прочесть эту книгу. Другие хорошие ресурсы по графике:
Мы будем использовать С++, но вы также можете писать и на чистом С. Если будете использовать С, вам придется использовать другую библиотеку для линейной алгебры, так же самостоятельно структурировать код, так как мы будем использовать классы для структурирования кода и RAII для управления временем жизни ресурсов. Также существует альтернативная версия руководства для разработчиков на Rust.
Для того, что бы разработчикам на других языках было проще понять, как работать с базовым API, мы будем использовать С версию Vulkan API. Однако, вы можете использовать C++ API, который немного упростит жизнь и поможет избежать некоторых ошибок.
Посмотри на котика и расслабься.
E-Book
Также вы можете скачать это руководство в формате электронной книги (нет русского):
Структура уроков
Для начала мы разберемся с тем, как работает Vulkan, и по шагам разберем, что нам нужно для отрисовки нашего первого треугольника на экране. Мы будем продвигаться маленькими шажочками, смысл которых поначалу будет вам не очень понятен, но потом вы поймете их роль когда увидите картину в целом. Следующим шагом будет настройка среды разработки Vulkan SDK, GLM для линейной алгебры и GLFW для создания окна. В уроках будет показано, как настроить все под Windows + Visual Studio и Ubuntu Linux + GCC.
После чего мы реализуем все основные компоненты для отрисовки нашего первого треугольника. Каждая глава будет иметь примерно следующий вид:
Каждая глава написана как продолжение предыдущей, но вы также можете читать их как отдельные статьи, знакомящие вас с определенным функционалом Vulkan, то есть вы можете использовать этот сайт как справочник по функционалу. Все функции и типы Vulkan, описанные тут, будут иметь ссылки на спецификацию, поэтому вы можете ознакомится с ними более подробно. Vulkan — новый API, поэтому в спецификации могут быть некоторые неточности или нехватка информации. Если столкнетесь с какими-то погрешностями, не стесняйтесь и оставляйте отзыв в этом репозитории.
Как упоминалось ранее, Vulkan API достаточно низкоуровневый с множеством настроек, что даёт вам максимальный контроль работы графического конвейера. Это вынуждает нас повторно выполнять большое количество шагов по многу раз. Чтобы этого избежать, мы будем стараться выносить такой функционал в отдельные вспомогательные функции.
Также в конце каждой главы будет прилагаться исходный код (включая предыдущие уроки). Вы всегда можете заглянуть туда, если у вас возникнет какая-то ошибка и вы захотите сравнить код или будут сомнения в его структуре. Весь код тестировался на нескольких видеокартах от разных производителей, чтобы исключить ошибки, связанные с железом, и проверить корректность исходников.
Вы всегда можете задать вопрос, относящийся к конкретной теме. Пожалуйста, указывайте в коментариях вашу платформу, версию драйвера, исходный код, ожидаемое поведение и фактическое поведение, чтобы люди могли быстро сориентироваться и помочь вам.
На сайте с оригиналом статьи есть раздел комментариев под основным блоком.
Vulkan — это все еще новый API и best practices еще не сформировались. В случае, если у вас появились какие-то советы, отзывы об учебнике или самом сайте, не стесняйтесь и оставляйте ваши запросы или исправления (можно пулл-реквесты на GitHub). Также можно следить за обновлениями руководства в репозитории.
После выполнения ритуала с рисованием треугольника мы начнем расширять нашу программу. Будем добавлять текстуры, модели и тд. Если у вас уже был опыт графического программирования, то вы знаете, что перед тем, как на экране что-то появится, нужно выполнить много шагов инициализации, создания буферов и тд. В Vulkan этих шагов на порядок больше, но не волнуйтесь, каждый шаг легко понять и вы поймете, что ни один из них не является лишним. Могу обрадовать, переход от скучного треугольника до отрисовки полноценной 3D модели с текстурами не потребует такого большого количества шагов и усилий от нас.
Как правило, рисование треугольника в программировании графики, это как написание «Hello world!» при изучении языка.
Если вы столкнетесь с какими-либо проблемами, следуя руководству, сначала проверьте FAQ, чтобы увидеть, есть ли там ваша проблема и ее решение. Если решение так и не было найдено, не стесняйтесь обращаться за помощью в разделе комментариев в главе.
От переводчика:
Ребят, кому интересен данный цикл статей, поставьте лайк или отпишите в комменты, чтобы я знал нужно оно или нет. Если вы заинтересованы, то постараюсь быстро и качественно перевести следующую статью.
Также буду очень рад, если вы будете сообщать мне о всех ошибках, опечатках и предложениях по улучшению переводов. Перевод и написание статьи заняло у меня около дня и никто кроме меня ее не проверял так что могут встречаться ошибки и опечатки.
Огромное спасибо за исправление моих ошибок и опечаток:
maxzhurkin
Mingun
Также всем остальным и модераторам хабра 🙂
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).
Забор самый простой метод синхронизации — он позволяет хосту ожидать выполнение определённых вещей. Например, завершения выполнения командного буфера. Но используется забор редко.
Семафор — способ синхронизации внутри устройства. Никак нельзя посмотреть его состояние или подождать его на хосте, нельзя также ждать его внутри командного буфера, но можем указать, какой семафор должен подать сигнал при завершении исполнения всех команд буфера, и какой семафор ждать перед тем, как начать выполнение команд в буфере. Только ждать будет не весь буфер, а его определённая стадия.
События — элемент «тонкой» настройки. Подать сигнал можно как с хоста, так и с устройства, ждать можно также и на устройстве, и на хосте. Событие определяет зависимость двух сетов команд (до и после) в командном буфере. И для события есть также специальная псевдо-стадия, которая позволяет ждать хост.
Барьер опять может быть использован только в устройстве, а ещё точнее — в командном буфере, объявляя зависимости первого и второго сета команд. Также можно дополнительно указать барьеры памяти, которые бывают трёх видов: глобальный барьер, барьер буфера и барьер изображения. Они не дадут ненароком прочитать данные, которые в данный момент записываются и/или наоборот, в зависимости от указанных параметров.
Конвейеры
Ниже показаны два конвейера Vulkan:
Т.е. в Vulkan есть два конвейера: графический и вычислительный. С помощью графического, мы, конечно же, можем рисовать, а вычислительный… вычислять. Что же ещё? Результаты вычислений могут потом отправится в графический конвейер. Так можно с лёгкостью сэкономить время на системе частиц, например.
Изменить порядок или изменить сами стадии конвейера нельзя. Исключение составляют программируемые стадии (шейдеры). Также можно отправлять разновидные данные в шейдеры (и не только) через дескрипторы.
Для конвейера можно создать кэш, который может быть использован (снова и снова) и в других конвейерах и даже после перезапуска приложения.
Конвейер необходимо настроить и ассоциировать с командным буфером, прежде чем последний будет использовать команды конвейера.
Проход отрисовки, графический конвейер и фреймбуфер
Итак, получаем следующую матрёшку:
Для того, чтобы можно было использовать команды отрисовки, нужен графический конвейер. В графическом конвейере необходимо указать проход отрисовки (Render Pass), который содержит информацию о подпроходах (subpass), их зависимостей друг от друга и прикреплениях (attachment). Прикрепление — информация о изображении, которое будет использоваться во framebuffer’ах. Framebuffer создаётся специально для определённого прохода отрисовки. Чтобы начать проход, нужно указать как сам проход (а также, если нужно, подпроход), так и framebuffer. После начала прохода можно рисовать. Можно также переключаться между подпроходами. После того, как рисование завершено, можно завершить проход.
Управление памятью и ресурсы
Память в Vulkan распределяется хостом и только хостом (за исключением swapchain). Если изображение (или другие данные) нужно поместить в устройство — выделяется память. Сначала создаётся ресурс определённых размеров, затем запрашивается его требования к памяти, выделяется для него память, затем ресурс ассоциируется с участком этой памяти и только потом можно копировать в этот ресурс необходимые данные. Также, есть память, которая может быть непосредственно изменена с хоста (host visible), есть локальная память устройства (память видеокарты, например) ну и также другие виды памяти, по своему влияющие на скорость доступа к ним.
В Vulkan можно также написать своё распределение памяти хоста, настроив Callback функции. Но учтите, что требования к памяти, это не только её размер, но и выравнивание (alignment).
Сами ресурсы бывают двух видов: буферы (buffers) и изображения (images). И те и другие разделяются по назначению, но если буфер — просто коллекция различных данных (вершинный, индексный или буфер констант), то изображение всегда имеет свой формат.
Шейдеры
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 и приятного кодинга.