iRacing: jak dobrać ustawienia dla 144 Hz i stabilnego frametime

Dlaczego 144 Hz w iRacing wymaga osobnego podejścia

Wysoki FPS kontra stabilny frametime

Przy monitorze 144 Hz intuicja podpowiada: „im więcej FPS, tym lepiej”. W iRacing taka logika bardzo szybko się mści. Kluczowe pojęcie to stabilny frametime, czyli możliwie równe odstępy czasowe pomiędzy kolejnymi klatkami. Monitor 144 Hz odświeża obraz co około 6,94 ms. Jeśli gra renderuje raz w 4 ms, raz w 12 ms, a średnio wychodzi 200 FPS, subiektywnie obraz będzie szarpał, mimo imponującej średniej.

Przy wysokim, ale niestabilnym FPS pojawia się typowe zjawisko: w telemetrycznych overlayach widzisz 180–220 FPS, a mimo to kamera na prostej i szybkie zmiany kierunku wzroku nie są płynne. To efekt „zębiącego się” frametime, a nie „za małego FPS”. W symulatorze, gdzie mózg reaguje na najmniejszą niespójność ruchu bocznego, odchylenia rzędu kilku milisekund są łatwo wyczuwalne i mylone z lagiem lub dropami.

Minimum jakości przy 144 Hz to dopasowanie ustawień tak, aby większość klatek mieściła się w wąskim przedziale czasowym (np. 6–8 ms dla targetu ~140 FPS lub 8–10 ms przy 100–120 FPS). Średnia może być teoretycznie wyższa, ale jeśli 1% low i 0.1% low wyraźnie odstają, stabilność frametime jest nieakceptowalna dla wymagającego simracera.

Jeżeli subiektywne odczucie jest takie: „gra niby ma dużo FPS, ale czuć szarpanie szczególnie na starcie i w szybkich łukach”, sygnałem ostrzegawczym jest właśnie brak kontroli nad frametime, a nie sama wartość FPS.

Charakterystyka silnika iRacing przy 144 Hz

iRacing to symulator mocno obciążający CPU: osobne wątki dla fizyki, sieci, audio, powtórek, AI (tam gdzie występuje), a także dla obsługi UI i telemetrii. GPU ma oczywiście znaczenie, ale przy pełnych gridach i złożonych torach to procesor często staje się wąskim gardłem. Przy 144 Hz każde dodatkowe „zadanie” w tym ekosystemie ma większą szansę zaburzyć równomierne dostarczanie klatek.

Silnik iRacing dokonuje stałej ilości obliczeń fizyki w określonym interwale czasowym. Jeśli CPU jest przeciążone (np. start wyścigu, wiele aut w lusterkach, dynamiczne cienie), pojedyncze klatki zaczynają się opóźniać. Przy monitorze 60 Hz takie opóźnienia bywają mniej wyczuwalne, bo margines na różnice jest większy, natomiast przy 144 Hz każda dodatkowa milisekunda od razu przekłada się na mikrostuttering.

Dodatkowy czynnik to system powtórek i rejestracji zdarzeń. Przy wysokich ustawieniach powtórek (Replay) i dużej ilości detali, ten element również dociąża CPU oraz I/O dysku. Kombinacja: zapis powtórki + pełen grid + dynamiczne oświetlenie potrafi wywołać skoki frametime nawet na pozornie mocnych zestawach, jeśli ustawienia są nieprzemyślane.

Jeżeli w sesjach solo frametime jest niemal wzorowy, a przy starcie wyścigu wykres zamienia się w „piłę”, oznacza to zwykle, że CPU jest już na limicie i 144 Hz bez redukcji detali to ponad jego realne możliwości.

60, 144 czy 240 Hz – gdzie celować z FPS

Monitor 144 Hz daje możliwość wyświetlenia 144 klatek na sekundę, ale nie oznacza to, że zawsze sensownie jest wymuszać 144 FPS. Pojawiają się trzy typowe strategie:

• Celowanie dokładnie w 144 FPS – ma sens tylko wtedy, kiedy zestaw CPU+GPU potrafi bez problemu utrzymać minimalne wartości powyżej ~140 FPS w najcięższych warunkach. W przeciwnym razie każdy spadek poniżej 144 powoduje większe wachnięcia frametime.
• Celowanie w nieco niższą, stabilną wartość (np. 120–130 FPS) – to często złoty środek. Monitor 144 Hz nadal zapewnia niski input lag i dobrą płynność, ale mamy zapas mocy, który wygładza frametime. Różnica w subiektywnej płynności pomiędzy 130 a 144 FPS jest niewielka, natomiast zysk w stabilności bywa ogromny.
• Jeszcze niższy, ale „żelazny” limit (np. 90–100 FPS) – dla słabszych zestawów lub przy pełnym focusie na stabilności. Ruch jest bardzo spójny, a monitor 144 Hz wykorzystuje się głównie po to, by zmniejszyć input lag i tearing przy G-Sync/FreeSync.

Jeżeli sesje wyścigowe pokazują, że przy 144 Hz spadki są częste, a przy 120 FPS frametime robi się „gładki”, punkt kontrolny jest oczywisty: lepiej ustabilizować 120 niż ścigać się o nierealne 144.

Synchronizacja, G-Sync/FreeSync i współpraca z target FPS

Mechanizmy synchronizacji obrazu wpływają bezpośrednio na to, jak odczuwany jest frametime. Klasyczny V-Sync czeka na odświeżenie monitora, przez co potrafi wprowadzić duży input lag i skokowy charakter FPS (skoki 144 → 72 → 48). G-Sync i FreeSync dopasowują moment odświeżenia ekranu do tego, kiedy GPU „dowiezie” klatkę, przez co ewentualne odchylenia frametime są maskowane, a tearing praktycznie znika.

Przy 144 Hz dobrze skonfigurowany układ G-Sync/FreeSync + limiter FPS poniżej maksymalnego odświeżania (np. 140 FPS) to często najbardziej przewidywalne rozwiązanie. Mamy niski input lag, brak rozrywania obrazu i bufor bezpieczeństwa na drobne spadki FPS bez wpadania w stany przepełnienia kolejki renderowania.

