Технически Reflex - интеграция на уровне движка (через SDK), которая даёт игре возможность переупорядочить работу CPU и GPU так, чтобы рендер выполнялся “just‑in‑time”.

Ключевой механизм, который Reflex оптимизирует - GPU render queue (очередь кадров/команд перед GPU). Когда сцена становится GPU‑bound, CPU способен «готовить кадры заранее», и очередь накапливается: GPU рендерит текущий кадр, а CPU уже положил в очередь следующие. Это повышает пропускную способность, но почти неизбежно увеличивает задержку: ввод игрока отражается не в ближайшем кадре, а в одном из будущих, ожидающих в очереди.

Сценарий, когда Reflex приносит измеримую пользу - GPU‑bound (высокая загрузка видеокарты). Именно там без Reflex чаще всего накапливается render queue, и именно там Reflex способен «сжать» её почти до нуля, уменьшая вклад очереди в end‑to‑end задержку.

Важно и то, что соревновательные игры динамичны: одна и та же катка может постоянно переключать систему между CPU‑bound и GPU‑bound (дым, частицы, взрывы, массовые события). NVIDIA отдельно описывает этот «маятник» boundedness и логику Reflex: когда сцена внезапно становится GPU‑bound, SDK не даёт работе выстроиться в очередь; когда сцена проста и вы уходите в CPU‑bound, механизм удерживает latency низкой другими средствами (в т.ч. через Boost‑логики по частотам).

Есть несколько распространённых причин, почему Reflex включён, но «вау‑эффекта» нет - и это обычно означает не «не работает», а у Reflex просто нет большого буффера, который можно срезать:

Когда ограничителем выступает CPU/движок, CPU физически не успевает обработать достаточно кадров и render queue часто минимальна или отсутствует. Устранять нечего - поэтому выигрыш по latency становится скромным и зачастую заметен только на измерениях.

Если у вас условные 300–600 FPS, миллисекунды распределены иначе, и даже уменьшение очереди «на кадр» превращается в разницу, которую сложно надёжно увидеть в метриках без инструментальных замеров.

3) Жёсткие лимитеры/синхронизация.

Frame cap, V‑Sync и некоторые режимы VRR меняют то, где именно пайплайн «ждёт». Reflex при этом остаётся полезным как механизм недопущения лишней очереди, но не может сделать длинный кадр коротким: если вы ограничили игру до 60 FPS, один кадр уже ~16,7 мс.

С точки зрения архитектуры пайплайна отключение Reflex в поддерживаемых competitive‑играх редко даёт рациональный выигрыш:

В GPU‑bound сценах вы почти гарантированно возвращаете возможность накапливать render queue и увеличивать задержку ввода.

В CPU‑bound сценах Reflex чаще всего либо почти нейтрален, либо даёт минимальные улучшения.

И что важно: NVIDIA в своём руководстве по оптимизации системной задержки прямо рекомендует включать Reflex в игре, если он доступен.

На поверхности обе технологии «про одно и то же» - уменьшение задержки за счёт уменьшения очереди. Но разница принципиальная: уровень контроля.

Драйверный Low Latency Mode (Ultra‑Low Latency)

В 2019 NVIDIA представила Ultra‑Low Latency Mode как драйверную опцию, которая реализует “just in time” frame scheduling: кадр отправляется в очередь «прямо перед тем, как GPU он понадобится». NVIDIA указывает и типичную зону максимального эффекта: GPU‑bound и FPS порядка 60–100.

Также NVIDIA прямо отмечает ограничение по параметру: поддержка заявлена для DX9/DX11; в DX12/Vulkan решение о постановке в очередь контролируется игрой (1).

Reflex - это интеграция «внутрь игры». NVIDIA подчёркивает: за счёт прямой интеграции Reflex не только уменьшает render queue, но и снижает CPU back pressure, что даёт улучшения «выше и сверх» драйверных техник.

Более того, NVIDIA отдельно фиксирует правило приоритетов: если в игре есть Reflex, предпочтительнее использовать его; при включении обоих режимов Reflex получает более высокий приоритет.

Именно поэтому два режима могут казаться «похожими», но давать разный эффект: они вмешиваются в пайплайн на разных уровнях и имеют разную степень влияния на CPU/GPU pacing.

Путаница вокруг 1% low - это один из самых частых источников неправильных выводов о Reflex (и не только о нём).

Во‑первых, 1% low - это статистика распределения, а не мгновенное значение.

1% low / 0.1% low  обычно описывают как способ представить «хвост» производительности - худшие участки вывода кадров во времени - чтобы выявлять ситуации, когда средний FPS высокий, но присутствуют заметные провалы и “jarring gameplay” (1).

То есть это показатель про интервал измерения, а не «FPS прямо сейчас».

Во‑вторых, разные оверлеи считают “1%” по‑разному.

Существует отдельная методологическая ловушка: инструменты могут считать процентиль по frametime, а отображать результат как FPS, что создаёт визуально «странные» цифры. В PresentMon процентиль, применённый к frametime, и процентиль FPS — это не одно и то же; например, 99‑й процентиль frametime соответствует 1‑му процентилю FPS (из‑за обратной зависимости FPS=1/frametime)
(1).

В‑третьих, “фриз” не обязан ломать 1% low.

Один единичный спайк на 200–300 мс может быть очень заметен глазом, но при длинном окне измерения и высокой частоте кадров он может изчезнуть в статистике 1% (и сильнее проявиться в 0.1% low или max frametime). И наоборот: 1% low может выглядеть низким из‑за устойчиво «тяжёлого хвоста» frametime без единственного явного стоп‑кадра.

И здесь ключевой момент: Reflex оптимизирует latency, а 1% low описывает стабильность throughput. Они связаны, но не тождественны - поэтому оценивать Reflex только по 1% low методологически рискованно.

Источники:
https://www.nvidia.com/en-us/geforce/guides/system-latency-optimization-guide/
https://developer.nvidia.com/performance-rendering-tools/reflex
https://www.nvidia.com/en-us/geforce/news/reflex-low-latency-platform/