Из каких условий состоит проход
Представьте рисование стеклянной панели. В нём участвуют программы обработки вершин и фрагментов, используемые ресурсы, формат целевого изображения и правила прозрачности. Некоторые параметры могут входить в заранее созданный pipeline, другие задаются динамически перед командой. Точная граница определяется API и его возможностями.
Если шейдер выдаёт данные, несовместимые с ожидаемой конфигурацией, ошибка находится в сборке прохода, а не обязательно в математике материала. По этой причине инженеры проверяют pipeline целиком: интерфейсы между стадиями, форматы, состояния и реальное содержимое привязанных ресурсов.
Зачем Direct3D 12 объединяет состояния
В Direct3D 11 многие части состояния устанавливались независимо. Документация перехода на Direct3D 12 объясняет пользу объединения значительной части конфигурации в immutable PSO: зависимые параметры можно обработать заранее. Во время записи команд выбирается уже подготовленный объект вместо полного конструирования сочетания на каждом draw call.
Это переносит часть работы из момента рисования в подготовку. Но заранее нужно знать необходимые комбинации. Большая библиотека материалов и режимов освещения может создавать множество вариантов; экономия на повторных установках не отменяет стоимости создания, хранения и управления этими вариантами.
Что остаётся переменным
Pipeline state не следует воспринимать как застывшую копию всей сцены. Позиция камеры, матрица объекта и значения материала передаются через данные, а не обязательно через новый объект pipeline. Иначе даже движение камеры вынуждало бы постоянно создавать новую конфигурацию, что уничтожило бы смысл предварительной подготовки.
Практический принцип — отделять выбор программы и режима от меняющихся чисел. Например, прозрачный и непрозрачный проход могут требовать разной конфигурации, а оттенки одного непрозрачного материала могут использовать общий pipeline. Как именно проводить границу, решает архитектура renderer и результаты измерений.
Почему появляются редкие длинные кадры
Если нужная комбинация впервые подготавливается во время интерактивного обхода, пользователь может заметить паузу. Такая задержка отличается от постоянно низкой производительности. Среднее время кадра сглаживает редкие события, поэтому для walkthrough или VR необходимо смотреть временной график, а не только средний FPS.
Практическая рекомендация для теста: пройти сцену с холодным кэшем, затем повторить маршрут. Сохранить отдельно моменты появления новых материалов, прозрачных объектов и специальных эффектов. Разница между проходами помогает найти этапы подготовки, но сама по себе ещё не доказывает, что виноват именно PSO.
Как организовать надёжный набор вариантов
Для собственного движка полезно задавать понятный ключ конфигурации и хранить связь с исходными шейдерами и версиями. Профилировщик показывает реальные переключения и пропущенные варианты. Изменение компилятора, API или драйвера может влиять на пригодность кэшированных данных, поэтому кэш не должен считаться вечным архивом проекта.
Для художника основной рычаг — дисциплина материалов: общие мастера там, где это оправдано, контролируемые переключатели и проверка конечной сборки. Удаление всех вариантов ради скорости подготовки не является универсальным решением: оно может вынудить GPU исполнять лишнюю работу в каждом кадре. Баланс зависит от назначения сцены.
Комбинаторный рост удобно показать условным примером: три варианта shader, четыре формата цели и два режима samples дают до двадцати четырёх сочетаний, если все они действительно нужны. Это не измерение реального движка. Проверка используемых сочетаний позволяет исключить ненужные варианты до компиляции и уменьшить объём подготовки. Динамическое состояние помогает только для тех параметров, которые конкретный API разрешает менять таким образом.