Brak jakiejkolwiek synchronizacji bywa rozwiązaniem dla graczy wyczulonych na input lag, ale przy 144 Hz i niestabilnym frametime efekt tearingu potrafi być bardzo agresywny, a „pływanie” fragmentów obrazu w horyzontalnym kierunku będzie irytować zwłaszcza na długich prostych.

Jeżeli po włączeniu G-Sync/FreeSync obraz uspokaja się, ale na starcie czuć „sprężynowanie” kierownicy i minimalne opóźnienie, sygnałem ostrzegawczym jest zbyt agresywny limiter (tuż przy 144) lub przeciążony CPU.

Jeżeli priorytetem są „zero mikroprzycięć” i maksymalna przewidywalność, punktem kontrolnym powinna być stabilizacja frametime wokół wybranego targetu FPS, a nie ślepe gonienie najwyższej możliwej średniej liczby klatek.

Punkty kontrolne przed zmianami – monitor, sprzęt, system

Parametry monitora 144 Hz i ich wpływ na płynność

Zanim zacznie się eksperymentować z iRacing, trzeba zweryfikować, czy monitor rzeczywiście pracuje w trybie 144 Hz i jakie funkcje są aktywne. Często to właśnie tu ukryty jest pierwszy powód niestabilnego frametime.

Lista podstawowych parametrów monitora do sprawdzenia:

• Tryb odświeżania w systemie – w Windows w ustawieniach ekranu należy upewnić się, że wybrano 144 Hz, a nie 60/120 Hz. Częsty błąd to zostawienie 60 Hz po instalacji sterownika GPU.
• Typ matrycy – TN, IPS, VA. Nie chodzi o „ładność” kolorów, ale o czas reakcji i ewentualne smużenie. Zbyt agresywny overdrive może powodować artefakty i subiektywnie pogarszać odczucie płynności.
• G-Sync/FreeSync – trzeba sprawdzić, czy monitor faktycznie obsługuje adaptacyjne odświeżanie w zakresie obejmującym okolice 100–144 Hz oraz czy funkcja jest włączona zarówno w OSD monitora, jak i w panelu sterownika.
• Tryb „low input lag” – niektóre monitory mają dedykowany tryb redukcji opóźnienia kosztem części upiększeń obrazu. W symulatorach ma to zwykle większą wartość niż agresywne filtry wygładzania krawędzi po stronie monitora.

Jeżeli monitor w Windows raportuje 144 Hz, ale w OSD widnieje 120 Hz lub funkcja FreeSync jest wyłączona, punkt kontrolny jest jasny: doprowadzić monitor do spójnej konfiguracji zanim zacznie się szukać problemów w samej grze.

CPU, GPU, RAM, SSD – które podzespoły są krytyczne dla 144 Hz

iRacing jest wyjątkowo czułe na jakość pojedynczego rdzenia CPU oraz ogólną przepustowość systemu. Dla 144 Hz kluczowe są:

• CPU – nowoczesny, wielordzeniowy procesor z wysokim taktowaniem bazowym i stabilnym boostem. iRacing korzysta z wielu wątków, ale wciąż jeden lub kilka wątków krytycznych często dochodzi do 100% obciążenia, co natychmiast podnosi frametime. Procesory ze słabym pojedynczym rdzeniem lub agresywnym throttlingiem to klasyczny sygnał ostrzegawczy.
• GPU – klasa karty graficznej powinna być adekwatna do rozdzielczości i liczby monitorów. Przy 144 Hz w 1440p lub w konfiguracji triple-screen nawet mocne karty mogą stać się wąskim gardłem, jeśli ustawienia graficzne są zbyt agresywne (odbicia, cienie, AA).
• RAM – minimum 16 GB, najlepiej w konfiguracji dual-channel, z możliwie niskimi opóźnieniami. Przy 8 GB system zaczyna walczyć z pamięcią wirtualną, a każde doczytywanie zasobów generuje skoki frametime.
• SSD – iRacing powinno być zainstalowane na SSD (NVMe lub SATA). Dysk HDD w 2024 roku w symulatorze to przepis na stuttery przy doczytywaniu obiektów i powtórek.

Jeżeli CPU dochodzi do 100% obciążenia przy starcie wyścigu, a GPU ma zapas, główny kierunek optymalizacji to redukcja opcji CPU-bound oraz kontrola procesów w tle, a nie dalsze obniżanie rozdzielczości.

Sterowniki, zasilanie i overlaye jako źródło stutterów

Sprawdzony system pod iRacing i 144 Hz musi być wolny od „niespodzianek” generowanych przez sterowniki i dodatki. Trzy obszary są szczególnie wrażliwe:

• Sterowniki GPU – zbyt stare mogą mieć problemy z G-Sync/FreeSync lub błędy w zarządzaniu energią, zbyt nowe czasem wprowadzają regresję. Warto dobrać wersję, która jest stabilna dla całego zestawu gier, a nie instalować każdą najnowszą betę. Dodatkowo należy wyłączyć zbędne funkcje typu „Experience overlay”, jeśli nie są potrzebne.
• Plan zasilania – w Windows ustawienie „Wysoka wydajność” lub „Maksymalna wydajność” często rozwiązuje problem z nagłym zbijaniem taktowania CPU/GPU, co bezpośrednio odbija się na frametime. W panelu sterownika GPU trzeba ustawić preferencję „maksymalna wydajność” dla iRacing.
• Overlaye i nakładki – Discord, Steam, GeForce Experience, MSI Afterburner, Rivatuner, aplikacje telemetryczne. Każda nakładka, która próbuje przechwycić obraz, może w niektórych konfiguracjach generować mikroprzycięcia. Trzeba je testować pojedynczo – zostawić tylko te naprawdę potrzebne.

Jeżeli przy wyłączonych overlayach frametime się wygładza, a po włączeniu Discord overlay lub Overwolf pojawia się nieregularne szarpanie, sygnał ostrzegawczy jest jednoznaczny: konflikt nakładki z trybem pełnoekranowym lub G-Sync/FreeSync.

Higiena systemu pod symulator

Dla jakości frametime w iRacing istotne jest także tło systemowe. Prosty audyt procesów potrafi wyeliminować wiele losowych skoków obciążenia CPU.

