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(…).
Итак, как же создать рендер контекст? Никак. Здесь его нет. Вместо это придумали другие вещи с другими названиями, которые даже будут напоминать 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 и задержка может вам дорого обойтись, особенно если выводить всю полученную информацию прямиком в консоль. После обработки сообщения, можно указать, передавать ли вызов функции дальше (в следующий слой) или нет — так можно избежать критических ошибок, но постараться работать дальше с менее опасными ошибками.
Есть также и другие расширения, о некоторых я расскажу позже в этой статье.
Устройство
Итак, что же за информацию мы собираем? Это, конечно же, поддерживаемые форматы, память, возможности и, конечно же, семейства очередей.
Очереди (queue) и семейства очередей (queue family)
Устройство может (или не может) делать следующие 4 вещи: рисовать графику, производить разные вычисления, копировать данные, а также работать с разреженной памятью (sparse memory management). Эти возможности представлены в виде семейств очередей: каждое семейство поддерживает определённые (может быть все сразу) возможности. И если идентичные семейства были разделены, Vulkan всё равно представит их как одно семейство, чтобы мы не так сильно страдали с кодом и выбирали нужное семейство. После того, как вы выбрали нужное (или нужные) семейства, из них можно получить очереди. Очереди — это место, куда будут поступать команды для устройства (потом устройство их будет брать из очередей и выполнять). Очередей и семейств, кстати, не сильно много. У NVIDIA обычно 1 семейство со всеми возможностями на 16 очередей. После того, как вы закончили с подбором семейств и количеством очередей, можно создавать устройство.
Команды, их исполнение и синхронизация
Все команды для устройства помещаются в специальный контейнер — командный буфер. Т.е. не существует ни одной функции в Vulkan, которая сказала бы устройству сделать что-либо сразу, и при завершении операции вернуть управление приложению. Есть только функции заполнения командного буфера определёнными командами (например, нарисовать что-либо или скопировать изображение). Только после записи командного буфера на хосте мы можем его отправить в очередь, которая, как уже известно, находится в устройстве.
Теперь, самое важное: хост не ожидает завершения исполнения команд и командных буферов. По крайней мере до того момента, пока не укажете это явным способом. После отправления командных буферов в очередь управление сразу возвращается приложению.
Есть 4 примитива синхронизации: забор (fence), семафор (semaphore), событие (event) и барьер (barrier).
Забор самый простой метод синхронизации — он позволяет хосту ожидать выполнение определённых вещей. Например, завершения выполнения командного буфера. Но используется забор редко.
Семафор — способ синхронизации внутри устройства. Никак нельзя посмотреть его состояние или подождать его на хосте, нельзя также ждать его внутри командного буфера, но можем указать, какой семафор должен подать сигнал при завершении исполнения всех команд буфера, и какой семафор ждать перед тем, как начать выполнение команд в буфере. Только ждать будет не весь буфер, а его определённая стадия.
Стадии конвейера (pipeline stages) и зависимости исполненияКак уже было сказано, не обязательно команды в очереди будут исполнятся по порядку. Если быть точнее, то последующие команды не будут ждать завершения предыдущих. Они могут выполнятся параллельно, или исполнение предыдущей команды может завершиться намного позже последующих. И это вполне нормально. Но некоторые команды зависят от исполнения других. Вы можете разделить их на два берега: «до» и «после», и также указать, какие стадии берега «до» должны обязательно выполнится (т.е. команды могут завершиться не полностью или не все), прежде чем начнут выполняться указанные стадии команд берега «после». Например, отрисовка изображения может приостановиться, чтобы сделать определённые вещи, а потом снова продолжить делать рисовать. Также может быть и цепочка зависимостей, но не будем уходить глубоко в
События — элемент «тонкой» настройки. Подать сигнал можно как с хоста, так и с устройства, ждать можно также и на устройстве, и на хосте. Событие определяет зависимость двух сетов команд (до и после) в командном буфере. И для события есть также специальная псевдо-стадия, которая позволяет ждать хост.
Барьер опять может быть использован только в устройстве, а ещё точнее — в командном буфере, объявляя зависимости первого и второго сета команд. Также можно дополнительно указать барьеры памяти, которые бывают трёх видов: глобальный барьер, барьер буфера и барьер изображения. Они не дадут ненароком прочитать данные, которые в данный момент записываются и/или наоборот, в зависимости от указанных параметров.
Конвейеры
Ниже показаны два конвейера 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 и приятного кодинга.
habr.com
Вышла первая версия Vulkan API
В разработке 3D-приложений, видеоигр и систем виртуальной реальности наступает новый этап. Совместными усилиями разработчики сделали важный шаг на пути к унификации кода и более эффективному использованию аппаратных ресурсов. Консорциум Khronos Group, насчитывающий более ста компаний, официально представил первую версию открытого кроссплатформенного API под названием Vulkan (ранее – GLNext). Он обеспечивает непосредственный контроль над ГП и ЦП, устраняя «узкие места» и повышая общую производительность.
На форумах часто можно увидеть однотипные вопросы о том, раскроет ли процессор X видеокарту Y и какая конфигурация при одинаковом бюджете будет производительнее в конкретных приложениях. Он возникает из-за того, что современные ГП обладают большей производительностью, чем ЦП того же уровня и поколения. В играх и других 3D-приложениях временами возникают ситуации, когда на ЦП приходится большая нагрузка, а ГП простаивает. Например, процессор обсчитывает взаимодействие игроков и объектов, а видеокарта ждёт от него данные, чтобы отрисовать следующий кадр. Из-за несбалансированности нагрузки возникают задержки, а динамичная игра может превратиться в покадровое слайд-шоу даже с мощной видеокартой.
Указанные проблемы характерны для платформы PC и практически незнакомы владельцами игровых консолей. Разработчики консольных игр всегда знают детальные спецификации приставок и могут выполнять глубокую оптимизацию кода с учётом их особенностей. Компьютеры, ноутбуки, планшеты – это зоопарк не только из разных конфигураций, но и принципиально отличных архитектур. При создании игр для столь разношёрстной платформы приоритетом становится универсальность кода, что негативно сказывается на скорости его исполнения.
Сравнение Vulkan API и OpenGL (изображение: Khronos Group).Разработчики операционных систем по-разному пытаются решить проблему низкой эффективности кода сторонних приложений. Microsoft начала искать пути оптимизации графических вычислений давно, однако реальная поддержка низкоуровневых операций появилась только в DirectX 12. Этот API доступен лишь в одной ОС – Windows 10. В свою очередь, положение Apple оказалось ближе к таковому у производителей игровых консолей. Когда одна и та же компания выпускает мобильные процессоры и софт, его согласованной работы добиться куда легче. Тем не менее, пути оптимизации самой разработки игр и приложений у Apple далеко не исчерпаны. В iOS 8 появился Metal API, также ориентированный на использование низкоуровневых операций.
Остальные крупные компании предпочитают действовать совместно и в рамках открытых стандартов. Появившийся 16 лет назад консорциум Khronos Group объединил более ста производителей, включая таких кровных друзей, как AMD, Nvidia и Intel. В своё время консорциум явил на свет открытые стандарты OpenGL, OpenCL, OpenCV и многие другие.
Khronos Group насчитывает более ста участников.По сравнению с 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 года.
www.computerra.ru
Vulcan API — описание, возможности, преимущества
Разработчиком инновационного интерфейса программирования приложений Vulkan стала компания Khronos Group. Данный интерфейс является кроссплатформенным и повышает производительность системы путем улучшения пропускной способности между центральным и графическим процессорами.
На сегодняшний день существует значительное различие в вычислительной мощности центрального процессора и видеоадаптера соответствующего поколения и уровня. Несбалансированность нагрузки между ЦПУ и ГПУ приводит к задержкам и дискомфорту в игровом процессе даже у обладателей самой последней мощной видеокарты. Vulkan призван скорректировать эту разность мощностей.
Что же внутри Vulkan?
Интерфейс Vulkan разрабатывался еще с 2014 года, чтобы заменить давно устаревший OpenGL. За основу были взяты библиотеки API – AMD Mantle. Vulkan представляет собой графическую библиотеку, которая дает возможность полного доступа к ГПУ и контроля его работы.
Vulkan использует свой язык SPIR-V и корректирует процесс компиляции шейдерных программ, что можно выполнить уже на стадии разработки. Также Vulkan позволяет нивелировать зависимость скорости отрисовки от качества драйверов.
Сильные стороны Vulkan
Большая часть достоинств API Vulkan нацелена на сбалансированность нагрузки центрального процессора и позволяет повысить количество запросов на отрисовку за один кадр.
Основными преимуществами API Vulkan являются следующие характеристики:
- Кроссплатформенность Vulkan открывает все больше преимуществ на рынке IT для приложений на разных платформах.
- Снижение задержек дает возможность разработчикам игр насыщать сцены большим количеством деталей и спецэффектов.
- Плавность и динамичность игрового процесса.
- Снижение энергопотребления и количества выделяемого системой тепла ввиду сбалансированной нагрузки на ЦПУ.
- Открытый код позволяет снизить затраты на портирование игр.
На сегодняшний день Vulkan работает в связке с видеоадаптерами AMD на основе архитектуры Graphics Core Next и ускорителя NVidia Kepler и Maxwell. Уже вышла в свет компьютерная игра, в которой поддерживается новый API.
Как утверждают разработчики нового интерфейса, Vulkan позволит пользователю раскрыть потенциал своей системы и обеспечить соответствующую производительность. А перед создателями игр открываются перспективы организации более зрелищных спецэффектов и возможность уделить больше внимания прорисовке мельчайших деталей виртуального мира.
www.starlink.ru
Оставить комментарий