FiringSquad over occlusion culling

Grafische toepassingen, en dan voornamelijk spellen, worden steeds complexer en vragen ook steeds meer rauwe prestaties en bandbreedte van videokaarten. Om te voorkomen dat deze daardoor enorm duur worden past men tegenwoordig steeds meer slimme methoden toe om de krachten van de chip te besparen. Occlusion culling is één van die methodes, in feite een ontzettend simpel idee: wat je niet ziet, dat bereken je ook niet. De implementatie daarvan is echter een heel stuk lastiger en er zijn dan ook verschillende methoden. Een hele simpele is de Early Z Check. Voor een pixel de pipeline ingaat wordt gecontroleerd of er al een pixel in de color buffer zit die bovenop deze nieuwe pixel komt te zitten. Als dat het geval is wordt de nieuwe niet meer berekend. Belangrijk hierbij is natuurlijk de volgorde waarin de pixels worden berekend.

HyperZ van ATi is een hiërarchische methode, gebaseerd op het werk van Ned Greene. Voor ieder blok van 64 pixels wordt de diepste Z-waarde onthouden. Zo kan veel sneller dan met een Early Z Check bepaald worden of een bepaald stuk van de scene zichtbaar is, waardoor veel minder bandbreedte gebruikt wordt. Nadeel is dat als er ook maar 1 pixel zichtbaar is het hele object getekend wordt, maar dat weegt niet op tegen het geheugen-voordeel. PowerVR heeft weer een compleet andere methode die werkt met raycasting, waar ook GigaPixel (overgenomen door 3dfx, nu in bezit van nVidia) en ATi aan werken. Een interessant stuk tekst voor mensen die wat meer willen weten over de werking van een videokaart:

Certainly there are advantages and disadvantages to all of these implementations. At the same time though, with careful implementation it can be made certain that the disadvantages never outweigh the advantages. At the same time though, it is possible for a sloppy implementation to present more bad than good. They all have the ability to remove hidden surfaces, and this is exactly the point.

At the same time, there is nothing to say that multiple implementations cannot be used simultaneously. For example, one might use early Z checking to remove surfaces prior to binning on a deferred rendering architecture. This is just one possible way. There are a variety of things that hardware developers will, and certainly do investigate.

Reacties (15)

[mvt]

