Что лучше vulkan или directx 11

Обновлено: 25.01.2025

Мы провели небольшой тест на производительность Vulkan в Dota 2, а именно сравнили значения FPS с данным API и без него. Результат окажется ожидаемым для многих, поскольку изменения вышли практически незаметными.

После появления Vulkan в Dota 2 мы конечно же не могли это пройти стороной и решили проверить, есть ли вообще хоть какая-то польза от него. Тесты проводились на разном «железе» и можно заявить, что серьезных изменений от появления данного API попросту нет. Возможно, в дальнейшем все начнет работать лучше, но на данный момент нет особого смысла качать DLC и играть с Vulkan.

Все настройки видео в Dota 2 на максимальных показателях, каждый скриншот кликабелен.

Процессор: AMD Phenom II X3 Black Edition 720, 2800 MHz
Видеокарта: Gigabyte GTX 950 2 Gb

Разница, все показатели в FPS

Процессор: Intel® Core™ i7-4790 Processor (8M Cache, up to 4.00 GHz)
Видеокарта: GeForce GTX 970

Разница, все показатели в FPS

Процессор: Intel® Core™ i3-3220 Processor (3M Cache, 3.30 GHz)
Видеокарта: GeForce GT 640

Разница, все показатели в FPS

Если кто-то еще не знает как установить DLC, то вот инструкция в несколько простых шагов:

Нажать ПКМ по Dota 2 в Библиотеке и выбрать пункт "Дополнительный контент"
Поставить галочку напротив Dota 2 - Support Vulkan, загрузка начнется сама
В параметрах запуска прописать -vulkan
Image not found
Если имеются данные настройки dx9/-dx11/-gl, то их нужно удалить и нажать "Ок"
Минимальные требования
Windows 7/8/10 64-bit: NVIDIA 600+ (365.18+ драйвера), AMD 7700+ (Crimson 16.5.2.1+ драйвера)
Linux 64-bit: NVIDIA 600+ (364.16+ драйвера), AMD GCN 1.2 (16.20.3 драйвера)
Память GPU не менее 2 ГБ

Следите за новостями у нас на сайте и в нашей группе Вконтакте!

ну не знаю как у вас там, но я поиграл одну катку с этим чудом. если меняешь местоположение камеры дикие лаги, иногда всё мерцает.
мб ктонить знает, как это исправвляется?

исправляется патчами которых еще нет

Мерцания исправили, а лаги: это просто создается кэш вулкана, у меня так дота вообще вылетала всю катку, потом вв последующих играх я заметил прирост (уже ниче не вылетало) всё красиво и плавненько!)

Ну незнаю, у меня с 60фпс до 75-100 поднялся. Заметно плавнее. Ноут Core i7-3630QM, NVIDIA GeForce GT 650M, 8гб оперативы.

А да, кстати. На самых последних дровах от нвидии(368.22) фризило с вулканом. Откатил как было (365.19) всё круто. У кого на нвидии стало хуже с вулканом попробуйте драйвера 365.19, может поможет.

Поставь настройки средние

1920х1080. Качество обработки на макс, высокое качество текстур и теней, вертикальная синхронизация.

сейчас бы мак версию никак не улучшать

Сейчас бы использовать мак для игр

Щас бы кучу денег на калькулятор потратить

то самое чуство, когда не видишь разницы в этих картинках, как и сравнительного теста АМD карты.

и без вулкана норм

Ничем не удивило)

смотришь на сравнения и с вулканом тормозит . Опять же у кого мощный комп , устанавливать не обязательно

Ну вообще то вулка не должен дать производительность в этих моментах, что на фото, он с кучей частиц работает, в замесах и когда много крипов

Попробовал Vulkan API - мне понравилось. На Radeon HD 7850 1GB никаких вылетов и фризов не было.

Играю на максимальных настройках FHD с включенным Vsync, так что за разницу фпс сказать ничего не могу, да мне это и ненадо. На directx в принципе тоже было все замечательно ( 60 fps ) но после ввода реборна иногда фпс тупо рандомно падал до 40 и уже выше не поднимался пока не перезапустишь игру. На вулкане же все так же плавно как и на директиксе, плюс пропали вот эти самые внезапные спады фпс.

Еще проповал OpenGL но там как раз таки я и ощутил всю прелесть фризов и долгой загрузки карты. Так что в моем случае это новое API мне очень помогло.

Интерфейсы прикладного программирования (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, и его отличиях от предыдущей версии 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, эксклюзивный доступ к заметной части визуального контента.

Современные 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. Популярное мнение гласит, что а) графические процессоры 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, а значит — не требуют столь же высокого параллелизма для полной загрузки.

В рамках обновления 4.3 начнется тестирование первой PC-версии игры с поддержкой API Vulkan.

