Что на самом деле происходит, когда видеопамять заканчивается

В сентябре 2026-го разводить холивар о том, хватает ли 8 ГБ видеопамяти, уже как-то неприлично. И даже не потому что вопрос закрыт, а потому что выбора особо не осталось. Ну, посудите сами. RTX 50 Super, которую нам два года обещали как спасение с 3-гигабайтными чипами GDDR7, на Gamescom похоронили окончательно. А то, что осталось на полках, дорожает на глазах: за один только август восьмигиговая RTX 5060 Ti у нас подорожала почти на 30-40%. И не потому что доллар вырос. Реальная причина – это дефицит памяти и то, что партнеры NVIDIA в попытках выжить первым зарезали именно дешевые карточки. Ну, оно и понятно: в условиях, когда чипов не хватает, штамповать копеечную Dual или Ventus – де-факто самоубийство.

С 16-гиговой версией получилось еще интереснее. Вы не поверите, но в конце августа ее вполне можно было взять за 50–60 тысяч. Да, не бесплатно, но в целом терпимо. А сейчас что? А сейчас за нее просят 70-80к, и люди берут. Да и чего бы не брать, если это остатки, которые закупали по старому курсу, а карточки из новой партии обещают быть еще дороже. Так что, восьмигиговая GPU в 2026 году – это уже не компромисс, а данность. И раз нам предстоит с этим как-то жить, давайте разбираться. Нет, не в том, хватит или нет, а в том, что конкретно происходит, когда памяти не хватает. Потому что происходит там, если честно, много всего, и почти ничего из этого в счетчике fps не видно.

Что вообще лежит в этих восьми гигабайтах

Для порядка проведем небольшую инвентаризацию. Потому что думать, что VRAM – это текстуры, – упрощение, из-за которого потом и рождаются странные выводы вроде того, что вы вот поставили текстуры на средние, а оно все равно икает.

Возьмем обычный рендер с отложенным освещением в разрешении 1440p и с активным DLSS в режиме Quality (то есть внутри у нас будет 1707×960) и прикинем на пальцах, куда на самом деле деваются 8 ГБ VRAM и почему текстурам из них достается меньше половины.

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

По генерации кадров стоит пояснить отдельно. Модель из DLSS 3 отъедала 1,5–2 ГБ, в DLSS 4 ее сделали экономнее процентов на 30, но 1–1,5 ГБ она все равно попросит, потому что несколько полноразмерных кадров держать где-то надо. А что касается DLSS 5, которая вышла на этой неделе, то данных по ней пока нет. Но раз она опять только для RTX 50, дешевле она точно не стала.

И вот только после всего этого очередь доходит до текстур. Только что им там остается-то? А остается, как вы понимаете, немного. Ведь на тех же 8 гигах сидит и кэш шейдеров, и композитор рабочего стола, и браузер с аппаратным декодированием видео, и все, что у вас открыто на фоне. Вот и получается, что до текстур доходит в лучшем случае 4–4,5 ГБ, а иногда и того меньше.

Отсюда и ирония, о которой маркетологи на коробке не пишут: фичи, которыми NVIDIA оправдывает ценник даже у младших карт, – и трассировка, и мультикадровая генерация – на восьмигиговой карте сами же и съедают около 3 ГБ из этих восьми еще до того, как игра загрузила первую текстуру. Отсюда и все вытекающие из недостатка VRAM нюансы: включаете вы, скажем, генерацию кадров, а она вместо того, чтобы улучшить fps, наоборот, делает только хуже.

А все потому, что ее буферы – это тот самый лишний гигабайт, который выталкивает игру за бюджет, и рывки от переполнения съедают весь выигрыш от нарисованных кадров. Так что если карта уперлась в память, первым делом выключать надо не текстуры, а генерацию.

Занято – не значит нужно

Хорошо, расход есть, и не маленький, скажете вы. Но зачем так все усложнять, если можно просто посмотреть, сколько памяти игра использует в реальности? Тем более, что для этих целей придумали целый Afterburner. Но тут есть подвох: цифра, которую все принимают за пруф, врет. Ну ладно, не врет, а просто показывает не то, что вы думаете. Но это, откровенно говоря, ничем не лучше.

Потому что показывает она не сколько памяти игра использует де-факто, а сколько под нее выделил драйвер. А это вообще не одно и то же. Ведь движки берут память с запасом: выделять ее в D3D12 дорого, и делать это посреди кадра никому не хочется. Так что игра, у которой в мониторинге занято 7,8 ГБ из 8, на деле может использовать только 5,5, а остальное держать про запас на всякий случай.

