что такое vulkan и directx 12

Что выбрать Vulkan или DirectX 12 в Red Dead Redemption 2?

Теперь когда Red Dead Redemption 2 наконец-то появился на платформе ПК, тысячи игроков прыгнули в игру, чтобы почувствовать вкус дикого запада. Как и большинство многоплатформенных игр, которые выпускаются на ПК, Red Dead Redemption 2 предлагает визуальные обновления и опции, недоступные в его консоли. В дополнение к настройкам для увеличения расстояния прорисовки объектов, точности моделирования физики и качества графических эффектов, игра также предлагает пользователям ПК два различных графических API-интерфейса. И Vulkan, и DirectX 12 можно выбрать из меню графических опций. Что делают эти API и что лучше для вас?

Что выбрать Vulkan или DirectX 12

Vulkan и DirectX 12 обеспечивают связь между игрой и оборудованием вашего ПК.

Что такое графический API?

API — это сокращение от интерфейса прикладного программирования. Когда речь заходит о видеоиграх на ПК, разработчики почти всегда используют один из популярных API для воплощения игр в жизнь на платформе. Эти API-интерфейсы позволяют разработчикам взаимодействовать с игровым движком без необходимости написания кода непосредственно для каждого конкретного варианта. Вместо того, чтобы разработчику приходилось писать уникальный код для Radeon RX 5700 XT, Radeon RX 580 и GeForce RTX 2080, графический API транслирует информацию и команды аппаратному обеспечению.

Какой API мне выбрать?

Red Dead Redemption 2 предлагает как Vulkan, так и DirectX 12 API в своем графическом меню. Vulkan — это многоплатформенный API рендеринга, который поддерживается Khronos Group и основан на AMD Mantle API. Он использовался в таких играх, как Doom (2016), The Surge 2 и в различных игровых портах Linux. DirectX 12 был разработан Microsoft и используется компьютерами Xbox One и Windows. Известные игры DirectX 12 включают Gears of War 5, Metro Exodus и Resident Evil 2.

Нет визуальной разницы между Vulkan и DirectX 12.