• Aktualizacje systemu – automatyczne aktualizacje Windows, instalacja sterowników i skanowanie bezpieczeństwa podczas sesji są prostą drogą do losowych dropów. Aktualizacje najlepiej wymuszać ręcznie poza czasem jazdy.
• Antywirus – real-time scanning nie powinien monitorować katalogu z iRacing ani logów telemetrycznych podczas wyścigu. Wykluczenia dla folderu gry to minimum.
• Procesy w tle – przeglądarki z wieloma kartami, klienty chmurowe (OneDrive, Dropbox), aplikacje do nagrywania wideo w trybie automatycznym – to wszystko może generować nagłe skoki obciążenia CPU i dysku.

Jeżeli log frametime pokazuje losowe skoki co kilka minut bez związku z sytuacją na torze, punkt kontrolny to dokładna analiza procesów w Menedżerze zadań i ewentualne odchudzenie systemu na czas jazdy.

Jeżeli monitor nie pracuje realnie na 144 Hz, sterownik GPU dławi wydajność w imię oszczędzania energii, a w tle działają ciężkie aplikacje, sama zmiana suwaków w iRacing nie przyniesie stabilnego frametime, niezależnie od zastosowanego limitera FPS.

Jak mierzyć i diagnozować frametime w iRacing

Dlaczego średni FPS nie wystarcza

Klasyczne metryki „średni FPS” czy „minimum FPS” dają jedynie ogólny obraz. Audyt jakości płynności przy 144 Hz musi opierać się na frametime i metrykach typu 1% low/0.1% low. Dopiero one pokazują, jak często i jak mocno zdarzają się odchylenia od typowej wartości.

Przykład praktyczny: konfiguracja A ma średnio 160 FPS, ale 1% low na poziomie 90 FPS, a 0.1% low spada do 60 FPS. Konfiguracja B ma średnio 120 FPS, 1% low 110 FPS, a 0.1% low około 100 FPS. Na papierze A wygląda „szybciej”, ale w odczuciu kierowcy B jest nieporównywalnie bardziej przewidywalna i przyjazna. Frametime w B oscyluje np. między 7,5 a 9 ms, natomiast w A między 4 a 16 ms.

Narzędzia do analizy frametime – co sprawdzić i jak je skonfigurować

Diagnostyka frametime przy 144 Hz wymaga precyzyjnych narzędzi. Overlay z samej gry z licznikiem FPS to za mało; potrzebne są logi i wykresy. Minimum to konfiguracja, która pozwala jednocześnie obserwować FPS, frametime oraz obciążenie CPU/GPU.

Podstawowe narzędzia i ich rola:

• MSI Afterburner + RivaTuner Statistics Server (RTSS) – klasyczny tandem do wyświetlania overlay’a z frametime oraz do logowania do pliku CSV. Kluczowe jest włączenie zapisu „Frametime” i „Framerate” oraz użycie statystyk 1%/0.1% low.
• FrameView / CapFrameX – narzędzia do analizy logów z naciskiem na frametime i percentile. Pozwalają wczytać plik z jazdy i precyzyjnie odfiltrować fragmenty sesji (np. tylko start, tylko długi stint).
• Panel sterownika GPU (NVIDIA/AMD) – przydatny do szybkiego wglądu w limitery, G-Sync/FreeSync, stan V-Sync i tryb zasilania. Tu często widać, czy limiter jest podwójny (RTSS + gra) albo czy gra działa w trybie okienkowym bez pełnego G-Sync.

Jeżeli frametime „na żywo” wygląda na niestabilny, ale log z CapFrameX pokazuje regularne skoki dokładnie co kilka sekund, sygnał ostrzegawczy to zewnętrzny proces lub agresywna telemetria, a nie same ustawienia graficzne.

Jeżeli overlay pokazuje równy FPS, ale słupki frametime mają losowe „kolce” w górę, punkt kontrolny to wykluczenie winy sprzętu I/O (dysk, sieć, USB) oraz aplikacji pracujących w tle.

Jak czytać wykres frametime i wyciągać praktyczne wnioski

Wykres frametime dla sesji iRacing przy 144 Hz powinien przypominać możliwie płaską linię z niewielkimi odchyłami. W praktyce liczy się nie tylko średnia, ale także częstotliwość i amplituda „szpilek”.

Główne wzorce zachowania frametime przy 144 Hz:

• Płaski odcinek z pojedynczymi rzadkimi kolcami – typowo drobne operacje systemowe lub sieciowe. Tolerowalne, o ile nie wpływają na reakcję samochodu w kluczowych momentach (wejście w zakręt, start).
• Cykliczne sinusoidy – frametime płynnie rośnie i spada w regularnych odstępach. Często sygnał throttlingu CPU/GPU albo agresywnej regulacji zegarów w trybie „oszczędzania energii”.
• Grupy gęstych „kolców” w konkretnych miejscach toru – doczytywanie obiektów, skoki liczby aut w polu widzenia, zbyt duży „crowd” lub zaawansowane cienie. To obszary, pod które trzeba stroić detale graficzne.
• „Piła” przy starcie i na restarcie – krótkotrwałe, ale powtarzalne przeciążenie CPU przy dużym gridzie. Tu wchodzi w grę optymalizacja liczby widocznych aut oraz ustawień przeciążających CPU.

Jeżeli frametime jest równy w kwalifikacjach i treningu, ale podczas startu w pełnym gridzie nagle powstaje „las kolców”, punkt kontrolny to liczba widocznych przeciwników, złożoność modeli aut i jakość detali w lusterkach.

Jeżeli wykres przez całą sesję ma kształt falującej linii o dużej amplitudzie, niezależnie od sytuacji torowej, sygnał ostrzegawczy to globalny problem z zasilaniem, throttlingiem albo źle ustawionym limitem FPS.

Scenariusze testowe – jak powtarzalnie badać konfiguracje

Porównywanie ustawień „na oko” bywa mylące. Do audytu frametime pod 144 Hz przydają się powtarzalne scenariusze testowe – najlepiej krótkie, ale obciążające reprezentatywne elementy gry.

Przykładowy zestaw scenariuszy:

• Start wyścigu w pełnym gridzie – maksymalne obciążenie CPU i GPU jednocześnie. Idealnie nadaje się do testowania limitera, synchronizacji i ustawień „Opponent detail”.
• Samotne hot-lapy na pustym serwerze – czysta próba stabilności CPU/GPU i systemu, bez wpływu ruchu sieciowego i renderowania wielu aut.
• Jazda w tłumie przy zmiennej pogodzie – scenariusz pod test cieni, odbić oraz znaczenia renderowania efektów (spray, mgła, oświetlenie).
• Camera TV/replay przy pełnym gridzie – często bardziej obciążająca niż cockpit; ujawnia problemy z doczytywaniem i buforowaniem tekstur.

Jeżeli konfiguracja zdaje test hot-lapów, ale wyraźnie „kruszy się” podczas startu i powtórek, punkt kontrolny to redukcja detali przeciwników i zoptymalizowanie efektów zależnych od liczby aut.

Jeżeli logi z powtarzalnych testów pokazują duży rozrzut wyników przy niezmiennych warunkach, sygnał ostrzegawczy to czynnik zewnętrzny: temperatury, inne aplikacje lub zmienna praca łącza sieciowego.

Fundamentalne decyzje: target FPS, limit, synchronizacja

Dobór targetu FPS pod 144 Hz – margines bezpieczeństwa zamiast „idealnych” 144

Dla monitora 144 Hz naturalną intuicją jest target na poziomie 144 FPS. W praktyce jednak najważniejsza jest stabilność wokół targetu, a nie jego zgodność z wartością odświeżania co do FPS. Kilkuprocentowy margines bezpieczeństwa zwykle poprawia frametime wyraźnie bardziej niż gonienie „idealnych” 144.

Podstawowe podejścia:

• Target ≈ 141–143 FPS – bezpieczny bufor pod G-Sync/FreeSync. Idealne, gdy GPU ma zapas mocy, a celem jest minimalizacja input lagu przy nadal bardzo równym frametime.
• Target ≈ 120 FPS – rozsądny kompromis dla słabszych konfiguracji lub triple-screen. Frametime około 8 ms nadal jest bardzo płynny, a margines od 144 Hz zmniejsza ryzyko nagłych skoków.
• Target ≈ 90–100 FPS – opcja awaryjna dla CPU-limitowanych konfiguracji, które nie są w stanie utrzymać wyższej liczby klatek przy starcie i większych gridach.

Jeżeli konfiguracja regularnie „dobija” do 144 FPS, ale co kilka sekund spada nagle do 110–120, sygnał ostrzegawczy to brak marginesu. W takiej sytuacji obniżenie targetu do 141 lub 120 FPS często wygładza frametime bardziej niż jakakolwiek korekta detali graficznych.

Jeżeli przy targetcie 120 FPS frametime nadal ma kolce przy starcie, punkt kontrolny to ograniczenia CPU, a nie sam wybór targetu – trzeba odchudzić scenę lub ograniczyć liczbę przeciwników widocznych w polu widzenia.

Limiter FPS – wewnętrzny iRacing czy RTSS/panel GPU

Źle dobrany limiter FPS potrafi zrujnować nawet dobrą konfigurację sprzętową. Przy 144 Hz i dążeniu do stabilnego frametime kluczowa jest decyzja, który limiter jest nadrzędny i jak jest ustawiony.

Główne opcje limitera:

• Limiter w iRacing – działa w samej grze, integruje się z logiką silnika. Zwykle pierwsze miejsce do konfiguracji. Ustawienie „Max FPS” w pliku ini lub w UI to podstawowy punkt kontrolny.
• RTSS – bardzo precyzyjny limiter z niską wariancją frametime, ale niewłaściwa konfiguracja (podwójne limity, zbyt niskie wartości) może generować dziwne interakcje z G-Sync/FreeSync.
• Panel sterownika (NVIDIA/AMD) – limiter na poziomie sterownika. Działa globalnie lub per gra, ale bywa mniej przewidywalny niż RTSS w kontekście frametime.

Bezpieczna procedura konfiguracji:

1. Wyłączyć wszelkie zewnętrzne limitery (RTSS, panel GPU), ustawić limit w iRacing (np. 141 FPS).
2. Sprawdzić stabilność frametime na kilku scenariuszach testowych.
3. Jeżeli frametime jest „poszarpany”, przetestować zamiast tego limiter w RTSS, wyłączając limiter w iRacing.
4. Unikać podwójnego limitowania (gra + RTSS + panel GPU) – to klasyczny generator nieregularnych skoków frametime.

Jeżeli przy włączonym limiterze w grze frametime skacze w takt zmiany sceny, a RTSS z tym samym targetem daje zauważalnie gładszą linię, punkt kontrolny to pozostawienie limitera w RTSS i wyłączenie limitera w iRacing.

Jeżeli w logach widać charakterystyczny „ząbkowany” wzór z powtarzającymi się wartościami frametime, sygnał ostrzegawczy to walka kilku limiterów o kontrolę nad tempem renderowania.

Synchronizacja pionowa, G-Sync/FreeSync i tryby okna/pełnego ekranu

Przy 144 Hz wybór mechanizmu synchronizacji ma ogromny wpływ na zarówno frametime, jak i input lag. W symulatorze liczy się powtarzalność reakcji bardziej niż prezentacja „filmowa”. Dlatego każdy wariant trzeba traktować jak osobny profil testowy.

Typowe konfiguracje:

• G-Sync/FreeSync + limiter FPS < 144 – klasyczne ustawienie „adaptacyjne” dla 144 Hz. Monitor dopasowuje odświeżanie do FPS, limiter redukuje ryzyko dotykania górnej granicy zakresu, co minimalizuje „szarpnięcia”.
• V-Sync OFF, G-Sync/FreeSync OFF, limiter FPS – minimalny input lag kosztem tearingu. Przy 144 Hz i stabilnym frametime tearing bywa akceptowalny, ale eksponuje się na długich prostych i jednolitych tłach.
• V-Sync ON bez G-Sync/FreeSync – teoretycznie eliminuje tearing, ale zwykle zwiększa input lag i wprowadza ryzyko „stutterów”, gdy FPS nie trzyma dokładnie wielokrotności odświeżania.

Konieczne punkty kontrolne:

• Tryb wyświetlania w iRacing – pełny ekran (exclusive fullscreen) dla pełnej obsługi G-Sync/FreeSync lub dobrze przetestowany „borderless”, jeżeli monitor i sterownik działają poprawnie w tym trybie.
• Stan przełączników w panelu GPU – G-Sync/FreeSync włączony globalnie i dla trybu pełnoekranowego (lub pełnoekranowy + okno, w zależności od monitora).
• V-Sync w grze i w panelu – wyłączyć podwójne wymuszanie; zwykle wyłącza się V-Sync w grze i kontroluje zachowanie przez G-Sync/FreeSync + limiter FPS.

Jeżeli przy G-Sync/FreeSync obraz jest gładki, ale kierownica „pływa” przy szybkich korektach, sygnał ostrzegawczy to zbyt wąski margines limitera (np. 143–144 FPS dla 144 Hz) albo zbyt agresywne buforowanie klatek.

Jeżeli po wyłączeniu G-Sync/FreeSync nagle znikają odczuwalne opóźnienia kosztem tearingu, punkt kontrolny to weryfikacja zakresu VRR monitora i rewizja targetu FPS, aby nie balansować na górnej granicy jego działania.

Buforowanie klatek i kolejkowanie – ukryte źródła opóźnienia

Oprócz widocznych ustawień synchronizacji istotne jest to, jak głęboka jest kolejka renderowanych klatek. Im więcej klatek oczekuje w kolejce, tym wyższy input lag, ale też tym łatwiej ukryć drobne nieregularności frametime kosztem responsywności.

Kluczowe parametry:

• „Low Latency Mode” (NVIDIA) / „Anti-Lag” (AMD) – ustawienie na „On” lub „Ultra” (NVIDIA) ogranicza głębokość kolejki. Przy 144 Hz często jest to punkt wyjścia do redukcji „gumowatości” odczuć z kierownicy.
• Prerendered frames / Maximum pre-rendered frames – starsza nazwa tego samego mechanizmu. Ustawienie wartości 1–2 zwykle poprawia responsywność kosztem minimalnie mniej „miękkiego” frametime.
• Opcje w samej grze – iRacing nie ma tak rozbudowanej ekspozycji tych parametrów, dlatego kontrola przez panel GPU jest często jedynym skutecznym narzędziem.

Jeżeli kierownica reaguje jak przez „poduszkę powietrzną”, mimo równych 144 FPS, sygnał ostrzegawczy to właśnie zbyt głęboka kolejka klatek – należy testowo włączyć tryb niskich opóźnień w sterowniku i powtórzyć pomiar frametime.

Jeżeli po agresywnym ograniczeniu kolejki frametime robi się nieco bardziej „szorstki”, ale auto prowadzi się precyzyjniej, punkt kontrolny to decyzja, który kompromis jest akceptowalny dla danego kierowcy i serii wyścigowej.

Kluczowe ustawienia graficzne w iRacing a 144 Hz

Ustawienia CPU-bound vs GPU-bound – rozróżnienie przed pierwszym cięciem

Przed zmianą poszczególnych suwaków w iRacing trzeba ustalić, czy główne ograniczenie pochodzi z CPU czy z GPU. Tylko wtedy cięcia w odpowiednich miejscach realnie poprawią frametime przy 144 Hz.

Prosta procedura diagnostyczna:

1. Uruchomić scenariusz krytyczny (start wyścigu, pełny grid) z overlayem pokazującym obciążenie CPU/GPU.
2. Obniżyć rozdzielczość o jeden stopień (np. z 1440p do 1080p) przy niezmienionych detalach.
3. Porównać średni FPS i frametime:
• jeśli poprawa jest minimalna lub żadna – ograniczeniem jest CPU;
• jeśli FPS wyraźnie rośnie, a frametime się wygładza – ograniczeniem jest GPU.

Jeżeli po zmianie rozdzielczości frametime praktycznie się nie zmienia, sygnał ostrzegawczy to wąskie gardło po stronie CPU, więc dalsze cięcie jakości tekstur nie przyniesie znaczących zysków.

Detale wpływające głównie na CPU – gęstość otoczenia i ruch

Elementy zależne od CPU najczęściej ujawniają się przy starcie wyścigu, w tłoku oraz na torach z rozbudowaną infrastrukturą. Tutaj każdy nadmiarowy „bajer” przelicza procesor, a nie karta graficzna.

Kluczowe przełączniki i suwaki:

• Opponents Detail / Number of Opponents – im więcej widocznych aut w wysokich detalach, tym większe obciążenie CPU (fizyka, cienie, kolizje, animacje). Punkt startowy dla 144 Hz to:
  • Opponents Detail na Medium/High,
  • Number of Opponents ograniczone do zakresu, który faktycznie widać w lusterkach i przed sobą (zwykle 18–25 zamiast „wszystkie”).
• Visible Cars in Mirrors – dodatkowy mnożnik obciążenia CPU i GPU, bo każde auto jest renderowane drugi raz. Ustawienie „All” często jest nadmierne; realne minimum to to, co ma znaczenie strategiczne (np. 6–10).
• Grandstands / Crowd – tryb „High” na torach z rozbudowanymi trybunami potrafi zabić frametime przy starcie. Ustawienie Low lub całkowite wyłączenie tłumów jest jednym z najtańszych cięć pod kątem FPS.
• Objects / Event / Pit Objects – wszelkie stożki, bandy, elementy w pit lane, ciężarówki, flagi. W wysokich detalach mnożą liczbę obiektów do przeliczenia. Redukcja na Medium ogranicza liczbę aktywnych „drobiazgów” bez radykalnej utraty czytelności toru.
• Particles / Particle Level – dym, kurz, spraye wodne w deszczu. Choć część pracy trafia na GPU, zarządzanie tymi efektami współdzieli zasoby CPU. Tryb Medium zamiast Ultra znacząco odciąża słabsze procesory przy dużym ruchu.

Jeżeli przy samotnych hotlapach 144 FPS jest stabilne, ale w pierwszym zakręcie wyścigu frametime skacze w górę jak „zęby piły”, sygnał ostrzegawczy to zbyt agresywne ustawienia przeciwników i obiektów sceny. Jeżeli po obniżeniu Opponents Detail i zatłoczenia trybun linia frametime się wygładza przy minimalnej wizualnej stracie, punkt kontrolny to trwałe przyjęcie tego profilu jako „wyścigowego”.

Detale wpływające głównie na GPU – rozdzielczość, cienie, odbicia

Po zabezpieczeniu CPU warto uporządkować to, co pożera czas GPU, zwłaszcza w wysokich rozdzielczościach i na monitorach 1440p/4K. Tu głównym celem jest unikanie sytuacji, w której karta ma chwilowe „zapadki” wydajności przy skomplikowanych scenach świetlnych.

Główne obszary do audytu:

• Screen Resolution / DSR / VSR – natywna rozdzielczość monitora jest punktem odniesienia. Dodatkowe skalowanie (DSR/VSR, supersampling) daje kosmetyczny zysk jakości przy ogromnym koszcie FPS. Minimum przy 144 Hz to brak nadmiarowego supersamplingu; lepiej użyć skalowania w dół (np. 90–95% render scale) niż „pchać” więcej pikseli niż monitor faktycznie wyświetla.
• Shadow Detail / Shadow Resolution – jedne z najbardziej destrukcyjnych ustawień dla stabilnego frametime:
  • cienie samochodu gracza – krytyczne dla czytelności, warto trzymać na Medium/High,
  • cienie przeciwników i otoczenia – można agresywnie ciąć do Low lub selektywnie wyłączać dalekie cienie.
• Reflections (Static / Dynamic) – odbicia karoserii, barierek, mokrego asfaltu. Tryb High/Ultra w deszczu potrafi „wystrzelić” frametime przy mijankach i w pit lane. Bezpieczny kompromis dla 144 Hz to:
  • Static Reflections – Medium,
  • Dynamic Reflections – Low/Medium lub ograniczone do najbliższych obiektów.
• AA (Anti-Aliasing – MSAA/SSAA) – wygładzanie krawędzi. SSAA jest wyjątkowo kosztowne na GPU. Zwykle MSAA x2/x4 + ewentualny filtr w sterowniku wystarcza, zamiast SSAA x2 lub wyższych wartości.
• Screen Space Effects (Bloom, God Rays, Lens Flare) – efektowna kosmetyka, ale mały wpływ na prowadzenie auta. Przy 144 Hz to naturalny kandydat do obniżenia lub wyłączenia w profilu wyścigowym.

Jeżeli karta graficzna działa w okolicach 95–99% i każde spojrzenie w lusterko powoduje wyraźny „szarp” na overlayu frametime, sygnał ostrzegawczy to zbyt wysoka kombinacja cieni i odbić. Jeżeli po redukcji refleksów i przełączeniu cieni na Medium zużycie GPU spada z „czerwonej strefy”, a frametime przestaje mieć losowe piki, punkt kontrolny to zostawienie tych ustawień jako twardego limitu dla 144 Hz.

Ustawienia specyficzne dla deszczu i niskiej przyczepności

iRacing w deszczu generuje zupełnie inny profil obciążenia niż suchy tor. Woda, spraye i refleksy świateł tworzą zestaw powtarzalnych „killerów” dla zarówno CPU, jak i GPU, szczególnie przy pełnym gridzie.

Sektory krytyczne:

• Rain / Weather Effects – intensywność i jakość efektów deszczu. Wysokie ustawienia wyglądają widowiskowo, ale mnożą ilość efektów cząsteczkowych i odbić. Dla wyścigów rankingowych bezpiecznym „minimum jakościowym” bywa Medium, tak aby widzieć spray i kałuże bez przesady z „mgłą wodną” w oddali.
• Particles (Rain/Spray) – ilość kropli i mgły za samochodami. To jedna z pierwszych opcji do ścięcia, gdy frametime w deszczu zaczyna „zębić”, podczas gdy sucha sesja jest stabilna.
• Reflections w deszczu – woda na asfalcie mnoży koszt dynamicznych odbić. Jeżeli konieczne jest utrzymanie 144 Hz, Dynamic Reflections w deszczu niemal zawsze powinny zostać na Low, a część graczy całkowicie je wyłącza w profilach „wet only”.
• Headlights / Night Lighting – nocny deszcz to podwójne obciążenie: deszcz + światła. Liczba renderowanych świateł przeciwników (Lod for Headlights) jest krytyczna – warto ograniczyć ich zasięg oraz detale.

Jeżeli suchy tor utrzymuje równy frametime, a po włączeniu sesji deszczowej wykres zamienia się w nieregularny „grzebień”, sygnał ostrzegawczy to brak oddzielnego profilu graficznego pod mokre warunki. Jeżeli po stworzeniu profilu „Rain 144 Hz” z niższymi refleksami, cząsteczkami i światłami nocnymi deszczowe sesje zaczynają zachowywać się podobnie stabilnie jak suche, punkt kontrolny to przypisanie tego profilu do wszystkich serii z dynamiczną pogodą.

Triple-screen, ultrawide i VR – specyfika wysokich odświeżań

Konfiguracje wielomonitorowe i VR stawiają inne wymagania niż pojedynczy ekran 144 Hz. Tu celem często nie jest „sztywne 144 FPS”, ale możliwie najwyższy stabilny target przy ogromnym obciążeniu GPU i CPU.

Dla triple-screen i ultrawide:

• Field of View (FOV) i rozdzielczość łączna – triple-screen oznacza praktycznie potrojenie liczby pikseli. Oczekiwanie 144 FPS w natywnych rozdzielczościach bywa nierealne. Racjonalny cel dla wielu konfiguracji to 100–120 FPS z równym frametime zamiast „szarpanych” 144.
• Shadow / Reflection per Screen – warto traktować cienie i odbicia jak „budżet na ekran”. To, co akceptowalne na jednym monitorze, na trzech staje się trzykrotnie droższe. Minimum to wspólne obniżenie cieni i refleksów na wszystkich ekranach oraz ograniczenie detali w bocznych panelach (jeśli sterownik/gry to umożliwiają).
• Mirrors i boczne kamery – lusterka na bocznych ekranach przy triple-screen są wyjątkowo ciężkie. Redukcja liczby aut w lusterkach i ewentualne obniżenie rozdzielczości lusterek znacząco porządkuje frametime.

W VR:

• Headset Refresh Rate – część gogli pracuje na 90, 120 lub 144 Hz. W VR absolutnym priorytetem jest brak stutterów, a nie sama liczba FPS. Lepszy jest sztywny 90 FPS niż skaczące między 110 a 144.
• Asynchronous Reprojection / Motion Smoothing – dla 144 Hz VR działające reprojekcje mogą ukryć braki FPS, ale każda „przełączka” między prawdziwą a syntetyczną klatką jest widoczna w odczuciu płynności. Minimum to tak dobra optymalizacja detali, aby reprojekcja była wyjątkiem, nie stałym stanem.
• Pixel Density / Supersampling VR – każdy krok ponad 100% render scale w VR zwiększa koszt GPU lawinowo. Przy dążeniu do równych 144 Hz w goglach często trzeba zejść do 80–100% i skompensować ostrość filtrami post-process.

Jeżeli triple-screen w hotlapach trzyma 144 FPS, a w wyścigu pojawia się charakterystyczne „pływanie” przy mijankach, sygnał ostrzegawczy to brak realnej rezerwy wydajności dla trzykrotnej liczby pikseli i przeciwników. Jeżeli obniżenie targetu do 120 FPS i równoległe ścięcie odbić oraz cieni w triple-screen powoduje spłaszczenie wykresu frametime, punkt kontrolny to uznanie 120 FPS za bardziej adekwatny cel niż „papierowe” 144.

PPD, supersampling i skalowanie obrazu – jak nie przekarmić 144 Hz

Poza rozdzielczością nominalną liczy się także liczba pikseli faktycznie renderowanych przez silnik gry i sterownik. Skalowanie obrazu i supersampling potrafią po cichu zwiększyć obciążenie nawet o kilkadziesiąt procent.

Najważniejsze mechanizmy:

• Render Scale / Resolution Scale – wewnętrzna rozdzielczość renderowania w stosunku do rozdzielczości wyświetlanej. Ustawienie powyżej 100% szybko winduje koszt GPU. Zamiast 110–130% bez kontroli, lepiej:
  • ustawić 100% jako baseline,
  • testowo zejść do 90–95% i sprawdzić wpływ na frametime oraz czytelność na konkretnym monitorze.
• Driver-level DSR/VSR / Image Scaling – globalne funkcje w sterownikach, które można przypadkiem zostawić aktywne. Sygnał ostrzegawczy to niezgodność między rozdzielczością ustawioną w grze a liczbą pikseli raportowaną przez overlay sterownika.
• Resolution Per Display (PPD w VR) – headsety raportują często „efektywną” rozdzielczość. Każdy skok PPD to w praktyce dodatkowe obciążenie dla GPU podobne do zwiększenia rozdzielczości monitora. Minimalny audyt to upewnienie się, że nie ma podbitego PPD w softwarze gogli ponad faktyczne potrzeby.

Jeżeli benchmarki syntetyczne sugerują, że konfiguracja powinna trzymać stabilne 144 FPS, a iRacing w praktyce „dusi” się przy 120–130 FPS, sygnał ostrzegawczy to właśnie nadmiarowe skalowanie lub supersampling. Jeżeli po wyłączeniu DSR w sterowniku i zresetowaniu render scale do 100% frametime nagle stabilizuje się w okolicach oczekiwań, punkt kontrolny to utrzymywanie skalowania jako wyjątku z pełną świadomością kosztu, a nie domyślnego dodatku.

Światła, cienie dynamiczne i nocne wyścigi przy 144 Hz

Nocny tor z pełnym oświetleniem to klasyczny stres test dla 144 Hz. Każdy reflektor, każda dynamiczna latarnia i każdy cień jest elementem obciążającym równocześnie GPU i CPU.

Elementy wymagające szczególnej dyscypliny:

• Headlights Quality / Range – jakość i zasięg świateł własnego auta i przeciwników. Optymalne ustawienie dla wyścigów nocnych to:
  • wysoka jakość i pełny zasięg dla samochodu gracza,
  • ograniczony zasięg i/lub niższa jakość świateł dla przeciwników, szczególnie tych w dalszej odległości.
• Dynamic Lights Count – maksymalna liczba jednocześnie aktywnych źródeł światła. Ustawienia typu „All” przy gęstym gridzie są zbyt kosztowne dla stabilnego frametime. Rozsądne minimum to wartość, która zapewnia dobrą widoczność najbliższych aut i kluczowych fragmentów toru, a resztę oświetlenia upraszcza.
• Shadow Casting Lights – nie każde źródło światła musi rzucać pełny cień. Jeżeli silnik gry oferuje rozróżnienie, warto zrezygnować z cieni dla dalszych lamp torowych, zostawiając je tylko dla najbliższego otoczenia auta.

Jeżeli przy nocnych wyścigach overlay frametime tworzy regularne „piki” przy każdej grupie samochodów, sygnał ostrzegawczy to zbyt wysoki limit dynamicznych świateł i pełne cienie dla wszystkich. Jeżeli po ograniczeniu zasięgu i liczby świateł przeciwników wciąż jesteś w stanie bezpiecznie czytać apex i pozycje aut, a wykres frametime staje się prostszy, punkt kontrolny to zaakceptowanie mniejszej „scenografii” na rzecz kontroli nad samochodem.

Profil „kwalifikacyjny” vs „wyścigowy” – dwa zestawy pod 144 Hz

Najczęściej zadawane pytania (FAQ)

Jakie FPS są optymalne pod monitor 144 Hz w iRacing?

Praktyczny zakres dla 144 Hz w iRacing to najczęściej 120–140 FPS. Warunek: frametime musi być możliwie równy, bez „pików” przy starcie, w tłoku i na torach z dużą liczbą detali. Jeżeli w najcięższych sytuacjach 1% low spada mocno poniżej targetu, nominalne 144 FPS są tylko pozorne.

Punkt kontrolny jest prosty: jeśli przy 144 FPS odczuwasz szarpanie w szybkich łukach, a po obniżeniu limitu do ~120 FPS ruch staje się spójny, to znak, że sprzęt nie dowozi „żelaznego” 144 Hz. W takiej sytuacji lepiej utrwalić stabilne 120 FPS niż gonić za nierealnym 144.

Co jest ważniejsze w iRacing: wysoki FPS czy stabilny frametime?