Игры — Games: PS4, PS5, PlayStation, PlayStation 4, PlayStation 5, PS VR, PS Vita, Xbox, Xbox One, Xbox Series X, Xb1, Nintendo, Nintendo Switch, NSW, Mobile, iOS, Android, Google Stadia, ПК, PC, Steam, Epic Games Store, Windows

Для использования API Vulkan в Rainbow Six Осада при запуске нажмите соответствующую кнопку. Вы сможете выбрать либо DirectX 11, либо Vulkan.

ПОЧЕМУ VULKAN

API Vulkan даст Rainbow Six Осада преимущества по сравнению с DirectX 11, что позволит улучшить функционал игры в нескольких аспектах.

Если вкратце, с Vulkan разработчики получат возможность применять динамическое индексирование текстур для снижения нагрузки на центральный процессор (далее — ЦП), а динамическую настройку разрешения и технологию Async Compute — для снижения нагрузки на графический процессор (далее — ГП). Эти функции уже используются на консолях, а с API Vulkan они появятся и на РС. Объединив их, мы сможем оптимизировать работу ЦП и ГП при прорисовке.

Для заинтересованных в технических деталях ниже приведена более подробная информация об этих функциях и эффекте, который они окажут на РС-версию. Для обеспечения корректной работы API Vulkan ознакомьтесь с разделом «ВАЖНАЯ ИНФОРМАЦИЯ».

VULKAN, DIRECTX 11 И API

Vulkan и DirectX 11 — графические программные интерфейсы приложения, или графические API. Они служат связующим звеном между Rainbow Six Осада (или любой другой игрой) и ГП.

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

И вот где имеет значение выбор API: подходящий интерфейс позволяет снизить нагрузку и повысить производительность. Некоторые API — например, Vulkan — эффективнее задействуют аппаратное обеспечение, и потому нагрузка на ЦП снижается. Иными словами, они несколько усложняют программисту процесс написания кода, но в то же время дают больше возможностей.

Сейчас в Rainbow Six Осада используется DirectX 11 — API, выпущенный более 10 лет назад. Он все еще позволяет добиться приличной производительности, но при этом графический драйвер серьезно нагружает ЦП. Более того, некоторые функции, поддерживаемые современными ГП, несовместимы со старыми API вроде DirectX 11. (Мы рассматривали вариант с DirectX 12, но по результатам внутренних тестов производительности ЦП отдали предпочтение Vulkan.)

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

ТЕСТИРОВАНИЕ VULKAN В RAINBOW SIX ОСАДА

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

Он будет внедрен уже в обновлении 4.3 для PC. Такой тест позволит оценить взаимодействие Vulkan с разнообразным аппаратным обеспечением, получить данные от более широкой аудитории и понять, осталась ли стабильность работы на том же уровне или даже выросла. Учтите, что процесс настройки Vulkan в Rainbow Six Осада еще продолжается, так что некоторые игроки могут не заметить изменений или даже наблюдать снижение производительности после запуска обновления. Наша задача — оптимизировать работу нового интерфейса, чтобы повысить эффективность обработки графики.

API Vulkan даст Rainbow Six Осада преимущества по сравнению с DirectX 11, что позволит повысить эффективность обработки графики. Более того, современный графический интерфейс поможет снизить нагрузку на ЦП и ГП, а также активировать дополнительные функции, которые в будущем откроют для разработчиков новые возможности. С обновлением 4.3 Vulkan подвергнут расширенному тестированию в РС-версии игры.

Не забудьте ОБНОВИТЬ ГРАФИЧЕСКИЕ ДРАЙВЕРЫ! Для лучших результатов: Nvidia — версия 441.87; AMD — версия 20.1.4; Intel — версия 26.20.100.7372.

ТЕХНИЧЕСКИЕ ДЕТАЛИ

API Vulkan создан для того, чтобы максимально приблизиться к аппаратному уровню. При его использовании в «Осаде» станут доступны три современные функции, улучшающие производительность:

Динамическое индексирование текстур (также известное как «bindless rendering»)
Render Target Aliasing
Async Compute

ДИНАМИЧЕСКОЕ ИНДЕКСИРОВАНИЕ ТЕКСТУР (ИЛИ «BINDLESS RENDERING»)

НАЗНАЧЕНИЕ: Динамическое индексирование текстур помогает снизить нагрузку на ЦП за счет уменьшения количества вызовов прорисовки (draw calls) (запрос графическому интерфейсу на прорисовку объекта, который появится на экране). Оно достигается благодаря тому, что ГП динамически выбирает текстуру, используемую в шейдере, вместо того чтобы привязать ее с помощью ЦП. В результате уменьшается количество обращений к драйверу и снижается нагрузка на процессор.

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ: Благодаря API Vulkan и динамическому индексированию текстур должна повыситься частота кадров при игре на компьютерах, производительность которых ограничена пропускной способностью ЦП.

RENDER TARGET ALIASING И ДИНАМИЧЕСКОЕ МАСШТАБИРОВАНИЕ

