Почему игры тормозят даже на мощном ПК: откуда берутся фризы при компиляции шейдеров и почему их не лечит видеокарта

120 FPS и плавная игра - не одно и то же

Средняя частота кадров плохо описывает кратковременные остановки. Если большая часть кадров выводится за 7-8 мс, а один внезапно занимает 80 мс, счетчик FPS после этого снова покажет привычное трехзначное значение. Глаз запомнит другое: картинка на мгновение дернулась.

Поэтому при анализе таких проблем полезнее смотреть на frametime, время подготовки каждого отдельного кадра. При стабильных 60 FPS новый кадр должен появляться примерно каждые 16,7 мс, при 120 FPS - каждые 8,3 мс. Один кадр продолжительностью 50 или 100 мс уже создает заметный рывок, хотя за следующую секунду средний FPS может почти восстановиться.

Шейдерная компиляция интересна именно этим. Она может практически не изменить среднюю производительность сцены после завершения работы, но испортить первый момент появления нового материала, эффекта, объекта или варианта освещения.

Из-за этого возникает на первый взгляд странная ситуация. Владелец меняет видеокарту среднего класса на гораздо более быструю, FPS заметно растет, а знакомый рывок возле той же двери остается.

Что такое шейдер и зачем его вообще компилировать

Современный GPU не получает от игры команду вроде "нарисуй мокрый асфальт с отражением фонаря". Видеокарта выполняет специализированные программы, которые определяют, что нужно делать с вершинами, пикселями и другими данными в графическом конвейере.

Такие программы называются шейдерами. Vertex shader обрабатывает вершины геометрии, pixel или fragment shader участвует в вычислении итогового цвета пикселя, compute shader используется для более общих параллельных вычислений. В современном рендерере применяются и другие стадии, особенно если задействована трассировка лучей.

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

В движке исходный вариант еще не является программой, которую конкретный GPU может непосредственно выполнить. Код проходит несколько стадий подготовки и в итоге должен превратиться в машинное представление, подходящее определенной архитектуре GPU и драйверу.

Именно часть этой работы игрок иногда оплачивает временем кадра.

Почему нельзя один раз скомпилировать шейдер и положить его в игру

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

ПК устроен иначе. Одна копия игры должна работать на GeForce, Radeon и Intel Arc разных поколений, с разными версиями драйверов. Даже две видеокарты одного производителя могут использовать разные архитектуры и требовать разного низкоуровневого кода.

Игра поэтому обычно распространяет шейдеры в форме, которая еще требует обработки на пользовательской системе. Для DirectX это может быть промежуточное представление DXIL, для Vulkan применяется SPIR-V. Дальнейшая работа уже зависит от графического API и драйвера.

Microsoft прямо называет компиляцию шейдеров одной из причин долгого первого запуска и внутриигровых заиканий в описании Advanced Shader Delivery. Компания объясняет проблему тем, что традиционно финальная компиляция зависит от сочетания самой игры, GPU и драйвера.

Отсюда следует неприятный для владельца ПК вывод: наличие готовой игры на диске еще не означает, что абсолютно весь исполняемый графический код для его видеокарты уже существует.

Фото: Andrey Matveev

Шейдер и PSO - не совсем одно и то же

Фраза "компиляция шейдеров" удобна, но современная проблема шире.

В Direct3D 12 движок работает с Pipeline State Object, PSO. Такой объект объединяет набор состояний графического конвейера, необходимых для определенного варианта рендеринга. Туда входят используемые шейдеры и параметры, связанные с rasterization, depth/stencil, blending и другими частями pipeline.

Преимущество подхода в том, что драйвер получает заранее описанное состояние вместо множества мелких изменений прямо перед отрисовкой. Недостаток проявляется, если нужная комбинация встретилась впервые и PSO приходится готовить слишком поздно.

Epic в документации Unreal Engine отдельно связывает shader compilation, PSO и framerate hitches. В описании PSO Precaching движок собирает возможные PSO и асинхронно готовит их заранее, чтобы нужное состояние не пришлось создавать в самый неудобный момент.

