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

В сентябре 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 — просто в нее не упираться. Скучно, зато проверено.