Stabilny frametime. Nawet 200 FPS ze skaczącym czasem klatki (np. 4 ms → 12 ms → 7 ms) będzie wyglądać i „czuć się” gorzej niż stałe 120 FPS z frametime w wąskim przedziale. Mózg bardzo szybko wyłapuje mikrostuttering, szczególnie przy ruchu bocznym i na starcie wyścigu.

Sygnał ostrzegawczy: overlay pokazuje 180–220 FPS, a mimo to obraz szarpie na prostych i przy szybkim rozglądaniu się. Punkt kontrolny: monitoruj 1% low i 0.1% low oraz przebieg frametime; jeśli są mocno oderwane od średniej, priorytetem staje się cięcie detali i/lub obniżenie targetu FPS.

Jak ustawić limiter FPS w iRacing pod monitor 144 Hz?

Bezpieczna praktyka to ustawienie limitu odrobinę poniżej odświeżania monitora, np. 140 FPS przy 144 Hz. Pozostawia to bufor kilku milisekund na wahania obciążenia GPU/CPU, ogranicza przepełnianie kolejki renderowania i zmniejsza opóźnienie wejścia w porównaniu z twardym uderzaniem w 144 FPS.

Jeżeli mimo takiego ustawienia nadal widzisz „piłę” na wykresie frametime przy starcie lub w tłoku, kolejny punkt kontrolny to dalsze obniżenie limitu (np. do 120 FPS) oraz redukcja najcięższych ustawień CPU-zależnych (liczba aut, cienie, powtórki), aż frametime „się wypłaszczy”.

Jak poprawnie skonfigurować G-Sync/FreeSync dla iRacing przy 144 Hz?

Krok po kroku trzeba zweryfikować: czy monitor ma aktywny G-Sync/FreeSync w OSD, czy w Windows ustawione jest faktyczne 144 Hz oraz czy w panelu sterownika adaptacyjne odświeżanie jest włączone dla iRacing. Dodatkowo limiter FPS ustaw niżej niż maksymalne odświeżanie monitora (typowo 2–4 FPS mniej).

Jeśli po włączeniu G-Sync/FreeSync obraz jest płynniejszy, ale pojawia się „sprężynowanie” kierownicy lub opóźnienie wejścia, sygnałem ostrzegawczym jest zbyt napięty limiter (np. 143–144 FPS przy 144 Hz) albo CPU dochodzące do 100% na krytycznych wątkach. W takiej sytuacji punktem kontrolnym jest lekkie obniżenie limitu FPS oraz detali obciążających procesor.

Dlaczego iRacing szarpie głównie na starcie wyścigu przy 144 Hz?

Start wyścigu to maksimum obciążenia CPU: pełen grid, wiele aut w lusterkach, dynamiczne cienie, AI (tam gdzie występuje), powtórki i telemetria. Jeśli jeden z krytycznych wątków procesora dobija do 100%, frametime zaczyna rosnąć skokowo, mimo że średni FPS nadal wygląda „dobrze” w overlayu.

Sygnał ostrzegawczy: w solo hotlap wszystko jest gładkie, a w wyścigu wykres frametime zamienia się w „piłę” od startu do pierwszych kilku okrążeń. Minimum, jakie trzeba wtedy zrobić, to:

• obciąć detale zależne od CPU (liczba widocznych aut, jakość cieni, efekty w lusterkach),
• zmniejszyć jakość i częstotliwość powtórek (Replay),
• ewentualnie obniżyć target FPS (np. z 144 do 120 lub 100 FPS).

Jeśli po tych zmianach frametime na starcie się wyrównuje, problemem nie był „za słaby GPU”, tylko przeciążony procesor.

Jak sprawdzić, czy problem z płynnością wynika z monitora czy z ustawień gry?

Najpierw trzeba potraktować monitor jak osobny obiekt audytu. Kryteria: czy w Windows wybrane jest faktyczne 144 Hz, czy w OSD monitor rzeczywiście pracuje na 144 Hz, czy G-Sync/FreeSync jest aktywny w zadeklarowanym zakresie oraz czy tryby typu „low input lag” lub upiększające filtry nie powodują dodatkowego opóźnienia lub artefaktów.

Jeżeli po doprowadzeniu monitora do spójnej konfiguracji nadal widzisz mikrostuttering, punkt kontrolny przenosi się do gry: porównaj zachowanie w solo vs. pełen grid, z powtórkami i bez, z niższym limitem FPS vs. „odblokowanym”. Jeśli problem nasila się wyłącznie przy obciążeniu CPU (tłok, powtórki, cienie), źródłem problemu nie jest monitor, tylko konfiguracja iRacing.

Jakie ustawienia graficzne w iRacing najbardziej psują frametime przy 144 Hz?

Najgroźniejsze dla stabilnego frametime są ustawienia mocno obciążające CPU: duża liczba widocznych aut, wysokie detale cieni (zwłaszcza dynamicznych), intensywne efekty w lusterkach, wysoka jakość i częstotliwość zapisu powtórek. To one na starcie i w peletonie „dopychają” procesor do limitu.

Punkt kontrolny: jeśli frametime jest dobry w hotlapie, ale „rozsypuje się” przy pełnym gridzie, priorytetem jest cięcie właśnie tych opcji, a nie zbijanie ogólnej jakości tekstur czy AA. Minimum, do którego warto dążyć, to konfiguracja, w której 1% low i 0.1% low są możliwie blisko średniej FPS w typowych dla ciebie warunkach wyścigowych.

Źródła

• G-SYNC 101: Input Lag & Optimal Settings. Blur Busters – Analiza wpływu G-Sync, limiterów FPS i V-Sync na input lag i frametime
• NVIDIA G-SYNC Technology Overview. NVIDIA – Opis działania G-Sync, adaptacyjnego odświeżania i zależności FPS–Hz
• AMD FreeSync Technology Whitepaper. AMD – Zasady działania FreeSync, zakresy odświeżania i wpływ na płynność obrazu
• iRacing User Manual – Graphics, Display and Replays. iRacing.com Motorsport Simulations – Oficjalne zalecenia dot. ustawień grafiki, powtórek i obciążenia CPU/GPU
• High Performance Graphics and Game Performance Optimization Guide. Intel – Wpływ CPU, wątków i ustawień graficznych na FPS i stabilność frametime