Именно поэтому в техническом разговоре выражение PSO compilation stutter часто точнее простого "шейдеры компилируются".

Что происходит в кадре, который внезапно занимает 100 мс

Представим, что игрок впервые входит в помещение. Там появляется материал стекла с определенным режимом прозрачности, динамический источник света, частицы пыли и отражение.

Движок начинает формировать команды для GPU и обнаруживает, что соответствующий вариант pipeline еще не готов. Если подготовка не была выполнена заранее и нет подходящего результата в кэше, системе приходится создать его сейчас.

Часть работы выполняется на CPU и внутри драйвера. В этот момент рендер не может продолжить нужную операцию так же быстро, как в обычном кадре. Вместо условных 8 мс кадр занимает 40, 80 или 150 мс.

Следующий кадр снова укладывается в норму.

Внешне это ощущается не как постоянный низкий FPS, а как одиночный толчок. Если подобных новых состояний много, игра начинает подергиваться при перемещении по ранее не посещенным областям.

Почему второй проход по тому же месту часто становится плавным

Результат компиляции можно сохранить.

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

Это дает характерный способ распознавания проблемы. Игрок проходит один участок и замечает рывки. Перезагружает сохранение, идет тем же путем второй раз, и большинство рывков исчезает.

Такое поведение хорошо согласуется с прогревом shader или pipeline cache.

Khronos показывает тот же принцип в документации Vulkan. В официальном примере Pipeline Management создание pipeline без готового кэша занимает больше времени и способно вызвать внезапное увеличение времени кадра. Сохраненный VkPipelineCache позволяет повторно использовать подготовленные данные между запусками приложения.

Это не означает, что любой исчезающий после второго прохода фриз обязательно вызван шейдером. Кэшируются также данные файловой системы, игровые ресурсы и другие компоненты. Но повторяемость "первый раз плохо, второй хорошо" является сильной зацепкой.

Почему после обновления драйвера фризы могут вернуться

Кэш не всегда можно использовать после изменения программной среды.

Скомпилированный результат зависит от драйвера и аппаратной платформы. После установки другой версии драйвера старые бинарные данные могут стать несовместимыми или быть намеренно признаны недействительными.

Тогда игра снова встречает часть состояний впервые.

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

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

В Unreal Engine bundled PSO caches тоже привязаны к конкретным данным игры. Epic указывает, что значительные изменения контента и шейдеров могут сделать накопленные записи несовместимыми.

Поэтому сравнивать плавность до и сразу после большого обновления нужно осторожно.

Откуда берется экран "Compiling Shaders" перед запуском игры

Некоторые разработчики предпочитают решить проблему грубо, но предсказуемо: заставить пользователя подождать.

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

С точки зрения пользователя старт стал дольше. С точки зрения frametime это хороший обмен. Лучше несколько минут один раз посмотреть на индикатор, чем получать десятки пауз в бою.

Особенно это заметно в играх на современных API, где количество возможных состояний велико.

Но заранее подготовить абсолютно все бывает сложно. Количество вариантов растет из-за комбинаций материалов, эффектов и настроек, а часть состояний зависит от того, что реально появится во время игры.

Поэтому даже после отдельного экрана подготовки редкие shader hitches полностью не исключены.

Почему игру нельзя заставить скомпилировать вообще все возможные варианты

Проблема быстро упирается в комбинаторику.

Допустим, материал поддерживает несколько вариантов освещения, теней, геометрии, качества отражений и эффектов. Каждый переключатель способен создавать дополнительную permutation, то есть отдельный вариант шейдера.

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

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

Приходится выбирать: подготовить распространенные состояния заранее, остальные компилировать асинхронно либо столкнуться с редкой работой непосредственно во время игры.

На этом месте проблема из "медленной видеокарты" превращается в задачу проектирования движка.

Почему Unreal Engine часто упоминают рядом с shader stutter

Unreal Engine широко используется в современных PC-играх, поэтому его проблемы хорошо заметны статистически. Но сам движок не создает фундаментальную проблему компиляции: с необходимостью подготовки shader и pipeline работают и собственные движки.