В Red Dead Redemption 2 нет визуальной разницы между выбором Vulkan или DirectX 12. Единственная разница между ними заключается в том, как они взаимодействуют с оборудованием вашего ПК. То как игра работает с этими API-интерфейсами, может отличаться в зависимости от используемого оборудования. Исходя из самых ранних тестов, основанных на отчетах игроков, Vulkan предлагает немного более высокую среднюю частоту кадров ( 3 2 голоса

Источник

Что такое Vulkan и DirectX и как они влияют на видеоигры

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

Предварительная информация о API

Прежде чем мы начнем говорить о DirectX и Vulkan, нам нужно сначала понять, что такое API. Аббревиатура означает «Интерфейс прикладного программирования».

Интерфейс предназначен для обеспечения связи между двумя объектами. Одним из примеров является графический интерфейс Windows, который играет роль посредника между операционной системой и пользователем.

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

Ориентировочный пример, в котором мы используем API, — это когда мы автоматически регистрируемся в новом социальном средстве или онлайн-сервисе, используя наши ранее существующие учетные записи из Facebook или Google (вместо создания новой учетной записи вручную).

В таких случаях веб-сайт использует API, через который он связывается с конкретной услугой (например, Facebook или Twitter), чтобы собирать нашу личную информацию (имя (имена), адрес электронной почты, контактные номера и т. д.) Для создания нашего нового аккаунта.

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

В таких случаях использование API-интерфейсов применимо к нашему компьютерному оборудованию и в частности, к нашей графической карте (видеокартам).

DirectX и Vulkan фактически улучшают связь между приложением (игрой) и графическим процессором, чтобы повысить производительность графики.

Microsoft DirectX

С выпуском Windows 95 и модели защищенной памяти разработчики не имели такого же доступа к ресурсам, как в MS-DOS. DirectX впервые появился в виде набора конкретных API для разработки мультимедийных приложений, таких как игры.

Термин «DirectX» начинается со слова «Direct», ссылаясь на прямой доступ к ресурсам системы. Некоторые примеры включают Direct3D для графики и DirectSound для аудио. Часть «Х» относится к API в общей коллекции; таким образом объединив все API-интерфейсы под названием DirectX. Вышеупомянутое название также вдохновило название популярной видеоигр компании Xbox.

Вышеприведенное иллюстрирует тесную связь между DirectX и консолью Microsoft. Его последняя версия, DirectX 12, имеет большие улучшения. Тем не менее он поддерживается только Windows 10 и новейшей игровой консолью компании Xbox One.

Direct3D является жемчужиной DirectX и полезен для создания 3D-объектов на нашем экране. Он также позволяет просматривать игры в полноэкранном режиме, а также использовать аппаратные ускорители. Последний метод позволяет реализовать некоторые функции более эффективно, чем они работают в программном обеспечении. Это может быть достигнуто за счет более эффективного использования аппаратного обеспечения нашего компьютера. В этом случае это будет наша видеокарта.

Вулкан AMD

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

Следует четко указать, что «низкий уровень» не относится к качеству. Вместо этого этот термин описывает способность Вулкана работать на аппаратном уровне.

Хронос окружает себя одними из самых больших имен в ИТ-индустрии. Некоторые из них — Google, Intel, Sony, Nvidia и AMD. Последние два дали API, свести к минимуму время разработки Vulkan.

OpenGL — популярный API среди графических дизайнеров. Фактически он был разработан Хроносом, и он также включает в себя многие характеристики Вулкана. Однако его прием игровыми дизайнерами был непредвиденным.

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

Здесь вы можете найти полный список с именами, которые содержат Khronos. Мантия обеспечила основную базу, на которой был разработан Вулкан. Наконец Vulkan в настоящее время находится в версии 1.1.

Как они влияют на игры

До этого момента мы рассмотрели некоторые основы, касающиеся API, Microsoft и Khronos. Но как они влияют на игры?

Эти два API значительно улучшили производительность. До сих пор DirectX, по-видимому, обеспечивал лучшую производительность, чем Vulcan, что на самом деле он не так далеко позади.

Microsoft утверждает, что DirectX 12 снижает потребление на 50% при использовании DirectX 11. С другой стороны, Vulkan также демонстрирует лучшую гибкость, чем его предшественник. Говоря о предшественниках, DirectX 11 и OpenGL были созданы с учетом одноядерных процессоров; что означает, что они не были точно настроены с использованием новых, многоядерных процессоров.

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

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

Поддержка нескольких графических карт

Здесь Khronos Group столкнулась со значительным разрывом между двумя API-интерфейсами с поддержкой использования нескольких графических карт (использование явного многоканального GPU). Мы можем использовать разные карты, если их чипы имеют аналогичную архитектуру и используют один и тот же драйвер. Это позволит различным картам обрабатывать другую часть экрана.

Microsoft здесь еще на один шаг впереди, позволяя использовать несколько графических карт даже у другого производителя, что часто бывает, поскольку большинство систем имеют независимый и интегрированный графический процессор. Важно подчеркнуть тот факт, что эти реализации отличаются от возможностей SLI и Crossfire от Nvidia и AMD, которые реализованы с помощью драйверов, и в частности, в случае SLI требуют идентичные графические карты.

Шейдеры

Шейдеры — это небольшие программы, которые запускаются на наших видеокартах. Они отвечают за определенные функции различных объектов в 3D-среде. Тени, туман и освещение в игре являются результатом шейдера.

Vulkan использует промежуточное представление для шейдеров под названием SPIR-V. Его двоичная форма похожа на байт-код DirectX DX.

SPIR-V версия 1.3 отличается SPIR-V opt, инструментом для уменьшения размера шейдеров. Максимальный размер достигает + 40% от байт-кода DX соответствующего представления для DirectX.

Кроме того, некоторые структуры в HLSL (высокоуровневый шейдерный язык), которые были разработаны Microsoft, не поддерживались непосредственно некоторыми видеокартами.

HLSL широко используется DirectX с версии 9. Он использовался в качестве дополнения к существующему языку ассемблера шейдеров. С новой версией SPIR-V Vulkan также поддерживает ее.

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

Совместимость с несколькими платформами

Что касается платформ, большое преимущество Vulkan заключается в том, что он поддерживает Windows, Linux, Mac OS, Android и iOS. DirectX 12 с другой стороны, поддерживается только в Windows 10 и Xbox One. Чтобы использовать усовершенствования, предлагаемые DirectX 12, нам нужно либо обновить нашу операционную систему до Windows 10, либо получить новую консоль компании.

Если вы хотите попробовать DirectX 12, и вам не удалось получить Windows 10 во время бесплатного обновления, ознакомьтесь с нашим пошаговым руководством по свободным методам модернизации, которые доступны:

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

С одной стороны, мы можем иметь названия на нескольких платформах, а с другой разные операционные системы имеют возможность размещать наши игры. Одна из причин, почему Linux не так популярен, как Windows, связана с тем, что последняя отличается от игр.

Распределение Linux может быть лучшим выбором для размещения наших игр, поскольку он может быть скорректирован для этой цели. Например Steam OS — это специализированная операционная система, предназначенная исключительно для игр.

Также подумайте: компания думает о создании программного обеспечения для разработки игр и хочет поддерживать API. Кто бы вы выбрали?

Оба имеют схожие мощности оба лучшие, чем их предшественники, и оба обеспечивают явное использование видеокарт. Vulkan поддерживает все платформы, включая Windows 10 и Xbox One, в то время как DirectX поддерживает только последние две.

Виртуальная реальность

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

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

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

Развитие и будущее

Было бы упущением, не говоря уже о ходе разработки двух API. С одной стороны, у нас есть ветеран DirectX с более чем 20-летним развитием. С другой стороны, Вулкану едва будет 3 года с 2015 года. Тот факт, что Vulkan является открытым исходным кодом, может немного повлиять на его темпы роста. Конечно игроки Khronos, похоже серьезно относятся к разработке API, так как уровни улучшения впечатляют.

Все мы можем создавать новые инструменты и модификации и предоставлять их сообществу, помогая API расти быстрее. Наконец следует упомянуть, что DirectX не имеет вышеуказанной функции. Несмотря на свои годы развития, около 40 игр в настоящее время используют Vulkan, занимая большую часть рынка. Некоторые из них — Quake, Roblox, Talos и Dota 2. Что касается производительности, Vulkan приближается к DirectX, и в некоторых случаях он превосходит его. Самые захватывающие примеры работы Вулкана — игра Doom.

Vulkan расширил свою поддержку названий AAA, таких как Wolfenstein II, не пренебрегая названиями VR, такими как Doom VFR и Serious Sam VR. Здесь вы можете увидеть подробный список поддерживаемых игр. Хотя здесь вы найдете игры с поддержкой DirectX 12.

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

Как вы относитесь к двум API?

Вы уже узнали всю информацию, которую мы предоставили на Vulkan и DirectX? Со временем их соперничество усиливается, какой из двух API вы считаете более полезным для развития игры? Мы с нетерпением ждем ваших комментариев.

Источник

Valve: DirectX 12 не имеет смысла для разработчиков игр, выбирайте Vulkan!

Интерфейс прикладного программирования (application programming interface, API) DirectX 12 обещает существенно увеличить производительность видеоигр в операционной системе Windows 10 благодаря более эффективному использованию современного оборудования по сравнению с предшественниками. Тем не менее, Valve Software считает, что нет смысла использовать DirectX 12, когда на подходе кросс-платформенный API Vulkan.

Все современные интерфейсы программирования приложений, используемые при создании видео игр — Apple Metal, Microsoft DirectX 12 и Vulkan, разрабатываемый Khronos Group — считаются низкоуровневыми API и обладают в целом аналогичными возможностями. Все три API эффективно используют современные многоядерные процессоры (в частности, обрабатывают большее количество запросов на отрисовку, чем интерфейсы предыдущих поколений), позволяют использовать графические процессоры для вычислений общего назначения, позволяют получить низкоуровневый доступ к ресурсам GPU (в том числе прямой доступ к памяти GPU), снижают значение драйвера графической карты для производительности в играх и т. д. Все три API совместимы с широким спектром аппаратного обеспечения, разработанного разными производителями.

Valve: Есть не так много причин, чтобы вообще использовать DX12 для вашей игры

Поскольку все три интерфейса программирования приложений созданы с разными целями, они имеют ряд отличий. Apple Metal совместим исключительно с Apple OS X и Apple iOS, а также рассчитан на работу с аппаратным обеспечением, применяемым Apple. Microsoft DirectX 12 совместим c огромным количеством графических процессоров разных разработчиков, но при этом исключительно с операционной системой Windows 10. В то же время Vulkan, который имеет много общего с AMD Mantle, но разрабатывается усилиями Khronos Group, совместим со всем спектром программного и аппаратного обеспечения, включая операционные системы Google (будущие версии Android) и Microsoft (Windows 7/8/10). Таким образом, Vulkan предпочтительнее для тех разработчиков программного обеспечения, которые хотят, чтобы их приложения работали на самых разных типах устройств.

«Если только вы не столь агрессивны, что планируете начать поставки игры на DirectX 12 в этом году, я бы сказал, что на самом деле есть не так много причин, чтобы вообще использовать DX12 для вашей игры», — сказал Дэн Гинзбург (Dan Ginsburg), разработчик программного обеспечения из Valve, на индустриальной конференции. «Причина этого в том, что Vulkan охватит и Windows 10, и другие платформы, а также аппаратное обеспечение. […] Мы планируем поддержать Vulkan не только на Windows 10, но и на Windows 7, Windows 8 и Linux».

Vulkan: от автомобиля до сервера

Для Valve, которая занимается разработкой своей собственной Steam OS для игровых ПК для гостиных (которые компания называет Steam Machines), использование DirectX 12 действительно имеет малый смысл. Учитывая, что Steam OS базируется на Linux, концентрация на Vulkan крайне логична для компании.

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

Так, DirectX 12 поддерживается коммерческой ОС, игровой консолью Xbox One, разработчиками нескольких GPU (AMD, Intel, NVIDIA, Qualcomm) c готовыми драйверами, а также имеет ряд преимуществ в области поддержки многочиповых (multi-GPU) графических подсистем. Кроме того, DirectX 12 готов.

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

Как результат, многим создателями программного обеспечения, которые планируют выпускать свои продукты в ближайшие 9–12 месяцев, просто придётся использовать Microsoft DirectX 12, если они хотят запускать свои приложения на Windows.

Источник

id Software объяснила, почему выбрала Vulkan вместо DirectX 12

На прошлой неделе шутер DOOM научился работать с Vulkan — интерфейсом, сходным по своим функциям с DirectX 12. В связи с этим у многих, особенно у тех, кто случайно обновился до Windows 10 и теперь утешает себя мыслями о возможности играть в полтора проекта с DirectX 12, возник вопрос — почему именно Vulkan, а не закрытый аналог от Microsoft?

Вопрос, как вы прекрасно понимаете, риторический, но студия id Software всё же решила дать на него официальный ответ.

По словам представителей студии Тиаго Сусы и Акселя Гнитинга, концептуально DirectX 12 и Vulkan очень похожи и они оба многое унаследовали от AMD Mantle. Однако главная проблема DirectX 12 — в его ограничениях. Данный API работает только на Windows 10, а ребята из id хотели достичь максимального охвата аудитории при сходной функциональности. Вот выбор и пал на Vulkan. Кроме того, по словам представителей студии, у Vulkan есть механизм расширения, который позволяет разработчикам тесно сотрудничать с крупнейшими производителями «железа» для конкретных оптимизаций.

А ведь где-то в параллельной вселенной все здравомыслящие разработчики поступают также — выбирают Vulkan, а не резервацию. Жаль, что эта чудная вселенная — не наша. Впрочем, поживём — увидим.

Источник

Сравнение быстродействия видеокарт в DirectX 11, DirectX 12 и Vulkan, часть 1

Интерфейсы прикладного программирования (API) долгое время оставались самым консервативным компонентом 3D-графики. Стандарт Direct3D 11 был представлен еще в 2008 году, и до сих пор основная масса новых игр на ПК использует его в качестве основного и в подавляющем большинстве случаев единственного API. Этот островок стабильности в чрезвычайно быстро развивающейся индустрии, какой являются компьютерные игры, образовался отнюдь не из-за традиционализма разработчиков ПО или производителей железа. Напротив, единый стандарт Microsoft, который вытеснил из большой игры некогда могущественного соперника (OpenGL), дал возможность всем участникам рынка сконцентрировать усилия на своих прямых задачах без необходимости оптимизировать драйверы, архитектуру GPU и игровые движки под несколько API одновременно (как в былинные времена под Glide и популярный OpenGL).

Недавние потрясения в этой сфере, связанные с названиями DirectX 12 и Vulkan, вызваны, по сути, усилиями единственной компании — AMD, которая в 2013 году выпустила собственный интерфейс программирования Mantle в сотрудничестве с DICE, автором игровой серии Battlefield. В данный момент работа над Mantle прекращена, но оба универсальных API нового поколения заимствовали идеи AMD и преследуют ту же цель — более эффективно использовать вычислительные ресурсы, которые имеются в распоряжении современных GPU.

Несмотря на столь привлекательную идею Direct3D 12 (здесь и далее мы будем говорить именно о графической библиотеке в составе DirectX) и Vulkan, темп внедрения новых API оставляет желать лучшего даже по сравнению с Direct3D 11, которому потребовался чрезвычайно долгий срок, чтобы целиком переманить разработчиков с Direct3D 9. И все же создатели значительного числа громких и высокобюджетных проектов последних двух лет внедрили поддержку Direct3D 12 или Vulkan по крайней мере в виде экспериментальной или побочной функции. В конце концов, методика тестирования GPU на 3DNews уже по большей части состоит из игр с поддержкой этих API. Подходящее время для того, чтобы провести исследование и сделать промежуточные выводы о том, насколько в действительности полезны DirectX 12 и Vulkan для производительности современного железа.

⇡#Новые функции Direct3D 12 и Vulkan

О принципах, лежащих в основе Direct3D 12, и его отличиях от предыдущей версии API Microsoft, мы писали в 2014 году, когда стандарт находился на ранней стадии разработки и многие из его особенностей еще не были финализированы. Главное, что изменилось в облике Direct3D 12 с тех пор, — это набор дополнительных функций рендеринга, открытых для графических процессоров с теми или иными аппаратными возможностями.

Оставим за кадром строение конвейера рендеринга и некоторые особенности программирования под Direct3D 12, которые описаны в нашей давнишней статье. Есть лишь несколько отличительных черт нового API, которые должны волновать широкую публику. Начнем обзор с универсально значимых пунктов и закончим той самой функцией Direct3D 12 (и Vulkan), которая породила много споров, непонимания и завышенных ожиданий на страницах публикаций и форумов, — асинхронными вычислениями.

Самой привлекательной чертой Direct3D 12 и Vulkan является быстрая подготовка т. н. draw call. В то время, когда AMD стремилась популяризировать Mantle, множество людей, ранее далеких от программирования компьютерной графики, были вынуждены познакомиться с этим термином. В 3D-рендеринге так называется команда, требующая создать единственную полигональную сетку (mesh). В играх каждая модель персонажа, юнита и практически любого независимого объекта представляет собой mesh. Следовательно, чем больше таких объектов присутствует на экране, тем больше draw calls должен отдать центральный процессор. Короткая подготовка draw call в Direct3D 12 при прочих равных условиях снижает нагрузку на CPU, сокращает время бездействия графического процессора и в результате дает возможность выводить больше объектов на экран. Помогает и распределение нагрузки в многоядерной системе, которое в Direct3D 12 происходит более эффективно.

Многоядерные CPU в Direct3D 12

В целом прослойка API в стеке ПО, управляющем графическим процессором, стала тоньше по сравнению с Direct3D 11 за счет того, что многие функции, которые в Direct3D 11 выполняются в той или иной степени автоматически (такие как управление памятью, синхронизация между очередями инструкций, поддержание параллелизма нагрузки на GPU и пр.), теперь полностью принадлежат игровому движку. С одной стороны, открываются широкие возможности для оптимизации быстродействия, но с другой — программист должен иметь в виду особенности архитектуры различных GPU, чтобы избежать падения производительности.

Direct3D 12 принес массу функций рендеринга, описанных в рамках feature levels 12_0 и 12_1. Но в отличие от предыдущих итераций Direct3D, 12-я версия предназначена не для того, чтобы явить миру нечто ранее невиданное (как это было с шейдерами в Direct3D 8 и тесселяцией полигонов в Direct3D 11). Действительно, некоторые возможности feature levels 12_0 и 12_1 повышают качество определенных эффектов (к примеру, связанных с прозрачными текстурами), а иные используются в перспективных алгоритмах рендеринга (см. описание VXGI в нашем обзоре GeForce GTX 980). И все же большинство пунктов feature levels 12_0 и 12_1 служит для того, чтобы графический процессор выполнял быстрее ряд уже известных задач, которые в противном случае создают большую нагрузку на пропускную способность блоков наложения текстур, шину памяти и пр.

В принципе, дополнительная вычислительная мощность, которую высвобождает новая версия API, сама по себе позволяет обогатить игровую графику более детализированными текстурами и объектами. Более того, в некоторых играх под Direct3D 12 и Vulkan геймплей тесно связан с выбором API (как в Ashes of the Singularity, которая за счет множества юнитов на экране создает огромное количество draw calls). Но если поставить вопрос в формулировке «Станет ли игра выглядеть лучше, если включить в ней Direct3D 12 или Vulkan?», то на данный момент ответ будет в подавляющем большинстве случаев отрицательным. Масштаб внедрения новых API все еще слишком мал, а железо на руках пользователей слишком разнообразно, чтобы разработчики игр открыли для видеокарт, хорошо работающих под Ditect3D 12 и Vulkan, эксклюзивный доступ к заметной части визуального контента.

Поддержка функций рендеринга Direct3D 12 в GPU различной архитектуры (Wikipedia)

По минимальным требованиям стандарта в категорию GPU, совместимых с feature level 12_1, проходят только архитектуры Vega, Maxwell и Pascal (а также интегрированная графика Intel, начиная с процессоров Skylake), а наиболее полной поддержкой обладает Vega и Intel HD Graphics. Но и другие архитектуры AMD или NVIDIA на том или ином уровне поддерживают ряд функций из feature level 12_0 и 12_1, в том числе одни из самых полезных: Conservative Rasterization, Volume Tiled Resources и Rasterizer Ordered Views.

При этом от графического процессора не требуется совместимость с feature level 12_0 и 12_1 для работы под Direct3D 12. В действительности GPU с возможностями на уровне feature level 11_0 и 11_1, созданные в ту пору, когда Direct3D 12 не было и в помине (архитектуры Femi и Kepler от NVIDIA и GCN первого поколения от AMD), могут воспользоваться всеми преимуществами runtime-библиотеки Direct3D 12 и, потенциально, получить выигрыш в быстродействии. У AMD и NVIDIA поддержка Direct3D 12 в драйвере начинается с серий Radeon HD 7000 и GeForce GTX 400 соответственно.

⇡#Асинхронные вычисления в Direct3D 11 и Direct3D 12

Современные GPU лишь в силу привычки называются графическими процессорами. Архитектура, состоящая из большого количества исполнительных блоков (ALU, потоковых процессоров или CUDA-ядер, в терминологии различных производителей), подходит для исполнения любых программ, легко разделяющихся на независимые друг от друга цепочки операций (GP-GPU, General Purpose GPU) — будь то промышленные задачи, майнинг криптовалюты, машинное обучение и т. д.

Методы GP-GPU применяются и в играх (по меньшей мере с того времени, когда NVIDIA купила компанию — создателя «физического ускорителя» Ageia и адаптировала ее API PhysX для работы на графических процессорах), но ни одна из коммерческих игр еще не может похвастаться тем, что раскрыла потенциал неграфических расчетов в такой степени, как «демки» PhysX, которые периодически демонстрирует NVIDIA. Причина лежит на поверхности: даже лучшие GPU не обладают избытком ресурсов для того, чтобы действительно масштабные вычисления игровой физики не уничтожили частоту смены кадров. Тем более в то время, как перед разработчиками ПО и железа открылись более заманчивые перспективы — разрешение сверхвысокой четкости и VR.

Однако актуальные и потенциальные функции вычислений общего назначения в современных играх не ограничиваются физикой. SSAO (Screen-Space Ambient Occlusion), локальные отражения в экранном пространстве (Screen-Space Reflections), генерация карт теней, различные модели глобального освещения и пр. могут быть реализованы в качестве методов GP-GPU. Нетрудно заметить, что в данном случае отсутствует принципиальная граница между задачами двух типов. Она существует лишь на уровне архитектуры приложения и API, когда графика и вычисления представляют собой отдельные очереди инструкций. Именно одновременное исполнение множественных очередей инструкций лежит в основе того, что называют (не вполне корректно, но об этом позже) асинхронными вычислениями.

В рамках Direct3D 11 существует единственная очередь инструкций для рендеринга графики. И как бы тщательно ни была оптимизирована архитектура GPU, в процессе рендеринга неизбежно возникают «пузыри», когда шейдерные ALU простаивают, в то время как свою работу выполняют другие компоненты процессора — блоки наложения текстур, ROP, шина памяти и т. д.

В свою очередь, Direct3D 12 и Vulkan позволяют создать две отдельные очереди — для графики и вычислений соответственно (не считая очереди для передачи данных по шине PCI Express), а задача распределения ресурсов GPU между ними ложится на сам процессор и его драйвер, которые следят за возникновением «пузырей» в той или иной очереди и эффективно их закрывают за счет инструкций из соседней очереди. В общих чертах подход аналогичен функции Hyper-Threading центральных процессоров.

Прим.: на самом деле в Direct3D 12 и Vulkan можно создавать множественные очереди всех трех типов — в зависимости от того, сколько поддерживает GPU.

Осталось пояснить, почему термин «асинхронность» не лучшим образом описывает то, что происходит в процессе рендеринга с двумя очередями инструкций, которые мы осторожно назвали отдельными, но не независимыми. Корректный (и официальный для Direct3D 12) термин — Multi-Engine. Дело в том, что те процедуры, которые исполняются в «графической» и «вычислительных» очередях Direct3D 12 или Vulkan, как правило, содержат взаимные зависимости данных: исполнение инструкций в одной очереди должно быть остановлено, пока не будет получен результат определенной инструкции из другой очереди.

В таком случае можно говорить лишь об одновременном (concurrent), но не асинхронном (независимом по времени завершения) исполнении. Примером истинной асинхронности является фоновый процесс с низким приоритетом, протекающий одновременно с рендерингом кадра, — такой, как декомпрессия ресурсов, обновление карт теней в моделях глобального освещения и пр. (см. слайд AMD выше). Таким образом, термин «асинхронные вычисления» применим к узкому кругу задач, в то время как понятие Multi-Engine описывает одновременное исполнение нескольких очередей вычислительных инструкций безотносительно к структуре зависимостей между ними.

«Асинхронные вычисления» не всегда асинхронны

⇡#Multi-Engine на GPU различной архитектуры: AMD GCN

Рассмотрим животрепещущий вопрос практической реализации Multi-Engine. Популярное мнение гласит, что а) графические процессоры AMD выигрывают от применения Multi-Engine, в то время как чипы NVIDIA (включая Pascal) не могут столь же эффективно использовать его в силу архитектурных ограничений, б) среди архитектур NVIDIA только Pascal поддерживает Multi-Engine. Как нам предстоит убедиться, оба утверждения в целом верны, но полная картина далеко не столь однозначна.

