Lossless Scaling

[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]