Tile Based Rendering
Als je het tile based rendering systeem van de PowerVR technologie in één zin zou moeten samenvatten, dan zou dat het best op de volgende manier gaan: ‘Datgene wat niet zichbaar is, wordt ook niet getekend.’ Dat dit niet zo voor de hand liggend is als het lijkt, blijkt verderop.
Om het systeem goed te begrijpen, kijken we eerst eens naar onderstaande afbeelding. We zien een willekeurige 3D-omgeving met daarin 3D-objecten: een rode kubus, een groene bol en een gele kegel. Als we van deze 3D-omgeving echter een 2D-afbeelding maken, bijvoorbeeld voor vertoning op een monitor, zal blijken dat de verschillende objecten elkaar overlappen. In het voorbeeld neemt de kegel voor een gedeelte het zicht weg van de bol en de kubus en de bol neemt nog voor een groter gedeelte het zicht van kubus weg.
Het grote verschil tussen de conventionele 3D technieken (die gebruikt worden op de chips van nVidia, ATI, 3dfx, enzovoorts) en de PowerVR 3D techniek volgt nu uit de manier waarop een afbeelding als deze op het scherm getoverd wordt.
Laten we eerst eens kijken naar de werkwijze van conventionele 3D-chips. Hierbij worden de 3D-objecten één-voor-één verwerkt. Lees voor wat basiskennis over de werking van 3D eerst even ons artikel ‘Hoe werkt een 3D grafische kaart? – Deel 1’. Zoals daarin beschreven worden de driehoeken waaruit de 3D-objecten bestaan eerst omgezet naar losse pixels (triangle setup / rasterization) en daarna worden deze pixels stuk voor stuk ingekleurd ofwel ‘ge-shade’. Voordat de uiteindelijke pixel wordt weggeschreven naar de frame buffer, het stuk geheugen waarin het eerstvolgende 3D-beeld wordt opgebouwd, wordt er eerst door middel van de Z-buffer bekeken of er niet toevallig al een pixel op de betreffende plaats is, die vóór de zojuist berekende pixel staat. Indien dat het geval is, wordt de berekende pixel gewoonweg ‘weggegooid’. De Z-buffer houdt dus voor alle pixels in de frame buffer de diepte bij. Zodra een nieuwe pixel op een bestaande plaats voor de bestaande pixel staat, wordt de bestaande pixel vervangen, anders wordt de nieuwe pixel weggegooid. Ook als een bestaande pixel vervangen wordt, is er natuurlijk voor niets een pixel berekend. De oude pixel, die uiteindelijk nooit op het scherm zal komen, had namelijk net zo goed niet berekend kunnen worden.
Dit weggooien van pixels is natuurlijk doodzonde: niet alleen heeft het berekenen van de pixel al aardig wat rekenkracht gevergd, maar ook geheugenbandbreedte! Alle texture-informatie voor de betreffende pixel (maar ook Z-buffer informatie) is namelijk braaf voor de pixel uit het geheugen gehaald, terwijl de pixel uiteindelijk wordt weggegooid. Dit niet gebruiken van berekende pixels noemt men ‘overdrawing’: absoluut een serieus probleem. Huidige games hebben al snel een overdraw-factor 3, wat betekent dat op iedere pixel-lokatie op het scherm gedurende de opbouw van een scherm gemiddeld drie pixels voor niets berekend worden. Je kunt je wel voorstellen dat dit echt zonde is van de rekenkracht en geheugbandbreedte.
Onderstaande afbeelding laat dit conventionele 3D-systeem duidelijk zien: eerst worden alle pixels van alle componenten verwerkt en ingekleurd. Hiervoor wordt ook alle texture-informatie vanuit het geheugen binnegeladen. Pas daarna wordt door middel van de Z-buffer bekeken of de pixel überhaupt op het scherm mag verschijnen. Bij een positieve uitslag wordt de pixel weggeschreven naar de frame buffer.
Laten we het voorbeeld van de kubus, bol en kegel er nog maar eens bijpakken. Het maakt in principe niet uit in welke volgorde de objecten verwerkt worden: in elk geval wordt een aantal pixel voor niets berekend. Stel dat eerst de kubus, daarna de bol en daarna de kegel verwerkt worden. Na het verwerken van de kubus, staat de 2D-afbeelding van de kubus klaar in de frame buffer. Nu de bol echter verwerkt wordt, zal blijken dat een gedeelte van de bol vóór de kubus staat. De rode pixels behorende bij de kubus op deze plaatsen worden dus overschreven door groene pixels van de bol. Jammer maar helaas: de tijd en geheugenbandbreedte die het heeft gekost om deze rode pixels te berekenen is verknoeid! Tot overmaat van ramp wordt een gedeelte van de groene pixels later ook nog eens overschreven door de gele pixels van de kegel.
Ook andersom, dus als eerst de kegel, dan de bol en dan de kubus verwerkt zouden worden, ontstaat het zelfde probleem. Eerst wordt de kegel helemaal opgebouwd en in de frame buffer gezet. Hoewel een groot gedeelte van de pixels van de bol totaal niet zichtbaal zullen zijn, wordt toch de gehele bol verwerkt door de 3D chip. Alle texture-informatie en dergelijke wordt zelfs voor de niet zichtbare plaatsen gewoon verwerkt. Pas op het laatste moment worden deze pixels weggegooid.
Op dit probleem heeft Imagination Technologies dus een oplossing gevonden onder de naam tile based rendering.