Причина репутации Unreal связана с большим числом проектов, динамическими материалами, разнообразием контента и тем, как предыдущие поколения движка собирали PSO.

Epic эту проблему не отрицает. В актуальных версиях UE5 используется PSO precaching: движок пытается определить необходимые графические состояния и запустить их подготовку до момента непосредственной отрисовки.

При этом даже документация Epic признает, что отдельные PSO могут возникать непосредственно во время работы. Разработчикам нужно следить, какие pipeline не удалось подготовить заранее, и закрывать оставшиеся случаи.

То есть Unreal Engine дает инструменты, но сам факт использования UE5 не гарантирует отсутствие shader stutter.

Фото: Matheus Bertelli

Почему одна игра на Unreal Engine дергается, а другая работает ровно

Движок - фундамент, а не готовая игра.

Студия решает, какие материалы использовать, как собирать PSO, когда запускать precaching, сколько комбинаций существует, что разрешено создавать динамически и как устроены загрузочные экраны.

Можно сделать игру на Unreal и заранее пройти большое количество необходимых pipeline. Можно оставить редкие состояния на runtime и получить фриз в момент первого появления эффекта.

Поэтому фраза "это Unreal, значит будет тормозить" технически слабая. Правильнее оценивать конкретную реализацию.

Разработчик также может исправить shader stutter патчем, не меняя графику и системные требования. Достаточно изменить процедуру precaching или включить в набор ранее пропущенные PSO.

Почему более мощный процессор иногда помогает, но не решает проблему

Компиляция создает нагрузку на CPU. Быстрый процессор способен закончить часть работы быстрее, особенно если система умеет распараллеливать задачи.

Но есть предел.

Если рендер-поток должен дождаться результата определенной компиляции, задержка все равно попадет в frametime. Вместо 100 мс она может стать 50 мс, но это все еще заметный рывок.

Дополнительно часть работы находится в драйвере и зависит от реализации конкретного pipeline.

Поэтому Ryzen 9 или Core Ultra верхнего класса способен уменьшить тяжесть ситуации, но покупка CPU не исправляет архитектурно позднюю подготовку PSO.

Это одна из причин, почему shader stutter встречается на системах, которые по обычным игровым тестам намного превышают рекомендуемые требования.

Почему более быстрая видеокарта помогает еще меньше

Финальный шейдер исполняется на GPU, но фриз возникает во время подготовки к его выполнению.

Можно поставить видеокарту, которая после завершения компиляции рисует сцену со 160 FPS вместо 80 FPS. При этом первый неожиданный PSO по-прежнему требует подготовки.

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

Пользователь видит низкую загрузку GPU во время рывка и иногда делает вывод, что видеокарта неисправна. На деле GPU может просто ждать, пока CPU, движок и драйвер подготовят следующие команды.

Высокая производительность GPU не устраняет ожидание работы, которая должна завершиться до начала отрисовки.

Почему увеличение объема видеопамяти тоже не является лекарством

Недостаток VRAM действительно вызывает собственные проблемы: вытеснение ресурсов, обращение к системной памяти, нестабильный frametime и провалы производительности.

Но shader compilation stutter способен происходить при совершенно свободной видеопамяти.

Если новый PSO нужно собрать сейчас, наличие еще 8 ГБ VRAM не делает его заранее скомпилированным.

Это хороший пример двух внешне похожих проблем с разными причинами. В обоих случаях игра может подергиваться при появлении нового контента, но диагностические признаки отличаются.

Проблема VRAM чаще усиливается с ростом разрешения, качества текстур и ray tracing. Shader stutter сильнее связан с первым появлением определенного состояния и может исчезнуть при повторном прохождении.

SSD тоже не способен убрать shader stutter

Еще одно распространенное объяснение любого фриза - медленный накопитель.

Игре действительно приходится подгружать текстуры, геометрию, аудио и другие данные. Если накопитель или путь загрузки не справляется, возникает streaming stutter.

Но скорость SSD и скорость компиляции pipeline - разные вещи.

Переход с SATA SSD на быстрый PCIe 5.0 NVMe может заметно ускорить определенные загрузки, но неизвестный PSO все равно придется подготовить.