Самый простой для анализа случай — это архитектура GCN (Graphics Core Next), на которой основаны все графические процессоры AMD последних лет, начиная с Tahiti (Radeon HD 7950/7970) и заканчивая Vega 10 (Radeon RX Vega 56/64). Как достоинства, так и недостатки чипов AMD в действительности располагают к применению Multi-Engine. GCN в своей основе ориентирована на вычисления GP-GPU в не меньшей степени, чем на рендеринг графики, и устроена таким образом, что добрая часть задачи насыщения GPU параллелизмом решается на уровне «железа», а не драйвера или приложения. Даже самые ранние чипы GCN обеспечивают одновременное исполнение нескольких очередей «вычислительных» команд одновременно с очередью рендеринга графики за счет командных процессоров двух типов — GCP (Graphics Command Processor) и ACE (Advanced Compute Engine). А начиная с третьего поколения архитектуры (чипы Tonga и Fiji), GCN также включает раздельные планировщики для шейдерных и «вычислительных» инструкций. В результате процессор может динамически передавать вычислительные ресурсы отдельных CU (Compute Unit — блок, содержащий 64 ALU) между несколькими очередями инструкций.

Кроме того, GCN допускает сравнительно безболезненную смену контекста CU. Смена контекста в данном случае означает, что CU, находящийся в ожидании данных от длительной операции, которой занимаются другие блоки GPU, получает от командного процессора другую работу, сохранив содержимое своих регистров в каком-либо внешнем хранилище. В GCN этим хранилищем является высокоскоростной интегрированный кеш, и процессор может пользоваться сменой контекста весьма свободно.