Wat ik mooi hieraan vind is dat hier hetzelfde principe geld als bij de eerste computers. Waar het duur word wordt beter gebruik gemaakt van wat er is.
Toen geheugen nog duur was werd geprobeerd alles zo goed en klein mogelijk te houden. Nu is het niet het geheugen wat niet in overvloed is, maar de bandbreedte . En je ziet hier weer dat er buiten de bandbreedte bottleneck word gewerkt (binnen de mogelijkheden die er zijn) om deze bottleneck zoveel mogelijk te ontlasten door minder over de bus te gooien. Hopelijk gaat het met deze inovaties niet de kant op zoals met de software, dat zodra geheugen kosten (HD's en RAM van maar enkele Kb's vergroot naar GB's) achteruit gingen en er meer van gekocht kon worden voor dezelfde prijs dat compactprogrammeren een uitgestorven vaardigheid werd.

[EfBe]

Lees meer over (hierarchical) occlusion culling op: http://www.cs.unc.edu/~zhangh/hom.html

Overigens is het wenselijk zo veel mogelijk al weg te snijden uit de set polys die naar de card worden gestuurd. Occlusion Culling is meer ter voorkoming van overdraw bij het renderen van objects die niet in de scenegraph zitten. Dit komt voor bij alle huidige FPS engines: de geometrie is statisch en is opgeslagen in een scenegraph, de objects (zoals stoelen, wapens, players etc) zitten niet met hun polygonen in de scenegraph maar als entiteiten. Als je middels de scenegraph gaat cullen, haal je alleen de polygonen weg die in de statische geometrie weggelaten kunnen worden. (bv alle polygonen achter een muur waar je naar staat te kijken). Echter alle objects VOOR die muur die niet in de scenegraph zitten (dus wapens, players etc) halen wel delen van die muur weg, (en wellicht elkaar) maar je tekent die pixels veelal wel. (Overdraw). Door occlusion culling op de kaart toe te passen voorkom je die overdraw, omdat de kaart alle polygonen behandelt en niet zoals de scenegraph alleen de statische geometrie. Dit levert iets snelheidswinst op, want overdraw wordt vermeden (maar je moet nog wel wat nakijken dus dat kost weer iets). Heb echter niet de illusie dat alle polygonen naar de kaart slingeren het geheel sneller maakt: een goede scenegraph is nog altijd te prefereren.

[Robin]

Dit wordt toch al een tijdje toegepast door de Kyro videokaarten

http://www.tweakers.net/nieuws/11306

Zoals je waarschijnlijk weet maakt deze kaart gebruik van tile-based rendering, een bandbreedte besparende methode waarbij alleen het voor de gamer zichtbare 3D data verwerkt wordt. Dankzij dit truukje legt een 110/110MHz Kyro kaartje met 64MB geheugen en een fill rate van 220Mpixels prestaties neer die vergelijkbaar zijn met die een GeForce2 MX

http://www.tweakers.net/nieuws/12354

[Verwijderd]

Occlusion culling?? dat is toch echt niets van de laatste tijd... de N64 maakt daar gebruik van.

[Verwijderd]

ATI gebruik in de 8500 Radeon's een 2e generatie Hyper-Z.

Die is dus nog een stukje geavanceerder dan wat je op de 7xxx serie en de originele Radeon's terugvindt.

[Verwijderd]

Occlusion culling is één van die methodes, in feite een ontzettend simpel idee: wat je niet ziet, dat bereken je ook niet.

toen ik dit las, moest ik meteen aan STMicroelectronics (Kyro) denken. die gasten waren toch al met een manier (Tile Based Rendering) hiervoor bezig?

[Wouter Tinus]

Yup, de Kyro serie van STM maakt gebruik van de PowerVR architectuur die ook in het originele artikel besproken wordt.

[Verwijderd]

Wat op een ietwat oudere machine nog wel eens voorkomt, is dat de systeembelasting (door wat voor reden dan ook) zo groot wordt, dat je beeld gaat 'hakkelen' en je ineens een aantal frames vooruitschiet. Het lijkt mij dat je in zo'n situatie met de nieuwe GPU geen beeld meer hebt. Loop je met UT oid in een stad, is je omgeving weg...

Overigens vind ik dat je ten alle tijden zuinig moet wezen met wat je hebt en het beste eruit moet proberen te halen...

[BadRespawn]

"Het lijkt mij dat je in zo'n situatie met de nieuwe GPU geen beeld meer hebt"

lijkt me niet. de hier besproken methode heeft alleen tot doel om datgene wat je niet zou zien in het uiteindelijk gerenderde beeld, niet te berekenen (waarbij het problem is dat je toch eerst moet rekenen om te weten wat niet zichtbaar zal zijn...maar daar zijn slimme truken voor).

Die methode zorgt voor een hogere framerate maar is op zich niet afhankelijk vd framerate.

Dat is wat anders dan zaken die je wel zou zien, niet berekenen met als doel om de framerate hoog te houden (dat zou wel framerate afhankelijk zijn).

[NuKeFaCe]

Zolang ik maar QUAKE3 kan spelen

[-=bas=-]

Wacht maar tot Quake4 uit komt, kijken of je dan nog zo tevreden met Q3 bent

[bolluserectus]

Dit werd ook al toegepast.
Dit is weer een nieuwe methode.
Wel opletten hè

Het lijkt me alleen verloren werk om de structuur en aansturing van de kaart aan te passen op de huidige bottleneck. IMHO
Het lijkt mij logischer dat er iets aan die bottleneck gedaan wordt in plaats 'oplossingen' te verzinnen die beter met zo'n beperking omgaan.

Maarja, als de PC markt niet opschiet moeten de GPU-fabrikanten wel, lijkt mij...

AARGH..

[Beaves]

Het lijkt mij logischer dat er iets aan die bottleneck gedaan wordt in plaats 'oplossingen' te verzinnen die beter met zo'n beperking omgaan.

Er wordt op deze manier toch iets aan de bottleneck gedaan? Er zijn maar twee manieren waarop je kan zorgen dat de performance van nieuwe GPU's omhoog gaan, dat is gebruiken van sneller geheugen of deze manieren, dus het niet renderen van pixels die je toch niet ziet.

En zoals in het artikel staat, zou het geheugen wat snel genoeg is veel te duur worden, dus dan zou de prijs nog hoger worden en dan zou niemand meer een nieuwe kaart kopen.

Ik begrijp eerlijk gezegd het probleem niet hoor, als deze manieren werken en de grafische kwaliteit blijft hetzelfde, wat maakt het dan uit? Ik ben blij dat ze hier aan werken, want anders zou de prijs omhoog gaan en dan kan ik het niet meer betalen.