Быстрый накопитель помогает быстрее читать уже существующий shader cache и игровые ресурсы. Он не превращает отсутствующий скомпилированный вариант в готовый.

Поэтому совет "поставь игру на NVMe" может решить фризы от asset streaming и ничего не изменить в тех же внешне похожих рывках от компиляции.

Как отличить shader stutter от подгрузки ресурсов

Абсолютной диагностики по одному наблюдению нет, но характер поведения многое подсказывает.

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

Streaming stutter способен повторяться при каждом быстром перемещении в новую область, особенно если системе приходится снова подгружать вытесненные ресурсы. Его выраженность может зависеть от скорости накопителя, объема RAM и VRAM.

У shader compilation есть еще один характерный момент: после очистки кэша или обновления драйвера старые фризы возвращаются, а затем постепенно исчезают.

Лучший способ проверки - записать frametime двух одинаковых проходов. Если пики четко привязаны к первому появлению событий и исчезают во втором, версия с кэшем становится значительно убедительнее.

Traversal stutter выглядит похоже, но имеет другую природу

В больших открытых мирах встречается еще один класс рывков. Игрок пересекает невидимую границу между областями, движок активирует новые объекты, физику, AI, геометрию или другие системы.

Такой фриз часто называют traversal stutter.

Внешне он напоминает компиляцию: короткий пик frametime в определенной точке карты. Но если пройти назад и снова пересечь ту же границу, рывок способен повториться.

Причина может находиться на CPU и вообще не иметь прямого отношения к shader cache.

Особенно неприятно, когда несколько механизмов накладываются. Первый переход через границу одновременно вызывает загрузку контента и создание новых PSO. После прогрева часть фриза исчезает, но небольшой повторяемый traversal spike остается.

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

Почему ограничение FPS иногда делает игру приятнее, но не лечит проблему

Предположим, GPU способен выдавать от 90 до 160 FPS. Frametime постоянно меняется даже без крупных фризов. Если ограничить частоту до стабильных 90 кадров, обычная нагрузка становится ровнее.

На этом фоне часть мелких колебаний действительно ощущается слабее.

Но кадр продолжительностью 80 мс останется кадром продолжительностью 80 мс. Лимитер не заставит нужный pipeline появиться заранее.

Поэтому ограничение FPS полезно для стабилизации общего frametime и снижения загрузки GPU, но относить исчезновение shader compilation к самому ограничителю нельзя.

Если после лимита проблема полностью пропала, стоит искать и другие причины: GPU saturation, особенности frame generation, синхронизацию или CPU/GPU-баланс.

Почему снижение графики тоже иногда ничего не меняет

Игрок последовательно переводит Ultra в High, отключает тени, уменьшает текстуры и получает в среднем еще 30 FPS. Фриз остается.

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

Некоторые параметры, напротив, способны изменить набор используемых шейдеров и PSO. После смены настроек игра может начать компилировать другие варианты, и первое прохождение даже временно станет хуже.

Особенно это касается включения и отключения ray tracing, изменения сложных эффектов и некоторых режимов освещения.

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

Почему Ray Tracing делает задачу сложнее

Трассировка лучей добавляет дополнительные шейдерные программы и состояния. Современная игра может использовать ray generation, miss, closest-hit и другие стадии, а также различные комбинации материалов и эффектов.

Количество вариантов увеличивается.

Это не означает, что ray tracing автоматически создает shader stutter. Разработчик может подготовить необходимые состояния заранее.

Но чем сложнее рендерер и чем больше динамических комбинаций, тем труднее обеспечить полное покрытие precaching.

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

Почему Frame Generation не скрывает настоящий hitch

DLSS Frame Generation, FSR Frame Generation и похожие технологии вставляют дополнительные кадры между отрендеренными.

Если базовый рендер идет стабильно, движение становится визуально плавнее.

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

Иногда счетчик с Frame Generation выглядит особенно обманчиво. Он показывает высокий итоговый FPS, тогда как редкий крупный frametime spike остается заметным.

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

