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

На уровне пользователя всё выглядит просто: одна настройка убирает разрыв изображения, другая делает движение плавнее. На самом деле между игрой и пикселями дисплея работает целая цепочка. Игра формирует кадр, процессор подготавливает команды, графический процессор выполняет рендеринг, DirectX и DXGI управляют представлением готовой поверхности, Windows участвует в планировании вывода, а контроллер дисплея передаёт изображение на монитор. Поэтому V-Sync нельзя понимать как обычный переключатель, который просто "замедляет видеокарту".

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

Монитор задаёт ритм, а видеокарта пытается успеть к следующему обновлению

Обычный монитор с частотой 60 Гц обновляет изображение примерно каждые 16,67 мс. При 120 Гц интервал составляет около 8,33 мс, при 144 Гц - около 6,94 мс, а при 240 Гц - около 4,17 мс. Это не означает, что видеокарта обязана создавать ровно столько кадров в секунду, но показывает, через какие промежутки времени дисплей способен начинать очередное обновление.

Представим игру, которая работает со скоростью 90 кадров в секунду на мониторе 60 Гц. Среднее время подготовки кадра составляет около 11,11 мс. Монитору же нужен интервал около 16,67 мс. Поэтому часть кадров оказывается готова в момент, когда дисплей ещё занят текущим обновлением.

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

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

В Windows за это отвечает связка Direct3D, DXGI, драйвера и подсистемы отображения. Метод Present используется приложением для передачи готового кадра дальше по цепочке. Параметр SyncInterval определяет, как presentation должен быть синхронизирован с вертикальным пустым интервалом. При ненулевом интервале вывод привязывается к определённым моментам вертикального обновления, а при нулевом приложение получает режим без такой синхронизации.

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

Что именно делает V-Sync и откуда берётся дополнительная задержка

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

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

На 60 Гц это особенно хорошо видно по времени. Один цикл длится около 16,67 мс. Если кадр был готов за несколько миллисекунд до очередного момента показа, ожидание может быть небольшим. Если он опоздал буквально на долю миллисекунды, система может потерять целый цикл. Тогда вместо условных 60 кадров в секунду последовательность показа может перейти к 30 кадрам в секунду на отдельных участках, если производительность стабильно не позволяет попадать в каждый интервал.

Так появляется ощущение рывков, которое часто называют stutter. Причина не обязательно в том, что GPU внезапно стал намного медленнее. Иногда проблема заключается именно в несовпадении времени завершения рендеринга с моментами, доступными для вывода.

Есть и второй важный фактор - очередь кадров. Между созданием изображения и его фактическим показом может существовать несколько этапов буферизации. Если приложение заранее отправляет несколько кадров, следующий кадр способен ждать своей очереди. Средний FPS при этом может выглядеть высоким, но время от действия игрока до отображения результата увеличивается.

Поэтому утверждение "V-Sync добавляет ровно одну задержку кадра" слишком грубое. Реальная задержка зависит от API, режима представления, количества буферов, очереди, поведения драйвера, настроек игры и того, успевает ли GPU закончить кадр до ближайшего момента обновления.

В современных Windows многое зависит и от модели flip presentation. В этой модели приложение передаёт системе поверхности, которые затем используются для вывода, вместо постоянного копирования содержимого в отдельную поверхность рабочего стола. Такая схема эффективнее и даёт системе больше информации о времени presentation. При работе с очередью кадров это особенно важно, потому что порядок Present и его параметры напрямую влияет на то, какие кадры будут показаны, а какие могут быть пропущены.

Почему отключение V-Sync убирает ожидание, но возвращает tearing

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

Это хорошо видно в игре с очень высокой частотой кадров. Допустим, монитор работает на 60 Гц, а GPU способен создавать 150 кадров в секунду. Между двумя обновлениями дисплея успевает завершиться несколько новых кадров. Без синхронизации один из них может начать использоваться во время уже идущего обновления.

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