Таким образом, управляющая логика GCN способна эффективно загружать исполнительные блоки GPU за счет инструкций из отдельных очередей, заполняя даже сравнительно небольшие «пузыри» конвейера. Итоговый прирост быстродействия зависит от того, насколько часто «пузыри» возникают в режиме одной очереди. Но ведь правда, графические процессоры AMD существенно недогружены в большинстве игр по сравнению с чипами NVIDIA, и с каждым новым поколением ситуация усугубляется. Достаточно взглянуть на Radeon RX Vega 64, которая в задачах GP-GPU по меньшей мере не уступает GeForce GTX 1080 Ti, но в играх едва справляется с GeForce GTX 1080. GCN — «широкая» архитектура, требующая высокого параллелизма для полной нагрузки. Поэтому да, возможности Multi-Engine, которые открывают современные API, могут стать большим подспорьем для AMD — с большой оговоркой о том, что разработчики игр начнут их активно использовать.

Multi-Engine на GPU различной архитектуры: NVIDIA Kepler, Maxwell и Pascal

Ситуация с поддержкой Multi-Engine в графических процессорах NVIDIA далеко не столь прозрачна, как в случае с AMD. Материалы NVIDIA, находящиеся в широком доступе, не дают ясного ответа на все вопросы. С полной уверенностью можно говорить лишь о том, каким именно из GPU архитектур Kepler, Maxwell и Pascal вообще разрешено иметь дело со смешанной нагрузкой (графика/вычисления) под управлением Direct3D 12 и Vulkan. А наше представление о том, почему это так, а не иначе, основано по большей части на сторонних источниках и не претендует на истину в последней инстанции. Что поделать, такова политика этой компании, особенно когда речь идет о недостатках их продуктов.

