Видеопамять и бюджет сцены

01Размер текстуры на диске не равен расходу

JPEG или PNG хранит сжатое представление. После декодирования renderer использует формат, подходящий для вычислений, который может занимать существенно больше. Разрядность каналов, число компонентов, mip-уровни и внутреннее сжатие меняют размер. Поэтому список файлов на диске не даёт точного бюджета GPU.

Учебный расчёт: несжатая текстура 4096 × 4096 с четырьмя каналами по 8 бит занимает 64 МиБ только на базовом уровне. Полная обычная цепочка mip-уровней добавляет примерно треть. Это арифметический пример заданного формата, не обещание такого расхода для любой текстуры в любом renderer.

02Геометрия имеет скрытую стоимость

Кроме позиций вершин нужны индексы, нормали, UV и другие атрибуты. Для трассировки добавляются структуры ускорения; для motion blur могут понадобиться данные времени. Displacement способен увеличить рабочую геометрию далеко за пределы того, что видно в исходной сетке редактора.

Практическая рекомендация: измеряйте сцену после подготовки renderer, а не только до запуска. Пик построения структур может оказаться выше устойчивого расхода во время сэмплирования. Если сцена падает на подготовке, снижение финального разрешения иногда почти не помогает: причиной может быть геометрическая часть.

03Изображение тоже занимает память

Цветовой буфер, глубина, нормали, AOV и временная история добавляют расход, который растёт с числом пикселей. Denoising и compositing могут потребовать собственные промежуточные данные. Удвоение ширины и высоты изображения увеличивает число пикселей в четыре раза, хотя итоговый расход всей сцены не обязан увеличиваться ровно так же.

Поэтому два проекта с одинаковыми ассетами, но разными passes и разрешением имеют разные требования. Для анимации следует тестировать кадр с максимальной сложностью, а не только первый. Нужный запас определяется пиком полного workflow, включая постобработку.

04Что происходит при переполнении

Некоторые backend могут использовать системную память или переносить данные между областями. CUDA документирует разные режимы unified memory, а Cycles отдельно описывает поведение поддерживаемых устройств. Но успешный доступ к RAM не делает её эквивалентом локальной VRAM по стоимости.

Если рабочий набор постоянно мигрирует, вычислительные блоки ждут данные. Это может проявляться резким изменением времени при небольшом увеличении сцены. Возможность out-of-core нужно проверять для конкретной программы и типа данных: поддержка текстур не всегда означает тот же механизм для всей геометрии.

05Почему две карты не дают простой суммы

При независимом рендеринге каждому GPU часто требуется собственное представление сцены. Поэтому два устройства с одинаковой памятью обычно увеличивают вычислительные возможности, но не автоматически максимальный размер проекта. Исключения требуют специальной поддержки renderer, аппаратного соединения и режима работы.

Нельзя использовать суммарный объём из рекламного описания системы как гарантированный бюджет одной задачи. Проверьте документированный механизм sharing, доступность на конкретных картах и реальное поведение сцены. Даже подтверждённое совместное использование может иметь другую стоимость доступа.

06Порядок сокращения расхода

Начните с измерений по категориям. Уменьшайте разрешение текстур, которые не дают видимой пользы в целевой камере; сохраняйте экземпляры вместо независимых копий; контролируйте displacement и нужные passes. После каждого изменения сравнивайте изображение. Цель — убрать бесполезные данные, сохранив детали, необходимые для конкретного output.