Warum wurden hardwarebeschleunigte Vektorgrafiken nicht entfernt?

Ich arbeite an einer App, bei der Vektorpfade mit 60 fps in Echtzeit bearbeitet werden, und ich bin sehr überrascht, wie wenig Informationen zu diesem Thema vorhanden sind. Zuerst habe ich versucht, meine Idee mit CoreGraphics umzusetzen, aber für meine Zwecke war sie nicht ausreichend . Dann entdeckte ich, dass es einen Khronos-Standard für hardwarebeschleunigte Vektorgrafiken namens OpenVG gab , und zum Glück hatte eine freundliche Seele eine OpenGL ES- Halbimplementierung namens MonkVG geschrieben .

Aber trotz der Tatsache, dass OpenVG eine sehr praktisch nützliche API ist, scheint es von Khronos mehr oder weniger aufgegeben zu werden. Laut Wikipedia hat die Arbeitsgruppe seit 2011 beschlossen, "keine regelmäßigen Treffen zur weiteren Standardisierung abzuhalten". Die Dokumentation besteht, so gut ich kann, nur aus einer einzigen Referenzkarte. Darüber hinaus gibt es im Internet kaum Beispiele für OpenVG. Ich kann im Handumdrehen Hunderte von OpenGL-Tutorials finden, aber OpenVG scheint auffällig zu fehlen.

Man könnte meinen, dass hardwarebeschleunigte Vektoren in der heutigen Welt der schnell wachsenden Auflösungen wichtiger sind, und es scheint, dass viele Unternehmen ihre eigenen Methoden implementieren, um dies zu erreichen. Qt und Flash verfügen beispielsweise über Schemata für hardwarebeschleunigte Vektoren, und viele Tools von Adobe bieten optional eine Hardwarebeschleunigung an. Aber es scheint, als würde das Rad neu erfunden, wenn es bereits einen Standard gibt!

Gibt es etwas, das ich an OpenVG vermisse, das es für den realen Gebrauch ungeeignet macht? Oder hat sich der Standard nur nicht rechtzeitig durchgesetzt und ist jetzt für Unbekanntes bestimmt? Glauben Sie, dass es in Zukunft Platz für eine standardisierte API für hardwarebeschleunigte Vektorgrafiken gibt, oder wird es einfacher sein, traditionelle rasterbasierte Techniken zu verwenden? Oder sind Vektoren einfach auf dem Weg nach draußen, bevor sie jemals reingekommen sind?

Update: Siehe unten in der Antwort

Diese Antwort kommt ein bisschen zu spät, aber ich hoffe, dass sie anderen klar wird (insbesondere jetzt, wo das C ++ - Standardkomitee Kairo in die Norm aufnehmen will):

Der Grund, warum sich niemand wirklich für "beschleunigte Vektorgrafiken" interessiert, ist die Funktionsweise von GPUs. GPUs arbeiten mit massiven Parallelisierungs- und SIMD-Funktionen, um die einzelnen Pixel einzufärben. AMD funktioniert normalerweise in Blöcken mit 64 x 64, 8 x 8 Pixeln, während NVIDIA-Karten normalerweise mit 32 x 32, 4 x 4 Pixeln arbeiten.

Selbst wenn sie ein 3D-Dreieck rendern, funktioniert die GPU mit ganzen Quads, die dieses Dreieck abdeckt. Wenn also ein Dreieck nicht alle 8 x 8 Pixel im Block abdeckt (oder 4x4 im Fall von nvidia), berechnet die GPU die Farbe der nicht abgedeckten Pixel und verwirft das Ergebnis. Mit anderen Worten wird die Verarbeitungsleistung für nicht abgedeckte Pixel verschwendet. Obwohl dies verschwenderisch erscheint, eignet es sich hervorragend zum Rendern von großen 3D-Dreiecken in Kombination mit einer großen Anzahl von GPU-Kernen (ausführlichere Informationen hier: Optimieren des grundlegenden Rasters ).

