Что такое компиляция шейдеров и почему из-за нее компьютерные игры тормозят?
Шейдеры — это то, что делает современные графические процессоры такими гибкими, поскольку эти графические процессоры предназначены для запуска всего, что может быть выражено в язык программирования шейдеров. Они заменяют старую технологию графического процессора «конвейер с фиксированными функциями», когда типы графических вычислений, которые мог выполнять графический процессор, были жестко встроены в его кремний.
Что такое компиляция шейдеров?
Сборник” — это компьютерный термин, который относится к коду, написанному программистом-человеком, и преобразованию его в машинный код, который может понять конкретный процессор, предназначенный для запуска рассматриваемого программного обеспечения. Так, например, вы можете скомпилировать свой код для работы на процессоре Intel или Яблочный кремний.
То же самое необходимо для GPU. Код шейдера должен быть скомпилирован для работы с рассматриваемой маркой и моделью графического процессора. Если вы меняете графический процессор, обновляете его драйверы или игра получает обновление, шейдеры необходимо компилировать заново.
Почему в некоторых компьютерных играх зависает компиляция шейдеров?
В некоторых играх компиляция шейдеров в фоновом режиме мешает самой игре, вызывая видимые зависания. Компьютер слишком усердно компилирует шейдеры, чтобы игра работала гладко. Некоторые разработчики стараются оптимизировать компиляцию так, чтобы она практически не влияла на производительность игры, в то время как другие распространяют компиляцию шейдеров на всю игру, надеясь, что заминка будет недолгой. В этом случае вы столкнетесь с заиканиями только в начале нового уровня или при входе в новую среду, в которой используются шейдеры, в которых до этого момента не было необходимости.
Подвисания при компиляции были особенно вопиющими в играх на Unreal Engine 4, широко распространенном и популярном игровом движке. В частности, эти заикания становятся проблемой при запуске игры под DirectX 12. Отчасти это связано с тем, что DirectX 12 меняет способ компиляции шейдеров, предоставляя разработчикам больший контроль. Однако это также означает, что у разработчиков может не быть лучшего способа оптимизировать компиляцию шейдеров с использованием последней и лучшей версии DirectX.
Почему на консолях компиляция шейдеров не тормозит?
Заикание при компиляции шейдеров — проблема, полностью отсутствующая в таких консолях, как PS5 и Xbox Series X|S. Это просто потому, что разработчики точно знают, какое оборудование находится внутри каждой консоли, поэтому они могут предварительно скомпилировать все шейдеры; нет необходимости компилировать их в локальной системе, потому что вы уже знаете, на какой графический процессор вы ориентируетесь.
Это можно сделать на ПК, но поскольку существует так много графических процессоров и системных конфигураций, это было бы нецелесообразно. Однако в случае Клапан Steam Deck, Valve включает предварительно скомпилированный кеш шейдеров с некоторыми играми, потому что, конечно же, все колоды Steam имеют одинаковый графический процессор.
Что вы можете сделать с компиляционным заиканием?
К сожалению, в большинстве случаев разработчикам приходится исправлять проблемы компиляции шейдеров. Хорошая новость заключается в том, что в конечном итоге они справятся с процессом. Unreal Engine 5.1 может включать автоматизированная функция это поможет разработчикам с кэшированием без столь серьезного влияния на производительность.
Список вещей, которые вы можете сделать, чтобы уменьшить заикание, невелик, но некоторые из этих вариантов могут помочь:
- Если игра позволяет предварительно скомпилировать шейдеры, разрешите это. Это может занять некоторое время, но игра будет работать без заиканий.
- Если обновление игры не включает исправление зависаний шейдеров, подождите, пока вы не закончите играть, иначе шейдеры могут скомпилироваться снова.
- Отложите обновления драйверов графического процессора, пока вы не закончите текущую игру, на случай, если она снова вызовет компиляцию.
- Когда в игре начинается заикание компиляции, нажмите кнопку паузы и подождите, пока оно не закончится, прежде чем играть дальше.
- Используйте DirectX 11 вместо DirectX 12 версии игры. Часто заикание шейдера уменьшено или отсутствует, хотя в придачу вы откажетесь от функций DX12.
- Вместо этого играйте в игру на консоли.
Со временем эта проблема, вероятно, исчезнет или станет гораздо менее навязчивой. Например, разработчики могут перенести компиляцию шейдеров на процессорные ядра, которые не нужны игре, что является обычной ситуацией на современных ПК с большим количеством ядер. До тех пор, #заикание останется раздражающей проблемой в компьютерных играх.
Долгая компиляция шейдеров Detroit Become Human
Здравствуйте, обновил дрова на видюшку и в детройте началась повторная компиляция шейдеров. Если в первый раз она была около 20 минут, то сейчас за полтора часа всего 30 процентов. Дрова переустанавливал. Игра стоит на харде, также есть ссд. Остальные характеристики: RX 474, e5-2420v2, 16 gb ram. Что посоветуете сделать в этом случае?
Попробуй найти куда эти шейдеры сохраняются и удалить всё. Возможно игра проверяет совместимость старых шейдеров и новых драйверов и это занимает больше времени чем просто создать новые
Вы нашли как исправить эту вечную компиляцию при запуске игры?
Что посоветуете сделать в этом случае?
Купить новый компьютер.
Когда мама сказала "иди поиграй на улице"
Такой ПК мы себе можем позволить
Ответ TBEPDOKOJI в «Про родительский контроль и ограничения компьютера»
В 1996 году, когда мне исполнилось 6 лет в соседнюю квартиру переехала молодая пара лет 20, мы быстро с ними подружились. Я был очень рад гостить у них, ведь у них было денди. Финансовое положение семьи не позволяло купить мне его, потому я иногда играл у них, а сам вожделел заветной приставкой. Но на семилетие получил тетрис и на том спасибо. Шли годы и в 2002 году я сам себе купил денди из накопленных денег, тогда, когда у многих моих знакомых была уже первая PlayStation. Так как приставка была самой дешевой из тех, что были, она была дико глючной, зависала, читала не все картриджи. В общем, иногда играл, но уже без детского восторга. Но прошло пару лет, финансовое положение внутри семьи выровнялось и в конце 2004 мне покупают компьютер. В 2005 я покупаю паленый билд висты на рынке и самостоятельно пытаюсь переустановить систему. Получилось, только диск D заблокировался. Интернета нет, пришлось идти в библиотеку и читать литературу, чтобы разобраться в проблеме. В итоге помог один очень хороший человек, старший брат моего друга. Но самое главное, я получил знания и опыт. С тех пор, я стал самым прошаренным среди своих сверстников и помогал всем с настройкой и проблемами по ПК. И понял что профессию я хочу выбрать, связанную с компьютерами. Когда я перешел в 11 класс 2006/2007 год, я твердо решил поступать в АйТи сферу в Краснодаре, ведь туда уже переехала учиться жила моя девушка(первая любовь). Но мечтам не удалось сбыться, я разбежался с ней. Отношения не выдержали расстояния. Решил поступить с другом в Новороссийске, быть курсантом, жить на казарме. Когда я пришел в приемную комиссию, сказал девушке за столиком, мне что-нибудь связанное с компьютерами. Она что-то перепутала и я поступил учиться на радиоинженера. Ни о чем не жалею, это повлияло на многое в моей жизни. А люди в группе были отличные. Надо отметить, что с 2005 по 2007 я наигрался вдоволь в компьютер. А потом началась учеба. В 2013 я закончил вышку. В 2014 устроился по специальности, теперь я чиню приборы и сервера на работе днем, а по вечерам, как хобби компьютеры. Фото разных моментов, как бывает дома.
В 2016 во мне что-то щелкнуло, начал играть. Собрал хороший комп, завел стим, закупил все игры детства, начал покупать новые. Перепрошел многое. Но самая любимая еще с детства Half-Life 2.
Сейчас мне почти 33, но я с гордостью могу сказать, что я игроман и не стесняюсь этого. Я люблю часок другой поиграть после работы, если есть время и нет забот.
Но в денди я так и не наигрался. Хотя сейчас иногда гоняю на кухне на андроид приставке через эмулятор.
Получилось сумбурно, но захотелось поделиться после поста @TBEPDOKOJI
Аж олдскулы свело
Разнообразие
Starcraft: когда все только начиналось
Я стратегоман. Давний. Долгий. Больше четверти века. Мои пристрастия лучше всего описывает случай на работе:
– Кроме того, скоро выйдет Legacy of the Void, так что учебный процесс, вероятно, будет сорван…
– Да не-е-е-е-т, Михаил Сергеевич, почему вы о нас так плохо думаете? Да разве мы можем играть вместо того, чтобы учиться?! – старшеклассники смотрят на меня честными глазами, еле сдерживая смех.
– Да вы-то тут при чем? Он для меня выходит!
Это будет заметка, полная ностальгии.
Мое знакомство с видеоиграми началось с Dune2 на Сеге и объяснений папы, почему нужно строить много харвестеров. Отец решал назревающую проблему моих увлечений по-военному: если явление невозможно предотвратить, то его следует возглавить. Раз сын все равно будет играть, то надо не кабель в шкаф прятать, а приучать к вещам, в которых надо напрягать голову. Так и вышло, что мне примерно в десять лет объяснили: экономическое доминирование – залог успеха в RTS. Риторический вопрос: какая еще игра, кроме Старкрафта, могла быть первой моей игрой на PC, если он появился в семье в июне 1998 года?
Я уверен, что в Старкрафт многие из гиков играли.
Кто из гиков не играл – его хотя бы видел.
Кто из гиков его не видел – об этой игре слышал.
А если и не слышал о самой игре, то от терминов типа «зерг-раш» не увернулся совершенно точно.
О самом Старкрафте написано очень много, поэтому я не думаю, что кому-то интересно очередное пересказывание сюжета, тактик и мемов про Южную Корею. Вместо этого я намерен немножко поговорить о начале победной поступи Старкрафта, вытаскивая на поверхность школьные воспоминания. Не думаю, что погрешу против истины, если скажу, что компьютерные игры сейчас – внушительная часть массовой культуры, а Starcraft – один из ее столпов. Двадцать с лишним лет назад это было немного не так. Лучше всего это показать с помощью цитаты. Году так в двухтысячном «Навигатор игрового мира», открывая длинную серию тактических советов, написал примерно так: «Игра ДВУХГОДИЧНОЙ давности все еще популярна…». Слово «двухгодичной» так и было написано – большими буквами; вряд ли кто-то тогда всерьез предполагал, что популярности первой части Старкрафта ничего не грозит еще минимум десяток лет.
Когда сама игра выходила, ее встретили не особо тепло. Та же «Страна игр», хотя и поставила высокую оценку (8,5 из 10, ЕМНИП), охарактеризовала игру примерно так: «Клон. Но самый лучший, который когда-либо был!»
Почему Starcraft взлетел – понятно. Но вот что из этого было тогда, в конце 90-х, неочевидным? Самое смешное, что неочевидным как минимум для многих обозревателей было главное преимущество этой RTS: баланс трех принципиально разных рас. Именно это обеспечило популярность сетевой игры, а она – очень долгую жизнь всему Старкрафту.
Тут надо понимать, что это в 2022 фразы типа «no rush 30 min» вызывают здоровый смех у любого, кто хотя бы раз видел игру в ладдере. В 1998 и даже в 2000 году это все было вовсе не само собой разумеющимся. В той же «Стране игр» в рецензии на игру было написано примерно так: «Игра не сбалансирована. Люди самые сильные, за зергов играть в принципе невозможно, а протоссы мощны, но крайне медлительны». Это уже потом через пару-тройку месяцев в том же журнале опубликовали письмо читателя, в котором прозвучала очень хлесткая формулировка: «Все утверждают, что в Starcraft нет баланса между расами, но что самое забавное, мнения о сильнейшей расе различаются».
И вот тут самое время поговорить об интересном. Почему это было неочевидным?
А что вообще такое баланс трех принципиально разных рас? Starcraft предложил в жанре RTS выбирать между сторонами, у которых из общего только потребляемые ресурсы. Но при этом у каждой из рас был набор тактик против каждого оппонента, и эти тактики не выглядели жестом отчаяния. На каждую связку юнитов есть свои контрмеры. Но все это еще надо было нащупать и причесать. Это во второй части с самого начала на каждой карте есть точка для быстрой экспансии и «чок» — узкий проход на основную базу.
В момент выхода игры еще никто не знал, что им предложили чуть ли не шахматы в реальном времени. Концепция RTS не нова. Экономический аспект – известно. Дерево технологий – было уже такое, что далеко ходить? Вот Warcraft II перед глазами, там уже все это есть. Starcraft отличался от других стратегий примерно так же, как кандидатская диссертация от дипломной работы: новизной. Но эту новизну только предстояло осмыслить и прочувствовать. Новизна потому и называется новизной, что раньше такого не было.
Какой вывод из этого напрашивается? Их два.
Первый – какая бы великолепная идея у вас ни была, для успеха ей надо опираться на уже проработанные решения. Starcraft потому и является эталоном, что воплощает уже проработанную к тому моменту концепцию RTS, добавляя к ней принципиально новую идею.
Второй – если ваша идея действительно великолепна, то ее нащупают, даже если не разглядят сразу.
На PlayStation удобнее: как делали порт Detroit Become Human
Полноценно оптимизировать генерацию шейдеров разработчики так и не смогли.
В самом конце 2019 года студия Quantic Dream выпустила на PC Detroit Become Human, бывший эксклюзив для PlayStation 4. Спустя 9 месяцев после релиза разработчики из Quantic Dream поговорили о том, как создавался порт для PC.
Портирование Detroit Become Human далось непросто: почти все технологии, использованные в игре, Quantic Dream разрабатывала самостоятельно. Адаптировать их под новую платформу тоже пришлось самим. Мы выбрали самые любопытные моменты из рассказа разработчиков.
Портирование Detroit: Become Human с Playstation 4 на PC
В этой серии постов мы расскажем о портировании игры Detroit: Become Human с PlayStation 4 на PC.
Detroit: Become Human была выпущена на PlayStation 4 в мае 2018 года. Мы начали работу над версией для PC в июле 2018 года, а выпустили её в декабре 2019 года. Это адвенчура с тремя играбельными персонажами и множеством сюжетных линий. Она имеет очень качественную графику, а большинство графических технологий было разработано самой компанией Quantic Dream.
3D-движок обладает отличными возможностями:
- Реалистичный рендеринг персонажей.
- PBR-освещение.
- Высококачественная постобработка, например Depth of Field (DOF), motion blur, и так далее.
- Временно́е сглаживание.
Detroit: Become Human
- Руководитель разработкой 3D-движка Ронан Маршалот и ведущие разработчики 3D-движка Николас Визери и Джонатан Сирет из Quantic Dream расскажут об аспектах рендеринга портированной игры. Они объяснят, какие оптимизации можно было без проблем перенести с PlayStation 4 на PC, и с какими сложностями, вызванными различиями между платформами, они столкнулись.
- Лу Крамер — это инженер по разработке технологий из AMD. Она помогала нам оптимизировать игру, поэтому подробно расскажет о неоднородном индексировании ресурсов на PC и, в частности, в картах AMD.
Выбор графического API
У нас уже была OpenGL-версия движка, которую мы применяли в наших инструментах разработки.
Но нам не хотелось выпускать игру на OpenGL:
- У нас было множество проприетарных расширений, которые были открыты не всем производителям GPU.
- Движок имел очень низкую производительность в OpenGL, хотя, разумеется, её можно было оптимизировать.
- В OpenGL существует множество способов реализации разных аспектов, поэтому правильная реализация разных аспектов на всех платформах превращалось в кошмар.
- Инструменты OpenGL не всегда надёжны. Иногда они не работают, потому что мы используем расширение, которого они не знают.
Мы выбирали между DirectX 12 и Vulkan, имеющими очень схожий набор функций. Vulkan в дальнейшем позволил бы нам обеспечить поддержку Linux и мобильных телефонов, а DirectX 12 обеспечивал поддержку Microsoft Xbox. Мы знали, что в конечном итоге нам нужно будет реализовать поддержку обоих API, но для порта разумнее будет сосредоточиться только на одном API.
Vulkan поддерживает Windows 7 и Windows 8. Так как мы хотели сделать Detroit: Become Human доступной как можно большему количеству игроков, это стало очень сильным аргументом. Однако портирование занял один год, и этот аргумент уже маловажен, ведь Windows 10 теперь используется очень широко!
Концепции разных графических API
OpenGL и старые версии DirectX имеют очень простую модель управления GPU. Эти API просты в понимании и очень хорошо подходят для обучения. Они поручают драйверу выполнять большой объём работы, скрытый от разработчика. Следовательно, в них очень сложно будет оптимизировать полнофункциональный 3D-движок.
С другой стороны, PlayStation 4 API очень легковесный и очень близок к «железу».
Vulkan находится где-то посередине. В нём тоже есть абстракции, потому что он работает на разных GPU, но разработчики имеют больше контроля. Допустим, у нас есть задача реализации управления памятью или кэша шейдера. Так как драйверу остаётся меньше работы, её приходится делать нам! Однако мы разрабатывали проекты на PlayStation, и поэтому нам удобнее, когда мы можем всё контролировать.
Сложности
Центральный процессор PlayStation 4 — это AMD Jaguar с 8 ядрами. Очевидно, что он медленнее, чем новое оборудование PC; однако PlayStation 4 имеет важные преимущества, в частности, очень быстрый доступ к «железу». Мы считаем, что графический API PlayStation 4 гораздо эффективнее, чем все API на PC. Он очень прямолинейный и мало тратит ресурсов впустую. Это означает, что мы можем добиться большого количества вызовов отрисовки на кадр. Мы знали, что высокое количество вызовов отрисовки может стать проблемой на слабых PC.
Ещё одно важное преимущество заключалось в том, что все шейдеры на PlayStation 4 можно было скомпилировать заранее, то есть их загрузка выполнялась практически мгновенно. На PC драйвер должен компилировать шейдеры во время загрузки игры: из-за большого количества поддерживаемых конфигураций GPU и драйверов этот процесс невозможно выполнить заранее.
Во время разработки Detroit: Become Human на PlayStation 4 художники могли создавать уникальные деревья шейдеров для всех материалов. Из-за этого получалось безумное количество вершинных и пиксельных шейдеров, поэтому мы с самого начала работы над портом знали, что это станет огромной проблемой.
Конвейеры шейдеров
Как мы знаем по нашему OpenGL-движку, компиляция шейдеров может занимать много времени на PC. Во время продакшена игры мы сгенерировали кэш шейдеров по модели GPU наших рабочих станций. Генерация полного кэша шейдеров для Detroit: Become Human заняла целую ночь! Все сотрудники получили доступ к этому кэшу шейдеров на утро. Но игра всё равно тормозила, ведь драйверу нужно было преобразовать этот код в нативный ассемблерный код шейдера GPU.
Оказалось, что Vulkan намного лучше справляется с этой проблемой, чем OpenGL.
Во-первых, Vulkan не использует напрямую высокоуровневый язык шейдеров наподобие HLSL, а вместо него применяет промежуточный язык шейдеров под названием SPIR-V. SPIR-V ускоряет компиляцию шейдеров и упрощает их оптимизацию под компилятор шейдеров драйвера. На самом деле, с точки зрения производительности он сравним с системой кэша шейдеров OpenGL.
В Vulkan шейдеры должны быть связаны, образуя VkPipeline . Например, VkPipeline можно создать из вершинного и пиксельного шейдера. Также он содержит информацию о состоянии рендеринга (тесты глубин, стенсил, смешение и т.д.) и форматы render target. Эта информация важна для драйвера, чтобы он мог обеспечить максимально эффективную компиляцию шейдеров.
В OpenGL компиляция шейдеров не знает контекста использования шейдеров. Драйверу нужно дождаться вызова отрисовки, чтобы сгенерировать двоичный файл GPU, и именно поэтому первый вызов отрисовки с новым шейдером может долго выполняться в CPU.
В Vulkan конвейер VkPipeline предоставляет контекст использования, поэтому у драйвера есть вся информация, необходимая для генерации двоичного файла GPU, и первый вызов отрисовки не требует излишней траты ресурсов. Кроме того, мы можем обновлять VkPipelineCache при создании VkPipeline .
Изначально мы пытались создавать VkPipelines в первый раз, когда он нам понадобится. Из-за этого возникали торможения, похожие на ситуацию с драйверами OpenGL. После чего VkPipelineCache обновлялся, и торможение пропадало до следующего вызова отрисовки.
Потом мы прогнозировали, что сможем создавать VkPipelines во время загрузки, но когда VkPipelineCache был неактуальным, это было так медленно, что стратегию загрузки в фоновом режиме реализовать не удалось.
В конечном итоге, мы решили генерировать все VkPipeline во время первого запуска игры. Это полностью устранило проблемы с торможением, но теперь мы столкнулись с новой сложностью: генерация VkPipelineCache занимала очень много времени.
Detroit: Become Human содержит примерно 99 500 VkPipeline ! В игре используется прямой рендеринг (forward rendering), поэтому шейдеры материалов содержат весь код освещения. Следовательно, компиляция каждого шейдера может занимать длительное время.
У нас появилось несколько идей по оптимизации процесса:
- Мы оптимизировали данные так, чтобы можно было загружать только промежуточные двоичные файлы SPIR-V.
- Мы оптимизировали промежуточные двоичные файлы SPIR-V с помощью оптимизатора SPIR-V.
- Мы сделали так, чтобы все ядра CPU тратили 100% времени на создание VkPipeline .
Многие VkPipeline очень похожи. Например, некоторые VkPipeline могут иметь одинаковые вершинные и пиксельные шейдеры, отличающиеся всего несколькими состояниями рендеринга, например, параметрами стенсила. В таком случае драйвер может считать их одним конвейером. Но если мы создаём их одновременно, один из потоков будет просто простаивать, ожидая, пока другой завершит задачу. По своей природе, наш процесс передавал все похожие VkPipeline одновременно. Чтобы решить эту проблему, мы просто изменили порядок сортировки VkPipeline . «Клоны» поместили в конец, и их создание в результате стало занимать гораздо меньше времени.
Производительность создания VkPipelines очень сильно варьируется. В частности, оно сильно зависит от количества доступных аппаратных потоков. На AMD Ryzen Threadripper с 64 аппаратными потоками оно может занимать всего две минуты. Но на слабых PC этот процесс, к сожалению, может проходить больше 20 минут.
Последнее было для нас слишком долго. К сожалению, единственным способом ещё сильнее снизить это время было уменьшение количества шейдеров. Нам требовалось бы изменить способ создания материалов, чтобы как можно большее их количество было общим. Для Detroit: Become Human это было невозможно, потому что художникам пришлось бы переделывать все материалы. Мы планируем реализовать в следующей игре правильный инстансинг материалов, но для Detroit: Become Human уже было слишком поздно.
Индексирование дескрипторов
Для оптимизации скорости вызовов отрисовки на PC мы использовали индексирование дескрипторов при помощи расширения VK_EXT_descriptor_indexing . Его принцип прост: мы можем создать набор дескрипторов, содержащий все используемые в кадре буферы и текстуры. Затем мы сможем получать доступ к буферам и текстурам через индексы. Основное преимущество этого заключается в том, что ресурсы связываются только один раз за кадр, даже если используются во множестве вызовов отрисовки. Это очень похоже на использование несвязанных ресурсов в OpenGL.
Мы создаём массивы ресурсов для всех типов используемых ресурсов:
- Один массив для всех 2D-текстур.
- Один массив для всех 3D-текстур.
- Один массив для всех кубических текстур.
- Один массив для всех буферов материалов.
Благодаря этой стратегии мы могли хранить малое количество наборов дескрипторов, общих для всех вызовов отрисовки и содержащих всю информацию, необходимую для отрисовки кадра.
Оптимизация обновлений наборов дескрипторов
Даже при малом количестве наборов дескрипторов их обновление по-прежнему оставалось узким местом. Обновление набора дескрипторов, если он содержит множество ресурсов, может быть очень затратным. Например, в одном кадре Detroit: Become Human может быть больше четырёх тысяч текстур.
Мы реализовали инкрементные обновления наборов дескрипторов, отслеживая ресурсы, которые становятся видимыми и невидимыми в текущем кадре. Кроме того, это ограничивает размер массивов дескрипторов, потому что им достаточно иметь ёмкость для обработки видимых ресурсов в текущий момент времени. Отслеживание видимости тратит мало ресурсов, потому что мы не используем затратный алгоритм вычисления пересечений с O(n.log(n)) . Вместо этого мы используем два списка, один для текущего кадра, второй для предыдущего. Перемещение оставшихся видимыми ресурсов из одного списка в другой и изучение оставшихся в первом списке ресурсов помогает определять, какие ресурсы попадают в пирамиду видимости и исчезают из неё.
Получившиеся при этих вычислениях дельты хранятся в течение четырёх кадров — мы используем тройную буферизацию, а для вычислений векторов движения объектов со скиннингом требуется наличие ещё одного кадра. Набор дескрипторов должен оставаться неизменяемым в течение не менее чем четырёх кадров, прежде чем его снова можно будет модифицировать, потому что он по-прежнему может пригодиться GPU. Поэтому мы применяем дельты к группам из четырёх кадров.
В конечном итоге, эта оптимизация снизила время обновления наборов дескрипторов на один-два порядка величин.
Батчинг примитивов
Использование индексирования дескрипторов позволяет нам выполнять батчинг множества примитивов в одном вызове отрисовки с помощью vkCmdDrawIndexedIndirect . Мы используем gl_InstanceID для доступа к нужным индексам в основном буфере. Примитивы можно сгруппировать в батчи, если они имеют одинаковый набор дескрипторов, одинаковый конвейер шейдеров и одинаковый буфер вершин. Это очень эффективно, особенно во время проходов глубины и теней. Общее количество вызовов отрисовки снижается на 60%.
На этом первая часть серии статей завершается. Во второй части инженер по разработке технологий Лу Крамер расскажет о неоднородном индексировании ресурсов на PC и, в частности, в картах AMD.