Что хранится в shader cache на диске

Это зависит от API, драйвера и игры.

Драйвер может хранить результат собственной компиляции. Движок способен вести отдельный pipeline cache. Vulkan позволяет приложению сохранять VkPipelineCache на диск и загружать его при следующем запуске.

Поэтому на ПК иногда существует несколько разных уровней кэширования одновременно.

В Windows каталог такого кэша может выглядеть для пользователя как набор непонятных бинарных файлов. Удалять его "для очистки компьютера" без причины невыгодно.

Свободное место вы получите, а первая игровая сессия после удаления способна стать хуже, потому что необходимые варианты придется создавать заново.

Почему программы очистки shader cache могут добавить фризов

Некоторые утилиты обслуживания Windows предлагают удалять DirectX Shader Cache вместе с временными файлами.

Это не опасно для системы. Кэш создается заново.

Но слово "временный" здесь не означает "бесполезный".

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

Поэтому регулярно очищать shader cache ради нескольких сотен мегабайт или гигабайт без конкретной причины нет смысла.

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

Почему увеличение лимита shader cache не всегда что-либо исправляет

В драйверах встречаются настройки размера shader cache, поэтому вокруг них появились многочисленные "оптимизационные" инструкции.

Большой кэш может быть полезен, если из-за ограничения старые записи слишком активно вытесняются. Но сам размер не исправляет позднее создание PSO.

Если нужный вариант никогда раньше не компилировался, хоть 100 ГБ пустого пространства кэша не помогут.

Если разработчик неправильно организовал precaching и игра постоянно создает новые состояния в критический момент, драйверская настройка тоже не переделает архитектуру движка.

Поэтому изменение лимита имеет смысл только тогда, когда установлен именно дефицит места для уже создаваемого кэша.

Почему модифицированные "готовые shader cache" из интернета сомнительны

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

На ПК результат может быть привязан к модели или архитектуре GPU, версии драйвера, версии игры и графическим настройкам.

Один файл, который работает у автора с определенной Radeon, необязательно применим к GeForce или даже к другому драйверу того же производителя.

Кроме технической несовместимости остается обычный риск скачивания неизвестных бинарных файлов с постороннего сайта.

Если игра или платформа официально распространяет предварительно подготовленные данные, ситуация другая. Там совместимость контролируется всей цепочкой поставки.

Почему Steam на Linux умеет заранее обрабатывать шейдеры

Проблема особенно интересна в Linux-играх через Vulkan и Proton. Valve использует shader pre-caching, чтобы часть необходимой работы выполнялась до непосредственного игрового процесса.

Это один из примеров того, как платформенный уровень пытается компенсировать разнообразие PC-конфигураций.

Однако универсально решить задачу непросто. Меняются игра, графический стек, драйвер и оборудование. Некоторые данные приходится перестраивать.

Поэтому даже хорошо организованная платформа не гарантирует отсутствия каждого runtime hitch в каждой игре.

Сам принцип при этом совпадает с консольной логикой: сделать дорогую работу до того момента, когда игроку нужен следующий кадр.

DirectX 12 дал разработчикам больше контроля и больше ответственности

С DirectX 11 значительную часть управления состояниями и оптимизаций скрывал драйвер. Современные низкоуровневые API вроде Direct3D 12 и Vulkan передали движку больше контроля над ресурсами, синхронизацией и pipeline.

Это позволяет лучше использовать современное железо и уменьшать CPU overhead.

Одновременно разработчик должен раньше принимать решения, которыми раньше в большей степени занимался драйвер.

PSO хорошо иллюстрирует этот обмен. Если необходимые объекты подготовлены заранее, рендер работает предсказуемо. Если создать их в момент первого draw call, стоимость сразу становится проблемой времени кадра.

Поэтому shader stutter нельзя описать как "DirectX 12 плохой". API предоставляет механизмы для эффективной работы. Вопрос в том, когда и как игра их использует.

Почему на консоли та же игра может работать плавнее

Это одна из областей, где фиксированная платформа имеет реальное преимущество.

