Technische Samenvatting: Het renderen van 3D Gaussians op een Graph Processor

Probleemstelling

3D Gaussian Splatting (3DGS) heeft zich gevestigd als een leidende methode voor real-time novel view synthesis, waarbij fotorealistische rendering en volledige differentieerbaarheid worden geboden. De huidige implementaties zijn echter zwaar geoptimaliseerd voor GPU-architecturen, die vertrouwen op grote off-chip DRAM, hoge geheugenbandbreedte en een globale adresruimte. Op GPU's is 3DGS-rendering geheugengebonden; de dominante kosten zijn de herhaalde verplaatsing van Gaussian-data door de geheugenhiërarchie (het laden van DRAM naar shared memory) in plaats van rekenkundige berekeningen.

Deze afhankelijkheid van globale geheugentoegang is inefficiënt voor opkomende, beperkte platformen, zoals AR-brillen en mobiele robots, waar "on-sensor" computing met alleen lokaal geheugen wenselijk is. Dit artikel behandelt de uitdaging om 3DGS aan te passen aan een DRAM-vrije architectuur die geen globale adresruimte en geen random-access geheugen heeft, waardoor datamigratie expliciet en lokaal moet zijn.

Methodologie

De auteurs hebben de eerste 3DGS-renderer geïmplementeerd op de Intelligence Processing Unit (IPU) van Graphcore, een massaal parallelle processor bestaande uit 1.472 onafhankelijke tiles. Elke tile beschikt over 624 KB lokale SRAM, 6 hardware-threads en geen extern DRAM. De architectuur volgt een Bulk Synchronous Parallel (BSP) model met expliciete, tijdens de compilatie gedefinieerde communicatiekanalen.

Pipeline Overzicht

De renderingpipeline brengt de vier stadia van 3DGS in kaart op het BSP-executiemodel van de IPU, waarbij wordt afgewisseld tussen lokale berekening en inter-tile communicatie:

1. Projectie (Lokale Berekening): Elke tile projecteert zijn lokaal opgeslagen 3D Gaussians naar het 2D-schermvlak, waarbij middens (means), conics en bounding boxes worden berekend.
2. Routing (Berekening + Uitwisseling): Gaussians waarvan de geprojecteerde middens buiten het lokale schermgebied van een tile vallen, worden geëvicteerd. Ze worden gerouteerd naar hun "anchor tile" (de tile die het schermgebied bezit dat de Gaussian bevat) via Manhattan-afstandshops op een North-East-West-South (NEWS) grid. Dit proces herhaalt zich over meerdere BSP supersteps totdat alle Gaussians hun anchor tiles hebben bereikt.
3. Bloom (Berekening + Uitwisseling): Zodra een Gaussian een anchor tile bereikt, wordt deze gepropageerd naar naburige tiles waarvan de schermgebieden er overlap mee hebben. Om cyclische kopieën en kanaalsaturatie te voorkomen, gebruiken de auteurs een tree-pattern propagatie: de anchor tile stuurt kopieën horizontaal, en die tiles sturen kopieën verticaal door.
4. Compositing (Lokale Berekening): Elke tile sorteert onafhankelijk zijn lokale Gaussians op diepte en voert front-to-back alpha compositing uit op zijn framebuffer-slice.

Belangrijke Architecturale Beperkingen

• Geen Globaal Geheugen: Scènedata verlaat de on-chip SRAM nooit. De volledige 3D Gaussian map is verdeeld over de tiles; geen enkele tile bevat de hele scène.
• Expliciete Datamigratie: In tegenstelling tot GPU's waar threads willekeurige globale adressen kunnen laden, kunnen IPU-tiles alleen data verzenden/ontvangen die tijdens de compilatie is gedefinieerd. Het algoritme moet de migratie van primitieven expliciet beheren.
• Geheugenbudget: Met ongeveer 1.472 tiles is de geaggregeerde geheugencapaciteit voldoende voor matige scènes, maar individuele tiles hebben strikte limieten (ongeveer 192 KB beschikbaar voor Gaussian-data na aftrek van buffers).

Belangrijkste Bijdragen