Поэтому куда честнее смотреть на выделенную память конкретного процесса в диспетчере задач или на счетчик GPU D3D memory dedicated в HWiNFO. Другое дело, что и эта цифра не показывает главного: сколько памяти игре вообще позволено занять. А позволено ей, между прочим, совсем не 8 ГБ. Дело в том, что Windows через QueryVideoMemoryInfo выдает каждому процессу свой бюджет, и на восьмигиговой карте он обычно составляет 6,5–7 ГБ, смотря кто еще висит на видеокарте.

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

Кто вообще всем этим рулит

Выдает этот бюджет и забирает его обратно, скажу сразу, точно не видеокарта. И даже не игра. Рулит всем менеджер видеопамяти внутри WDDM – та самая штука, которая сидит в ядре Windows еще с Висты, о которой мы недавно рассказывали, и которую под DX12 переписали в WDDM 2.0.

Тут сразу оговорюсь, чтобы не отхватить в комментариях: само по себе железо в страничные промахи умеет еще с Pascal, но графический стек на это не рассчитывает. WDDM и D3D12 требуют, чтобы все, что GPU может тронуть в текущем кадре, заранее лежало там, откуда он читает напрямую. А таких мест два: своя VRAM и кусок обычной оперативки, который Windows отдает под видеокарту и который GPU видит через GART как продолжение своей памяти. Этот кусок вы наверняка видели: это та самая общая память графического процессора в диспетчере задач, которая на 32 ГБ оперативки показывает 16 и выглядит чистой халявой. Только халявы не бывает, и чуть ниже станет понятно, почему.

В D3D11 и OpenGL за все это отвечал драйвер, а в D3D12 и Vulkan бюджет отдали приложению: теперь движок и сам следит за Budget, и сам ужимает пул текстур, и сам дергает Evict, когда прижало. Если движок все это умеет, вы получаете мыло, но хотя бы плавное. А вот если не умеет, за дело берется системный менеджер, и вот тут-то и начинается самое интересное.

Как только процесс перевалил за бюджет, менеджер начинает переселять выделенные блоки в тот самый кусок оперативки. Причем не выгружать в своп, как многие думают, а переносить туда, откуда GPU может читать данные напрямую по шине. Игра, кстати, об этом даже не узнает: суслика она не видит, хоть он и есть. Она рисует себе дальше как ни в чем не бывало, просто часть ресурсов теперь лежит в DDR5 на другом конце PCIe. И каждое обращение к ним идет уже не на 448 ГБ/с, как у GDDR7 на 5060 Ti, а ровно на столько, сколько даст шина. А шина у RTX 5060 и 5060 Ti – это x8 (у RX 9060 XT все 16 линий, и это один из немногих ее настоящих козырей), так что и считать будем для x8:

Оперативка в таблице, кстати, указана не просто так. Ведь за шиной стоит еще и контроллер памяти процессора, и весь канал упирается в самое узкое из двух звеньев. Вот и получается, что в худшем случае, когда восьмигиговая карта стоит на B450 с DDR4, между GPU и текстурой, которая нужна ему прямо сейчас, лежит канал в 16 ГБ/с. То есть не 448 как надо, а в 28 раз меньше. И это мы еще не считаем задержки, которые тоже влияют на конечный результат, и притом весьма заметно.

Но и это еще не все, потому что при постоянном превышении бюджета менеджер начинает гонять блоки туда-сюда каждый кадр: один вытеснил, другой вернул, а в следующем кадре все наоборот. Microsoft в документации так прямо и пишет: процесс, который не влезает в бюджет, будут периодически замораживать, чтобы дать поработать остальным. Вот вам и фризы на 100–300 мс, которые ни один средний fps в жизни не поймает, просто потому что за секунду они растворяются в среднем.

Выселяет менеджер из VRAM, правда, далеко не все подряд. Приложение может расставить приоритеты через SetResidencyPriority, и нормальные движки так и делают: буферам кадра и DLSS – высокий, подгружаемым текстурам – низкий. Плюс драйвер помнит, что и когда использовали, а буферы кадра трогают каждый кадр, так что в хвост очереди они не попадают почти никогда, да и кто ж их выселит, они же памятник.