Разработчик знает конкретный GPU, драйвер и конфигурацию системы. Не нужно готовить вариант для десятков семейств видеокарт и множества драйверов.

Можно заранее выполнить значительно больше платформозависимой работы и проверить весь набор состояний на одном известном оборудовании.

На ПК игра должна адаптироваться к системе после установки.

Это не оправдывает плохо подготовленный PC-порт. Разработчики могут и должны использовать precaching и другие методы. Но техническая задача действительно сложнее, чем на фиксированной консольной платформе.

Фото: hoeldino

Что Microsoft пытается изменить с Advanced Shader Delivery

До недавнего времени типичный PC сам выполнял значительную часть аппаратно-зависимой компиляции. Microsoft решила вынести часть работы из компьютера пользователя.

Advanced Shader Delivery, ASD, использует State Object Database. Игра или инструменты собирают сведения о необходимых состояниях, после чего аппаратный производитель может использовать offline compiler для подготовки Precompiled Shader Database под конкретную конфигурацию.

Готовые данные доставляются вместе с игрой через поддерживаемую инфраструктуру.

Смысл здесь интереснее простого нового кэша. Результат компилируется не в самый первый момент на PC игрока, а заранее вне его системы, после чего загружается подходящий набор.

В марте 2026 года Microsoft сообщила о расширении Advanced Shader Delivery для Windows и работе с AMD, Intel, NVIDIA, Qualcomm и Epic. К лету 2026 года ASD вышла за пределы первоначального сценария ROG Xbox Ally, а поддержка начала расширяться на обычный PC-рынок.

Это уже не теория о том, как когда-нибудь можно решить shader stutter. Инфраструктура постепенно появляется в Windows.

Почему ASD не исправит старые игры одним обновлением Windows

Чтобы предварительно доставить корректно скомпилированные данные, нужно знать, какие pipeline требуются игре, собрать соответствующую базу и связать ее с системой распространения и драйвером.

Если старый проект ничего такого не предоставляет, Windows не может надежно угадать абсолютно все состояния игры.

Microsoft развивает инструменты, позволяющие собирать State Object Database, но массовое покрытие библиотеки PC-игр требует участия экосистемы.

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

Даже при полном покрытии shaders останутся другие виды stutter: traversal, asset streaming, сборка мусора, CPU spikes, нехватка памяти и ошибки самой игры.

Почему драйвер NVIDIA или AMD сам не может полностью решить проблему

Драйвер может кэшировать результат и выполнять собственные оптимизации.

Но он не знает игровую сцену так, как ее знает движок.

Драйвер видит запрос на создание pipeline. Если запрос пришел за миллисекунду до того, как pipeline понадобится, пространство для маневра уже маленькое.

Движок способен знать намного раньше, что через загрузочный экран игрок попадет на уровень, где понадобятся определенные материалы и состояния. Именно поэтому правильный precaching лучше надежды на драйвер.

Advanced Shader Delivery пытается соединить эти уровни: информацию от игры, offline compiler производителя GPU и механизм доставки магазина.

Почему игроки часто обвиняют Windows

Иногда обоснованно: ОС, драйверная модель и фоновые процессы тоже способны влиять на frametime.

Но характерный shader hitch рождается на стыке нескольких компонентов. Игра выбрала момент создания PSO, графический API передал запрос, драйвер должен сгенерировать аппаратный код, CPU выполняет работу, а система кэширования решает, можно ли использовать уже готовый результат.

Поэтому установка "чистой Windows" может временно даже усилить проблему. Все старые shader caches исчезли, и первые игровые запуски начинаются с нуля.

После нескольких часов ситуация улучшается, что иногда ошибочно принимают за "Windows сама оптимизировалась".

В реальности прогрелись игровые и драйверные кэши.

Может ли антивирус усиливать микрофризы

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

Но это не типичное универсальное объяснение shader stutter.

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

Если frametime spike возникает строго при первом появлении графического эффекта и исчезает при повторении, архитектура pipeline остается более вероятной причиной.

Отключать защиту Windows на основании случайного совета из ролика смысла нет.

Почему быстрые ядра CPU иногда важнее их количества

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