В отличие от AMD, NVIDIA решила разделить свои GPU на преимущественно потребительские либо профессиональные модели, начиная с архитектуры Kepler. Первые изначально лишены массы вычислительных функций, бесполезных в игровых задачах (таких как быстрое исполнение расчетов двойной точности). Кроме того, на пути от архитектуры Fermi (GeForce 400/500) к Kepler, а затем Maxwell разработчики последовательно сокращали управляющую логику GPU, переложив часть функций на драйвер.

Тем не менее поддержка смешанной нагрузки даже в массовых чипах NVIDIA значительно расширилась со времен Kepler. «Мелкие» чипы архитектуры Kepler (GK10X, GeForce GTX 680 и ниже, а также GeForce GTX 770) способны работать с единственной очередью команд, будь то графика или чисто вычислительная задача (ни о каком Multi-Engine речи не идет). В «большом» Кеплере (GK110/210, GeForce GTX 780/780 Ti и GeForce GTX TITAN) и чипах Maxwell первого поколения (GK107, GeForce GTX 750/750 Ti) внедрили отдельный блок для приема «вычислительных» очередей Hyper-Q, но отдельная «вычислительная» нагрузка одновременно с графикой возможна только под проприетарным API CUDA. Кроме того, «вычислительная» очередь может задействовать один и только один из 32 слотов блока CWD (CUDA Work Distributor), распределяющего цепочки операций между отдельными SM.

