Bevezető
A VSync az AA és az AF mellett az egyik legrégebben használt, többnyire minden játék által támogatott
"képjavító effekt". Míg az AA-t többé-kevésbé mindenki ismeri ("recék eltüntetése"), egy, a VSync működésére
vonatkozó körkérdésre valószínűleg közel sem 100%-ban helyes válaszok érkeznének. Mivel a VSync-et egy
hasznos eszköznek tartjuk, amelynek viszont váratlan hatásai lehetnek a játékok teljesítményére, érdemesnek
gondoltuk egy cikkben áttekinteni, hogyan is működik, ill. milyen "mellékhatásokra" kell számítani, ha
bekapcsoljuk.
Mi a VSync és hogy működik?
A VSync (egyes helyeken VSynch) a Vertical Synchronization kifejezés rövidítése,
amit magyarra talán (nem igazán) frappánsan úgy lehet fordítani, hogy Várakozás a képfrissítésre.
A név tömören le is írja a működést: amikor a VSync be van kapcsolva, akkor a VGA-kártya a következő frame
megrajzolásának elkezdésével megvárja, amíg az előző frame megjelenítése befejeződött (azaz pl. a CRT
monitorokon a katódsugár eljutott a képernyő legaljára). Ennek az az értelme, hogy elkerülhető vele a
tearing ("képszakadás") hatás: amennyiben a kép megrajzolása és megjelenítése "ütközik" egymással, akkor
egy megrajzolt kép helyett két fél képet látunk. Pl. ha a rajzolás lassabban halad, és a katódsugár "beelőz"
a képernyő felénél, akkor a képernyő felső felében az aktuálisan rajzolt, alsó felében az előző képkocka
látszik. Az alábbi két ábra ezt igyekszik szemléltetni, előbb elvi síkon, majd gyakorlatban:
A tearing elsősorban akkor kellemetlen, amikor nagy sebességgel megy a játék
és / vagy gyorsan változnak a fényviszonyok (ilyen játék pl. a F.E.A.R.) - a képernyőn látható csíkok eléggé
ki bírják zökkenteni az embert a játék élvezetéből, és ilyenkor érdemes a VSync-et bekapcsolni. Ez a megoldás
rögtön jelent egy sebességbeli korlátot is: bekapcsolt VSync mellett a játék futása nem lehet gyorsabb, mint
a képernyőnk képfrissítése (a legtöbb játékosnál 60Hz, 75Hz vagy 85Hz - ez rendre 60fps-t, 75fps-t és 85fps-t
jelent). Még ennél is nagyobb gond azonban, hogy ha a játék sebessége alacsonyabb, mint a képfrissítés
frekvenciája, akkor a játék által nyújtott fps a várakozások miatt alacsonyabb lesz - 60 Hz-es képfrissítést
feltételezve, 50fps-ből 30fps lesz, 28 fps-ből 20fps, stb. Erről is rajzoltunk egy ábrát:
A fentiekből látható, hogy a VSync működésével kapcsolatban felmerülnek
időzítési és megvalósítási kérdések - ezek minél jobb megoldásának érdekében a VSync működése az évek folyamán
változott is. Jelenleg 3 módon tudunk VSync-et csinálni (ebből a játékok az elsőt egyáltalán nem használják) -
lássuk ezek ismertetését!
Single Buffer
Nagyon régen, még a C64-es időkben a programozó a látható képernyőre rajzolt - egyrészt nemigen
törődött a tearing hatással, másrészt a memória mérete miatt igen korlátozottak voltak a lehetőségei arra,
hogy a második (Double Buffering) megoldást használja. Ilyenkor a VSync-nek is elég kevés
értelme van: miután a katódsugár a rajzolás alatt lévő képen "szaladgál", a tearing csak akkor kerülhető el,
ha a képernyő megrajzolása gyorsabb, mint a képfrissítés. Az Amigán és a PC-n ezt a megoldást már nem is
használta szinte senki (sőt, C64-en is leszkoktak róla, ahogy a karakteres képernyő előtérbe került).
Double Buffering
A Double Buffering megoldás egy nagyon egyszerű összefüggés (vagy inkább össze nem függés)
felismerésének eredménye: nem kell feltétlenül ugyanazt a képet néznünk, amit éppen rajzolunk, hanem az
aktuális képkocka rajzolása közben ráérünk az előző képet nézni - ha elég gyors a rajzolás (30-40fps már
jó ebből a szempontból), akkor ez a kis késés nem fog feltűnni még akkor sem, ha az aktuális
kocka megrajzolása közben két frissítésnyi ideig (60Hz esetén 2x16.6 = 33.3ms-ig) kell bámulnunk az előzőt.
A megoldás ebből egyenesen következik: két képernyőt (buffert) használunk, az egyikre rajzolunk, a másikat
pedig megmutatjuk, majd a rajzolás befejezésekor megcseréljük a kettőt. Viszont lényegében ezzel állandósítjuk a
tearninget, mert a két kép megcserélésekor a katódsugár szinte biztosan a képen jár valahol, és bufferek
cseréjekor a képernyő alsó részén már az új kép látható, fent viszont még a régi:
A VSync bekapcsolása ezt a gondot 100%-osan megoldja - addig ismételgeti az előző kép megjelenítését
az éppen erre a célra beállított bufferből, amíg a következő kép el nem készül, és ezután a következő
megjelenítés befejezése után jöhet a buffercsere. Kép:
A képen jól látszik, miért is van a VSync-nek hatása a teljesítményre,
és miért lesz az fps-ünk a képfrissítés frekvenciájának egész számú osztója - amikor a VGA végez a kép
kirajzolásával, akkor utána addig kényszerpihenőn lesz, amíg a frissítés be nem fejeződik, és meg nem történik
a buffercsere, ugyanis egyszerűen nincs hová rajzolnia. Ezen segít a következő, egyben utolsó megoldás.
Triple Buffering
Az előző technika rendkívül egyszerű módon továbbfejlesztett változata a Triple Buffering - a két
buffer helyett három van, az egyik látható, a másik kettőbe rajzolni tudunk. Így az előzőekben felvázolt
várakozás megszűnik - ha az első rajzbuffer betelik, akkor a maradék ráérő időben a másodikban már készülhet
a következő kép (miközben a képernyőn a harmadik buffer tartalma látható).
Ezek az előredolgozások aztán egy idő után felgyülemlenek - ha pl. 40fps sebességgel menne
a játék VSync nélkül, akkor az első képkocka kirajzolására két frissítésnyi időt kell várni, a másodikéra
viszont csak egyet - és így a Double Buffering 30fps-ével szembem itt meglesz a 40fps. A következő
ábrán ez látható:
Érdemes kiemelni, hogy a Triple Buffering akkor a leghasznosabb, amikor a
játék sebessége a képfrissítés sebessége környékén ingadozik - ekkor a 30fps-es és 60fps-es szakaszok
váltakozása nagyon zavaró tud lenni, ezt a Triple Buffering csaknem teljesen kiküszöböli azáltal, hogy a
60fps-es teljesítménybe csak sokkal ritkábban és rövidebb időre "rondít bele" egy-egy 30-as szakasz.
A teszt és az alapfeltételezések
Miután a játékokra többnyire nincs nagy betűkkel ráírva, hogy melyik technikát használják, és a driverekben
megjelenő "force triple buffering" típusú opciók eléggé hatástalanok, kénytelenek
vagyunk mérésekkel kideríteni, mi is a helyzet - innen tudjuk levonni a következtetést, hogy az adott
játékban érdemes-e a VSync-et használni. A következő feltételezésekkel élünk:
- Ha a játék sebessége jelentősen (30-40%) a képfrissítési frekvencia (esetünkben 60Hz) felett van, akkor várhatóan nincs különbség a két, ill. három buffer között, 60fps körül lesz a teljesítmény.
- Ahogy közeledünk a 60fps-hez, a Double Buffering megoldás a 60fps alá időnként "beeső" sebesség miatt elkezd lassulni, míg a Triple Buffering a lassabb frame-eket tudja kompenzálni, ezért szinte fix 60fps-en fog futni a játék.
- 60fps alatt a Double Buffering rohamosan elkezd lassulni, és a VSync nélküli 50fps-ből már jobbára csak 30 marad - a Triple Buffering teljesítmény fokozatosan csökken, és minimálisan lesz lassabb, mint a VSync nélküli eset.
- 30fps felé közeledve az előző két eset fog ismétlődni feleakkora sebességgel, majd ugyanez 20fps-re, és így tovább - ennél a sebességnél már nem a tearing a játékos legfőbb gondja.
Tesztkörnyezet
| A konfiguráció elemei | |
| Alaplap | Gigabyte X38-DS4, FSB @333MHz |
| CPU és órajel | Intel E6700 (4M L2 cache), @3.00GHz (9x333) |
| CPU hűtés | Cooler Master HyperTX2 |
| Memória | 4x1GB Geil Ultra DDR2-8500 |
| Memória beállítások | 1066MHz (3.2x333), 5-5-5-15, tRD: 6 |
| Tápegység | Corsair TX650 |
| Operációs rendszer | Windows Vista x86 Ultimate SP1 |
| VGA neve | Core clock | Shader clock | Memory clock | Driver |
| Radeon HD4850 | 625 MHz | 993 MHz (x2) | Catalyst 8.11 WHQL | |
A VGASpeed.hu tesztkörnyezetének részletes ismertetője itt
található meg.
A tesztben résztvevő játékok
DirectX 9
F.E.A.R. v1.08
Oblivion v1.2.046
Race Driver: GRID v1.2
Rainbow Six: Vegas v1.06
DirectX 10
Bioshock v1.1
Crysis v1.21
World in Conflict v1.09
DirectX 10.1
Assassin's Creed v1.0
Far Cry 2 v1.0
S.T.A.L.K.E.R.: Clear Sky v1.5.0.7
Unigine Tropics demo v1.1
A játékokról, ill. a VGASpeed.hu tesztmódszereiről részletes ismertető
a bal oldali menü Tesztmódszer és játékok pontjában érhető el.
Mivel itt a játékok viselkedését vizsgáltuk, nem mértük végig az összes szokásos
esetet (6 / játék), hanem igyekeztünk egy-egy olyat kiválasztani, ahol jól megmutatkozik, mit is művel a játék
a bufferek tekintetében.
Nézzük akkor az elmélet után, mit mutat a gyakorlat!