[h1]🖼️ Апскейлингу — да, генерации кадров — нет[/h1]
Сначала два дисклеймера.
[list]
[*]Lossless Scaling я тестировал и на основном ПК — конфигурация приложена к отзыву, — и на Steam Deck.
[*]Этот текст не только про конкретную «утку», но и про frame generation как технологию в целом. Реализации LSFG, NVIDIA Frame Generation отличаются по качеству, но базовая претензия одна: сгенерированный кадр не равен реально рассчитанному кадру.
[/list]
Сразу уточню: [b]Lossless Scaling технически делает то, что заявлено[/b]. Апскейлинг работает, LSFG генерирует промежуточные кадры, а частота предъявления изображения растет. Мой отрицательный отзыв не про «обман» или неработающую программу. Он про практическую ценность технологии, которую сегодня из каждого утюга называют must-have для слабых устройств, особенно для Steam Deck.
[h2]🔍 Почему апскейлинг я в итоге принял[/h2]
Когда в 2018 году начали массово продвигать DLSS, я относился к нему максимально скептически. Тем более что DLSS 1 действительно выглядел плохо. Да и в целом я много лет предпочитал играть вообще без сглаживания: spatial aliasing и «лесенки» мой мозг воспринимал как четкую пиксельную структуру, а не как дефект. Размытие от TAA раздражало сильнее.
Со временем ситуация изменилась. Во многих современных играх temporal anti-aliasing уже нельзя нормально отключить, а так называемое «нативное» изображение все равно проходит через временную фильтрацию. Выбор часто выглядит уже не как «идеально четкий native без AA против DLSS», а как [b]мыльный TAA против DLSS с дополнительной производительностью[/b].
Апскейлер снижает внутреннее разрешение рендера, а затем реконструирует изображение до целевого. В GPU-bound сценарии это уменьшает стоимость настоящего кадра, снижает GPU frame time и позволяет движку реально рассчитывать больше кадров в секунду.
Цена есть: потеря высокочастотных деталей, ghosting, temporal instability и размытие в движении. Но в моем опыте современные DLSS/FSR/XeSS дают [b]разительно более качественный результат[/b], чем простое снижение выходного разрешения или render scale до сопоставимого числа пикселей.
Я не полюбил мыло. Просто в какой-то момент за примерно сопоставимую потерю четкости мне начали давать больше [b]реально отрисованных[/b] кадров. Это понятный компромисс.
[h2]🎞️ Реальные и сгенерированные кадры — не одно и то же[/h2]
Высокий FPS нужен не только ради визуальной плавности. Важнее полный контур обратной связи:
[b]ввод → игровая симуляция → рендер → вывод на дисплей.[/b]
Когда апскейлинг повышает базовый FPS, движок чаще формирует новые состояния игрового мира и новые кадры, содержащие реакцию на ввод. Обычно сокращается frame time и уменьшается end-to-end latency — пока система не упирается в CPU или другое ограничение.
Frame generation решает другую задачу. Он вставляет синтетические изображения между реально отрисованными кадрами и повышает [i]presentation frame rate[/i]. Картинка становится плавнее, но новый промежуточный кадр не является новым шагом игровой симуляции и не содержит независимо рассчитанной реакции на свежий ввод.
Поэтому 120 реальных FPS ощущаются отзывчивее, чем 60 реальных FPS даже на 60-герцовом мониторе. Дисплей не покажет все 120 кадров, но к моменту очередного сканирования может получить более свежий кадр. Возраст отображаемой информации уменьшается.
А условные 30 → 60 через FG — это повышение частоты предъявления изображений, а не перевод всего игрового контура на 60 Гц.
[h2]🎮 Steam Deck: нарисованные 60 не заменяют настоящие 60[/h2]
Представим типичный для слабого устройства сценарий. Игра работает в районе 30–35 FPS. Мы фиксируем базу на 30 и с помощью LSFG получаем на счетчике условные 60.
Визуальное движение действительно становится плавнее. Но:
[list]
[*]базовый frame time остается около 33,3 мс;
[*]новые состояния игрового мира по-прежнему рассчитываются примерно 30 раз в секунду;
[*]управление не начинает ощущаться как при нативных 60 FPS;
[*]сам этап генерации и вывода тоже имеет вычислительную стоимость;
[*]при низкой базе заметнее ошибки интерполяции, проблемы с интерфейсом, частицами, перекрытиями и быстрыми движениями.
[/list]
Чем больше временной интервал между настоящими кадрами, тем больше движения алгоритму приходится восстанавливать. Получается парадокс: [b]чем ниже базовый FPS и чем сильнее хочется «удвоения», тем хуже исходные условия для frame generation[/b].
Поэтому для себя я предпочту стабильные настоящие 30 FPS, а не визуальные 60 с отзывчивостью низкой базы и артефактами.
Иногда FG ощущается как технология для человека, который сидит рядом и смотрит. Он видит более плавную картинку, но не чувствует задержку между движением стика или мыши и реакцией камеры. Игрок чувствует и то и другое.
[h2]⚙️ На мощном железе FG тоже не бесплатен[/h2]
Допустим, без генерации игра выдает 90 реальных FPS. После включения FG счетчик показывает 130–140 FPS, но из-за вычислительной стоимости самого алгоритма базовый рендер проседает, например, до 70–80 FPS.
На экране кадров стало больше, но новые состояния игры рассчитываются с частотой 70–80 FPS. Отзывчивость определяется базовым рендером и общей end-to-end latency, а не красивой итоговой цифрой 140.
То есть FG не «дарит» дополнительные кадры бесплатно. Он расходует ресурсы GPU и может снизить частоту настоящих кадров.
Конкретная величина просадки зависит от игры, видеокарты, разрешения и реализации, но принцип один: [b]итоговый FPS после FG нельзя напрямую сравнивать с таким же нативным FPS[/b].
[h2]⚡ «Просто включи Reflex»[/h2]
Да, NVIDIA Reflex и аналогичные механизмы действительно уменьшают системную задержку: ограничивают render queue и лучше синхронизируют CPU с GPU.
Но Reflex полезен и без генерации кадров. Я не вижу смысла намеренно отказываться от технологии, которая снижает latency, только чтобы потом приписать ее эффект frame generation.
Корректное сравнение — [b]Reflex без FG против Reflex с FG[/b], а не обычный режим против связки FG + Reflex.
Reflex способен частично компенсировать задержку, но он не превращает синтетический кадр в новый шаг симуляции и не делает вычислительную стоимость FG нулевой.
[h2]♟️ Где генерация кадров все-таки может быть полезна[/h2]
Я допускаю ее применение в медленных и пошаговых играх: Civilization, XCOM и похожих проектах, где нет постоянной жесткой связи между движением манипулятора, камерой и реакцией на экране.
Также технология может иметь смысл при уже высокой базовой частоте, когда человеку важнее приблизить визуальную плавность к герцовке дисплея, а небольшое ухудшение latency его не беспокоит.
Но это совсем не то же самое, что рекламировать FG как способ превратить нестабильные 25–30 FPS на слабом устройстве в «полноценные 60».
[h2]🦆 Что в итоге с самой Lossless Scaling[/h2]
Еще раз: программа работает. Она масштабирует изображение и генерирует промежуточные кадры. Ее универсальность — реальное достоинство: ее можно применять к играм без встроенного апскейлинга или FG и к старым проектам.
Но Steam спрашивает не о том, выполняется ли код без ошибок, а рекомендую ли я продукт.
[b]И вот как must-have для слабого железа и Steam Deck я Lossless Scaling не рекомендую.[/b]
Не потому, что «утка» сломана, а потому, что массовый сценарий ее покупки строится вокруг обещания, которое многие понимают неправильно. 30 реальных FPS не превращаются в настоящие 60. Картинка становится плавнее, но частота симуляции, базовый frame time и отзывчивость управления остаются привязаны к реальному рендеру.
Апскейлинг я принял: он уменьшает стоимость настоящего кадра и дает реальный прирост производительности.
Генерацию кадров — пока нет.
[b]Мне нужен не счетчик со сгенерированными изображениями, а более короткий путь от моего действия до реально рассчитанной реакции игры.[/b]
