У світі аналізу продуктивності ПК-ігор ми схильні зациклюватися на часі кадру, і не без причини. Просте середнє значення FPS може бути надзвичайно оманливим, тоді як графік часу кадру може миттєво показати, чи гра плавно відтворює кадри, чи страждає від ривків, затримок, обмежень процесора/платформи чи інших форм нерівномірної подачі кадрів.
Однак, хоч як були б корисні часи кадру, є одна головна проблема з покладанням лише на них: вони не завжди говорять нам, що гравець фактично бачить на моніторі.
Це особливо важливо сьогодні, оскільки сучасні ПК-ігри — це вже не просто просте питання рендерингу кадру грою, його представлення та негайного відображення монітором. Між змінною частотою оновлення (VRR), вертикальною синхронізацією (V-Sync), зовнішніми обмежувачами частоти кадрів, нелімітованими частотами кадрів, що перевищують максимальну частоту оновлення монітора, безрамковими шляхами презентації, плануванням на рівні драйвера графіки та технологіями генерації кадрів, взаємозв’язок між виведенням кадрів грою та остаточним відображеним зображенням може стати напрочуд складним, і саме тут на допомогу приходять часи відображення.
Час кадру, або точніше MsBetweenPresents в термінології Intel PresentMon, вимірює час між двома викликами Present() програми. Простіше кажучи, вони показують, як часто гра надсилає кадри. Час відображення, або MsBetweenDisplayChange, вимірює час між фактичними змінами зображення на екрані. Ще простіше кажучи, вони показують, як часто зображення, що бачить гравець, фактично змінюється.
Обидва показники корисні, але якщо питання полягає в тому: “Наскільки плавно виглядає гра на моєму моніторі?”, то часи відображення часто є кращим показником.
Це не означає, що час кадру марний. Зовсім ні. Час кадру все ще неймовірно цінний для оцінки того, що робить ігровий рушій. Якщо гра має ривки при компіляції шейдерів, затримки на стороні процесора/платформи, ривки при потоковому завантаженні активів або нерівномірне планування симуляції/рендерингу, то час кадру часто виявить це дуже чітко. Але якщо ми конкретно намагаємося оцінити сприйняту плавність — тобто послідовність подачі кадрів на дисплей — тоді нам потрібно дбати про те, що фактично досягає монітора, а не лише про те, що гра намагалася представити.
У цій статті ми пояснимо різницю між часом кадру та часом відображення, чому ця відмінність важлива, і чому часи відображення можуть дати нам більш точне уявлення про сприйняту плавність у двох сценаріях: V-Sync проти зовнішнього обмежувача частоти кадрів та поведінка планування кадрів NVIDIA DLSS Frame Generation з MsBetweenDisplayChange проти MsBetweenPresents.
Час кадру проти часу відображення: Яка різниця?
Перш ніж рухатися далі, давайте встановимо базову термінологію. Коли більшість ПК-геймерів, оглядачів або інструментів для бенчмаркінгу говорять про час кадру, вони зазвичай мають на увазі час між послідовними кадрами, що надсилаються грою. У термінології PresentMon це представлено як MsBetweenPresents.
Менший час кадру (традиційно вимірюваний у мілісекундах або мс) означає вищу частоту кадрів (традиційно вимірювану у кадрах на секунду або FPS). Наприклад, час кадру 16,67 мс відповідає частоті кадрів приблизно 60 FPS, 8,33 мс — приблизно 120 FPS, 4,17 мс — приблизно 240 FPS тощо.
Ось чому графіки часу кадру такі корисні. Якщо гра працює зі швидкістю 120 FPS, в ідеалі ми б хотіли бачити часи кадру близько 8,33 мс. Якщо графік раптом підскочить до 33 мс, 50 мс або 100 мс, то в цей момент щось пішло жахливо не так, і гравець, ймовірно, відчув неприємний ривок чи затримку.
Однак виклик Present() не відображає того, що користувачі фактично бачать на своїх екранах. Кадр може бути представлений грою, потім поставлений у чергу/буферизований, затриманий, синхронізований з інтервалом оновлення, відкинутий, замінений, частково відображений як розрив, або на нього може вплинути власна поведінка оновлення монітора. Ось чому існує MsBetweenDisplayChange. Замість вимірювання частоти представлення програми, він вимірює частоту фактичних видимих змін зображення на рівні дисплея. Це важлива відмінність, оскільки візуальна плавність відчувається не на виклику Present(), а на рівні дисплея.
Простими словами, час кадру ближче до того, що робить гра. Час відображення ближче до того, що бачить гравець.
Чому ця відмінність важлива для бенчмаркінгу ПК-ігор
Історично аналіз часу кадру вже був значним поліпшенням порівняно зі звітуванням про середній FPS. Гра могла в середньому показувати 120+ FPS і все одно відчуватися жахливо під час гри, якщо подача кадрів постійно стрибала. Ось чому показники 1% найнижчих та 0,1% найнижчих FPS стали такими популярними: вони намагаються охопити найгірші частини кривої продуктивності, які середній FPS повністю приховує.
Але оскільки конвеєри презентації ПК стали складнішими, нам тепер доводиться поставити трохи інше запитання: чи вимірюємо ми, наскільки послідовно гра надсилає кадри, чи вимірюємо ми, наскільки послідовно змінюється дисплей? Ці дві речі часто подібні, особливо в простому, добре працюючому сценарії без VRR, генерації кадрів чи композиції. Але вони не завжди ідентичні, і коли вони розходяться, ця різниця може бути дуже важливою. Ось чому оверлей, що показує лише час кадру, іноді може виглядати гірше або краще, ніж досвід. Оверлей може бути не “неправильним” у даних, які він звітує. Він може просто звітувати про інший етап конвеєра.
З цієї причини ця стаття зосереджується на захопленнях CapFrameX/PresentMon, які безпосередньо порівнюють MsBetweenPresents та MsBetweenDisplayChange. Мета — не для вас “довіряти нашим очам”, а показати, як змінюються дані залежно від того, вимірюємо ми частоту представлення гри чи фактичну видиму частоту дисплея.
Для наших тестів ми провели захоплення CapFrameX у відповідній тестовій сцені Resident Evil Requiem з цільовою частотою кадрів/часом кадру 120 FPS/8,33 мс відповідно для запусків VSync проти зовнішнього обмежувача частоти кадрів, і з розблокованою цільовою частотою кадрів для нашого захоплення DLSS Frame Generation. Також захоплення проводилися на нашій настільній тестовій системі, яка має такі відповідні характеристики:
- Процесор: Intel Core i7-14700K
- ОЗП: 32 ГБ DDR5-7000 CL34
- Накопичувач: 2 ТБ PCIe 4.0 NVMe SSD
- Відеокарта: NVIDIA GeForce RTX 4090
- Операційна система: Windows 11 25H2
- Усі прошивки системи, BIOS, оновлення ОС та драйвери графіки були повністю оновлені перед тестуванням.
Важливе зауваження: Щоб реєструвати час відображення за допомогою CapFrameX, необхідно увімкнути опцію “використовувати метрики MsBetweenDisplayChange” у розділі налаштувань/опцій:
Перший сценарій: V-Sync проти зовнішнього обмежувача частоти кадрів
Перший сценарій — це V-Sync проти зовнішнього обмежувача частоти кадрів — зокрема, асинхронний обмежувач RTSS (RivaTuner Statistics Server) — і саме тут обговорення потребує обережного підходу.
V-Sync має погану репутацію серед багатьох ПК-геймерів, і не без причини. Традиційний V-Sync може збільшити затримку введення, особливо коли GPU дозволено агресивно чергувати кадри. Він також може спричинити ривки, якщо система не може підтримувати частоту оновлення монітора. Падіння нижче фіксованої цілі V-Sync може призвести до повторюваних кадрів та великих стрибків у тривалості кадрів, що може відчуватися жахливо.
Однак, коли гра може належним чином підтримувати цільову частоту оновлення, V-Sync також може забезпечити надзвичайно чисту подачу дисплея. Причина проста: V-Sync узгоджує представлення кадрів з циклом оновлення монітора. Коли все працює правильно, це може призвести до дуже рівномірного часу відображення, тому V-Sync може виглядати візуально плавно, хоча й з відчутною компромісом у затримці.
Зовнішні обмежувачі частоти кадрів, навпаки, часто оцінюються за тим, наскільки пласким виглядає графік часу кадру. Такі інструменти, як RTSS, можуть забезпечити надзвичайно послідовне планування представлення, тому вони настільки популярні серед ентузіастів ПК. У багатьох випадках хороший зовнішній обмежувач може бути фантастичним. Але ось важлива частина: ідеально виглядаючі часи кадру автоматично не гарантують ідеально виглядаючих часів відображення. Якщо частота обмежувача не узгоджується добре з фіксованою поведінкою оновлення монітора, особливо з вимкненим VRR, тоді гра може виглядати плавною з точки зору MsBetweenPresents, тоді як частота дисплея менш чиста з точки зору MsBetweenDisplayChange. Це не означає, що RTSS або інші capping FPS є поганими. Це був би неправильний висновок. Правильний висновок полягає в тому, що обмежувач частоти кадрів слід оцінювати не лише за тим, наскільки добре виглядає графік часу представлення. Його слід також оцінювати за тим, що відбувається на дисплеї.
V-Sync
Спочатку розглянемо графік часу кадру нижче з увімкненим V-Sync:
Потім графік часу відображення, також з увімкненим V-Sync:
Як видно з наведеного вище графіка часу кадру, показаного синім кольором, дані MsBetweenPresents виглядають помітно більш стрибучими, ніж очікувалося, і, якби вони розглядалися окремо, могли б помилково припустити, що V-Sync забезпечує нерівномірний або не дуже плавний візуальний досвід. Однак графік часу відображення, показаний зеленим кольором, розповідає зовсім іншу історію. З увімкненим MsBetweenDisplayChange подача кадрів стає набагато більш послідовною, при цьому найбільші відхилення від цільового показника 8,33 мс досягають лише 0,1–0,15 мс. Такий рівень розбіжності надто малий, щоб його можна було помітити в реальній грі, навіть для дуже чутливих гравців. Отже, цей приклад чітко демонструє, чому часи відображення можуть бути більш точним представленням сприйнятої плавності, ніж традиційний час кадру в сучасних сценаріях презентації.
Зовнішній обмежувач частоти кадрів
Для асинхронного обмежувача RTSS, спочатку розглянемо графік часу кадру:
Потім графік часу відображення:
Щодо обмежувача частоти кадрів RTSS Async, графік часу кадру спочатку виглядає досить переконливо. Тут все ще є деякі стрибки, але загальна послідовність залишається досить високою, при цьому більшість часу кадрів залишаються близькими до цільового показника 8,33 мс. Однак графік часу відображення малює зовсім іншу картину. Порівняно з результатом із увімкненим V-Sync, видима подача кадрів явно менш послідовна, що відповідає досвіду, який ми мали під час тестування. З обмежувачем RTSS Async, використаним без V-Sync, гра демонструвала помітне тремтіння та розриви екрану, обидва з яких повністю були відсутні при увімкненому V-Sync. Ось чому часи відображення такі важливі: графік часу кадру може змусити обмежувач виглядати досить добре відсортованим на рівні програми/представлення, але графік часу відображення точніше відображає нерівномірну візуальну подачу, яку фактично бачить гравець на моніторі.
Другий сценарій: NVIDIA DLSS Frame Generation
Другий сценарій — це NVIDIA DLSS Frame Generation, і це, мабуть, один із найчіткіших сучасних прикладів того, чому MsBetweenPresents вже недостатньо. З останньою версією DLSS Frame Generation на підтримуваних відеокартах GeForce RTX 40/50 серії, планування кадрів може відбуватися після викликів Present() гри, що означає, що традиційний час кадру на основі представлення може не точно відображати частоту, яка зрештою надсилається на монітор.
Спочатку розглянемо наступний графік часу кадру CapFrameX з MsBetweenPresents:
Як видно з наведеного вище захоплення CapFrameX, тестування DLSS Frame Generation з вимкненим MsBetweenDisplayChange робить показники набагато гіршими, ніж вони насправді відчуваються. Оскільки CapFrameX тут покладається на MsBetweenPresents, графік фактично показує частоту представлення програми, а не остаточну частоту відображення. Результатом є неохайний графік часу кадру, який зазвичай свідчить про надзвичайно погану подачу кадрів, з жахливими 1% та 0,1% найнижчими показниками, хоча це не обов’язково те, що бачить гравець на дисплеї.
Тепер розглянемо те саме попереднє захоплення CapFrameX, але з увімкненим MsBetweenDisplayChange у налаштуваннях CapFrameX:
Як тільки ми запускаємо той самий бенчмарк з увімкненим MsBetweenDisplayChange у налаштуваннях захоплення CapFrameX, картина повністю змінюється. Час відображення тепер відображає фактичну частоту видимих змін кадрів, включаючи те, як виведення DLSS Frame Generation планується на дисплей. Замість того, щоб робити DLSS FG зламаним або погано спланованим, графік тепер показує подачу кадрів так, як вона має бути для коректно працюючого конвеєра презентації генерації кадрів. Таким чином, оцінка результату лише за допомогою часу кадру на основі представлення може зробити досвід на папері набагато гіршим, ніж він насправді виглядає на моніторі. У такому типі конвеєра презентації часи відображення є не просто другорядним показником; це показник, який найкраще відображає остаточну частоту кадрів, що надсилається гравцеві.
Чому відео на YouTube не підходять для такого аналізу
Оскільки ця тема в основному стосується видимої плавності, може здатися очевидним, що відеопорівняння були б найкращим способом продемонструвати це. На жаль, це не завжди так.
Звичайне відео на YouTube не є ідеальним засобом для демонстрації відмінностей у плануванні кадрів при високій частоті оновлення. Якщо оригінальна графіка була записана зі швидкістю 120+ FPS, але кінцеве онлайн-відео відображається зі швидкістю 60 FPS, то багато тимчасової інформації, яку ми намагаємося проаналізувати, вже втрачено, передискретизовано або приховано.
Таким чином, і для цілей цієї статті, попередні графіки із захоплень CapFrameX, які ми проаналізували, становлять усі докази наших тверджень.
Переваги та недоліки часу кадру
На цьому етапі може здатися, що ми стверджуємо, що час кадру застарів. Це абсолютно не так. Час кадру залишається неймовірно корисним, особливо коли ви намагаєтеся діагностувати, що відбувається всередині гри або вашої системи. Якщо гра має ривки при компіляції шейдерів, ривки при потоковому завантаженні активів, затримки на стороні процесора, обмеження GPU або будь-яку іншу форму нерівномірної поведінки продуктивності, час кадру може чітко виявити ці проблеми.
Час кадру також є більш інтуїтивним показником для багатьох видів аналізу продуктивності ПК. Коли ми говоримо, що гра працює зі швидкістю 60 FPS, 120 FPS або 240 FPS, ми зазвичай думаємо про те, скільки часу займає гра для створення послідовних кадрів. Це робить MsBetweenPresents надзвичайно цінним для класичного бенчмаркінгу та аналізу продуктивності на рівні ігрового рушія.
Однак час кадру має обмеження. Кадр, що представляється грою, не гарантує, що він був відображений чисто, негайно або взагалі. Час кадру також може не повністю враховувати ефекти поведінки VRR, невідповідність сканування фіксованої частоти оновлення, поведінку зовнішнього обмежувача FPS, планування V-Sync та режими планування кадрів генерації кадрів.
Іншими словами, час кадру чудово підходить для розуміння виробничої сторони конвеєра. Він не завжди є найкращим показником для оцінки кінцевої сторони відображення конвеєра.
Переваги та недоліки часу відображення
Час відображення, навпаки, набагато ближче до того, що гравець фактично бачить. Насправді, якщо графік часу відображення нерівномірний, то видима подача кадрів нерівномірна. Якщо вона чиста, то остаточна частота відображення, ймовірно, чиста, за умови відсутності інших візуальних артефактів, проблем із затримкою чи обмежень захоплення, що заважають інтерпретації.
Це робить час відображення особливо корисним для оцінки сприйнятої плавності. Вони також дуже допомагають при порівнянні поведінки VRR, планування генерації кадрів, V-Sync та впливу інших обмежувачів FPS на візуальну плавність тощо.
Однак час відображення також не є ідеальним. По суті, вони не завжди говорять вам, чому щось пішло не так всередині ігрового рушія. Стрибок часу відображення може вказати на те, що кадр відображався занадто довго, але це може не одразу повідомити вам, чи була причиною процесор, відеокарта, потокове завантаження активів, компіляція шейдерів, режим представлення кадру чи щось інше.
Ось чому найкращий аналіз не повинен сліпо використовувати один показник. Таким чином, час кадру та час відображення слід розглядати як взаємодоповнюючі.
Отже, який показник слід використовувати технічним оглядачам?
Відповідь на це запитання просто залежить від поставленого запитання. Якщо мета — визначити, чи є ривки в ігровому рушії, чи процесор обмежує відеокарту, чи компіляція шейдерів викликає затримки, або чи налаштування графіки надмірно навантажує ресурси GPU/VRAM, тоді традиційний час кадру все ще надзвичайно корисний. З іншого боку, якщо мета — оцінити, наскільки плавно виглядає гра на моніторі, тоді час відображення зазвичай є більш релевантним показником. На нашу думку, технічні оглядачі повинні показувати обидва, коли це можливо.
Принаймні, аналіз продуктивності повинен чітко вказувати, який показник використовується. Якщо графік базується на MsBetweenPresents, це слід позначити. Якщо відсоткові показники FPS базуються на MsBetweenDisplayChange, це також слід чітко зазначити. Це особливо важливо, тому що два захоплення можуть розповісти різні історії залежно від використовуваного показника. Гра може виглядати чистою за часом представлення, але бути нерівномірною за часом відображення. Інша конфігурація може виглядати гірше за часом представлення, ніж вона насправді відчувається на дисплеї. Жоден графік не є обов’язково “оманливим”. Вони просто вимірюють різні етапи конвеєра рендерингу та представлення кадрів.
Заключні слова
Роками графіки часу кадру були одним з найкращих інструментів для аналізу продуктивності ПК, і це залишається правдою й сьогодні. Вони набагато корисніші, ніж просто середні показники FPS, і залишаються необхідними для діагностики ривків, затримок, апаратних обмежень та нерівномірної поведінки гри/рушія.
Однак сучасні ПК-ігри стали складнішими, ніж може повністю пояснити старий графік часу кадру. VRR змінює спосіб відстеження монітором гри; технології генерації кадрів часто впроваджують власні механізми планування кадрів, а зовнішні обмежувачі частоти кадрів можуть забезпечити чудове планування представлення, але все ж взаємодіяти по-різному з дисплеєм. Саме тому ми твердо віримо, що часи відображення заслуговують на важливе місце в сучасному аналізі продуктивності ПК-ігор та бенчмаркінгу.
Про автора: Себастьян Кастелланос — науковець з даних за освітою та професією. Він також глибоко захоплений апаратним і програмним забезпеченням для ПК-ігор. Нещодавно він почав писати технічні статті та посібники на Wccftech про ПК-апаратне забезпечення, ігри та моди.
Слідкуйте за Wccftech на Google, щоб отримувати більше новин у своїх стрічках.
Подальше читання
Користувач підтверджує, що Intel Arc Pro B70 може грати в Crimson Desert, але артефакти дратують
Сарфраз Хан
Crimson Desert офіційно отримала підтримку Intel Arc GPU та XeSS 3.0 Frame Generation
Сарфраз Хан
Тестовано кожен обмежувач FPS у Cyberpunk 2077: Nvidia Reflex проти RTSS проти Special K
Себастьян Кастелланос
«Порт ARK: Survival Ascended на Nintendo Switch 2 можливий лише з UE 5.7», — каже розробник ARK; студія намагається запустити генерацію кадрів
Алессіо Палумбо
Чи варто купувати? (Порада ІТ-Блогу): Розуміння різниці між часом кадру та часом відображення є ключовим для об’єктивної оцінки плавності ігрового процесу, особливо з сучасними технологіями, як VRR та генерація кадрів. Хоча інструменти типу CapFrameX дозволяють глибше зануритися в ці показники, для пересічного геймера головне — відчуття плавності. Новітні ігри та технології роблять час відображення все більш важливим показником для оглядачів. Тому, якщо ви бачите, що аналіз включає обидва показники, це ознака більш ретельного та достовірного тестування.
За матеріалами: wccftech.com