Динамическое распределение мощностей между графической и «вычислительной» очередями появилось только в Maxwell второго поколения (серия GeForce 900), но существует критически важное ограничение: перераспределение происходит лишь на границе draw call, а значит, драйверу нужно выделить необходимую для той или иной задачи группу SM (Streaming Multiprocessor, блок, в который организованы CUDA-ядра) заранее. Отсюда возникают ошибки планирования, которые невозможно устранить на лету, и даже при идеальном предсказании эвристики драйвера Maxwell будет пропускать мелкие «пузыри» конвейера. Кроме того, Maxwell несет тяжелые потери от смены контекста, т. к. промежуточные результаты вычислений сохраняются в (обладающей сравнительно высокой латентностью) оперативной памяти, при этом происходит полная очистка кеша L1 и разделяемой памяти GPU. В таких условиях быстродействию не настолько сильно вредит достаточно короткий простой отдельных SM, как смена контекста.

Похоже, именно эти архитектурные ограничения побудили NVIDIA заблокировать Multi-Engine в драйвере для Kepler и Maxwell. Приложение может создать сколько угодно «вычислительных» очередей, но драйвер все равно объединит их с графической очередью. По-прежнему единственная лазейка для разработчиков — это использовать CUDA, хотя на ситуацию с распределением ресурсов и смену контекста API никак не влияет.