У V-Sync off есть важное преимущество: приложение не обязано ждать фиксированный момент обновления. Это позволяет снизить часть задержки и использовать высокий FPS. Но цена заключается в том, что момент смены кадра больше не обязан совпадать с началом нового цикла обновления.

В Windows для современных приложений существует ещё более точный механизм, связанный с tearing support. DXGI позволяет использовать presentation с интервалом синхронизации 0 и специальным флагом разрешённого разрыва. Это особенно важно для оконного и borderless-режима, где вывод проходит через современную модель flip.

Само отключение V-Sync не гарантирует бесконечный FPS. Игра может иметь собственный ограничитель кадров, ждать другие события или упираться в CPU, GPU и очередь presentation. Поэтому формула "V-Sync выключен = FPS максимально возможный" неверна.

Есть и обратная сторона очень высокого FPS. Чем больше кадров создаёт GPU относительно частоты монитора, тем больше готовых изображений может быть создано между двумя обновлениями дисплея. Это не обязательно делает картинку визуально хуже во всём, но увеличивает вероятность заметного tearing.

G-Sync меняет не скорость игры, а частоту обновления самого дисплея

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

У обычного 60-герцевого дисплея есть условный ритм: новый цикл начинается примерно каждые 16,67 мс. У VRR-дисплея этот интервал может изменяться. Если GPU подготовил следующий кадр быстрее, монитор может начать новое обновление раньше. Если кадр оказался сложнее и занял больше времени, дисплей может подождать дольше, не показывая старый кадр при прежнем фиксированном ритме.

NVIDIA описывает G-Sync именно как технологию, которая сопоставляет частоту обновления монитора с частотой кадров GPU. Поэтому G-Sync нельзя считать просто "более быстрым V-Sync". Это другой механизм согласования двух источников времени.

Результат особенно заметен при нестабильном FPS. Допустим, игра меняется между 83, 97 и 72 кадрами в секунду. На фиксированном мониторе эти значения не совпадают с одним постоянным ритмом обновления. При VRR дисплей может подстраивать интервалы под фактическую последовательность готовых кадров.

Важна именно последовательность времени, а не только среднее число кадров. Если один кадр готов через 9 мс, следующий через 12 мс, а третий через 8 мс, средний FPS не рассказывает, в какой момент каждый кадр стал доступен. VRR работает именно с этой временной стороной вывода.

G-Sync при этом не ускоряет сам рендеринг. Если GPU рассчитывает кадр 25 мс, технология не превращает его в 10 мс. Она изменяет условия, в которых монитор ожидает и показывает уже готовые кадры. Поэтому слабый GPU G-Sync не сделает мощнее, но сделает поведение дисплея более согласованным с реальной скоростью рендеринга.

Где в этой цепочке находится Windows и почему она не просто передаёт кадр монитору

Упрощённая схема "игра -> видеокарта -> монитор" полезна для первого знакомства, но для понимания V-Sync и G-Sync её недостаточно. Между приложением и физическим дисплеем находится программно-аппаратная цепочка, в которой Windows и графический драйвер определяют, каким способом готовая поверхность будет представлена.

Игра вызывает графический API и в конечном итоге делает Present. DXGI получает запрос на presentation и учитывает параметры swap chain. Дальше в зависимости от режима вывода, типа swap chain, возможностей драйвера и дисплея меняется конкретный путь передачи.

В оконном режиме изображение может участвовать в композиции рабочего стола через Desktop Window Manager. Современная flip-модель позволяет передавать поверхности более эффективно, а в некоторых сценариях возможен прямой вывод без традиционного полного копирования изображения для композиции.

Полноэкранный режим тоже не является одним универсальным сценарием. Для него Windows и DXGI могут использовать flip-путь, а конкретная конфигурация зависит от характеристик поверхности, драйвера и дисплея. Именно поэтому две игры с одинаковыми настройками V-Sync могут ощущаться немного по-разному.

