Краткий обзор Vulkan API

Так что же такого особенного в этом новом Vulkan API и почему нас это должно волновать?

Вот API Vulkan в сотне слов или меньше: это API с низкими накладными расходами, почти металлический API для 3D-графики и вычислительных приложений. Vulkan в основном является продолжением OpenGL. Первоначально он назывался «инициативой OpenGL следующего поколения» и включает в себя несколько фрагментов API Mantle от AMD. Предполагается, что Vulkan обеспечивает многочисленные преимущества по сравнению с другими API-интерфейсами графических процессоров, обеспечивая превосходную кроссплатформенную поддержку, лучшую поддержку многопоточных процессоров, меньшую нагрузку на ЦП и некоторую независимость от ОС. Это также должно упростить разработку драйверов и позволить предварительную компиляцию драйверов, включая использование шейдеров, написанных на разных языках.

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

Как появился Vulkan API

Вулкан был первоначально анонсирован Khronos Group в марте 2015 года, а предварительная дата запуска назначена на конец 2015 года. Если вы не знакомы с Khronos, это некоммерческий отраслевой консорциум, основанный пятнадцать лет назад некоторыми из самых больших имен в мире. графическая индустрия, включая ATI (теперь часть AMD), Nvidia, Intel, Silicon Graphics, Discrete и Sun Microsystems. Даже если вы не слышали о Khronos, вы наверняка слышали о некоторых их стандартах, таких как: OpenGL, OpenGL ES, WebGL, OpenCL, SPIR, SYCL, WebCL, OpenVX, EGL, OpenMAX, OpenVG, OpenSL ES, StreamInput, COLLADA и glTF.

К настоящему моменту вы, вероятно, думаете: «Ах, это же те ребята», поэтому я могу пропустить остальную часть вступления и сосредоточиться на самом API.

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

Теперь я понимаю, что у многих технофилов есть свои оговорки по поводу маркетинговых терминов, таких как «гибкий», «расширяемый» и «модульный», но на этот раз мы имеем дело с настоящим МакКоем. На самом деле, это основная идея Vulkan: он задуман как API для масс, от детей, играющих на смартфонах, до их родителей, проектирующих здания и игры на рабочих станциях.

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

Для получения более подробной информации я предлагаю вам взглянуть на официальный обзор Vulkan в формате PDF.

ДНК мантии AMD

Если подход, близкий к металлу, звучит устрашающе знакомо, возможно, вы следили за анонсами графических процессоров AMD за последние два года или около того. AMD удивила отраслевых обозревателей, когда объявила о своем API Mantle в 2013 году, и еще раз удивила их, когда решила отключить API, объявив в марте 2015 года, что не будет выпускать Mantle 1.0 в качестве общедоступного SDK. В двух словах, Mantle пообещала в некоторых ситуациях значительно повысить производительность и эффективность, особенно в отношении ЦП, поскольку это уменьшит накладные расходы на обработку. Это звучало как хорошая идея, так как геймеры могли собрать собственные ПК с несколько более медленными процессорами и вложить больше денег в первоклассные видеокарты. Это звучало очень удобно и для AMD, потому что у компании уже много лет не было конкурентоспособных высокопроизводительных процессоров, хотя у нее все еще есть хорошие продукты с графическими процессорами.

Когда плачущие фанаты AMD собрались, чтобы оплакать кончину своего спасителя, Мантл чудесным образом воскрес. Хорошие новости пришли в виде сообщения в блоге, написанного вице-президентом AMD по визуальным и перцептивным вычислениям Раджей Кодури. По совпадению, в соответствии с религиозной темой, Кодури однажды произнес проповедь на горе во время презентации AMD на Гавайях в 2013 году, но я отвлекся.

Шутки в сторону, команда Кодури проделала хорошую работу. Хотя Mantle не стал новым отраслевым стандартом, он стал основой для Vulkan. Самое большое отличие заключается в том, что Vulkan не будет ограничен аппаратным обеспечением AMD GCN; он будет работать на гораздо большем количестве графических процессоров от разных производителей. Вы, наверное, понимаете, к чему я клоню; немного лучше иметь единый графический API с низкими накладными расходами, который работает на разных операционных системах и аппаратных платформах, чем иметь проприетарные API для разных архитектур графических процессоров, ОС и так далее.

Vulkan API просто берет хороший кусок пирога Mantle и делится им со всеми, независимо от ОС, аппаратного обеспечения, расы или религии.

Да, и еще кое-что: Mantle в конце концов вынудила Microsoft и Khronos наконец-то что-то сделать с DirectX и OpenGL раздуванием и неэффективностью. Это был нежный дружеский пинок в зад, или «бадонкадонк», как любит выражаться один топталер.

Как Vulkan сравнивается с OpenGL?

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

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

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