НАЗНАЧЕНИЕ: Render Target Aliasing позволит использовать в РС-версии динамическое масштабирование, изменяющее разрешение в зависимости от нагрузки на ГП. Игроки смогут выбрать желаемую частоту кадров, а игра автоматически подстроит разрешение для достижения этого результата и таким образом стабилизирует работу игры на компьютерах, производительность которых ограничена пропускной способностью ГП.

ОЖИДАЕМЫЙ РЕЗУЛЬТАТ: С момента запуска в «Осаде» применялись разные методы масштабирования с использованием временного сглаживания. Игроки на РС могут выбрать в игре разрешение, отличное от аналогичного параметра монитора, что позволяет отрисовать изображение в более низком разрешении, а затем увеличить его до размера экрана с помощью временного масштабирования. Временное масштабирование — качественный метод, за счет которого можно добиться эффективного сглаживания с низким размытием, а заодно и повышения производительности.

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

ASYNC COMPUTE

НАЗНАЧЕНИЕ: Async Compute — технология аппаратного обеспечения, позволяющая ГП выполнять задачи параллельно, что дает возможность добиться лучшей оптимизации. С момента запуска «Осады» Async Compute применялась на консолях для повышения производительности при использовании эффектов отражений и объемного света. Видеокарты поддерживали эту технологию, но мы не могли задействовать ее из-за DX11. Благодаря API Vulkan это станет возможным.

ВАЖНАЯ ИНФОРМАЦИЯ

Графические драйверы:ОБНОВИТЕ ГРАФИЧЕСКИЕ ДРАЙВЕРЫ. (Nvidia — версия 441.87; AMD — версия 20.1.4; Intel — версия 26.20.100.7372).__ Последние пару месяцев мы совместно с Nvidia, AMD и Intel занимались оптимизацией работы драйверов в «Осаде». Чтобы добиться максимальной производительности, обязательно установите их последние версии (если используются старые, вы получите предупреждение).

Аппаратная поддержка: К сожалению, некоторые старые модели видеокарт не поддерживают API Vulkan.

Превышение лимита видеопамяти: Одно из преимуществ драйверов на базе DirectX 11 — отличный контроль превышения лимита видеопамяти. В случае с Vulkan оно может вызвать зависания и даже прекращение работы игры. В связи с этим для обеспечения стабильности игрокам потребуется внимательно следить за расчетными объемами потребления памяти в меню настроек графики. При превышении будет отображаться соответствующее предупреждение. Чтобы избежать такой ситуации, стоит снизить качество текстур и/или разрешение игры — параметры, оказывающие самое сильное влияние на производительность.

Мы предлагаем РС-игрокам запустить игру с поддержкой Vulkan, чтобы результаты тестов могли быть максимально обширными.

Сравнение графики в RDR2 для PC. В качестве API выступают DX12 и убийца OpenGL - Vulkan. Второй известен своим перегруженным API и очень усложненным кодированием.

Комментарий удален по просьбе пользователя

Ты синьеришь графику в ААА-студии?

Комментарий удален по просьбе пользователя

API известен своим перегруженным API

Господи, не понимаешь, так не пиши.

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

Отлично, я сейчас кидаю фото даты в паспорте на фоне этого коммента, и если я по возрасту не школьник, ты мне покупаешь рдр2, идёт?

Комментарий удален по просьбе пользователя

Вулкан не перегруженный, он мультиплатформенный + опенсорсный

Тогда давай свои коммиты в драйвер. Я подожду. Пока я видел только 1500 строк для минимального time to triangle.

А что ещё кроме этого ты видел?

Извини, я не понимаю чем тебе помогут "мои" коммиты к драйверу, когда ты говоришо о отрисовке геометрии для какой то рандомной игры в коде на плюсах.

Комментарий удален по просьбе пользователя

Посмотрел видео: вулкан то отстаёт на 1 фпс, то опережает на 1 фпс. Что я должен был увидеть?

Ты должен был увидеть summary, итоги бенчмарков. По ним видно, что на низких настройках графена минимальный и максимальный фпс вулкана намного выше, чем на дх12. А вот на высоких настройках вулкан наоборот сдает, и там максимальный фпс намного ниже, чем у дх12. Очевидно, можно сделать вывод, что вулкан лучше для низких настроек и слабого железа, а дх12 - наоборот, выбор тех, кто побогаче и выкручивает графон на более боярском железе. Наверное. Может, это нихуя и не значит, я понятия не имею, просто видос посмотрел

Но ведь средний у вулкана на максималках всё равно выше.

Тут отличие на уровне погрешности, ни о чём не говорит.

Я согласен, но я просто обратил внимание на то что "Вулкан для минималок" и обратное ему - это ошибочное утверждение.
Эти API будут вести себя по разному на разном железе и на данном примере они ведут себя почти одинаково.

Читайте также: