Dlaczego gra może się zacinać mimo wysokiej liczby klatek

Gra pokazuje ponad dziewięćdziesiąt klatek na sekundę, ale na chwilę zamiera przy obrocie kamery lub wejściu do nowego obszaru. Średni FPS nie przestał być użyteczny. Odpowiada na ogólne pytanie: ile klatek powstało w danym przedziale? Aby ustalić, czy docierają w równym rytmie, trzeba sprawdzić ich czasy.

Zacznij od czasu klatki, a dopiero potem wybierz kolejne pomiary. Pojedynczy procent „wąskiego gardła” ani jednorazowy spadek wykorzystania GPU nie wskazują, którą część należy wymienić.

Długa klatka może ukryć się za dobrą średnią

Przy idealnie równomiernym wyświetlaniu odstęp między klatkami w milisekundach wynosi około 1 000 ÷ FPS. Zatem 60 FPS odpowiada około 16,67 ms, a 120 FPS około 8,33 ms. To przeliczenie czasu, a nie wynik testu komputera.

Załóżmy, że zapis zawiera 100 klatek: 99 trwa po 10 ms, a jedna 100 ms. Łączny czas wynosi 99 × 10 + 100 = 1 090 ms. Dzielenie liczby klatek przez całkowity czas daje około 91,74 FPS. Średnia wygląda przyzwoicie, lecz jedno oczekiwanie wciąż jest znacznie dłuższe.

Ilustracja: syntetyczne obliczenie czasów klatek i przebieg sprawdzania, nie zrzut ekranu z testu gry.

Średnia arytmetyczna chwilowych FPS poszczególnych klatek też różni się od liczby klatek podzielonej przez całkowity czas. Okno pomiaru, uwzględnienie ekranów ładowania i definicja statystyczna narzędzia mogą zmienić końcowy wynik.

Przydatny jest także udział wolnych klatek w czasie. W hipotetycznym nagraniu trwającym 60 sekund sześć klatek po 100 ms zajmuje łącznie 0,6 sekundy, czyli 1% przedziału. To nadal sztuczny przykład, ale zachowuje rzadkie przerwy, które percentyl może pominąć.

Ilustracja: 100 syntetycznych klatek. Oś pozioma oznacza numer klatki, a nie równomiernie upływający czas. Klatka 50 trwa 100 ms; pozostałe 99 trwają po 10 ms.

Ustal, jaki rodzaj klatek zarejestrowano

Oficjalna strona NVIDIA FrameView wymienia pomiary liczby klatek, czasu klatki i mocy oraz zapis logów.[1] Log zachowuje dane wokół zdarzenia, ale samo narzędzie rejestrujące nie dowodzi, że procesor jest wąskim gardłem.

Przed porównaniem raportów sprawdź klatki renderowane i wyświetlane, generowanie klatek, synchronizację pionową oraz limit FPS. Łączenie klatek generowanych z bazowymi renderowanymi może podnieść wynik bez proporcjonalnej poprawy reakcji na sterowanie. Problemy w torze wyświetlania mogą też znajdować się poza logiem renderowania, więc równy wykres nie wyklucza każdego widocznego przycięcia.

„1% low” pomaga badać słabszą wydajność klatek, lecz programy mogą liczyć ten wskaźnik inaczej. Zachowaj wraz z wynikiem nazwę narzędzia, wersję, definicję metryki i długość zapisu. Nie utożsamiaj go z pojedynczą najwolniejszą klatką i nie twórz rankingu z pomiarów różnych narzędzi.

CapFrameX wyraźnie odróżnia percentyle uporządkowanych klatek od czasu, który upłynął.[3] „99% klatek spełnia próg” nie oznacza ściśle, że „99% czasu gry jest płynne”, ponieważ kilka wolnych klatek może zająć dużo czasu. Wyjaśnia też różnicę między wartością percentyla a podsumowaniem najwolniejszej części próby. Jeśli raport podaje tylko „1% low”, bez sposobu obliczania, zachowaj to zastrzeżenie.

Które pola logu czytać razem?

Otwórz CSV i najpierw sprawdź nagłówki. Dokumentacja konsolowej wersji PresentMon definiuje poniższe pola; rzeczywisty wynik zależy od wersji i opcji przechwytywania.[2]

Pola opisują różne przedziały, a praca CPU i GPU może się nakładać. Nie dodawaj po prostu kolumn z założeniem, że suma musi równać się całemu czasowi klatki. MsGPUBusy nie jest procentem wykorzystania GPU z Menedżera zadań. Przeczytaj definicje, zanim uznasz dwie liczby za porównywalne.

Jeśli odstępy między przekazaniami rosną i aktywny czas GPU wyraźnie się wydłuża, warto sprawdzić obciążenie graficzne. Jeśli praca GPU jest krótka, ale oczekiwanie długie, mogą mieć znaczenie limit FPS, dostarczanie pracy przez CPU lub harmonogramowanie. To zawęża poszukiwania, a nie dowodzi zbyt małej wydajności procesora. Projekt opisuje także ograniczenia związane z API i harmonogramowaniem sprzętowym. Nie uzupełniaj arbitralnie brakujących ani ograniczonych pomiarowo pól.[4]

Zachowaj dowody z krótkiej, powtarzalnej trasy

Wybierz trasę, którą da się powtórzyć, i utrzymaj tę samą rozdzielczość, grafikę, ruch kamery oraz limit FPS. Zapisz pierwotne ustawienia, uruchom rejestrowanie i zachowaj wynik. Oznacz pliki wersją gry, sterownikiem grafiki, sceną i ustawieniami, aby móc je później porównać.

Przy każdym skoku zanotuj, czy występuje przy pierwszym wejściu, gwałtownym obrocie kamery, uruchomieniu programu w tle czy każdym przejściu przez to samo miejsce. Analizuj razem dostępne metryki CPU, GPU, pamięci i dysku. Nie wpisuj zera w miejsce niezarejestrowanych odczytów czujników.

Na początek wykonaj trzy przejścia i zachowaj wszystkie wyniki. Przy dużych różnicach sprawdź scenę, temperatury, pamięć podręczną i zadania w tle, zanim wydłużysz lub dodasz testy. Zachowanie tylko najlepszego przejścia usuwa zmienność, którą trzeba wyjaśnić.

Poniższy szablon służy jako punkt wyjścia. Sześćdziesiąt sekund i trzy przejścia są przykładami, a nie gwarancją wystarczającego pomiaru dla każdej gry.

Porównuj zimne starty oddzielnie od już odwiedzonych scen. Przycięcia podczas pierwszego ładowania zasługują na osobny zapis. Badając stałe obciążenie graficzne, nie zestawiaj w jednej grupie pierwszego ładowania, a w drugiej danych po rozgrzaniu pamięci podręcznej.

PresentMon pozwala wybierać proces po nazwie, ustawiać długość pomiaru i wskazywać wyjściowy plik CSV.[2] Zarówno w interfejsie graficznym, jak i w wierszu poleceń sprawdź proces docelowy, by nie mieszać klatek launchera i gry. W tym artykule nie wykonano rzeczywistego przechwytywania gry; ilustracje objaśniają metryki.

Zmieniaj tylko jeden warunek naraz

Jeśli podejrzewasz obciążenie graficzne, zmniejsz jeden konkretny koszt renderowania i powtórz trasę. Przy podejrzeniu zakłóceń w tle zamknij jeden znany program i zmierz ponownie. Nie zmieniaj jednocześnie sterowników, jakości grafiki i limitu FPS wraz z restartem gry, bo przyczyna poprawy stanie się niejasna.

Jeżeli niższa jakość podnosi średni FPS, lecz skok pozostaje w tym samym miejscu, średnie obciążenie renderowania i ta pauza mogą być różnymi problemami. Przycięcie na pierwszym przejściu, które później słabnie, może mieć związek z ładowaniem zasobów lub pamięcią podręczną, ale sam wzorzec nie identyfikuje przyczyny. Niskie wykorzystanie GPU może wynikać z limitu, czekania na CPU lub innych ograniczeń; nie oznacza bezpośrednio za małej wydajności karty graficznej.

Zapisz wniosek powiązany z warunkami, na przykład „we wszystkich trzech przejściach wystąpił skok przy wejściu do obszaru, a obniżenie cieni go nie usunęło”, zamiast „PC ma 30% wąskiego gardła”. Kolejny test może wtedy zbadać miejsce skoku i różnicę ustawień cieni, zamiast znowu zaczynać od domysłów.

Źródła

1. Oficjalna strona NVIDIA FrameView. Potwierdza funkcje pomiaru FPS, czasu klatki i logowania. Nie potwierdza wykonania testu, identycznych pól mocy dla wszystkich GPU ani zainstalowanego programu.

2. Dokumentacja PresentMon Console Application. Stan gałęzi main odczytany 2026-09-27. Definiuje pola CSV, proces docelowy i czas pomiaru. Pola zależą od wersji; nie oznacza to lokalnego przechwytywania.

3. CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. Wyjaśnia percentyle i x% low. Źródło pojęć metrycznych, a nie zrzut aktualnego interfejsu.

4. Dokumentacja i ograniczenia projektu PresentMon. Sprawdzone 2026-09-27. API i harmonogramowanie sprzętowe mogą wpływać na pomiar; zapisuj środowisko, zamiast od razu wnioskować o wąskim gardle.