Разработчики смогут выбрать три разных уровня или уровня экосистемы Vulkan.

• Используйте Vulkan напрямую для максимальной гибкости и контроля.
• Используйте библиотеки и слои Vulkan для ускорения разработки.
• Используйте Vulkan через готовые игровые движки, полностью оптимизированные для нового API.

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

Последний вариант, пожалуй, самый заманчивый, потому что тяжелую работу проделали такие тяжеловесы индустрии, как Unity, Oxide, Blizzard, Epic, EA, Valve и другие.

Вот краткая таблица OpenGL и Vulkan:

Честно говоря, я не думаю, что это даже справедливо сравнивать эти два. Vulkan — производная от Mantle, а OpenGL — мастодонт с 20-летним багажом. Предполагается, что Vulkan избавится от множества устаревших вещей; в этом весь смысл. Предполагается, что Vulkan упростит тестирование и внедрение, упростит работу драйверов и улучшит переносимость шейдерных программ с помощью промежуточного языка SPIR-V.

Это подводит нас к следующему вопросу. Что Vulkan на самом деле означает для разработчиков?

Ожидается, что SPIR-V изменит языковую экосистему

Так где же вступает в игру SPIR-V и что происходит со старым добрым GLSL?

GSLS пока останется в живых, и это будет первый язык шейдинга, поддерживаемый Vulkan. Переводчик GLSL в SPIR-V сделает всю тяжелую работу, и вуаля! Вы получите SPIR-V, готовый накормить голодную среду выполнения Vulkan. Разработчики игр смогут использовать серверные части SPIR-V и Vulkan, вероятно, полагаясь на внешние интерфейсы компилятора с открытым исходным кодом. Помимо GLSL, Vulkan может поддерживать ядра OpenCL C, в то время как работа над добавлением поддержки C++ продолжается. Еще одним вариантом являются будущие предметно-ориентированные языки, фреймворки и инструменты. Хронос даже упоминает о возможности разработки новых экспериментальных языков.

Что бы ни выбрали разработчики, все дороги ведут к Вулкану, через SPIR-V, а затем к множеству различных устройств.

Предполагается, что SPIR-V улучшит переносимость тремя способами:

• Общие инструменты
• Единый набор инструментов для одного ISV
• Простота

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

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

SPIR-V проще обычного языка высокого уровня, что упрощает реализацию и обработку.

Производительность будет улучшена несколькими способами, в зависимости от того, как реализован Vulkan:

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

Khronos не указывает никаких показателей производительности и отмечает, что «пробег определенно будет варьироваться». Все будет зависеть от того, как используется Вулкан. Если вы хотите узнать подробности, обязательно ознакомьтесь с официальным документом SPIR-V.

Vulkan выглядит многообещающе с точки зрения разработчика

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

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

Khronos выделяет следующие преимущества, которые стали возможными благодаря SPIR-V:

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

Я уверен, вы согласитесь, что это звучит хорошо, но впереди еще долгий путь.

Vulkan: это работает, но работа еще не завершена

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

Лучшая иллюстрация Vulkan, которую я когда-либо видел, была сделана Imagination Technologies, одним из ведущих производителей мобильных графических процессоров. Imagination Technologies GPU IP используется во всех гаджетах iOS, наряду с многочисленными другими конструкциями System-on-Chip на базе ARM и даже в некоторых низковольтных чипах Intel x86.

На прошлой неделе Imagination опубликовала сообщение в блоге с подробным описанием прироста производительности, который стал возможен благодаря Vulkan. Выбор оборудования был несколько необычным: Google Nexus Player на базе редко используемого четырехъядерного процессора Intel с графическим процессором PowerVR G6430. Устройство было протестировано с последним драйвером Vulkan API для графических процессоров PowerVR, а эталонный запуск был выполнен на OpenGL ES 3.0. Разрыв в производительности был не чем иным, как ошеломляющим.

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

Тем не менее, есть большое предостережение: это не тот прирост производительности, который вы можете ожидать в реальной жизни. Команда Imagination Technologies использовала преувеличенный сценарий, чтобы подчеркнуть превосходство Vulkan, довести его до предела, и в этом конкретном сценарии предел находится в пользу Vulkan по сравнению с OpenGL ES. Кроме того, имейте в виду, что этот тест привязан к графическому процессору , но он по-прежнему является хорошей иллюстрацией превосходного использования ЦП Vulkan.

Как Vulkan снижает загрузку процессора?

Помните ту таблицу OpenGL и Vulkan, которая была у нас ранее, или, если быть более точным, тот бит мозаичного рендеринга ? Вероятно, нет, так вот, в двух словах: Imagination использовала Vulkan для пакетной обработки вызовов отрисовки в тайлах и рендеринга тайлов за раз. В зависимости от того, где находится тайл в момент рендеринга кадра, он может появиться или исчезнуть из поля зрения, изменить уровень детализации и так далее. В OpenGL ES все вызовы отрисовки динамические, они отправляются с каждым кадром, в зависимости от того, что находится в поле зрения. Вызовы отрисовки, которые уже были выполнены, не могут быть кэшированы.

