// magyarázó · 2026.07.11 Mi az az 1% low FPS, és miért lehet darabos egy játék 120 FPS mellett is? A 1% low FPS megmutatja, milyen gyakran esik szét a simaság a rosszabb képkockák miatt. Ezért lehet darabos egy játék magas átlag FPS mellett is. olvasás →

A modern PC-s játékosok egyik legidegőrlőbb élménye: a gépházban a legújabb grafikus vezérlő és egy modern többmagos processzor dolgozik, a monitor sarkában lévő mérőszoftver stabil 120 vagy 140 képkockát jelez másodpercenként, a játékmenet mégis váratlanul megtorpan. Amint eldördül egy új fegyver, felrobban az első gránát, vagy átlépünk egy új zóna küszöbén, a kép tizedmásodpercekre kőkeményen megdermed. Ez a jelenség a shader-fordításból fakadó akadozás (shader compilation stutter). A mikromegakadások közvetlenül a modern, alacsony szintű grafikus felületek architektúrájából és a PC-s hardverkörnyezet töredezettségéből fakadnak.

Hogyan látja a videokártya a játék kódját?

A shaderek (árnyalók) valójában kisméretű, rendkívül specializált programok, amelyeket a grafikus processzor több ezer számítási magja párhuzamosan futtat. Ők felelnek a háromdimenziós modellek geometriájának mozgatásáért (vertex shader), a felületek textúrázásáért és megvilágításáért (pixel shader), valamint a füst-, víz- és részecskeeffektek fizikai viselkedéséért (compute shader). Egy modern, összetett játék akár több tízezer vagy százezer ilyen különálló shader-programot is használ a jelenetek felépítéséhez.

A fejlesztők ezeket a kódokat magas szintű programozási nyelveken, például HLSL (High-Level Shader Language) vagy GLSL környezetben írják meg. Amikor a Steamen vagy más digitális áruházban letöltünk egy játékot, a telepítőcsomagban ezek a kódok platformfüggetlen köztes kódként (DirectX Bytecode / DXIL vagy SPIR-V) érkeznek meg a háttértárra a végleges gépikód-fájlok helyett.

Itt ütközik ki a PC-s platform alapvető sajátossága. Míg a központi processzorok terén az évtizedek óta szabványos x86-64 architektúra miatt a lefordított programfájl egyaránt natívan fut Intel és AMD processzoron, a grafikus processzorok világában nincs egységes utasításkészlet (ISA). Az NVIDIA Ada Lovelace vagy Blackwell mikroarchitektúrája teljesen más gépi logikát és regiszterkiosztást használ, mint az AMD RDNA 3 és RDNA 4 megoldásai, vagy éppen az Intel Xe grafikus chipjei. A köztes kódot ezért közvetlenül a felhasználó gépén, a telepített grafikus meghajtóprogram (driver) segítségével át kell fordítani a hardver saját, natív gépi kódjára.

DirectX 11 vs. DirectX 12: a védőháló eltűnése és a PSO-paradigma

A korábbi DirectX 11-es korszakban a játékosok jóval ritkábban szembesültek ezzel a problémával. A DirectX 11 magas szintű grafikus felületként működött: a meghajtóprogram óriási háttérmunkát végzett el a fejlesztők helyett. A renderelési állapotokat – például a képelemek keverését (blend state), a mélységellenőrzést és a raszterizálást – a játékmotor futásidőben, egymástól függetlenül módosíthatta. A grafikus kártyák driverei a háttérben folyamatosan optimalizálták és összefésülték ezeket az állapotokat, miközben az NVIDIA és az AMD mérnökei kézzel készített játékprofilokkal simították el a felmerülő akadozásokat.

A meghajtóprogram kényelmi szolgáltatásai komoly processzorterhelést (driver overhead) generáltak a háttérben: a CPU egyetlen vezérlőszála rendszeresen a grafikus kártya szűk keresztmetszetévé vált, megakadályozva a hardver maximális kihasználását.

