Display listák

A primitívek kötegeitglBegin/glEndfüggvény párosok segítségével állítjuk össze, melyek egyediglVertexhívásokat tartalmaznak. Ez nagyon rugalmas módja a primitívek összeraká-sának. Sajnos, amikor a teljesítményt is figyelembe kell venni, akkor ez a lehető legrosszabb módja a geometria továbbítására a GPU felé. Vegyük a következő pszeudokódot, ami egy megvilágított, textúrázott háromszög:

g l B e g i n ( GL_TRIANGLES ) ; g l N o r m a l 3 f ( x , y , z ) ; g l T e x C o o r d 2 f ( s , t ) ; g l V e r t e x 3 f ( x , y , z ) ; g l N o r m a l 3 f ( x , y , z ) ; g l T e x C o o r d 2 f ( s , t ) ; g l V e r t e x 3 f ( x , y , z ) ; g l N o r m a l 3 f ( x , y , z ) ; g l T e x C o o r d 2 f ( s , t ) ; g l V e r t e x 3 f ( x , y , z ) ; g l E n d ( ) ;

11 függvényhívást kell elvégeznünk egy háromszög létrehozásához. Mindegyik függ-vény potenciálisan drága ellenőrző kódot tartalmaz az OpenGL meghajtóban, ráadásul 24 különböző négy byte-os paramétert kell a veremre helyezni és természetesen visszaadni a hívó függvénynek. Ez kis munka a CPU-nak. Egy 3D-s színtér létrehozásához 10 000-szer vagy többször ennyi háromszögre van szükség. Könnyű elképzelni, hogy a grafikus hardver

8.1. DISPLAY LISTÁK 121

a CPU-ra várakozik, amíg összerakja és továbbítja a geometriai kötegeket. Természetesen van olyan lehetőség, amikor vektor-paraméterű függvényeket használunk, mint például a glVertex3fv, amelyek segítségével konszolidálni lehet a köteget, valamint sávokat és legyezőket is használhatunk a redundáns transzformációk és másolások csökkentésére. Az alapmegközelítés azonban abból a teljesítmény igényből ered, hogy szükség van több ezer nagyon kicsi, potenciálisan költséges művelet geometriai kötegekben való elküldésére Ezt a módszert gyakranközvetlen módú renderelésneknevezik.

8.1.1. Kötegelt feldolgozás

Az OpenGL, ahogy ezt már korábban említettük, szoftveres felületet biztosít a számítógép grafikus hardveréhez. Azt gondolhatjuk, hogy a meghajtó program az OpenGL a parancsokat

”valamilyen” módon speciális hardver utasításokra vagy műveletekre alakítja át és aztán a grafikus kártyára küldi, hogy azokat azonnal végrehajtsa. Ami nagyjából igaz attól eltekintve, hogy ezek a parancsok nem hajtódnak végre egyből. Ehelyett egy lokális pufferben gyűlnek össze, amíg egy határt el nem érnek. Ekkor ezek a parancsok a hardverhez kerülnek/ürítőd-nek¹. A fő oka az ilyen típusú elrendezésnek az, hogy a grafikus hardverhez vezető út sok időt vesz igénybe, legalábbis a számítógép idejében kifejezve azt. A puffer küldése a grafikus hardverhez egy aszinkron művelet, ami azt jelenti, hogy a CPU egy másik feladatot kezdhet el és nem kell várnia az elküldött kötegelt renderelési utasítások befejeződéséig. A hardver egy adott parancshalmaz renderelése alatt, amíg CPU azzal van elfoglalva, hogy egy új grafikus képhez tartozó (tipikusan egy animáció következő képkockája) parancsokat dolgoz fel. Ez a fajtapárhuzamosításnagyon hatékonyan működik a CPU és a grafikus hardver között.

Három esemény idéz elő ürítést az aktuális renderelő parancsok kötegénél. Az első akkor következik be, amikor a meghajtó program parancs puffere tele van. Ehhez a pufferhez nem férünk hozzá és nem módosíthatjuk annak méretét sem. Akkor is történik ürítés, amikor egy puffer cserét hajtunk végre. Ez a művelet addig nem hajtódik addig, amíg a sorban álló parancsok mindegyike végre nem hajtódik. A puffercsere egy nyilvánvaló jelzés a meghajtó programnak, hogy az adott színtér létrehozása befejeződött és az elküldött parancsok eredményének meg kell jelennie a képernyőn. Amennyiben egyszeres színpuffert használunk, akkor az OpenGL nem szerez tudomást arról, hogy mikor fejeztük be a parancsok küldését és így arról sem tud, hogy mikor kell a kötegelt parancsokat a hardverre küldeni, hogy végrehajtsa azokat. Ahhoz, hogy ezt az eljárást elősegítsük, a glFlush() parancsot kell meghívnunk, hogy manuálisan idézzük elő az ürítést.