В результате OpenGL ES требуется много обращений в режим ядра, чтобы изменить состояние драйвера и проверить его. Vulkan этого не делает, потому что он полагается на предварительно сгенерированные команды (буферы команд) для снижения нагрузки на ЦП и устранения необходимости проверки или компиляции во время цикла рендеринга. Команда Imagination описала возможность повторного использования командных буферов как «полезную в некоторых обстоятельствах» и возможность использования «в значительной степени» во многих играх и приложениях.

Второе изменение правил игры — параллельная генерация буфера , которая позволяет Vulkan использовать мощность всех ядер ЦП. OpenGL ES был разработан до появления многоядерных мобильных чипов, но за последние три года индустрия перешла от двух-, четырех-, восьми- и десятиядерных процессоров с помощью SoC Apple A-серии и Nvidia Tegra из Денвера. чипы как единственное заметное исключение. Я рассказывал о тенденциях мобильных SoC в одной из своих предыдущих статей в блоге, рассказывая о готовящемся компиляторе Optimizing Android, так что вы можете проверить его для получения дополнительной информации.

Давайте попробуем провести аналогию: если бы Vulkan был двигателем внутреннего сгорания, он бы сохранял и повторно использовал часть своей мощности почти так же, как турбокомпрессор и промежуточный охладитель (командные буферы), и он мог бы использовать четыре, шесть, восемь или даже десять цилиндров без потери эффективности (параллельная генерация буфера). Сравнение Vulkan с OpenGL ES звучит как сравнение нового, уменьшенного турбодвигателя со старым одноцилиндровым двигателем на Triumph Trophy вашего дедушки.

Ну хоть дедушка был настоящим рокером, а не модником.

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

Потенциальные недостатки Vulkan API (спойлер: их не так много)

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

• Добавлена ​​сложность кода в определенных сценариях
• Пора торговать
• Уровень поддержки отрасли
• Vulkan может быть не таким актуальным или эффективным на некоторых платформах (настольных компьютерах).
• Убедить разработчиков использовать Vulkan на некоторых платформах
• Ограниченная совместимость с устаревшим оборудованием

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

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

Поддержка отрасли не должна быть проблемой; В конце концов, это стандарт Khronos, но это может занять некоторое время. Это одна из причин, по которой я сосредоточил этот пост на мобильном сегменте; Мобильное программное и аппаратное обеспечение развиваются быстрее, и может пройти еще несколько кварталов, прежде чем мы увидим, как Vulkan оказывает влияние на настольные платформы. Именно так устроена индустрия, в нише настольных ПК есть о чем беспокоиться: поддержка профессиональных приложений, толпы геймеров с вилами, которые сходят с ума по каждому вырванному кадру, и так далее. Однако тот факт, что Vulkan является производным от AMD Mantle, обнадеживает.

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

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

Еще одним поводом для беспокойства может быть совместимость со старым оборудованием. Vulkan потребуется аппаратное обеспечение OpenGL ES 3.1 или OpenGL 4.1, а также новые драйверы. Например, графические процессоры Imagination Technologies PowerVR серии 6 могут его поддерживать, а серия 5 — нет. Серия Qualcomm Adreno 400 поддерживает OpenGL ES 3.1, а серия 300 — нет. Серии ARM Mali T600 и T700 поддерживают OpenGL ES 3.1, но поддержка более старых моделей серии T400 отсутствует. К счастью, к тому времени, когда Vulkan станет актуальным, большинство устройств с неподдерживаемыми графическими процессорами исчезнут. К ним относятся iPhone 5/5C, iPad четвертого поколения и устройства Samsung на базе определенных чипов Exynos серии 5000. Устройствам на базе Qualcomm может не повезти, поскольку графические процессоры Adreno 300-й серии используются в относительно недавних и популярных разработках, таких как Snapdragon 410, Snapdragon 600, Snapdragon 800 и 801. Однако я подозреваю, что большинство из них к тому времени исчезнет. Вулкан становится по-настоящему актуальным.

Живи долго и рендеринг

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

Примерно в то же время, когда мы получим драйверы, игровые движки и игры, оптимизированные для Vulkan, мы получим новое оборудование, с которым можно будет поиграть, и я не имею в виду лишь незначительные аппаратные настройки. Разработка мобильных SoC застопорилась по ряду причин, которые я не буду сейчас вдаваться, но 2016 год станет важным годом для отрасли, поскольку 14/16-нм узлы FinFET станут доступными для большего числа производителей и станут экономически выгодными для основного оборудования, а не флагманские чипы.

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