Среди «зеленых» GPU только семейство Pascal допущено к функции Multi-Engine в Direct3D 12 и Vulkan, ибо Pascal, в отличие от Maxwell, умеет передавать ресурсы SM между очередями графики и «вычислений» динамически, не дожидаясь завершения draw call. При этом цена смены контекста осталась высокой (вплоть до 0,1 мс или 170 тыс. циклов GPU в случае GeForce GTX 1070/1080!), а значит, Pascal по-прежнему ограничен в гибкости при работе с несколькими очередями команд по сравнению с GCN.

В итоге NVIDIA довольно сильно усложнила жизнь разработчикам приложений, желающим использовать Multi-Engine. GCN неприхотлива и предсказуема в плане смешанной нагрузки, но ускорители Radeon на рынке в меньшинстве. С другой стороны, видеокарты с графическими процессорами NVIDIA стоят во множестве игровых ПК и вдобавок принадлежат к нескольким поколениям с различным уровнем поддержки Multi-Engine и методами его использования. Но, к счастью для NVIDIA, ее продукты и без того не испытывают недостатка в быстродействии. Чипы Maxwell и Pascal в сравнении с процессорами GCN соответствующего класса имеют более «узкую» архитектуру с меньшим числом шейдерных ALU, а значит — не требуют столь же высокого параллелизма для полной загрузки.

Графика + вычисления, макс. N очередей	Вычисления, макс. N очередей	Распределение CU/SM в смешанном режиме
AMD GCN 1.4 (Vega)	1 +		Динамическое
AMD GCN 1.3 (Polaris)	1 +		Динамическое
AMD GCN 1.2 (Tonga, Fiji)	1 +		Динамическое
AMD GCN 1.1 (Hawaii)	1 + 64	64	Динамическое
AMD GCN 1.1 (Bonaire)	1 + 16	16	Динамическое
AMD GCN 1.0 (Cape Verde, Bonaire, Pitcair, Tahiti)	1 + 8	2	Динамическое
NVIDIA Pascal (GP10X)	1 + 31	32	Динамическое
NVIDIA Maxwell 2 (GM20X)	1 + 31 (CUDA)	32	Статическое
NVIDIA Maxwell 1 (GM107)	1 + 31 (CUDA)	32	Статическое
NVIDIA Kepler (GK110)	1 + 31 (CUDA)	32	Статическое
NVIDIA Kepler (GK10X)	1	1	—

⇡#От теории — к практике

Мы долго говорили об особенностях API нового поколения и готовы перейти к бенчмаркам, но сначала придется признать: все сказанное в теоретической части не получится напрямую связать с цифрами. Поддержка Direct3D 12 или Vulkan в какой-либо игре еще не значит, что ее движок задействует ту или иную из новых функций, а главное, нам неизвестно, насколько широко и эффективно она используется. Также не будем забывать, что Direct3D 12 и Vulkan являются сравнительно низкоуровневыми API, и задача оптимизации быстродействия под GPU различной архитектуры лежит на плечах разработчиков движка (некоторые из которых прямо сообщают, что поддержка Direct3D — экспериментальная опция и ожидать чудес не стоит). Эти переменные останутся скрыты от глаз исследователя без полноценного профайлинга приложений — задачи, которая выходит далеко за рамки данного обзора. Как бы то ни было, результаты тестирования дают представление о быстродействии видеокарт в API нового поколения на данный момент — вне зависимости от того, как могла бы сложиться идеальная картина.

⇡#Тестовый стенд, методика тестирования

В тестовую обойму вошли семь игр 2016–2017 годов выпуска, среди которых шесть поддерживают API Direct3D 12, а две — Vulkan. Доподлинно известно, что все они так или иначе задействуют функцию Multi-Engine («асинхронные вычисления»). И пара слов об отдельных играх.

Тесты выполнены при разрешениях 1080p, 1440p и 2160p. Настройки выбраны таким образом, чтобы обеспечить высокую частоту смены кадров (от 60 FPS и выше в режиме 1080p) на мощных GPU последнего поколения и приемлемую частоту (от 30 FPS в 1080p) на ускорителях среднего уровня, что соответствует реальным сценариями использования. Для слабых видеокарт (Radeon RX 560 и GeForce GTX 1050 Ti) выбраны иные, более щадящие параметры качества графики в ряде игр.

