Кадр как подготовленная работа
Приложение записывает операции в command lists и передаёт их очередям. Вместо постоянной сборки графического состояния из независимых частей используется заранее подготовленный pipeline state object. Descriptor heaps и таблицы описывают доступ шейдеров к ресурсам. Такая модель позволяет планировать сложный кадр более явно.
Для движка это возможность распределить подготовку работы между CPU-потоками и сократить часть повторяемых действий. Но если сцена ограничена тяжёлым освещением на GPU, уменьшение расходов CPU может почти не влиять на итоговое время. Оптимизация полезна только тогда, когда затрагивает реальное узкое место.
Ресурс нельзя уничтожать слишком рано
Возврат функции на CPU не означает, что GPU закончил выполнять записанные команды. Приложение должно сохранять используемую память и синхронизировать повторное использование буферов. Fences помогают отслеживать завершение работы; resource barriers описывают переходы и необходимые зависимости внутри обработки кадра.
Представьте обновление данных света каждый кадр. Если CPU перезапишет область, из которой GPU ещё читает предыдущий кадр, получится гонка. Практическое решение обычно строится на нескольких версиях буфера и контроле завершения работы. Этот пример показывает причину сложности API лучше, чем абстрактное обещание «низкого уровня».
Откуда появляются задержки при первом показе
PSO связывает существенную часть состояния pipeline. Большое число комбинаций материалов, освещения и форматов может порождать много вариантов. Подготовка или компиляция недостающего варианта во время интерактивного показа способна вызвать заметную паузу. Организация кэша и предварительного создания вариантов относится к обязанностям движка.
Практическая рекомендация для оценки сцены: различайте холодный запуск и повторный проход. Средний FPS не показывает редкие длительные кадры. Для walkthrough полезно проверять первый вход в помещение, появление нового материала и смену режима отображения, а не только неподвижную камеру после прогрева.
D3D12, DXR и аппаратные уровни
Название D3D12 не гарантирует поддержку каждой функции. DXR добавляет программные интерфейсы трассировки, а его возможности определяются сообщаемым tier, драйвером и подходящим SDK. Другие расширения также имеют собственные требования. Перечень в спецификации не равен перечню на конкретной видеокарте.
Художник работает с возможностями приложения: включёнными отражениями, GI, тенями и режимами экспорта. Даже когда все они используют D3D12, для разных проходов могут применяться растеризация, трассировка и compute-фильтры. Поэтому API нельзя приравнивать ни к path tracing, ни к физически корректному результату.
Как оценить пользу для проекта
Сначала определяют требуемые эффекты и целевые устройства, затем проверяют рекомендованный backend у разработчика программы. Сравнение проводят на одной версии проекта, с одинаковым output resolution и сопоставимыми настройками. Фиксируют не только GPU time, но также время загрузки, стабильность кадров и потребление памяти.
Если одна конфигурация использует temporal upscaling, а другая рисует нативное разрешение, разницу нельзя приписать одному API. Аналогично переход с запечённого освещения на динамическую GI меняет вычислительную задачу. Результатом теста должен быть конкретный рабочий профиль для данной сцены, а не общий рейтинг технологий.
Практический диагностический пример: кадр содержит копирование текстуры, вычислительный проход и чтение результата в графическом pipeline. Если изображение повреждается только при высокой нагрузке, проверьте время жизни ресурсов и зависимости очередей до изменения материала. Повторите захват на небольшом наборе объектов. Устранение случайного порядка выполнения является исправлением корректности; ускорение оценивается отдельно после стабилизации результата.