Первыми на вылет идут текстуры локации, из которой вы ушли 2 минуты назад, поэтому при небольшом переполнении картинка и не разваливается. Вот только редко нужное и совсем ненужное – это не одно и то же. Стоит развернуться на 180°, и холодные текстуры нужны прямо сейчас, причем все разом, а лежат они по ту сторону PCIe. Отсюда и типичная картина переполнения: ровные 60 fps, пока бежишь вперед, и провал до 15, стоит только резко повернуть камеру в сторону.

Как это выглядит в игре: три сценария и один обман

Переполнение VRAM в самой игре может проявляться в трех похожих друг на друга ипостасях. Причем похожих настолько, что из-за этого сходства зачастую даже бывает непонятно, что вообще чинить.

Сценарий первый, вежливый. Это когда движок умеет считать. Такие движки, как UE5, id Tech или Decima, держат для текстур отдельный пул с жестким лимитом, и как только они переполняются, то просто выбрасывают верхние мипы. Игра при этом не тормозит: fps ровный, редкие кадры в порядке, в тестах все прилично. А потом вы подходите к NPC и видите лицо, у которого текстура на пару мипов ниже, чем у стены за спиной. 

Помните Hogwarts Legacy на релизе, где на мыльные лица не жаловался только ленивый? Вот это оно и было. И это не баг. Движок сделал ровно то, что должен был: не дал игре упасть, а пожертвовал картинкой. Самое противное здесь в том, что обзоры с графиками fps этого не показывают в принципе, потому что на графике-то все хорошо. В итоге вы купили карту, она вроде тянет, и только через месяц замечаете, что текстуры на высоких выглядят примерно как на средних у соседа с GT 1050.

Ручка у этого поведения, кстати, вполне конкретная: в UE это r.Streaming.PoolSize, в id Tech – ползунок текстурного пула, тот самый, из-за которого Indiana Jones на пресете Supreme не давал себя запустить на 8 ГБ. И не потому что игре и правда нужно 12, а потому что мылить движок не умеет и не хочет.

Сценарий второй, честный. Это когда движок не ужимается или ужиматься ему уже некуда, и тогда за дело берется системный менеджер с переселением в оперативку. И вот тут уже начинаются настоящие цифры. TechSpot гонял RTX 5060 Ti 8 ГБ против 16 ГБ на разных поколениях PCIe, и в тяжелых сценах на PCIe 3.0 восьмигиговая выдала 27 кадров в среднем и всего 9 по редким (тот самый 1% low). Шестнадцатигиговая на тех же настройках оказалась быстрее на 130% в среднем и на 411% по редким. 411%, на минуточку, между двумя картами с одним и тем же чипом. А у ComputerBase на 27 играх в 1440p вышло так:

• в 12 играх у 8 ГБ проблем нет;

• в 11 – небольшие, по их меркам это минус 19% fps в среднем, но играть еще можно;

• в 9 – либо слайд-шоу, либо не запускается вовсе.

И это на PCIe 5.0. Что характерно, загрузка GPU при этом нередко проседает до 70%, и народ идет менять камень. А камень-то вообще ни при чем: чип просто ждет данные с другого конца шины. Так что упавшая загрузка – это симптом, а не диагноз. Диагноз – это когда общая память ползет вверх при выделенной в потолке.

Сценарий третий, окончательный. Это когда CreateCommittedResource возвращает E_OUTOFMEMORY, движок не знает, что с этим делать, и вы видите то самое «Out of video memory trying to allocate a rendering resource» (как это по-русски?). Обычно это случается в UE на загрузке уровня или при компиляции шейдеров, когда игра пытается создать что-то большое одним куском, например структуры для трассировки или буферы генерации кадров. Иногда вместо этого прилетает DXGI_ERROR_DEVICE_REMOVED и перезапуск драйвера по таймауту, и тогда экран моргнул, а игра закрылась.

А теперь обещанный обман. Дело в том, что ровно эта же ошибка про нехватку видеопамяти с 2024 года массово вылетает у владельцев Core i9-13900K и 14900K. Причем с RTX 4090 и 32 ГБ оперативки, где никакой нехватки нет и быть не может. Всему миной деградация Raptor Lake: нестабильность на высоких частотах ломает компиляцию шейдеров в UE, а движок заворачивает любой сбой выделения памяти в одну и ту же строку. Люди меняли видеокарты, а помогала в итоге прошивка BIOS с новым микрокодом. Так что если ошибка про видеопамять, а карта у вас на 16 или 24 ГБ, сначала проверьте процессор. Я серьезно.