При таких настройках мы едва ли сможем в полной мере оценить экономию ресурсов CPU на подготовке draw call, которую обеспечивает Direct3D и Vulkan. Испытания API Mantle в свое время показали, что максимальный рост быстродействия возникает в несбалансированных конфигурациях (мощный GPU и двухъядерный центральный процессор) либо при кадровой частоте свыше 100 FPS. Тестирование на платформе со сниженным числом ядер и частотой CPU будет представлено во второй части статьи.

Для тестирования были избраны пять видеокарт на базе GPU каждого производителя в диапазоне архитектур от GCN 1.1 (Radeon R9 390X) до GCN 1.4 (Radeon RX Vega 64) и от Kepler (GeForce GTX 780 Ti) до Pascal (GeForce GTX 1080 Ti) соответственно.

⇡#AMD Radeon R9 390X

⇡# AMD Radeon R9 Fury X

⇡# AMD Radeon RX 560

⇡#AMD Radeon RX 580

⇡# AMD Radeon RX Vega 64

⇡#NVIDIA GeForce GTX 780 Ti

⇡#NVIDIA GeForce GTX 980 Ti

⇡#NVIDIA GeForce GTX 1050 Ti

⇡#NVIDIA GeForce GTX 1060

⇡#NVIDIA GeForce GTX 1080 Ti

⇡#Общие результаты

В таблицах ниже сведены данные об изменении производительности видеокарт при смене API с Direct3D 11 на Direct3D 12 или Vulkan.

⇡#Выводы

Усредненные результаты сравнения API, приведенные в таблицах выше, пусть и позволяют уловить определенные тенденции, но в действительности несут мало полезной информации, потому что игры ведут себя по-разному на различных платформах. При этом в большинстве случаев средний «процент» видеокарты задает одна или две игры, а остальные бенчмарки оказались индифферентны к смене API в практическом масштабе. Вопрос «Как API нового поколения влияют на быстродействие» не имеет общего ответа, и это совершенно предсказуемо. Слишком велика разница в архитектуре современных графических процессоров, а вместе с ней — полнота и качество поддержки Direct3D 12 и Vulkan в игровых движках. Сочетание каждой игры и каждого GPU — это уникальный случай, в котором смена API может как значительно увеличить, так и, в худшем случае, просто уничтожить быстродействие.

И все-таки даже по имеющимся данным можно выделить, с одной стороны, несколько видеокарт, которые подают воодушевляющий пример в новых интерфейсах программирования, а с другой стороны — те GPU, которым Direct3D 12 и Vulkan не приносит никакой пользы или и вовсе вредит.

Начнем с «неудачников». Для GeForce GTX 780 Ti тесты в API нового поколения обернулись полной катастрофой. Мало того, что некоторые игры официально не поддерживают Direct3D 12 на архитектуре Kepler или просто не запускаются, нет ни единой игры, в которой эта видеокарта не теряет производительность (при высоких разрешениях — вплоть до уровня слайд-шоу). Отчасти виновато эксплицитное управление памятью в Direct3D 12: программисты поленились оптимизировать движок под видеокарты с 3 Гбайт RAM. Но и GeForce GTX 980 Ti, несмотря на 6 Гбайт памяти, выступил не сильно лучше. В большинстве тестов быстродействие флагманского Maxwell снижается в Direct3D 12 и Vulkan (особенно велики потери в Battlefield 1). Прирост, и весьма существенный, есть только в DOOM.

Ускорители Pascal бюджетного и среднего уровня (GeForce GTX 1050 Ti и GTX 1060) также выигрывают от API нового поколения в DOOM. Результаты остальных тестов по большей части умеренно отрицательные. На этом фоне достижение GeForce GTX 1080 Ti уже в том, что он перестал терять быстродействие в ряде тестов под Direct3D 12 и Vulkan, а кое-где приобрел дополнительные FPS.

Положение видеокарт AMD, как и предсказано теорией, в целом благоприятно. Главные выгодополучатели новых API — большие чипы Hawaii (Radeon R9 390X), Fiji (Radeon R9 Fury X) и Vega (Radeon RX Vega 64), а лучшие игры для них — Ashes of the Singularity и, конечно же, DOOM. Остальные тесты обернулись незначительным ростом или падением FPS. Кроме того, Radeon R9 Fury X страдает в высоких разрешениях (см. эксплицитное управление памятью) и при любых режимах — в Battlefield 1. Несколько обескураживают результаты чипов Polaris (Radeon RX 560 и RX 580), ведь к ним в новых API благосклонен только DOOM. Direct3D 12 в Battlefield 1 однозначно вредит, а в остальных тестах «состояние пациента стабильно».

Какие общие выводы можно сделать из такой сложной картины? Во-первых, придется забыть о комбинации Direct3D 12 и чипов NVIDIA поколений Kepler и Maxwell (и тем более Fermi), а также видеокарт с небольшим объемом памяти. Никто больше не будет оптимизировать ПО под такое железо. Что касается процессоров Pascal, то им Direct3D 12 и Vulkan в целом не помогают, зато и не вредят (что и требовалось доказать). Наилучшие перспективы — у больших GPU AMD с подходящим объемом видеоОЗУ. Однако рано подводить черту: впереди еще одно тестирование на платформе со слабым CPU.

Источник