Но не каждая работа бесконечно масштабируется по потокам.

Если критический pipeline нужен прямо сейчас, задержка может зависеть от одной или нескольких последовательных стадий. Тогда производительность отдельного ядра влияет сильнее, чем наличие еще десятка свободных потоков.

Это объясняет, почему два процессора с одинаковым числом ядер могут по-разному проходить период shader compilation.

Но снова речь идет о степени проблемы, а не об исправлении. Грамотно подготовленная игра по возможности не должна ставить такую работу на путь критического кадра.

Почему 1% Low тоже не всегда рассказывает всю историю

1% Low полезнее среднего FPS для оценки нестабильности, но одиночный огромный hitch может раствориться даже в этом показателе.

Особенно при длительном бенчмарке.

Например, трехминутный проход содержит тысячи кадров. Несколько очень длинных кадров ухудшат ощущения, но агрегированная цифра не покажет их расположение и причину.

Для анализа shader stutter лучше график frametime.

На нем видно, что происходит: постоянная "гребенка", редкие огромные пики, регулярные рывки через одинаковые промежутки или несколько крупных всплесков только в первом проходе.

Форма графика часто полезнее любого единственного числа.

Как проверить игру на shader stutter без специальной лаборатории

Нужен воспроизводимый участок.

Запускаем игру после нормальной загрузки, проходим короткий маршрут и записываем frametime. Желательно выбрать место, где появляются разные противники, эффекты и материалы.

Затем без изменения графических настроек повторяем тот же маршрут.

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

После обновления драйвера можно провести тот же тест снова. Возвращение пиков на первом проходе даст еще одну зацепку.

Такой эксперимент намного полезнее смены десяти параметров одновременно.

Почему чистый тест лучше проводить после перезапуска игры

Обычный повтор маршрута внутри одной сессии показывает эффект памяти и внутренних кэшей движка.

Перезапуск дает следующий уровень проверки: сохраняется ли результат между запусками.

Если второй проход плавный только до закрытия игры, возможно, используется преимущественно оперативный кэш.

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

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

Когда очистка shader cache действительно полезна

Есть несколько ситуаций, когда начать с чистого состояния разумно.

Игра получила крупное обновление и стала вести себя аномально. После установки драйвера появились графические ошибки. Кэш явно поврежден. Нужно провести воспроизводимый тест первого запуска.

Тогда его можно удалить штатными средствами Windows или драйвера.

После очистки первый запуск нельзя использовать как доказательство ухудшения производительности. Именно он обычно является самым тяжелым.

Правильное сравнение требует одинаковых условий: чистый кэш против чистого кэша либо уже прогретый против прогретого.

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

Если игра создает нужный PSO непосредственно в критическом render path и не готовит его заранее, набор пользовательских настроек ограничен.

Можно установить актуальный драйвер, не удалять кэш, дождаться предусмотренной игрой предварительной компиляции и проверить отсутствие фоновой нагрузки.

Но нельзя через панель NVIDIA или AMD заставить движок заранее узнать все состояния, которые разработчики не включили в precaching.

Именно здесь полезно признать предел домашних "оптимизаций".

Если тысячи владельцев разных конфигураций получают одинаковый одноразовый фриз в одной сцене, менять Windows, SSD, память и BIOS в надежде на чудо вряд ли рационально. Нужен патч игры или изменение драйверной/платформенной инфраструктуры.

Почему обзор PC-игры должен проверять первый проход

Обычный встроенный бенчмарк запускают несколько раз и берут средний результат. Для стабильной оценки GPU это правильно: первый прогон часто отбрасывают как прогревочный.

Но именно поэтому shader compilation может полностью исчезнуть из обзора.

Первый проход дергался, второй прогрел кэш, третий дал красивый график. В таблицу попадает третий.

Для обзора производительности видеокарты такой метод имеет смысл. Для оценки состояния самого PC-порта он скрывает существенную часть пользовательского опыта.

Человек после покупки игры проходит сцену впервые, а не в четвертый раз подряд.

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

Почему мощный тестовый стенд здесь особенно полезен