PCIe как множитель, а не как причина

Несмотря на то что PCIe 3.0 всплывал в этой статье чуть ли не в каждом разделе, о самом-то главном мы так и не поговорили – а именно виновата ли шина сама по себе? Спойлер: нет.

Пока данные лежат в VRAM, по шине ходит мелочь вроде командных буферов и обновлений констант, и ей хватает любого поколения PCIe. Так что менять плату ради одной шины смысла нет, и кто говорит обратное, тот перевирает.

Другое дело, что происходит, когда игра вылезла за бюджет. Тут шина из мелочи превращается в единственный канал, по которому GPU достает выселенные текстуры, и вот здесь поколение решает все. То, что на PCIe 5.0 обошлось бы парой рывков, на 4.0 уже заметно, а на 3.0 превращается в неприемлемые 9-10 кадров. Так что шина – не причина беды. Шина – это ее множитель.

А ведь кто у нас вообще берет восьмигиговые карты? Явно не владельцы X870E. Их берут на B450, B550 и Z490, то есть на все то, что стоит у людей с 2019–2021 года и что менять никто не собирается. Ну, а что? Процессор-то еще нормальный, а переезд на AM5 с нынешними ценами на плашки DDR5 – это тысяч 45–50 сверху. Вот и получается связка, где самая уязвимая к переполнению карта встает на платформу с самым узким аварийным каналом.

Чем это ловить, если не Afterburner

Средний fps и Afterburner, как мы уже выяснили, переполнение не ловят. Зато его ловят три другие вещи, и ни одна из них не требует ничего сложнее бесплатной утилиты.

• Первая – это время кадра вместо fps. Откройте PresentMon или CapFrameX с графиком времени кадра, и переполнение будет видно сразу. Выглядит оно не как 45 вместо 60, а как ровная линия с одиночными шипами по 80–200 мс, которые вылезают на повороте камеры или на входе в новую зону. На графике fps все это размазывается в незаметный процент, а на графике времени кадра торчит так, что не пропустишь.

• Вторая – это два счетчика в HWiNFO рядом: GPU D3D memory dedicated, то есть выделенная, и GPU D3D memory dynamic, то есть та самая общая. Пока динамическая держится около нуля, все в порядке. Поползла вверх при выделенной в потолке, значит, текстуры уже уехали на другой конец шины. А вот если выделенная не в потолке, а мыло есть, то это первый сценарий, и крутить надо пул текстур в настройках, а не бежать за новой картой.

• Третья – это слот. GPU-Z покажет, на каком поколении PCIe и на скольких линиях карта реально договорилась с платой. Карта x8 на PCIe 3.0 – это не чуть медленнее, это вдвое уже аварийный канал у карточки, которой он понадобится первой. А если криво вставили или воткнули через райзер и линк договорился на x4, то все, что выше, умножается еще на два.

Сухой остаток

Если совсем коротко, то нехватка видеопамяти в 2026-м – это не одна проблема, а лестница из 4 ступенек: мыло, рывки, вылет и ложный вылет по вине процессора. И ни одну из них средний fps не покажет. Смотреть надо на время кадра, на динамическую память рядом с выделенной и на то, на скольких линиях договорился слот. Ну и на текстуры: высокие вместо ультра на восьмигиговой карте почти всегда лучше, чем ультра, из которых движок все равно выкинул верхние мипы.

Что до обещанного спасения в виде нейросетевого сжатия текстур, то заграница нам поможет, но не сейчас. NVIDIA показала на GTC сцену, где текстуры в BCn занимают 6,5 ГБ, а в NTC – 970 МБ, и это красиво. Вот только режим, который экономит VRAM на самом деле, стоит по замерам Tom’s Hardware 0,5–0,85 мс на кадр в одном проходе, без DLSS шумит так, что смотреть больно, и, по словам разработчика NTC Алексея Пантелеева, «жизнеспособен только на самых быстрых GPU». То есть на тех, у которых памяти и так хватает. А коммерческих игр с NTC на сегодня попробуй отыщи, так что это технология для следующего поколения консолей и для ждунов RTX 60.

Софт когда-нибудь догонит железо, но не в этом поколении и не на этих картах. А пока память дорожает быстрее, чем программисты учатся ее экономить, единственный рабочий способ не упереться в VRAM – просто в нее не упираться. Скучно, зато проверено.