DWM тоже имеет собственную логику планирования композиции и presentation. Windows предоставляет API для работы со временем кадров и параметрами композиции. Это показывает важную вещь: отображение готового изображения является отдельной задачей от его рендеринга.

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

Поэтому кнопка V-Sync в игре фактически меняет правила presentation, а не только работу графического процессора. Она говорит цепочке вывода, как согласовать готовые кадры с обновлением дисплея.

Что происходит с кадром от вызова Present до изображения на экране

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

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

Если используется синхронизация с вертикальным обновлением, Present может быть связан с определённым числом вертикальных интервалов. В документации DXGI SyncInterval описывает, как presentation синхронизируется с vertical blank. При интервале 1 вывод привязывается к следующему подходящему вертикальному интервалу, а при нулевом интервале синхронизация не задаётся таким способом.

Если кадров в очереди несколько, их судьба зависит от параметров presentation и используемой модели swap chain. В flip-модели новые вызовы Present могут влиять на то, сколько времени будут показываться уже поставленные кадры. При определённых последовательностях кадры с нулевым интервалом способны приводить к тому, что промежуточные кадры будут отброшены, если они уже потеряли практический смысл для вывода.

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

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

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

Именно здесь становится очевидной разница между "синхронизировать кадр" и "синхронизировать монитор с кадром". V-Sync в классическом понимании ориентируется на ритм дисплея. G-Sync использует возможности VRR, чтобы менять сам ритм дисплея в ответ на готовность кадров.

Почему G-Sync не отменяет значение ограничения FPS

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

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

Например, для монитора 144 Гц можно использовать ограничение немного ниже 144 FPS. Конкретное значение зависит от игры, драйвера, метода ограничения кадров и требований пользователя к задержке. Универсального числа, которое одинаково оптимально для всех систем, нет.

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

Важный момент состоит в том, что G-Sync не делает каждый FPS одинаковым. Если игра выдаёт 40 FPS, между готовыми кадрами всё равно будет большой временной интервал. VRR помогает согласовать монитор с этим интервалом, но не превращает 40 кадров в ощущение 100 кадров. Плавность движения по-прежнему зависит от фактической частоты создания новых изображений.

V-Sync и G-Sync не являются взаимоисключающими настройками

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

G-Sync отвечает за переменную частоту обновления, а V-Sync может выступать ограничителем поведения, когда частота кадров приближается к пределу VRR. Поэтому комбинация может быть логичной: внутри диапазона монитор подстраивается под GPU, а при достижении максимальной частоты применяется дополнительное правило синхронизации.

Здесь особенно важно различать настройки внутри игры и параметры драйвера. Игра может иметь собственный V-Sync, драйвер может иметь глобальную настройку, а монитор может иметь отдельный переключатель Adaptive-Sync или G-Sync Compatible. Эти уровни не всегда означают одно и то же действие.

Пользователь может включить VRR на мониторе, активировать G-Sync в драйвере и отдельно выбрать V-Sync в игре. В результате итоговое поведение определяется не одной галочкой, а комбинацией всех уровней. Поэтому одинаковые названия настроек не гарантируют одинаковую задержку и одинаковый способ presentation.

Для практического понимания достаточно запомнить одну логику:

  1. V-Sync связывает момент показа кадра с фиксированным ритмом вертикального обновления;

  2. G-Sync позволяет дисплею менять частоту обновления под готовность кадров в пределах диапазона VRR;

  3. Ограничение FPS помогает не упираться в верхнюю границу VRR и сохранять предсказуемое поведение;

  4. Отключение V-Sync и отсутствие VRR позволяют выводить кадры свободнее, но могут привести к tearing;

  5. Низкий FPS не устраняется ни V-Sync, ни G-Sync, потому что обе технологии работают с моментом вывода, а не создают дополнительную вычислительную мощность.