Wenn wir also auf die vektorbasierte Rasterung zurückblicken, werden Sie feststellen, dass beim Zeichnen von Linien, auch wenn diese dick sind, eine massive Leerstelle vorhanden ist. Es wird viel Rechenleistung verschwendet und vor allem Bandbreite (was die Hauptursache für den Stromverbrauch und häufig einen Engpass darstellt). Es sei denn, Sie zeichnen eine horizontale oder vertikale Linie mit einem Vielfachen der Stärke von 8 und sie passt sich perfekt an 8 Pixel Grenzen, viel Rechenleistung und Bandbreite werden verschwendet.

Die Menge an "Makulatur" kann reduziert werden, indem der zu rendernde Rumpf berechnet wird (wie dies bei NV_path_rendering der Fall ist), aber die GPU ist immer noch auf 8x8 / 4x4-Blöcke beschränkt (auch die GPU-Benchmarks von NVIDIA lassen sich mit höheren Auflösungen besser skalieren, das Verhältnis pixel_covered / pixels_wasted ist viel niedriger).

Aus diesem Grund interessieren sich viele Menschen nicht einmal für "Vektor-HW-Beschleunigung". GPUs sind einfach nicht gut für die Aufgabe geeignet.

NV_path_rendering ist eher die Ausnahme als die Norm, und sie haben den neuartigen Trick eingeführt, den Schablonenpuffer zu verwenden. Dies unterstützt die Komprimierung und kann die Bandbreitennutzung erheblich reduzieren.

Trotzdem bin ich skeptisch gegenüber NV_path_rendering und zeige mit ein wenig googeln, dass Qt bei der Verwendung von OpenGL (auch bekannt als empfohlen) deutlich schneller ist als NV_path_rendering von NVIDIA: NV-Pfad-Rendering Mit anderen Worten, NVIDIAs Folien haben XRender's Version von "versehentlich" verglichen Qt. Hoppla.

Anstatt zu argumentieren, dass "alles, was mit der HW-Beschleunigung gezeichnet wird, schneller ist", geben Qt-Entwickler ehrlicher zu, dass das HW-beschleunigte Zeichnen von Vektoren nicht immer besser ist (siehe Erklärung zu deren Rendering: Qt Graphics and Performance - OpenGL ).

Und wir haben den Teil der "Live-Bearbeitung" von Vektorgrafiken nicht angesprochen, der eine schnelle Erzeugung von Dreiecksstreifen erfordert. Bei der Bearbeitung komplexer SVGs kann dies tatsächlich zu einem erheblichen Mehraufwand führen.

Ob es besser ist oder nicht, hängt stark von den Anwendungen ab; Ich hoffe, dass Ihre ursprüngliche Frage "Warum hat es nicht geklappt?" jetzt beantwortet ist: Es gibt viele Nachteile und Einschränkungen, die zu berücksichtigen sind, was viele Leute oft skeptisch macht und sie möglicherweise sogar dazu veranlasst, keine zu implementieren .

Update: Ich wurde darauf hingewiesen, dass die Zahlen völlig falsch sind, da die genannten GPUs nicht in 64x64- und 32x32-Blöcken rastern, sondern in 8x8 = 64 und 4x4 = 16. Dies macht die Schlussfolgerungen des Beitrags ziemlich zunichte. Ich werde diesen Beitrag bald später mit aktuelleren Informationen aktualisieren.

Ich denke nicht, dass es wirklich wahr ist, dass sich niemand wirklich für "beschleunigte Vektorgrafiken" interessiert, wie in dieser Antwort geschrieben .

