reinterpretcast
Yllä olevassa esimerkissä saattaa aluksi vaikuttaa siltä, että virkistystaajuus 0,26 Hz ja ruudunpäivitysnopeus 0,2 FPS (Frames Per Second) saattavat olla tarpeeksi lähellä toisiaan, jotta näytöt näkyisivät oikein, mutta on kuitenkin selvää, että kun katsot demoa, nämä kaksi ovat täysin epäsynkronoituja ja näin ollen ruudun repeäminen tapahtuu säännöllisesti.
Todellinen ongelma tässä esimerkissä on se, että se on ”yhden puskurin sovellus”. Kirjoitamme kehykset suoraan puskuriin, joka syötetään näytölle, joten kun näyttö haluaa päivittää kuvansa, on olemassa riski, että se saa kehyksen, joka ei ole vielä täysin valmis. Todellisessa sovelluksessa ruudunpäivitysnopeus voi usein muuttua dramaattisesti tietyistä olosuhteista riippuen, mikä voi pahentaa tätä ongelmaa yhden puskurin sovelluksissa ja tehdä näytön repimisestä entistäkin arvaamattomampaa.
Tuplapuskurointi
Yksi keino lieventää joitakin näistä ongelmista on käyttää tuplapuskurointia. Tämä piirtotapa koostuu siitä, että kehyksen tiedot kirjoitetaan takapuskuriin ja kopioidaan sitten ensisijaiseen puskuriin (näytön videosyöttö) vasta, kun kehys on valmis. Näin käyttäjä ei koskaan näe puolivalmiita kehyksiä, eikö niin? Väärin.
Vaikka ruudun repeäminen yleensä vähenee huomattavasti kaksinkertaisen puskuroinnin avulla, datan kopiointi vie aikaa, ja siksi on täysin mahdollista, että näyttö päivittää kuvansa puskurin kopiointiprosessin puolivälissä! Tätä ongelmaa voidaan havainnollistaa täsmälleen samalla tavalla kuin yhden puskurin repimistä – kuvittele edellisessä demossa, että ensisijaiseen puskuriin kirjoitettavat pikselit eivät ole suoraan näytönohjaimen tuottamia, vaan ne sijoitetaan puskuriin peräkkäin toissijaisesta puskurista kopiointitoiminnon tuloksena.
Kaksoispuskurointi + VSync
Lisäksi lieventävä taktiikka on VSyncin käyttö. VSync on lyhenne sanoista ’vertikaalinen synkronointi’, ja se toimii antamalla takapuskurin kirjoittaa ensisijaiseen puskuriin vasta heti näytön päivityksen jälkeen. Toiveena on, että puskurin kopiointi olisi valmis ennen seuraavaa päivitystä. Tämä vähentää dramaattisesti ruudun repeilyä, mutta sillä on omat ongelmansa.
Jos sinulla on korkean kuvanopeuden sovellus, VSync toimii yleensä täydellisesti. Ruudunpäivitysnopeutesi rajoittuu näytön virkistystaajuuteen, mutta se ei haittaa, koska näyttösi näyttäisi joka tapauksessa sillä taajuudella. Ongelma tulee, kun saavutat näytön virkistystaajuutta alhaisemman ruudunpäivitysnopeuden.
Tapauksessa, jossa saavutat 60 FPS 75 Hz:n näytöllä – se tarkoittaa, että kehyspuskuri päivittyy 80 %:lla ruudunpäivitysnopeudesta. Jos VSync on käytössä, kehykset on kopioitava näyttöpuskuriin virkistystaajuuden alarajalla. Tässä tapauksessa sovellus myöhästyy ”määräajasta” joka toisella syklillä, joten ruutunopeutemme on lopulta puolet virkistystaajuudesta: 37,5 FPS. Tämä on huomattavasti vähemmän kuin 60 FPS, jonka näytönohjain voi saavuttaa.
TL;DR tuplapuskuroidulle VSyncille on, että jos saavutat jatkuvasti korkeamman FPS:n kuin virkistystaajuutesi, se voi olla hyvä idea ruudun repeämisen vähentämiseksi, mutta jos FPS putoaa näytön virkistystaajuuden alapuolelle, VSync voi vähentää FPS:ää merkittävästi.
Triple Buffering + VSync
Triple Buffering + VSync
Pyhä Graalin malja tässä koko sotkussa on yleensä triple buffering ja VSync. Kaksoispuskuroinnin kanssa käytettävän VSyncin rajana on, että framerate voi laskea merkittävästi johtuen ajasta, joka kuluu odottamiseen, kun sekundaaripuskuri kopioidaan oikeaan aikaan primaaripuskuriin. Odottelu ei useinkaan ole loistava ajatus tietotekniikassa, jossa se voidaan välttää, joten ratkaisu tässä tapauksessa on yksinkertaisesti lisätä toinen puskuri.
Kolmen puskurin kanssa kahteen takapuskuriin voidaan vetää vuorotellen, joten on aina niin, että yksi puskuri on valmis ja toinen on käynnissä. Tämä tarkoittaa sitä, että heti näytön päivityksen jälkeen se puskuri, joka on tällä hetkellä valmis, voidaan kopioida ensisijaiseen puskuriin – tämä tarjoaa VSyncin edut ilman aiemmin käsiteltyjä framerate-haittoja.
Kolminkertaisen puskuroinnin suurin haittapuoli siellä, missä se on käytettävissä sovelluksissa, on se, että se vie enemmän muistia – jos puhumme näytönohjaimista, tämä tarkoittaa enemmän VRAM-muistia (Video RAM). Tämä on nopeaa muistia, jota näytönohjain käyttää suoraan, joten joissakin tapauksissa kolminkertainen puskurointi voi aiheuttaa merkittävää FPS-pudotusta, kun korkeamman viiveen RAM-muistia käytetään korvaamaan natiivin VRAM-muistin puutetta. Tyypillisesti tämä ei ole suuri ongelma, koska kolmannen puskurin viemä muistin määrä on usein pieni verrattuna VRAM:n kokonaiskokoon, mutta VSync, jossa on vain kaksi puskuria, voi kuitenkin tarjota paremman ruudunpäivitysnopeuden joissakin hyvin kapeissa tapauksissa! Swings and roundabouts, eh?