1. Eerste SRAM-only 3DGS Implementatie: Het artikel presenteert de eerste rendering van 3D Gaussians op een MIMD (Multiple Instruction, Multiple Data) processorarchitectuur die uitsluitend vertrouwt op on-chip SRAM, waardoor externe DRAM-toegang voor scendedata wordt geëlimineerd.
2. Compile-Time Routing Schema: Een nieuw mechanisme voor het verdelen van Gaussian-primitieven over tiles op basis van schermruimte-eigendom, werkend binnen de beperkingen van vaste, tijdens de compilatie gedefinieerde communicatiekanalen.
3. Prestatie- en Bottleneck-analyse: Een gedetailleerde evaluatie van het systeemprestaties, waarbij specifieke bottlenecks worden geïdentificeerd die inherent zijn aan DRAM-vrije rendering:
   • Inter-tile Bandbreedtesaturatie: In dichte regio's kunnen uitgaande kanalen vol raken voordat alle Gaussian-kopieën zijn gepropageerd, wat leidt tot "tiling artifacts" (rechthoekige gaten) in de gerenderde afbeelding.
   • Per-Tile SRAM Druk: Een hoge Gaussian-dichtheid in specifieke schermregio's kan de buffercapaciteit van een enkele tile overschrijden, wat leidt tot gegevensverlies.
   • Workload Imbalans: Niet-uniforme Gaussian-dichtheid zorgt ervoor dat sommige tiles aanzienlijk langzamer zijn dan andere, waardoor de gehele BSP-barrière wordt vertraagd.
4. Inzichten voor Toekomstige Architecturen: Het werk suggereert dat expliciete inter-SM (Streaming Multiprocessor) communicatie op GPU's het DRAM-verkeer zou kunnen verminderen, en dat 3D-representaties beter ontworpen kunnen worden om ruimtelijke en temporele lokaliteit te benutten.

Resultaten

• Visuele Kwaliteit: Voor scènes met een matige dichtheid (bijv. 25k–90k Gaussians) is de IPU-rendering visueel bijna identiek aan de GPU-baseline, waarbij fijne details zoals tekst en dunne structuren behouden blijven.
• Doorvoersnelheid (Throughput): Het systeem bereikt interactieve framerates (ongeveer 20 FPS) op een enkele IPU voor kleine tot middelgrote scènes. Echter, de prestaties verslechteren bij zeer dichte scènes (bijv. 273k Gaussians) door de eerder genoemde bottlenecks.
• Energie-efficiëntie: Hoewel de ruwe doorvoersnelheid (FPS) van de IPU lager is dan die van high-end GPU's (GTX 1080, RTX 4090), is het energieverbruik aanzienlijk lager (~27W vs ~75–90W). De architectuur demonstreert dat 3DGS volledig on-chip kan draaien, waarbij host-communicatie slechts 1,6% van de executietijd beslaat.
• Data-lokaliteit: Het systeem benut temporele lokaliteit effectief. Voor incrementele camerabewegingen (typisch voor SLAM/AR) is de "churn rate" (het deel van de Gaussians dat re-routing vereist) zeer laag (<12%), terwijl willekeurige teleports bijna 100% re-routing vereisen.

Betekenis en Claims

Het artikel beweert niet dat de IPU een superieure algemene rendering engine is vergeleken met GPU's. In plaats daarvan gebruikt het de IPU als een experimenteel platform om aan te tonen dat 3DGS fundamenteel geen DRAM vereist.

De auteurs stellen dat door de globale adresruimte weg te laten, de noodzaak van expliciete datamigratie duidelijk wordt. Dit onthult dat:

1. Lokaliteit is Cruciaal: Rendering is het meest efficiënt wanneer datamigratie wordt geminimaliseerd. Het ontwerp van de IPU dwingt het algoritme om gebruik te maken van het feit dat in scenario's met incrementele weergave (robotica, AR), de meeste primitieven nabij hun vorige schermpositie blijven.
2. Algoritmische Implicaties: De geobserveerde bottlenecks (bandbreedte, capaciteit, imbalans) belichten trade-offs die toekomstige GPU-kernelontwerpen kunnen informeren. Specifiek suggereren de auteurs dat directe inter-SM communicatie op GPU's, in plaats van het routeren van alle cross-block data via DRAM, de dominante geheugenkosten van 3DGS zou kunnen verlagen.
3. Toekomstige Richtingen: Het werk motiveert de ontwikkeling van "on-sensor" en edge-architecturen voor differentiële rendering, en suggereert dat toekomstige 3D-representaties en hardware gezamenlijk ontworpen moeten worden om ruimtelijke en temporele coherentie te benutten, wat potentieel het energieverbruik en de latentie vermindert door het vermijden van globale geheugentoegang.