Néhány OpenGL parancs azonban nem pufferelt későbbi végrehajtás céljából (például glReadPixelsés glDrawPixels). Ezek a függvények közvetlenül érik el a frame puffert és olvassák és írják azt direkt módon. Ezek az utasítások sebesség csökkenést idéznek elő a csővezetéken való áthaladásban, mivel az aktuális sorban álló parancsokat először ki kell üríteni és végre kell hajtani azokat, mielőtt a színpuffert közvetlenül módosítanánk.

Erőszakosan kiüríthetjük a parancs puffert és várhatunk arra, hogy a grafikus hardver befejezze az összes renderelési feladatát a glFinish() függvény meghívásával. Ezt a függvényt csak nagyon ritkán használjuk a gyakorlatban.

1Az eredeti terminológiában angolul eztflush-nak nevezik.

8.1.2. Előfeldolgozott kötegek

Az OpenGL parancsok hívásához kapcsolódó tevékenységek igen költségesek. A magas szintű OpenGL parancsok lefordulnak és átalakítódnak alacsony szintű hardver utasításokká.

Egy összetett geometria, vagy csak egy nagy mennyiségű vertex adat esetén ez az eljárás több ezerszer végrehajtódik csak azért, hogy egy kép megjelenjen a képernyőn. Természetesen ez az imént említett probléma azonnali renderelési mód esetén.

A geometria vagy másik OpenGL adat gyakran ugyanaz marad képkockáról képkockára.

Az egyetlen dolog, ami változik, az a modellnézeti mátrix. A megoldás erre a feleslegesen ismételt többletmunkára az, hogy elmentjük a parancs pufferben található, előre kiszámított adatdarabot, amely valamilyen ismételt renderelési műveletet hajt végre, mint például egy tórusz megrajzolása. Ezt az adatdarabot később bemásolhatjuk egyszerre a parancspufferbe, megtakarítva ezzel a sok függvényhívást és a fordítási munkát, amely az adatot létrehozza.

Az OpenGL megoldást nyújt az előfeldolgozott parancsok létrehozására. Ezt az előfel-dolgozott parancslistát display listának hívjuk. Ugyanúgy, ahogy az OpenGL primitíveket glBegin/glEndutasításokkal határoljuk el, a display listákatglNewList/glEndList függ-vény hívásokkal különítjük el egymástól. Egy display listát egy egész értékkel azonosítunk, amit nekünk kell megadni. A következő kód részlet egy tipikus példája a display lista létrehozásának:

g l N e w L i s t ( <u n s i g n e d i n t e g e r name > ,GL_COMPILE ) ; / / . . .

/ / OpenGL f ü g g v é n y h í v á s o k / / . . .

g l E n d L i s t ( ) ;

A GL_COMPILE paraméter azt jelzi az OpenGL-nek, hogy csak fordítsa le a listát és még ne hajtsa azt végre (nem fog megjelenni az adott alakzat). Használhatjuk a GL_COMPILE_AND_EXECUTE értéket is, ami párhuzamosan felépíti a display listát és végre is hajtja a renderelési utasításokat. Rendszerint a display listákat csak felépítjük a program inicializálási részében és csak a rendereléskor hajtjuk végre azokat.

A display lista azonosító tetszőleges előjel nélküli egész lehet. Azonban, ha ugyanazt az értéket kétszer használjuk, akkor a második display lista felülírja az előzőt. Éppen ezért érdemes egy olyan mechanizmust használni, amely megóv bennünket a már létrehozott display lista felülírásától. Különösen hasznos ez akkor, amikor többen fejlesztenek egy függvénykönyvtárat. A GLuint glGenLists(GLsizei range)függvény meghívásával, visszatérési értékként egy egyedi display lista azonosító sorozat első elemét kapjuk vissza. A display lista felszabadítást aglDeleteLists(GLuint list, GLsizei range)függvény meghívásával végezhetjük el, amely nem csak a display lista neveket, hanem a listák számára lefoglalt memória területeket is felszabadítja.

Az előre lefordított OpenGL parancsokat tartalmazó listákat a glCallList(GLuint list) függvényhívással tudjuk végrehajtani. A display listákat tartalmazó tömböket a glCallLists(GLsizei n, GLenum type, const GLvoid *lists)utasítás segítségével tudjuk lefuttatni, ahol az első paraméter a display listák számát adja meg a lists nevű tömbben. A függvény második paramétere pedig a tömb adat típusát határozza meg, amely rendszerintGL_UNSIGNED_BYTE.