Nvidia scheint das ein bisschen zu interessieren. Neben Kilgard, dem leitenden Techniker bei NV_path_rendering (von nun an NVpr, um meine Finger zu schonen), hat Neil Trevett, der auch Vice President bei Nvidia ist, NVpr in den letzten Jahren so gut wie möglich beworben. siehe seine talk1 , talk2 oder talk3 . Und das scheint sich ein bisschen ausgezahlt zu haben. Derzeit wird NVpr in Googles Skia (das wiederum in Google Chrome verwendet wird) und unabhängig [von Skia] in einer Beta-Version von Adobe Illustrator CC (Beta) verwendet, wie Kilgards Folien bei GTC14 belegen . Es gibt auch einige Videos von den Vorträgen: Kilgard's und Adobe's. Ein Kairoer Entwickler (der für Intel arbeitet) scheint ebenfalls an NVpr interessiert zu sein. Mozilla / Firefox-Entwickler haben auch mit NVpr experimentiert und interessieren sich in der Tat für GPU-beschleunigte Vektorgrafiken im Allgemeinen, wie diese FOSDEM14- Talkshows zeigen.

Microsoft kümmert sich auch ein bisschen darum , weil sie Direct2D erstellt haben , das ziemlich weit verbreitet ist [wenn Sie der Meinung sind, dass der Mozilla-Entwickler von dem oben erwähnten Vortrag abstammt].

Nun zur ursprünglichen Frage: Es gibt in der Tat einige technische Gründe, warum die Verwendung von GPUs für das Pfad-Rendering nicht einfach ist. Wenn Sie erfahren möchten, wie sich das Rendern von Pfaden von der 3D-Vertex-Geometrie nach Moorstandard unterscheidet und warum die GPU-Beschleunigung beim Rendern von Pfaden nicht trivial ist, dann hat Kilgard einen sehr guten FAQ-ähnlichen Beitrag , der leider irgendwo im OpenGL-Forum vergraben ist.

Weitere Informationen zur Funktionsweise von Direct2D, NVpr und dergleichen finden Sie in Kilgards Artikel Siggraph 2012 , der sich natürlich auf NVpr konzentriert, aber auch gute Arbeit leistet, um frühere Ansätze zu überprüfen. Es genügt zu sagen, dass schnelle Hacks nicht gut funktionieren ... (wie im Text der PSE-Frage angegeben). Es gibt signifikante Leistungsunterschiede zwischen diesen Ansätzen, wie in diesem Artikel erörtert und in einigen frühen Demos von Kilgard gezeigt, z dieses Video . Ich sollte auch beachten, dass im offiziellen NVpr-Erweiterungsdokument mehrere Leistungsverbesserungen im Laufe der Jahre aufgeführt sind.

Nur weil NVpr 2011 (in seiner ersten veröffentlichten Implementierung) unter Linux nicht so gut war , heißt das nicht, dass die GPU-Beschleunigung von Vektoren / Pfaden als Antwort von Goldberg hoffnungslos ist , wie der Blogpost von Qt, Zack Rusin, 2011, sagte scheint daraus gefolgert zu haben. Tatsächlich hat Kilgard am Ende dieses Blogposts mit aktualisierten Treibern geantwortet, die eine 2x-4x-Verbesserung gegenüber Qts schnellerem Code zeigten, und Rusin hat danach nichts gesagt.

Die Valve Corp. kümmert sich auch um das GPU-beschleunigte Vektor-Rendering, jedoch in geringerem Maße um das Font / Glyph-Rendering. Sie haben eine nette, schnelle Implementierung der Glättung großer Schriftarten mit GPU-beschleunigten vorzeichenbehafteten Distanzfeldern (SDF) erhalten, die auf der Siggraph 2007 vorgestellt wurden , die in ihren Spielen wie TF verwendet wird. Es gibt eine Video-Demonstration der Technik auf YouTube (aber ich bin nicht sicher, wer das gemacht hat).