Почему одинаковые 144 FPS могут ощущаться по-разному

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

Представим две последовательности. В первой новый кадр готовится каждые 6,94 мс почти без отклонений. Во второй несколько кадров занимают 4 мс, затем один занимает 14 мс, после чего снова идут быстрые кадры. Среднее значение может оказаться похожим, но движение во второй последовательности будет менее равномерным.

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

Поэтому при оценке игровой плавности полезно смотреть не только на FPS, но и на frame time. Например, 100 FPS соответствуют среднему времени около 10 мс на кадр. Если frame time постоянно держится около этого значения, движение будет выглядеть заметно ровнее, чем при сильных скачках времени кадра при том же среднем FPS.

Есть ещё одна причина различий: очередь presentation. Игра может создавать кадры быстрее, чем они показываются. Если система накапливает несколько готовых изображений, пользователь видит не обязательно самый свежий результат. С точки зрения среднего FPS всё может выглядеть отлично, но управление станет менее непосредственным.

Современные механизмы flip presentation и возможности GPU позволяют уменьшать такие проблемы, однако конкретное поведение всё равно зависит от игры. Поэтому две игры на одном компьютере с одинаковыми 144 FPS могут иметь разное ощущение управления.

Что происходит при 60, 144 и 240 Гц на практике

На 60 Гц один цикл обновления длится около 16,67 мс. Потеря одного момента синхронизации заметна сильнее, потому что следующий доступный момент находится относительно далеко. Поэтому классический V-Sync на 60 Гц особенно чувствителен к падениям производительности около границы 60 FPS.

На 144 Гц один цикл занимает около 6,94 мс. Промежутки между возможными моментами вывода короче, а движение воспринимается плавнее. При этом требования к времени кадра становятся жёстче: чтобы стабильно выдавать 144 FPS, среднее время рендеринга должно быть около 6,94 мс или меньше.

На 240 Гц интервал составляет примерно 4,17 мс. Это сокращает время между обновлениями и позволяет быстрее показывать новые состояния сцены. Но высокая частота сама по себе не гарантирует низкую задержку. Если CPU или GPU создаёт длинную очередь кадров, часть преимущества может потеряться ещё до того, как изображение попадёт на монитор.

VRR особенно полезен там, где FPS не держится идеально. При частоте 144 Гц игра может работать то на 138, то на 126, то на 141 FPS. Для фиксированного режима это уже несогласованность двух ритмов. Для VRR такая последовательность является нормальным рабочим сценарием, пока значения находятся в поддерживаемом диапазоне.

Главная разница между V-Sync и G-Sync скрыта во времени

Если убрать маркетинговые названия и посмотреть на механизм, различие становится достаточно простым. V-Sync отвечает на вопрос: "Можно ли показать этот кадр в согласованный момент фиксированного обновления?" G-Sync отвечает на другой вопрос: "Когда именно стоит начать следующее обновление, чтобы оно соответствовало готовому кадру?"

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

Отсюда следуют и практические эффекты. V-Sync хорошо решает tearing на дисплее с фиксированной частотой, но ожидание ближайшего момента вывода может увеличить задержку и сделать просадки производительности заметнее. G-Sync уменьшает необходимость ждать фиксированный ритм внутри рабочего диапазона VRR и позволяет сохранить отсутствие tearing при переменном FPS.

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

В итоге V-Sync и G-Sync лучше рассматривать не как две конкурирующие кнопки, а как разные способы управлять последним этапом движения кадра от GPU к экрану. V-Sync привязывает presentation к вертикальному ритму, а G-Sync позволяет самому дисплею менять этот ритм в ответ на готовность изображения. Именно поэтому понимание V-Sync и G-Sync начинается не с настроек графики, а с простой последовательности: GPU создаёт кадр, DXGI принимает запрос на его представление, Windows и драйвер определяют путь вывода, а дисплей решает, в какой момент физически начать показывать следующую картинку.