- Es wird ein Ansatz vorgestellt, der zur Effizienzsteigerung beim CPU-basierten 2D-Grafik-Rendering die Struktur Sparse Strips nutzt
- Im Mittelpunkt steht die Erforschung von Datenstrukturen und Verarbeitungsmethoden, um hochperformantes Rendering auf der CPU statt auf der GPU zu realisieren
- Durch sparse Datenrepräsentation werden der Speicherverbrauch reduziert und auch in komplexen Szenen hohe Rendering-Geschwindigkeiten erreicht
- Das Design verbessert gegenüber herkömmlichen CPU-Rendering-Verfahren die Effizienz der Parallelverarbeitung und die Cache-Ausnutzung
- Die Arbeit zeigt das Potenzial, hochwertige 2D-Grafik allein mit der CPU umzusetzen
Forschungsüberblick
- Diese Arbeit zielt auf hochperformantes 2D-Grafik-Rendering auf der CPU ab und untersucht Wege, die Abhängigkeit von der GPU zu verringern
- Das Kernkonzept ist eine Datenstruktur namens Sparse Strips, die statt durchgängiger Daten auf Pixelebene nur die benötigten Bereiche effizient speichert
- Mit dieser Struktur werden geringere Speicherzugriffskosten und höhere Rendering-Geschwindigkeit erreicht
Struktur der Sparse Strips
- Ein Strip steht für einen zusammenhängenden Pixelbereich in einem 2D-Bild; in sparse Form werden nur die benötigten Teile gespeichert
- Dieser Ansatz ist besonders effizient bei Bildern mit viel Leerraum oder komplexer Vektorgrafik
- Im Vergleich zu herkömmlichem Rendering mit vollständigem Buffer bietet er geringeren Speicherverbrauch und bessere Cache-Effizienz
Leistung und Implementierung
- Durch die Nutzung von SIMD-Befehlen und Multithreading der CPU wird die Parallelverarbeitungsleistung maximiert
- Versuchsergebnisse zeigen, dass sich dieselbe Szene auch ohne GPU mit Leistung auf Echtzeit-Rendering-Niveau verarbeiten lässt
- Die Implementierung wurde in C++ geschrieben und bei verschiedenen Auflösungen sowie unterschiedlichen Szenenkomplexitäten getestet
Einsatzmöglichkeiten
- Einsetzbar in UI-Rendering, Vektorgrafik-Engines und 2D-Pipelines von Game Engines in CPU-zentrierten Umgebungen
- Auch in eingebetteten Systemen oder Serverumgebungen mit eingeschränkter GPU kann hochperformante 2D-Grafikverarbeitung unterstützt werden
Fazit
- Der Sparse-Strip-basierte Ansatz belegt eine Entschärfung von Bottlenecks beim CPU-Rendering und eine Verbesserung der Speichereffizienz
- Er zeigt Potenzial als alternatives Modell zu GPU-abhängigen Grafikverarbeitungsstrukturen
- Zusätzliche Kennzahlen oder Vergleichsdaten sind im PDF-Volltext nachzulesen
1 Kommentare
Hacker-News-Kommentare
Die im Paper definierte Struktur
struct Stripsieht so aus, als wäre sie 64 Bit (8 Byte) groß, im Text steht jedoch, dass ein Strip 64 Byte groß seiNachgerechnet wirkt es eher wie 259×8 + 7296 ≈ 9 KB. Irgendetwas mit den Einheiten scheint falsch zu sein
Es könnte nur ein einfacher Tippfehler sein, aber es ist auch möglich, dass jeder Strip in Cache-Line-Größe (64 Byte) allokiert wurde.
So ließe sich False Sharing vermeiden, daher könnte der Renderer absichtlich so aufgebaut worden sein
Das Paper konzentrierte sich hauptsächlich auf Laufzeitvergleiche und behandelte keine Vergleiche des Speicherbedarfs
Blaze: Parallel Rasterization on CPU ist in dem Zusammenhang ebenfalls sehenswert
Das Projekt ist interessant. In Abschnitt 3.9 sieht es so aus, als wäre die Ausgabe ein Bitmap, das letztlich auf die GPU kopiert werden muss
Skia wechselt zu WebGPU, und da WebGPU Compute Shader unterstützt, wirkt 2D-Grafik hinsichtlich Portabilität und Performance zunehmend wie ein gelöstes Problem
Dennoch gibt es weiterhin Fälle, in denen ein CPU-Renderer nützlich ist — zum Beispiel im Web, wo Shader beim Laden der Seite zur Laufzeit kompiliert werden müssen
Theoretisch wäre also auch eine Struktur denkbar, die wie ein JS-JIT zunächst mit einem CPU-Renderer startet und dann umschaltet, sobald die GPU-Shader bereit sind
Ein weiterer Vorteil ist die geringe Binärgröße. WebGPU (auf Basis von dawn) ist ziemlich groß
Referenzlink
In größeren Projekten gibt es auch eine Version namens Vello Hybrid, bei der die Geometrieberechnungen auf der CPU und das Pixel-Painting auf der GPU erfolgen
Die Idee, den CPU-Renderer während der Shader-Kompilierung zu verwenden, haben wir ebenfalls erwogen, aber noch nicht umgesetzt
Eher im Gegenteil: Wenn auf der GPU gerendert wird, muss das Bild anschließend wieder zurückkopiert werden, was ineffizient ist
Ich habe kürzlich Code geschrieben, der hochpräzise N-Body-Bahnen mit Millionen von Vertices rendert,
und ich frage mich, ob sich die in diesem Paper vorgeschlagene RLE-Darstellung auf der GPU implementieren ließe und dabei trotz ihrer Einfachheit gut funktionieren würde
Demo-Video
Interessant. Ich würde gern die Single-Core-Performance der verglichenen Renderer sehen.
Das würde wahrscheinlich etwas über die Effizienz des Codes aussagen. Beliebte Renderer könnten langsamer sein, dafür aber weniger CPU verbrauchen
Ergebnisse findet man außerdem im offiziellen Benchmark von Blend2D oder in meinem vello_chart, das zusätzliche Renderer einbezieht
Ist Raph Levien, einer der Betreuer, zufällig der Autor der früheren Bibliothek Libart?
Etwas off-topic, aber ich frage mich, seit wann die PDF-Vorschau auf GitHub nur noch einige Seiten lädt
Ich fände es besser wie früher, das gesamte PDF auf einmal zu laden und es dann vom Browser rendern zu lassen
Ich frage mich, ob es Benchmarks gibt, mit denen sich die Korrektheit (correctness) eines Renderers verifizieren lässt
Dabei misst man die Radiosity einer realen Szene und vergleicht sie mit dem Simulationsergebnis
Im Echtzeit-Rendering wird auch mit Offline-Renderern wie Arnold oder Octane als Referenz verglichen
Cornell-Box-Wiki
Es gibt keinen Renderer, der die Realität perfekt reproduziert, alle gehen in gewissem Maß Trade-offs ein