Der SDF-Ansatz wurde von einem der Cairo & Pango-Entwickler in Form von GLyphy verfeinert . Sein Autor hielt einen Vortrag auf der linux.conf.au 2014. Die zu lange nicht beobachtete Version besteht darin, dass er eine Arc-Spline-Approximation der Bezier-Kurven vornimmt, um die SDF-Berechnung im Vektorraum (und nicht im Rasterraum) besser nachvollziehbar zu machen (Valve hat letztere durchgeführt). Aber selbst mit der Arc-Spline-Näherung war die Berechnung noch langsam; Er sagte, seine erste Version lief mit 3 fps. Also macht er jetzt ein paar Grid-basierte Cullings für Sachen, die "zu weit weg" sind, was aussieht wie eine Form von LOD (Level of Detail), aber im SDF-Raum. Mit dieser Optimierung liefen seine Demos mit 60 fps (und es war wahrscheinlich Vsync begrenzt). Seine Shader sind jedoch unglaublich komplex und stoßen an die Grenzen von Hardware und Treibern. Er sagte etwas in der Art: "Für jede Fahrer / Betriebssystem-Kombination mussten wir etwas ändern". Er fand auch signifikante Fehler in Shader-Compilern, einige davon wurden dann von ihren jeweiligen Entwicklern repariert. Es klingt also sehr nach der Entwicklung von AAA-Spielen ...

Andererseits scheint Microsoft ein wenig neue GPU-Hardware in Auftrag gegeben / spezifiziert zu haben, um ihre Direct2D-Implementierung mit Hardware zu verbessern, die von Windows 8 verwendet wird, sofern verfügbar . Dies wird als target-independent rasterization ( TIR ) bezeichnet, ein Name, der etwas irreführend ist, was das Zeug tatsächlich zu tun scheint, was in der Patentanmeldung von Microsoft dargelegt ist . AMD behauptete, dass TIR die Leistung in 2D-Vektorgrafiken um etwa 500% verbesserte . Und zwischen ihnen und Nvidia gab es ein bisschen "War of Words", weil die Kepler-GPUs es nicht haben, während es die GCN-basierten GPUs von AMD tun. Nvidia hat bestätigtdass dies in der Tat ein bisschen neue Hardware ist, nicht einfach etwas, was ein Treiber-Update bieten kann. Sinofskys Blogpost enthält einige weitere Details, einschließlich einiger tatsächlicher Benchmarks für TIR. Ich zitiere nur die allgemeinen Ideenbits:

Um die Leistung beim Rendern unregelmäßiger Geometrie (z. B. geografische Grenzen auf einer Karte) zu verbessern, verwenden wir eine neue Grafikhardwarefunktion namens Target Independent Rasterization (TIR).

Mit TIR kann Direct2D weniger CPU-Zyklen für die Tessellierung aufwenden und der GPU so schnell und effizient Zeichenanweisungen geben, ohne die visuelle Qualität zu beeinträchtigen. TIR ist in neuer GPU-Hardware für Windows 8 verfügbar, die DirectX 11.1 unterstützt.

Nachfolgend sehen Sie ein Diagramm, das die Leistungsverbesserung beim Rendern von Geometrie mit Anti-Alias-Effekten aus einer Vielzahl von SVG-Dateien auf einer DirectX 11.1-GPU zeigt, die TIR unterstützt:

Wir haben eng mit unseren Grafikhardware-Partnern [read AMD] zusammengearbeitet, um TIR zu entwerfen. Durch diese Partnerschaft wurden dramatische Verbesserungen ermöglicht. DirectX 11.1-Hardware ist bereits auf dem Markt und wir arbeiten mit unseren Partnern zusammen, um sicherzustellen, dass mehr TIR-fähige Produkte auf breiter Basis verfügbar sind.

Ich denke, dies war eines der schönen Dinge, die Win 8 hinzugefügt hat und die im Metro-UI-Fiasko größtenteils für die Welt verloren gingen ...

Wahrscheinlich, weil der Nutzen die Kosten nicht überwiegt.