Keskustelu: Ohjelmointikysymykset: C: Animaation nykiminen

OpenGL:llä tehty animaatio XP:ssä nykii aika ajoin aivan perkeleesti. Nykiminen vähenee satakertaisesti, kun grafiikan aktivoinnin jälkeen kutsuu Billin funktioita;

SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

(Tässä ilmeisesti SetThreadPriority -kutsu on tarpeeton, mutta ei se varmaan pahastakaan ole.)

Pullonkaulana on siis pöljä XP, joka päivittelee ja ihmettelee kaikessa rauhassa omia säikeitään, kun ikkunalle pitäisi piirtää animaatiota kaikella teholla.

Onko jotain muita lisäkeinoja vaimentaa käyttöjärjestelmän häirintää silloin, kun ikkunassa ajetaan animaatiota maksimi päivityksellä?

Realtime-prioriteetin käyttö ei kylläkään ole kovin fiksua, mutta kukin tavallaan.

Jaa, viisaampaa on varmaan sitten olla ottamatta koneesta kaikkea tehoa irti? Sinulle on varmaan myös opetettu, ettei gotoa saa käyttää, koska plaap, plaap, plaap. Itse olen törmännyt muutaman vuosikymmenen aikana kouralliseen tapauksia, joissa gotolla saa puristettua viimeisetkin käytettävissä olevat kellojaksot. Edelleen näemmä pienellä manööverillä GL:n listoihin sai tasan puolet enemmän tehoa, jolloin animaation päivitystaajuus nousi 30:stä optimaaliseen 60 kuvaan sekunnissa (60 Hz tft, 1920x1200). Ehkei sekään ole suoraan oppikirjoista, mutta kukin ottaa koneestaan tehot irti tavallaan.

PS. Kysymys oli sulavasta animaatiosta, eikä siitä, mikä sinun mielestäsi on fiksua.

JoinTuanJanohon kirjoitti:

Edelleen näemmä pienellä manööverillä GL:n listoihin sai tasan puolet enemmän tehoa, jolloin animaation päivitystaajuus nousi 30:stä optimaaliseen 60 kuvaan sekunnissa (60 Hz tft, 1920x1200).

Seuraava on toki pelkkää spekulaatiota:

Mielestäni vaikuttaisi "hieman" erikoiselta, että noin suuri nopeusero johtuisi pelkästään Windowsin resurssien jakamisesta ohjelmalle. Sattumoisin tuohon sopisikin eräs toinen mahdollinen syy mielestäni aika hyvin: Jos ohjelmassa on käytössä v-sync ja kaksoipuskurointi, odotetaan aina puskurien vaihdon yhteydessä hetkeä, jolloin näyttö on piirtänyt edellisen kuvan ruudulle kokonaan, ja valmistautuu piirtämään seuraavaa. Tässä välissä on sitten sopivaa päivittää näytettävän puskurin sisältö (= vaihtaa puskurit).

Nyt kun virkistystaajuutesi on 60 Hz, tulee tämä hetki vastaan 1/60 sekunnin välein. Jos nyt ohjelmasi teoreettinen fps sattuu olemaan hieman alle 60 ruutua sekunnissa, kestää uuden kuvan saamiseksi valmiiksi hieman yli tuon 1/60 sekunnin verran. Tällöin näyttö on kuitenkin jo ehtinyt seuraavalle päivityskierrokselle, joten puskureiden vaihtaminen jää odottamaan sen (toisen virkistyksen) loppumista. Näin kuva päivitetään uuteen vain joka toisella kerralla, ja todelliseksi fps:ksi saadaan tuo 30.

Nyt jos realtime prioriteetti auttaa puristamaan sen verran tuota nopeammaksi, että uusi kuva saadaan laskettua sen 1/60 sekunnin rajoissa, onnistuu päivittäminen joka kerta, ja fps nousee 60:een.

Muita ratkaisuja tuohon voisi siis olla:
* ottaa v-sync pois käytöstä (saattaapi huonontaa kuvanlaatua = luoda pientä välkyntää)
* käyttää triplapuskurointia (tietääkseni myös tämä ratkaisisi ongelman)
* pienentää näytön tarkkuutta (jolloin piirtämistä olisi vähemmän)
* jne

tn kirjoitti:

Muita ratkaisuja tuohon voisi siis olla:
* ottaa v-sync pois käytöstä (saattaapi huonontaa kuvanlaatua = luoda pientä välkyntää)
* käyttää triplapuskurointia (tietääkseni myös tämä ratkaisisi ongelman)
* pienentää näytön tarkkuutta (jolloin piirtämistä olisi vähemmän)
* jne

Jaa, kysymyksessä on työkone Centrino Duo, joka on tarkoitettu 3D-grafiikalle. Ihmetystä on herättänyt, että miksei XP häärää niitä omia säikeitään sillä toisella prosessorilla, ja antaisi toisen prosessorin kokonaan sovellukselle?

Kuitenkin, kun exe pyörii, koneessa on aina 50 prosenttia käyttämätöntä kapasiteettia. Saisiko tuota lisätehoa edelleen sillä, että ohjelmaa ajaisi kahtena exenä, jotka olisivat tahdistettu niin, että kumpikin prosessori olisi käytössä?

Varsinaisena tavoitteena on suhteellisen raskas simulaatio, jonka pitäisi sitten sulavan animaation lisäksi ehtiä laskemaan paljon asioita. OpenGL:stä saa luultavasti enemmän irti, jos listojen sijasta käyttäisi sitä VBO-tekniikkaa. Onko kenelläkään kokemuksia, kuinka paljon tekniikan hyödyntäminen tehostaisi grafiikkaa (polygoneja on paljon).

Oliko muuten tuolle triplapuskuroinnille jokin valmis alustusfunktio?

JoinTuanJanohon kirjoitti:

Varsinaisena tavoitteena on suhteellisen raskas simulaatio, jonka pitäisi sitten sulavan animaation lisäksi ehtiä laskemaan paljon asioita. OpenGL:stä saa luultavasti enemmän irti, jos listojen sijasta käyttäisi sitä VBO-tekniikkaa. Onko kenelläkään kokemuksia, kuinka paljon tekniikan hyödyntäminen tehostaisi grafiikkaa (polygoneja on paljon).
Oliko muuten tuolle triplapuskuroinnille jokin valmis alustusfunktio?

Tehoa tulee paljon VBO:iden kanssa.
Väylän läpi ajettuna jo noin 300000 polyn käyttö hyydyttää helposti nopeammankin kortin.
Nehessä on hyvä esimerkki VBO:ista. Suositellaan kaikille asiasta kiinnostuneille.

OpenGL:ssä ei tietääkseni ole triplapuskurointia.

pieslice kirjoitti:

OpenGL:ssä ei tietääkseni ole triplapuskurointia.

Käsittääkseni ainakin Windowsissa kokoruututilassa kaksoispuskurointi toimii oikeasti kolmoispuskurointina.

Suosittelen tosiaan v-syncin poistamista hetkeksi, jotta selviää, minkä verran eroa oikeasti on.