Műszaki szempontDirectX 11 (Magas szintű API)DirectX 12 / Vulkan (Alacsony szintű API)
ÁllapotkezelésDinamikus, független állapotok (különálló raszterizáció, maszkolás, keverés)Monolitikus Pipeline State Object (PSO): minden állapot egyetlen oszthatatlan blokkban
Shader-fordításA grafikus meghajtóprogram (driver) intézi és simítja el a háttérbenA játékmotor közvetlen feladata az állapotok előzetes összeállítása és mentése
Processzorterhelés (Overhead)Jelentős: a meghajtóprogram folyamatosan egyetlen fő CPU-szálat terhelMinimális: közvetlen hardverelérés és kiváló többmagos processzorkihasználás
Akadozás (Stutter) jellegeRitkább mikromegakadás, de a CPU-korlát miatt alacsonyabb maximális képkockaszámDrasztikus mikromegakadás (frame time tüske), ha a szükséges PSO hiányzik a cache-ből
Előzetes fordítási igényMinimális menübeli várakozásKötelező előzetes fordítás („Building Shaders”) az akadozásmentes játékmenethez
A DirectX 11 és DirectX 12 renderelési és állapotkezelési különbségei

A modern hardverekhez tervezett, alacsony szintű felületek – a DirectX 12 és a Vulkan – pont ennek a korlátnak a lebontására születtek. Eltávolították a driver védőhálóját, és a hardver közvetlen vezérlését a játékfejlesztők kezébe adták. Bevezették a Pipeline State Object (PSO) koncepcióját. A modern grafikus hardvereken a csővezeték egyes fázisai szoros függőségben állnak egymással: a hardver nem tudja a shadert önmagában értelmezni anélkül, hogy ne ismerné pontosan a hozzá kapcsolódó geometriai formátumot, a raszterizációs beállításokat és a kimeneti renderelési célokat.

A DirectX 12 megköveteli, hogy a fejlesztők az egész grafikus csővezetéket egyetlen, oszthatatlan blokként (PSO) hozzák létre és fordítsák le. Egy ilyen összetett állapot lefordítása a hardver sajátosságaitól és a kód bonyolultságától függően akár több tíz ezredmásodpercig is elhúzódhat a processzoron. Amikor a játékmotor elmulasztja a csővezeték-állapotok előzetes összeállítását és gyorstárazását, a fordítás közvetlenül a játékmenet közben indul el – pontosan akkor, amikor a képernyőn először bukkan fel egy új részecske-effekt vagy egy ellenfél modellje. A renderelő szál kényszerpihenőt tart, a grafikus vezérlő várakozásra kényszerül, a képkockaidő (frame time) pedig a folyamatos 60 vagy 120 FPS-hez szükséges 16,6 vagy 8,3 milliszekundumos szintről hirtelen a másodperc töredékéig tartó kiugró tüskével lő ki, amit a játékos azonnali, érezhető akadozásként él meg.

Miért nem tapasztalunk ilyet PlayStation 5-ön vagy Steam Decken?

A konzolos játékosok körében a shader-akadozás gyakorlatilag ismeretlen jelenség. A magyarázat a hardveres zártságban rejlik:

  • Rögzített hardverprofil: A PlayStation 5 és az Xbox Series konzolokban pontosan meghatározott, egységes AMD hardverkomponensek találhatók. A fejlesztők az irodáikban, még a játék boltokba kerülése előtt le tudják fordítani a szoftver összes létező PSO-állapotát a konzol natív gépi kódjára. Amikor a játékos letölti a címet, a merevlemezre már a végleges, kész bináris kerül – a konzolnak játék közben egyetlen sort sem kell fordítania.
  • A Steam Deck és a Valve hálózata: Bár a Steam Deck PC-s játékokat futtat a Proton kompatibilitási rétegen keresztül, a Valve a Steam hálózatát használja fel a probléma elhárítására. A Fossilize nevű eszköz rögzíti a játékok futása során előforduló összes pipeline-állapotot. Mivel az összes Steam Deckben azonos APU és nyílt forráskódú Mesa RADV meghajtóprogram dolgozik, a Valve szerverein lefordítják ezeket a shadereket, és a Steam kliens a játék letöltésekor automatikusan mellékeli az előre elkészített gyorsítótárat (Steam Shader Pre-caching).