Обычно сверхмощный CPU и GPU нужны для того, чтобы убрать аппаратное ограничение из теста.

С shader stutter тот же принцип работает наоборот: если система способна постоянно выдавать 150-200 FPS, любой длинный кадр становится хорошо виден.

Когда игра работает в среднем на 35 FPS, общий frametime и так высокий. Дополнительный провал сложнее отделить визуально.

Если же RTX верхнего уровня вместе с быстрым Ryzen или Core демонстрирует одинаковый резкий spike в конкретной сцене, аргумент "компьютер слабый" быстро отпадает.

Это и есть причина, по которой проблемы компиляции становятся заметными в технических разборах дорогих игровых систем.

Что делать игроку на практике

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

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

Shader cache без причины лучше не чистить. Утилиты "оптимизации" Windows, которые регулярно удаляют его вместе с мусором, могут каждый раз возвращать часть разовой работы.

Если фризы постоянные, следует записать два одинаковых прохода. Исчезают пики во втором - вероятен фактор кэширования. Повторяются в тех же географических точках - стоит проверить traversal и streaming. Усиливаются вместе с заполнением VRAM - отдельно изучать память.

Так диагноз постепенно становится конкретным.

Что не стоит делать

Переустанавливать Windows после первого найденного frametime spike рано.

Покупать более быстрый NVMe только ради shader compilation тоже.

Добавление RAM, увеличение файла подкачки, отключение службы печати, таймеров Windows и десятков случайных функций BIOS не исправляет поздно созданный pipeline.

Особенно осторожно стоит относиться к "готовым оптимизированным shader caches" неизвестного происхождения и утилитам, которые обещают убрать все статтеры одной кнопкой.

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

Хорошая новость: проблема технически решаема

Shader compilation stutter не является неизбежным свойством PC.

Его можно уменьшить или практически убрать, если необходимые pipeline известны заранее и подготавливаются до первого использования.

Unreal Engine развивает PSO Precaching. Vulkan имеет pipeline cache. Direct3D предоставляет инструменты сохранения pipeline state. Драйверы ведут собственные кэши. Microsoft строит Advanced Shader Delivery, чтобы подходящие аппаратно-зависимые результаты приезжали на PC уже подготовленными.

То есть вся индустрия движется в одном направлении: вынести дорогостоящую работу из игрового кадра.

Сложность состоит в количестве игр, GPU, драйверов и возможных состояний рендера.

Почему Advanced Shader Delivery может оказаться важнее очередных 10% производительности GPU

Современная игровая видеокарта уже способна выводить очень высокий FPS. Пользователь все чаще замечает не недостаток средней скорости, а нарушение равномерности кадров.

Дополнительные 10% производительности легко показать полоской в диаграмме. Исчезнувший 100-миллисекундный hitch намного труднее выразить одним числом, но субъективно он способен дать больше.

В этом смысле предварительная доставка шейдеров затрагивает одну из старых слабостей открытой PC-платформы: необходимость выполнять аппаратно-зависимую подготовку уже после установки игры.

Если ASD и похожие механизмы получат широкую поддержку магазинов, движков и производителей GPU, фраза "первый запуск всегда дергается, потом проходит" может постепенно перестать считаться нормой.

Но на 2026 год технология еще не означает, что shader compilation stutter исчез со всей библиотеки Windows-игр.

Почему термин "оптимизация игры" здесь наконец можно разложить по конкретным действиям

Игроки часто говорят, что порт "плохо оптимизирован", объединяя одним выражением низкий FPS, фризы, высокое потребление VRAM и загрузку CPU.

Для shader stutter причина намного конкретнее.

Есть shader permutations. Есть PSO. Есть момент их компиляции. Есть кэш. Есть возможность подготовить pipeline до первого draw. Есть варианты, которые разработчик не смог или не успел precache.

Это позволяет отделить проблему от общей производительности.

Игра способна быть очень быстрой после прогрева и при этом иметь плохую подготовку первого прохождения. Другая может работать с меньшим средним FPS, но выдавать почти ровный frametime.

Для восприятия плавности второй вариант иногда приятнее.