Тайловые GPU: осознанный выбор загрузки и сохранения вложений рендеринга

Рассматривайте вложение как данные со сроком жизни

Тайловый GPU обрабатывает небольшие области кадрового буфера с локальным хранением. Восстановление прежнего содержимого вложений или экспорт промежуточных результатов могут создавать внешний трафик памяти. Выбор операций загрузки и сохранения сообщает реализации, какое содержимое важно на границах рендеринга. Объяснение Arm показывает, почему эти решения способны существенно влиять на пропускную способность мобильных GPU. [1]

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

Выбирайте начальное состояние по фактическим чтениям

Используйте LOAD, когда нужно сохранить прежнее содержимое. Выбирайте CLEAR, когда требуется определённое одинаковое начальное значение. Используйте DONT_CARE только при ненужности старого содержимого и правильной инициализации каждого значения, которое позже будет прочитано. Vulkan определяет отброшенное начальное содержимое как неопределённое внутри области рендеринга. [2]

Кажущаяся полноэкранной отрисовка не доказывает перезапись всего: отбрасывание по глубине, scissor-области, маски записи или смешивание могут сохранять зависимость от прежних данных. Подходящее тайловое оборудование может инициализировать локальное хранилище операцией очистки вложения без восстановления предыдущего изображения. [1]

Пример расчёта: масштаб передачи

Условное вложение размером 1920 на 1080 пикселей с 4 байтами на пиксель содержит 1920 * 1080 * 4 = 8294400 байт. Одна полная загрузка и одно полное сохранение передают 16588800 байт в модели без сжатия.

При 60 кадрах в секунду это 16588800 * 60 = 995328000 байт в секунду, приблизительно 0.995 GB/s. Это не измеренная пропускная способность и не гарантированная экономия: сжатие, кэши, частичные области и решения реализации меняют реальный трафик. Расчёт показывает, почему стоит изучить необязательную передачу вложения туда и обратно.

Сохраняйте окончательные данные только при необходимости

Сохраняйте результаты, нужные для показа, дальнейшего рендеринга или обратного чтения. Если содержимое больше не нужно, операция сохранения с отбрасыванием может избежать его удержания. Операция DONT_CARE для сохранения в Vulkan делает содержимое неопределённым. У NONE иная семантика: её нельзя считать способом сохранить вновь записанные данные для последующего прохода. [3]

Для подходящих временных вложений изучите транзиентное использование и поддерживаемое ленивое выделение памяти. Объединяйте совместимую работу, если это позволяет локальное повторное использование, но проверяйте реальное исполнение, не предполагая слияния всех логических проходов. Чтения соседних пикселей могут требовать другого пути памяти. [1]

Проверяйте корректность до интерпретации счётчиков

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

Источники

• [1] Picking the Most Efficient Load/Store Operations — Attilio Provenzano, Arm.
• [2] VkAttachmentLoadOp — Khronos Group, Vulkan specification.
• [3] VkAttachmentStoreOp — Khronos Group, Vulkan specification.