Объём видеопамяти воспринимается как одна характеристика, но нагрузки за ней стоят принципиально разные. В игровом конвейере память работает как кэш с постоянной подкачкой: содержимое меняется от кадра к кадру, а движок сам управляет тем, что держать в ней прямо сейчас. В вычислительном рендеринге и в задачах обучения моделей память работает как рабочее пространство: данные должны лежать в ней целиком на всё время расчёта. Отсюда и расходятся требования — там, где игра деградирует плавно, расчёт останавливается совсем.
Как память расходуется в игровом кадре
За время одного кадра графический процессор читает текстуры, буферы геометрии, карты теней, промежуточные цели рендеринга и записывает результат. Основной объём занимают текстуры, но нужны они не все сразу: движок подгружает мип-уровни в зависимости от того, насколько близко объект к камере, и выгружает то, что ушло из поля зрения. Этот механизм называется стримингом и рассчитан на то, что память меньше полного набора ассетов уровня.
Отсюда важное следствие: игра при недостатке объёма не падает, а начинает жертвовать качеством или временем. Движок понижает детализацию текстур, увеличивает задержку подгрузки, чаще обращается к системной памяти через шину PCIe. Результат виден как подгрузка текстур на глазах, редкие подвисания при повороте камеры и провалы минимальных значений частоты кадров при ровном среднем. Средний показатель при этом может почти не измениться — именно поэтому нехватку памяти легко не заметить, глядя только на усреднённые цифры.
Почему пропускная способность важна не меньше объёма
Игровая нагрузка на память — это огромное количество мелких обращений с плохой локальностью: выборки текстур идут по всей площади кадра, а не последовательным потоком. Здесь на первый план выходит пропускная способность, то есть произведение эффективной частоты на ширину шины, и объём кэша, который гасит часть обращений. Карта с большим объёмом, но узкой шиной может упираться в пропускную способность раньше, чем в ёмкость: данные помещаются, но подать их к вычислительным блокам с нужным темпом не получается. Соотношение этих двух параметров и то, как оно меняется с разрешением, разбирается подробнее в разделе про видеокарты.
Рендеринг: сцена целиком или ничего
В офлайновом рендеринге на графическом процессоре логика другая. Трассировка лучей требует произвольного доступа к любой части сцены на любом шаге: луч, ушедший в отражение, может обратиться к геометрии на другом конце модели. Заранее предсказать, что понадобится через микросекунду, невозможно, поэтому классический подход — держать в памяти всю сцену: геометрию, ускоряющие структуры, текстуры, карты освещения. Когда набор не помещается, рендер либо аварийно завершается с ошибкой нехватки памяти, либо переключается в режим работы через системную память, где производительность падает в разы, либо отдаёт задачу центральному процессору целиком.
Разница в характере отказа принципиальна. Игра при нехватке объёма теряет часть качества и продолжает работать. Расчёт при нехватке объёма не выдаёт результат вообще — или выдаёт его через время, несопоставимое с ожидаемым. Планировать объём под такую нагрузку приходится по верхней границе сцены, а не по типичной.
Что ещё меняет требования в профессиональных задачах
Помимо самого объёма расходятся ещё три вещи. Первая — разрядность данных. Игры почти везде обходятся половинной и одинарной точностью, а часть расчётных задач требует более широких форматов, что напрямую умножает занимаемый объём. Вторая — накладные расходы на промежуточные структуры: ускоряющие иерархии для трассировки, буферы сглаживания, кэши запечённого освещения. Они не видны в статистике сцены, но занимают заметную часть памяти. Третья — сама надёжность хранения: одиночная ошибка в текстуре игрового кадра исчезнет через шестнадцать миллисекунд, а такая же ошибка в многочасовом расчёте испортит результат целиком и обнаружится в лучшем случае визуально. По этой причине в вычислительных конфигурациях память с коррекцией ошибок рассматривается как обязательная, а не как опция; механика такой коррекции разобрана в разделе про память ECC.
Как из этого складывается приоритет
Для игровой нагрузки порядок приоритетов обычно такой: достаточный для целевого разрешения объём, затем пропускная способность и кэш, затем производительность вычислительных блоков. «Достаточный» здесь определяется разрешением и настройками текстур, а не абстрактным запасом на будущее: лишний объём при узкой шине не даст ничего.
Для рендеринга и вычислений порядок обратный: сначала объём с запасом под самую тяжёлую сцену, затем корректность и стабильность, и только затем скорость. Карта, которая считает быстро, но не вмещает проект, бесполезна; карта, которая вмещает и считает медленнее, задачу всё-таки выполняет.
Смешанный сценарий — рабочая станция, на которой днём идёт моделирование, а вечером игры — разрешается по требованиям расчётной части, потому что игра приспособится к любому разумному объёму, а рендер не приспособится ни к какому недостаточному. Это же соображение стоит держать в голове при оценке того, сколько памяти реально понадобится проекту через год работы, когда сцены неизбежно вырастут в детализации.