Az asztali PC-k piacán a processzorok, dedikált videokártyák, architektúrák és meghajtóprogramok kombinációja rendkívül töredezett. Emiatt a zárt konzolokkal ellentétben lehetetlen egyetlen, központilag előre lefordított univerzális bináris csomagot kiadni, amely minden konfiguráción azonnal működne.

A „Building Shaders” képernyők és a motorok védelmi vonalai

Amikor egy modern játék – például a The Last of Us Part I, egy Call of Duty epizód vagy egy Unreal Engine 5 alapon futó cím – első indításakor percekig tartó betöltőcsíkot nézünk a főmenüben, a program pontosan ezt a fordítási munkát végzi el. A játék a processzor összes magját maximális terhelésre járatva végigmegy a játéktérben előforduló ismert PSO-kon, és a lefordított gépi utasításokat a helyi meghajtón található Shader Cache könyvtárba menti.

Bár a játékosok gyakran kényelmetlennek érzik a menüben való várakozást, jelenleg ez jelenti a legbiztosabb védelmet a játék közbeni mikroakadások ellen. Amint egy shader bekerül a helyi tárolóba, a grafikus vezérlő a következő alkalommal azonnal, mikroszekundumos késleltetéssel hívja be a memóriába.

Az újabb játékmotorok emellett aszinkron shader-fordítást (Async Shader Compilation) alkalmaznak. Ha a játékos olyan zónába lép, amelynek csővezeték-állapota még nem szerepel a gyorsítótárban, a motor nem fagyasztja le a képkockák megjelenítését: a fordítást a háttérszálakra irányítja, a képernyőn pedig átmenetileg egy egyszerűsített, alapértelmezett shadert jelenít meg. Ennek hatására a kép folyamatos marad, legfeljebb az vehető észre, hogy egy fénycsóva, fegyvertűz vagy árnyékfelület egy pillanatnyi késéssel kapja meg a részletes kidolgozást.

Gyakorlati lépések a játékosok számára

A probléma alapvető forrása a motorok felépítésében rejlik, a felhasználók azonban a rendszer beállításával csökkenthetik a kellemetlen tüneteket:

  • Ne szakítsuk meg az előzetes fordítást: Ha a játék a főmenüben vagy az indításkor shader-optimalizációt jelez, érdemes megvárni a folyamat végét a kampány vagy az online mérkőzés elindítása előtt.
  • A Shader Cache méretének megnövelése az illesztőprogramban: Az NVIDIA Vezérlőpultban (3D beállítások kezelése) a Shader Cache Size paraméter alapértelmezetten a meghajtóprogramra van bízva (Driver Default), ami a gyakorlatban szűkös, mindössze néhány gigabájtos lemezterületet engedélyez. A mai 80–120 GB-os modern címek mellett ez a tárhely hamar megtelik, a rendszer pedig a legrégebben indított játékok lefordított gyorsítótárát automatikusan felülírja – így egy régebbi címhez visszatérve a fordítási folyamat elölről kezdődik. A beállítást érdemes kézzel 10 GB-ra vagy korlátlanra (Unlimited) módosítani némi háttértár feláldozásával, megelőzve a gyorsítótár idő előtti törlését.
  • A videomemória (VRAM) túllépésének kerülése: Ha a grafikai beállítások túllépik a videokártya fizikai memóriáját, a textúrák és adatok a PCIe buszon keresztül a lassabb rendszermemóriába szorulnak. A memóriahiány okozta késleltetés és a shader-fordítási tüske összeadódva drasztikus akadozást eredményez.
  • Driverfrissítés utáni türelem: Minden grafikus illesztőprogram-frissítés érvényteleníti a korábban lementett shader cache állományokat, mivel a driver fordítólogikája megváltozhatott. Új driver telepítése után az első játékmenetek során természetes, ha a gyorsítótár újbóli felépüléséig átmeneti mikroakadások tapasztalhatók.

A PC-s hardverkínálat sokszínűsége miatt a shader cache felépülése elkerülhetetlen technológiai lépés marad: a csúcskategóriás grafikus chipek sem tudják kikerülni a hiányzó PSO-k fordítási idejét, a mikroakadások hatékony felszámolásának valódi kulcsa a játékmotorok agresszív háttérszálas és aszinkron rutinjaiban rejlik.