DE102021121109A1

DE102021121109A1 - Wiederherstellung dreidimensionaler modelle aus zweidimensionalen bildern

Info

Publication number: DE102021121109A1
Application number: DE102021121109.3A
Authority: DE
Inventors: Samuli Matias Laine; Janne Johannes Hellsten; Tero Tapani KARRAS; Yeongho SEOL; Jaakko T. Lehtinen; Timo Oskari Aila
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-08-17
Filing date: 2021-08-13
Publication date: 2022-02-17
Also published as: US20220051481A1; CN114155331A; US11734890B2

Abstract

Ein dreidimensionales (3D) Modell eines Objekts wird aus zweidimensionalen (2D) Bildern des Objekts wiederhergestellt. Jedes Bild in der Menge der 2D-Bilder enthält das Objekt, das aus einer anderen Kameraposition aufgenommen wurde, und die Verformungen eines Basisnetzes, das das 3D-Modell definiert, können entsprechend jedem Bild berechnet werden. Das 3D-Modell kann auch eine Textur-Map enthalten, die die Beleuchtungs- und Materialeigenschaften des 3D-Modells darstellt. Die Wiederherstellung des 3D-Modells stützt sich auf analytisches Antialiasing, um eine Verbindung zwischen den Pixelfarben in den 2D-Bildern und der Geometrie des 3D-Modells herzustellen. Ein modularer differenzierbarer Renderer sorgt für hohe Leistung, indem er vorhandene, hoch optimierte Hardware-Grafikpipelines zur Rekonstruktion des 3D-Modells nutzt. Der differenzielle Renderer rendert Bilder des 3D-Modells und Unterschiede zwischen den gerenderten Bildern und den Referenzbildern werden rückwärts durch die Rendering-Pipeline propagiert, um das 3D-Modell iterativ anzupassen.

Description

HINTERGRUND DER ERFINDUNG
Inverses Rendering ist eine Technik, welche zur iterativen Wiederherstellung einer Form, von Beleuchtung und Materialeigenschaften eines 3D-Modells auf der Grundlage von 2D-Bildern eingesetzt wird. Inverses Rendering ist eine Herausforderung, da die Operationen, die zum Rendern des 3D-Modells verwendet werden, um die 2D-Bilder zu erzeugen, nicht einfach rückwärts durchgeführt werden können, um das 3D-Modell aus den 2D-Bildern zu erzeugen. Herkömmliche inverse Rendering-Techniken konzentrieren sich üblicherweise entweder auf Bildqualität oder Leistung. Es ist daher notwendig, diese Probleme und/oder andere mit dem Stand der Technik verbundene Probleme zu lösen.
ZUSAMMENFASSUNG DER ERFINDUNG
Ausführungsformen der vorliegenden Erfindung betreffen die Wiederherstellung dreidimensionaler (3D) Modelle aus zweidimensionalen (2D) Bildern. Es werden Systeme und Verfahren offenbart, welche die Wiederherstellung eines 3D-Modells eines Objekts aus einem Satz von 2D-Bildern des Objekts ermöglichen. Jedes Bild in dem Satz von 2D-Bildern beinhaltet das Objekt, das aus einer anderen Kameraposition aufgenommen wurde. Das wiederhergestellte 3D-Modell kann als ein einfaches Basisnetz dargestellt werden, das durch Eckpunkte definiert ist, die Positionen im 3D-Raum entsprechen. Formveränderungen des 3D-Modells können für jedes Bild entsprechend berechnet werden. In einer Ausführungsform sind die Formveränderungen Offsets für die Eckpunktpositionen. Das 3D-Modell kann auch eine Textur-Map umfassen, welche die Beleuchtung und Materialeigenschaften des 3D-Modells darstellt. Die Wiederherstellung des 3D-Modells stützt sich auf analytisches Antialiasing, um eine Verbindung zwischen Pixelfarben in den 2D-Bildern und der Geometrie des 3D-Modells herzustellen.
Es werden ein Verfahren, ein computerlesbares Medium und ein System zum Konstruieren eines 3D-Modells aus 2D-Bildern offenbart. Ein durch eine Ausgangsgeometrie definiertes Bild des 3D-Modells wird gerendert, wobei eine von einer Rendering-Pipeline durchgeführte Antialiasing-Operation Daten verarbeitet, die mit der Geometrie verknüpft sind, um das Bild zu Netz, und Pixeldifferenzen werden auf der Grundlage des Bildes und eines Referenzbildes berechnet. Die Pixeldifferenzen werden durch die Antialiasing-Operation der Rendering-Pipeline rückwärts propagiert, um Geometrieänderungen zu berechnen, die einer Reduzierung der Pixeldifferenzen entsprechen, und die Ausgangsgeometrie wird auf der Grundlage der Geometrieänderungen angepasst, um eine modifizierte, das 3D-Modell definierende Geometrie zu erzeugen.
Figurenliste
Die vorliegenden Systeme und Verfahren zum Wiederherstellen von 3D-Modellen aus 2D-Bildern werden nachfolgend mit Bezug auf die beigefügten Figuren detailliert beschrieben; sie zeigen:

1A zeigt eine konzeptionelles Schema eines Systems zur Wiederherstellung von 3D-Modellen gemäß einer Ausführungsform.
1B zeigt ein weiteres konzeptionelles Schema zur Wiederherstellung von 3D-Modellen gemäß einer Ausführungsform.
1C zeigt ein konzeptionelles Schema analytischen Antialiasings gemäß einer Ausführungsform.
1D zeigt ein weiteres konzeptionelles Schema analytischen Antialiasings gemäß einer Ausführungsform.
2A zeigt ein Blockdiagramm eines beispielhaften Systems zur Wiederherstellung von 3D-Modellen, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.
2B zeigt ein weiteres Blockdiagramm des beispielhaften Systems zur Wiederherstellung von 3D-Modellen, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist
2C zeigt ein weiteres Blockdiagramm des beispielhaften Systems zur Wiederherstellung von 3D-Modellen, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.
3 zeigt ein Flussdiagramm eines Verfahrens zur Wiederherstellung von 3D-Modellen, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.
4 zeigt eine beispielhafte Parallelverarbeitungseinheit (PPU), die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.
5A zeigt ein konzeptionelles Schema eines Verarbeitungssystems, das unter Verwendung der PPU von 4 implementiert wurde und zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.
5B zeigt ein beispielhaftes System, in dem die verschiedenartige Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert werden können.
5C zeigt Komponenten eines beispielhaften Systems, das zum Trainieren und Anwenden maschinellen Lernens in mindestens einer Ausführungsform verwendet werden kann.
6A zeigt ein konzeptionelles Schema einer Grafikverarbeitungspipeline, die durch die PPU von 4 implementiert wurde und zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.
6B zeigt ein beispielhaftes Game-Streaming-System, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es werden Systeme und Verfahren zum Wiederherstellen von 3D-Modellen aus 2D-Bildern offenbart. Ein modularer differenzierbarer Renderer ermöglicht eine hohe Leistung, indem er vorhandene, hoch optimierte Hardware-Grafikpipelines zur Rekonstruktion des 3D-Modells nutzt. In einer Ausführungsform werden eine oder mehrere Operationen des differenzierbaren Renderers unter Verwendung einer beliebigen Kombination aus einer Grafikpipeline einer Grafikverarbeitungseinheit (GPU), allgemeinen GPU-Rechenkernen oder einer zentralen Verarbeitungseinheit (CPU) durchgeführt. Der differenzierbare Renderer ermöglicht Operationen wie Rasterung einer großen Anzahl von Dreiecken, Interpolation von Attributen, gefilterte Suche nach Texturen sowie benutzerprogrammierbare Schattierung und Geometrieverarbeitung, und das alles in hohen Auflösungen. Im Gegensatz zu herkömmlichen Systemen ist das wiederhergestellte 3D-Modell präzise und kann durch Rendern analytischer Antialiasing-Bilder des 3D-Modells und Weitergabe von Unterschieden zwischen den gerenderten Bildern und Referenzbildern rückwärts durch die Rendering-Pipeline erzeugt werden, um das 3D.Modell iterativ anzupassen.
Figure 1A zeigt ein konzeptionelles Schema eines Systems zur Wiederherstellung von 3D-Modellen 100 gemäß einer Ausführungsform. Ein Satz von 2D-Bildern eines Objekts 110 wird aus einer Vielzahl von Kamerapositionen aufgenommen. Das Systems zur Wiederherstellung von 3D-Modellen 100 konstruiert ein 3D-Modell 130 des Objekts unter Verwendung des 2D-Bilder-Satzes, um ein 3D-Ausgangsmodell zu verfeinern. Das 3D-Ausgangsmodell kann eine Kugel oder andere geometrische Form sein. In einer Ausführungsform ist das 3D-Modell 130 ein Basismodell, welches verformt wird, um ein spezifisches 3D-Modell zu erzeugen, das jedem der 2D-Bilder in dem Satz entspricht. In einer anderen Ausführungsform wird ein vollständiges 3D-Modell 130 für jedes des einen oder der mehreren 2D-Bilder in dem Satz erstellt. Ein Satz von Textur-Maps 125 ist eine globale Oberflächentextur, welche Beleuchtungs- und Materialeigenschaften 120 definiert, die auf das 3D-Modell 130 angewendet werden können. In einer Ausführungsform umfasst der Satz von Textur-Maps 125 eine MIP-Mapped-Textur. Eine globale Ausgangsoberflächentextur kann eine konstante Farbe sein, und die Farben jedes Texels in der allgemeinen Ausgangsoberflächentextur werden durch das System zur Wiederherstellung von 3D-Modellen100 angepasst, um den Satz von Textur-Maps 125 zu erzeugen.
Das Ziel des Systems zur Wiederherstellung von 3D-Modellen 100 besteht in der Erzeugung des 3D-Modells 130, welches, wenn es unter Verwendung des Satzes von Textur-Maps 125 gerendert wird, gerenderte Bilder erzeugt, die dem Satz von 2D-Bildern des Objekts 110 genau entsprechen. Die Kamerapositionen, die dem Satz von 2D-Bildern des Objekts 110 zugeordnet sind, werden vom System zur Wiederherstellung von 3D-Modellen 100 zum Rendern des 3D-Modells 130 verwendet. Im Gegensatz zu herkömmlichen Rendering-Systemen, deren Ziel es ist, Bilder von hoher Qualität zu rendern, nutzt das System zur Wiederherstellung von 3D-Modellen 100 Rendern, um die Wiederherstellung des 3D-Modells 130 zu ermöglichen. Anders ausgedrückt werden die gerenderten Bilder verarbeitet, um die Geometrie, die das 3D-Modell definiert, zu bestimmen und fein abzustimmen. In einer Ausführungsform wird die Geometrie durch die Positionen der Eckpunkte definiert, welche ein Netz des 3D-Modells 130 bilden. In einer Ausführungsform wird das Netz durch andere Arten von Primitiven oder Darstellungen definiert. In einer Ausführungsform umfasst der 2D-Bilder-Satz des Objekts 110 ein Video.
Wiederherstellung des 3D-Modells 130 kann verwendet werden, um eine Erfassung der Gesichtsleistung ohne Marker durchzuführen. Ohne Marker bedeutet, dass in der Menge der 2D-Bilder des Objekts 110 keine Orientierungspunkte auf dem Objekt markiert sind. Der Wiederherstellungsprozess konstruiert das 3D-Modell 130, das die in den verschiedenen 2D-Bildern sichtbaren Gesichtsausdrücke reproduziert. Wiederherstellung des 3D-Modells ermöglicht die Erzeugung neuer Bilder des 3D-Modells für Charakter-Animation, beispielsweise während eines Spielverlaufs oder zur Filmproduktion.
Weitere erläuternde Informationen werden unter Betrachtung verschiedener optionaler Architekturen und Funktionen dargelegt, mit denen die vorstehende Grundstruktur je nach Wünschen des Benutzers implementiert werden kann. Es wird ausdrücklich darauf hingewiesen, dass die folgenden Informationen nur zur Veranschaulichung dienen und in keiner Weise als einschränkend anzusehen sind. Jedes der folgenden Merkmale kann optional mit oder ohne Ausschluss anderer beschriebener Merkmale integriert werden.
1B zeigt ein weiteres konzeptionelles Schema eines Systems zur Wiederherstellung von 3D-Modellen 100 gemäß einer Ausführungsform. Das System zur Wiederherstellung von 3D-Modellen 100 empfängt ein 3D-Ausgangsmodell 132 eines Objekts und eine globale Ausgangstextur (nicht dargestellt). In einer Ausführungsform sind die Texturkoordinaten des 3D-Ausgangsmodells 132 mit jedem Eckpunkt, der das 3D-Ausgangsmodell 132 definiert, verknüpft, und die Verknüpfung zwischen den Eckpunkten und den Texturkoordinaten bleibt unverändert, selbst wenn die Positionen der Eckpunkte geändert werden, um das konstruierte 3D-Modell 134 zu erzeugen. Jedoch werden die Inhalte der globalen Textur angepasst, wenn das konstruierte 3D-Modell 134 geändert wird.
Das System zur Wiederherstellung von 3D-Modellen 100 empfängt auch den 2D-Bildersatz eines Objekts 110, welcher das Referenzbild 112 enthalten kann. Wie zuvor beschrieben, besteht das Ziel des Systems zur Wiederherstellung von 3D-Modellen 100 darin, eine globale Textur und ein konstruiertes 3D-Modell 134 (z. B. bildspezifisches Netz) zu finden, die, wenn sie von einer mit dem Referenzbild 112 verbundenen Kameraposition 114 gerendert werden, ein gerendertes Bild 115 erzeugen, welches mit dem Referenzbild 112 übereinstimmt. In einer Ausführungsform vergleicht das System zur Wiederherstellung von 3D-Modellen 100 das Referenzbild 112 und das gerenderte Bild 115 durch Ermitteln der Unterschiede und berechnet einen Bild-Raum-Verlust. Der Bild-Raum-Verlust wird dann durch die Rendering-Operationen rückwärts propagiert, um das 3D-Ausgangsmodell 132 anzupassen und das konstruierte 3D-Modell 134 zu erzeugen. Im Gegensatz zu herkömmlichen Rendering-Systemen, die ausgelegt sind, Bilder aus 3D-Geometrie zu erzeugen, enthält das System zur Wiederherstellung von 3D-Modellen 100 eine differenzierbare Rendering-Pipeline. Die differenzierbare Rendering-Pipeline kann in einem Vorwärtsbetriebsmodus (Forward Propagation) Bilder aus 3D-Geometrie erzeugen und in einem Rückwärtsbetriebsmodus (Backward Propagation) 3D-Geometrie aus Bildern rekonstruieren. Rendering und Backward Propagation können für mehrere verschiedene Referenzbilder wiederholt werden, um das 3D-Ausgandsmodell 132 iterativ anzupassen, indem das 3D-Ausgangsmodell 132 verformt wird, um den einzelnen Referenzbildern zu entsprechen.
Im Kontext der folgenden Beschreibung sind das gerenderte Bild 115 und andere Bilder, welche vom System zur Wiederherstellung von 3D-Modellen 100 gerendert werden, Antialising-Bilder, bei denen die Antialiasing-Operation Geometriedaten (z. B. Eckpunktpositionen oder Primitive) verarbeitet, die mit dem 3D-Ausgangsmodell 132 oder dem Basisnetz verbunden sind, um das Bild zu antialisieren. In einer Ausführungsform ist die Antialiasing-Operation eine analytische Antialiasing-Operation, welche schattierte Pixelwerte auf der Grundlage der geometrischen Abdeckung bestimmt, nachdem Rasterung, Sichtbarkeitsprüfung und Textur-Mapping durchgeführt wurden.
1C zeigt ein konzeptionelles Schema des analytischen Antialiasing gemäß einer Ausführungsform. Die gerenderte Geometrie 136 bildet eine Silhouettenkante 138 eines Objekts, welches sich im Vergleich zum Hintergrund oder einer anderen Oberfläche, die durch das Objekt abgedeckt ist, näher an der Kamera befindet. In einer Ausführungsform bildet eine Kante eine Silhouette, wenn sie nur ein Verbindungsdreieck hat oder wenn sie zwei Dreiecke mit der gleichen Windung verbindet (was bedeutet, dass beide Dreiecke entweder nach vorn oder nach hinten gerichtet sind). In einer Ausführungsform bildet eine Kante eine Silhouette, wenn die mit der Kante verbundenen Dreiecke, unabhängig von der Windung, von der Kamera aus gesehen auf derselben Seite der Kante liegen.
Silhouettenkanten liefern nützliche Informationen, die für die genaue Wiederherstellung eines 3D-Modells des Objekts erforderlich sind, da die Form des Objekts in der Bildebene extrahiert und in Kombination mit der Kameraposition verwendet werden kann, um die Geometrie (z. B. Eckpunkte) für das 3D-Modell anzupassen. Somit liefert jedes 2D-Referenzbild und das entsprechende gerenderte analytische Antialiasing-Bild, wie weiter beschrieben, zusätzliche Informationen, die zur Verbesserung des 3D-Modells genutzt werden.
Jedes der Pixel 135 und 140 enthält ein einzelnes Muster im Zentrum des Pixels. Herkömmlicherweise ist die gerenderte Geometrie 136 in Pixel 135 sichtbar und in Pixel 140 nicht sichtbar, weil das Muster in Pixel 135 von der gerenderten Geometrie 136 abgedeckt ist und das Muster in Pixel 140 nicht abgedeckt ist. Wenn die Pixel 135 und 140 schattiert sind, erscheinen sie daher als schattierte Pixel 141 und 142. Die schattierten Pixel 141 und 142 sehen für viele verschiedene Positionen und Ausrichtungen der Kante 138 gleich aus. Die schattierten Pixel 141 und 142 liefern nur genügend Informationen, um zu wissen, dass sich ein Schnittpunkt 137 der Kante 138 irgendwo entlang eines horizontalen Segments zwischen den beiden Mustern 135 und 140 befindet. Wenn das Muster in Pixel 140 abgedeckt oder nicht abgedeckt ist, ist der Übergang eher abrupt und diskontinuierlich als glatt oder allmählich und stellt die gerenderte Geometrie 136 nicht präzise dar.
Anstatt sich einfach darauf zu verlassen, ob Muster abgedeckt sind oder nicht, um die schattierten Pixel zu berechnen, verwendet analytisches Antialiasing die geometrischen Daten, insbesondere die Kante 138 und den Schnittpunkt 137, um die schattierten Pixel 143 und 144 zu berechnen. Wie in 1C dargestellt, ist das Pixel 144 schattiert, da es teilweise von der gerenderten Geometrie 136 abgedeckt ist. Wenn der Schnittpunkt 137 näher an das Muster in Pixel 140 herkommt, erhöht sich der Beitrag der gerenderten Geometrie 136 zum schattierten Wert des schattierten Pixels 144. Umgekehrt nimmt der Beitrag der gerenderten Geometrie 136 zum schattierten Wert des schattierten Pixels 144 ab, je weiter sich der Schnittpunkt 137 in Pixel 140 von dem Muster entfernt. Dieselbe Information, die verwendet wird, um den Beitrag der gerenderten Geometrie 136 zu den schattierten Pixeln 143 und 144 im Bildraum zu bestimmen, kann rückwärts verwendet werden, um Gradienten von Eckpunktpositionen im 3D-Modellraum zu berechnen. So wie analytisches Antialiasing ein genaueres Bild in puncto Objektsichtbarkeit erzeugt, sorgen die entsprechenden Eckpunktgradienten für genauere Anpassungen des 3D-Modells.
In einer Ausführungsform verläuft die Kante 138 zwischen den Zentren horizontal benachbarter Pixel 135 und 140 und wird dadurch erkannt, dass in die Pixel 135 und 140 eine unterschiedliche Dreieckskennung (ID) gerastet ist. Die Pixel 135 und 140 können zusammen als Paar verarbeitet werden, und einer der folgenden Fälle kann eintreten: (a) Die Kante 138 kreuzt das Segment, das die Pixelzentren am Schnittpunkt 137 innerhalb von Pixel 140 verbindet, wodurch die Farbe von Pixel 135 in Pixel 140 übergeht. (b) Die Kreuzung findet innerhalb von Pixel 135 statt, so dass die Überblendung (Blending) in umgekehrter Richtung erfolgt. Zur Annäherung an die geometrische Verdeckung zwischen den Flächen ist der Mischfaktor eine lineare Funktion der Lage des Kreuzungspunktes - von Null im Mittelpunkt bis 50 % in der Pixelmitte. Diese spezielle analytische Antialiasing-Methode ist differenzierbar, da die resultierenden Pixelfarben kontinuierliche Funktionen der Positionen der Eckpunkte der gerenderten Geometrie 136 sind. In einer Ausführungsform kann eine komplexere Berechnung zur Bestimmung des Blending-Faktors durchgeführt werden, wobei zum Beispiel die Ausrichtung, Länge und Position der Endpunkte der Kante 138 berücksichtigt werden, um genauer abzuschätzen, wie stark die gerenderte Geometrie 136 das Pixel 140 abdeckt. In einer Ausführungsform können bei der Bestimmung des Blending-Faktors mehrere Kanten berücksichtigt werden. In einer Ausführungsform können mehrere Blending-Faktoren bestimmt werden, um ein Blending zwischen mehr als zwei Pixeln zu ermöglichen.
1D zeigt ein weiteres konzeptionelles Schema analytischen Antialiasings gemäß einer Ausführungsform. Die gerenderte Geometrie 146 bildet eine Silhouettenkante 148 eines Objekts. Jedes der Pixel 145 und 150 enthält ein einzelnes Muster im Zentrum des Pixels. Herkömmlicherweise ist die gerenderte Geometrie 146 in Pixel 145 sichtbar und in Pixel 150 nicht, da das Muster in Pixel 145 von der gerenderten Geometrie 146 abgedeckt ist und das Muster in Pixel 150 nicht abgedeckt ist. Wenn sie schattiert sind, erscheinen die Pixel 145 und 150 daher als schattierte Pixel 151 und 152. Bei Verwendung herkömmlicher Rasterung (ein Muster pro Pixel oder sogar mehrere Muster pro Pixel) ohne analytisches Antialiasing ist die Sichtbarkeit (d. h. welche Geometrie in jedem Pixel sichtbar ist) diskontinuierlich und stückweise konstant - Verschieben eines Eckpunkts oder der Kante 148 um einen infinitesimalen Betrag ändert nicht, welche Pixel (oder Muster) die gerenderte Geometrie 146 abdeckt.
Im Gegensatz dazu verwendet analytisches Antialiasing die Kante 148 und den Schnittpunkt 147, um die schattierten Pixel 153 und 154 zu berechnen. Ein Schnittpunkt 147 befindet sich innerhalb von Pixel 145, wodurch die Farbe von Pixel 150 in Pixel 145 übergeht. Wie in 1D gezeigt, ist Pixel 153 schattiert, da es teilweise von der gerenderten Geometrie 146 abgedeckt ist, und Pixel 154 ist nicht schattiert, da die gerenderte Geometrie 146 das Pixel 150 nicht schneidet.
Analytisches Antialiasing approximiert das Pixelintegral (durchschnittliche Oberflächenfarbe innerhalb des Pixels) auf der Grundlage der Position einer Silhouettenkante im Pixel. Die Ausgangsfarbe des Pixels hängt, unter anderem, von den Positionen der Eckpunkte ab, welche die Silhouettenkante im Pixel definieren; insbesondere vom Schnittpunkt des Segments zwischen Pixelpaaren für verschiedene Dreieck-IDs. Die Abhängigkeit ist (stückweise) kontinuierlich und daher differenzierbar, und somit werden die Gradienten der Eckpunktpositionen auch die Änderung der Farbe des Ausgabepixels widerspiegeln, welche auf eine Änderung zurückzuführen ist, inwieweit die näher gerenderte, die Silhouettenkante definierende Geometrie das Pixel abdeckt. Die Gradienten werden daher Informationen darüber enthalten, wie sich Verschieben der Eckpunkte auf die Position der Silhouettenkante im gerenderten Bild auswirkt. Wie in den 1C und 1D dargestellt, ändert sich die Farbe des Pixels, wenn sich die Silhouettenkante der gerenderten Geometrie näher an das Pixelzentrum oder weiter weg von ihm bewegt. Die Änderungen der Pixelfarbe geben also Aufschluss über die Position der Eckpunkte. Im Gegensatz dazu ändert sich bei Verwendung herkömmlicher Rasterung die Farbe des Pixels nur, wenn das Zentrum abgedeckt oder nicht abgedeckt ist, so dass aus der Farbe nur sehr wenige Informationen über die Eckpunktpositionen ermittelt werden können. Befindet sich daher die Silhouettenkante eines konventionell gerenderten 3D-Modells an einer falschen Stelle im Bildraum, gibt es nur wenige oder gar keine Informationen, anhand derer die Eckpunkte des 3D-Modells so angepasst werden können, dass die Silhouettenkante näher dort erscheint, wo sie im gerenderten Bild sein sollte.
Die Technik zur Wiederherstellung von 3D-Modellen kann das analytische Antialiasing-Verfahren verwenden, um nicht nur die Form des Objekts, sondern anhand der Anzahl der 2D-Bilder des Objekts auch die Beleuchtungs- und Materialeigenschaften des 3D-Modells wiederherzustellen. Analytisches Antialiasing ist in einer differenzierbaren Rasterungspipeline enthalten, welche eine verzögerte Schattierung zum Rendern des 3D-Modells durchführt, um die gerenderten Bilder für jede mit den 2D-Bildern verbundene Kameraposition zu erzeugen. Insbesondere wird analytisches Antialiasing an der Ausgabe der Deferred-Shading-Operation (verzögerte oder aufgeschobene Schattierung) durchgeführt, wobei schattierte Pixel und, als zusätzliche Eingaben, Daten für die Geometrie, Dreiecks-IDs sowie Eckpunktpositionen und -indizes empfangen werden.
Analytisches Antialiasing kann implementiert werden, indem zunächst potenzielle Sichtbarkeitsdiskontinuitäten durch Auffinden aller benachbarten horizontalen und vertikalen Pixelpaare mit nicht übereinstimmenden Dreieck-IDs ermittelt werden. Für jede potenzielle Diskontinuität wird das Dreieck abgerufen, das der kameranäheren Oberfläche zugeordnet ist, wie aus den während der Rasterung berechneten normalisierten Gerätekoordinatentiefen (NDC-Tiefen) hervorgeht. Dann werden die Kanten des Dreiecks untersucht, um festzustellen, ob eine der Kanten eine Silhouette bildet und zwischen den Pixelzentren der Pixelpaare verläuft. Bei horizontalen Pixelpaaren werden nur vertikal orientierte Kanten (|w_c,1 · y_c,2 - w_c,2 · y_c,1| > |w_c,1· x_c,2 - w_c,2 · x_c,1|) berücksichtigt und umgekehrt, wobei (x, y, w) die x-, y-Pixelkoordinaten im Clipraum sind. Wenn eine Silhouettenkante das Segment zwischen den Pixelzentren kreuzt, wird eine Blending-Gewichtung durch Bestimmen des Schnittpunktes berechnet, an dem die Kreuzung auftritt. Die Pixelfarben werden dann so angepasst, dass sie die annähernde Abdeckung einer der beiden Oberflächen in den Pixeln widerspiegeln. Die Technik approximiert im Wesentlichen die genaue Oberflächenabdeckung pro Pixel unter Verwendung einer achsenausgerichteten Scheibe. Demzufolge ist die Abdeckungsschätzung nur für die perfekt vertikalen und horizontalen Kanten, die über das Pixel hinausgehen, genau. Für andere (nicht vertikale und nicht horizontale) Überschneidungen ist die Abdeckungsschätzung jedoch eine angemessen ausreichende Annäherung, um ein genaues 3D-Modell zu erstellen. In einer Ausführungsform kann die komplexere Berechnung zur Bestimmung des Blending-Faktors durchgeführt werden, wobei zum Beispiel die Ausrichtung, Länge und Lage der Kantenendpunkte berücksichtigt werden.
Ausgehend von einer 3D-Szenenbeschreibung in Form geometrischer Formen, Materialien sowie Kamera- und Beleuchtungsmodellen läuft das Rendern von 2D-Bildern auf zwei Rechenprobleme hinaus: Es gilt herauszufinden, welche Teile der 3D-Szene in jedem Pixel sichtbar sind und welche Farbe die sichtbaren Teile zu haben scheinen. Ein geeigneter differenzierbarer Renderer muss Gradienten für alle dabei verwendeten Parameter - zum Beispiel Beleuchtungs- und Materialparameter sowie die Inhalte von Textur-Maps - bereitstellen. Im Zusammenhang mit der folgenden Beschreibung ist es hilfreich, den Rendering-Prozess in die folgende Form aufzugliedern, wobei die endgültige Farbe I_i des Pixels an den Bildschirmkoordinaten (x_i, y_i) wie folgt gegeben ist $I_{i} = \underset{x, y}{filter} (shade (M (P (x, y)), lights)) (x_{i}, y_{i}) .$
Hier bezeichnet P(x,y) den Weltpunkt, der an den (kontinuierlichen) Bildkoordinaten (x, y) nach der Projektion von 3D auf 2D sichtbar ist, und M(P) bezeichnet alle räumlich variierenden Faktoren (Textur-Maps, Normalenvektoren usw.), welche sich auf den Oberflächen der Szene befinden. Die Schattierungsfunktion modelliert in der Regel Licht-Oberflächen-Interaktionen. Der 2D-Antialiasing-Filter, der sowohl für die Bildqualität als auch für die Differenzierbarkeit entscheidend ist, wird auf die Schattierungsergebnisse bei kontinuierlichen (x, y) angewendet, und die endgültige Farbe wird durch Abtasten des Ergebnisses im Pixelzentrum (x, y) erhalten.
2A zeigt ein Blockdiagramm eines beispielhaften Systems zur Wiederherstellung von 3D-Modellen 100, welches zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist. Es versteht sich, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt sind. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Anordnungen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente funktionale Einheiten, welche als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jeder geeigneten Stelle implementiert werden können. Verschiedene hier beschriebene Funktionen, welche von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Darüber hinaus werden Fachleute wissen, dass jedes System, welches die Operationen des Systems zur Wiederherstellung von 3D-Modellen 100 durchführt, in den Anwendungsbereich und den Geist der Ausführungsformen der vorliegenden Erfindung fällt.
Das System zur Wiederherstellung von 3D-Modellen 100 umfasst eine 3D-Modell-Konstruktionseinheit 200, einen differenzierbaren Renderer 215 und eine Bildraumverlust-Einheit 245. Der differenzierbare Renderer 215 umfasst eine Rendering-Pipeline 205 und eine Backward-Propagation-Pipeline 260. Ein 3D-Modell wird von einer Kameraposition aus in einem Vorwärtsdurchlauf durch die Rendering-Pipeline 205 des differenzierbaren Renderers 215 gerendert, um ein Antialiasing-Bild zu erzeugen. Die 3D-Modell-Konstruktionseinheit 200 liefert eine Darstellung des 3D-Modells an die Rendering-Pipeline 205 zusammen mit einer Referenz-Kameraposition. In einer Ausführungsform kann ein 3D-Ausgangsmodell ein Basisnetz sein, welches so einfach wie ein Würfel oder eine Kugel ist. In einer Ausführungsform umfasst das 3D-Modell Eckpunkte im 3D-Modellraum und mit den Eckpunkten verknüpfte Attribute. Eine Ausgangsoberflächen-Textur-Map, welche dem 3D-Ausgangsmodell entspricht, kann eine einheitliche Farbe sein.
Die Rendering-Pipeline 205 verarbeitet das 3D-Modell, indem sie Schritte der Transformation (von 3D zu 2D), Rasterung, Interpolation, Textur-Lookup und Antialiasing durchführt. Eine letzte Stufe in der Rendering-Pipeline 205 führt analytisches Antialiasing durch, um sichtbarkeitsbezogene Effekte geometrischer Kanten auf das gerenderte Bild zu berechnen. Wenn die Analytik-Antialiasing-Operation in umgekehrter Richtung von der Backward-Propagation-Pipeline 260 durchgeführt wird, bestimmt sie, wie der Gradient der Pixelfarben auf den Gradienten des 3D-Modells übertragen wird.
Die Bildraumverlust-Einheit 245 bestimmt einen Bildraum-(Farb-)Verlust auf der Grundlage von Farbunterschieden pro Pixel zwischen dem entzerrten Bild und einem Referenz-(Ziel-)Bild des Objekts, welches mit der Referenzkameraposition verknüpft ist. Die Unterschiede quantifizieren die Genauigkeit des 3D-Modells des Objekts und stellen einen „Verlust“ dar. In einer Ausführungsform werden die Differenzen als mittlere quadratische Differenz pro Pixel berechnet. In einer Ausführungsform werden die Differenzen zwischen hochdimensionalen Einbettungen der Bilder berechnet, beispielsweise unter Verwendung vortrainierter neuronaler Netze. Der Bildraumverlust benachteiligt 3D-Modelllösungen, bei denen das gerenderte Bild nicht mit dem Referenzbild übereinstimmt. Die Bildraumverlust-Einheit 245 kann jedoch auch andere Verlustfunktionen zusammen mit dem Bildraumverlust verwenden, um die Optimierung zu regulieren. In einer Ausführungsform bestraft ein Laplace-Verlust Lösungen, bei denen sich die Krümmung des Netzes im Vergleich zum Basisnetz stark verändert, was die Optimierung effektiv dazu anregt, nur Lösungen zu berücksichtigen, die physisch plausibel sind.
Die Backward-Propagation-Pipeline 260 empfängt Gradienten des antialisierten Bildes, welche angeben, wie die Farbe jedes Pixels des antialisierten Bildes den Verlust beeinflusst. Die Backward-Propagation-Pipeline 260 berechnet (1) den Gradienten des entzerrten Bildes, der in die letzte Stufe der Rendering-Pipeline 205 (analytisches Antialiasing) eingegeben wird, und (2) den Gradienten der Eckpunktpositionen. Das Forward-Rendering, der Vergleich mit einem Referenzbild und die Backward Propagation werden für mehrere Kamerapositionen durchgeführt, um eine Oberflächen-Textur-Map und -Geometrie für eine modifizierte Version des ursprünglichen 3D-Modells oder des Basisnetzes für jedes Referenzbild zu erstellen. Das Ergebnis ist ein 3D-Modell des Objekts und eine entsprechende Oberflächen-Textur-Map, welche nach dem Rendern mit den Zielbildern übereinstimmen. Die Verwendung mehrerer Kamerapositionen ermöglicht die Wiederherstellung verschiedener Teile des Objekts durch das analytische Antialiasing aufgrund der Vielfalt der gerenderten Silhouettenkanten.
In einer Ausführungsform sind die Textur-Map-Werte (z. B. Textur-Map-Koordinaten und Texel) und Eckpunktpositionen latente Variablen, welche optimiert werden können, um den Verlust zu verringern und dadurch die Genauigkeit des 3D-Modells zu verbessern. Die Bestimmung, wie die latenten Variablen zu ändern sind, um den Verlust zu verringern, erfolgt durch Backward Propagation. Bei der Weitergabe von Antialiasing-Bildgradienten durch die Backward-Propagation-Pipeline 260 ist der Gradient der Ausgabe für jeden Berechnungsschritt bekannt (d. h. wie sich Änderungen der Ausgabewerte jedes Berechnungsschritts auf den Verlust auswirken), so dass die Gradienten der Eingaben für den Berechnungsschritt bestimmt werden können (d. h. wie sich Änderungen der Eingabewerte jedes Berechnungsschritts auf den Verlust auswirken werden). Die von jedem Schritt während der Forward Propagation durch die Rendering-Pipeline 105 berechneten Parameter können der Backward-Propagation-Pipeline 260 zur Berechnung der entsprechenden stufenweisen Gradienten bereitgestellt werden.
Nachdem die Antialiasing-Bildgradienten durch die gesamte Backward-Propagation-Pipeline 260 rückwärts propagiert wurden, kann quantifiziert werden, wie sich die Änderung der latenten Variablen auf den Verlust auswirkt, und die latenten Variablen können in die Richtung angepasst werden, die den Verlust verringern sollte. Die sichtbarkeitsbezogenen 3D-ModellGradienten, die während der Rückwärtspropagation berechnet werden, zeigen die Auswirkung an, die das Verschieben der Eckpunktpositionen auf das Antialiasing-Bild aufgrund von Änderungen der fraktionellen Pixelabdeckung hat. Die 3D-Modell-Konstruktionseinheit 200 empfängt die 3D-Modellgradienten und passt das 3D-Modell an, um den Verlust zu verringern.
Wendet man Gleichung (1) auf das differenzierbare Rendering an, können die Geometrie, Projektion und Beleuchtung als parametrische Funktionen betrachtet werden. Der sichtbare Weltpunkt wird von der Geometrie, parametrisiert durch θ_G, und der Projektion, parametrisiert durch θ_C, beeinflusst. In ähnlicher Weise werden die Oberflächenfaktoren durch θ_M und die Lichtquellen durch θ_L parametrisiert. Im einfachsten Fall könnten θ_G und θ_M beispielsweise die Eckpunktkoordinaten eines Dreiecksnetzes mit fester Topologie und eine diffuse Albedo beschreiben, die an den Eckpunkten gespeichert und in das Innere der Dreiecke interpoliert wird. In einer Ausführungsform ist die 3D-Modelldarstellung eine komplexe Parametrisierung, welche von einem Deep-Learning-Modell innerhalb der 3D-Modell-Konstruktionseinheit 200 berechnet und in den differenzierbaren Renderer 115 eingegeben wird. Im Kontext der folgenden Beschreibung umfasst differenzierbares Rendering die Berechnung der Gradienten ∂L(I)/∂{θ_G,θ_M,θ_C,θ_L} einer skalaren Funktion L(I) des gerenderten Bildes Iin Bezug auf die Szenenparameter. Es ist zu beachten, dass dies nicht die Berechnung der (sehr großen) Jacobi-Matrizen [θI / ∂θ_G] usw. erfordert, sondern nur die Fähigkeit, Multiplikation mit Jacobi-Transponierung zu implementieren (Back Propagation), was das Endergebnis durch die Kettenregel ergibt: $[\frac{\partial L (I)}{\partial θ_{G}}] = [\frac{\partial I}{\partial θ_{G}}] [\frac{\partial L}{\partial I}],$
und in ähnlicher Weise für die anderen Parametervektoren.
Zwei Hauptfaktoren machen die Entwicklung effizienter Rendering-Algorithmen zu einer Herausforderung. Erstens ist die Abbildung P(x, y) zwischen den 3D-Modell- oder Weltraumpunkten und den Bildschirm- oder Bildkoordinaten dynamisch: Sie wird durch Änderungen sowohl der Szenengeometrie als auch der 3D-zu-2D-Projektion beeinflusst. Außerdem ist die Abbildung aufgrund von Abdeckungsgrenzen diskontinuierlich. Diese beiden Faktoren sind auch die Hauptschwierigkeiten bei der Berechnung der Gradienten durch die Backward-Propagation-Pipeline 260.
Der differenzierbare Renderer 215 kann 3D-Szenen mit hoher Auflösung rendern, die in Bezug auf geometrische Details, Okklusion und Aussehen komplex sind. In einer Ausführungsform wird das Rendering in Echtzeit durchgeführt und die Stufen in den Pipelines parallelisieren die Verarbeitung sowohl der grafischen Primitive als auch der Pixel. In einer Ausführungsform umfasst der differenzierbare Renderer 215 modulare, konfigurierbare und programmierbare Stufen, um eine einfache Konstruktion potenziell komplexer benutzerdefinierter Rendering-Pipelines zu ermöglichen. In einer Ausführungsform nimmt der differenzierbare Renderer 215 die Eingangsgeometrie und Textur-Maps (z. B. das 3D-Modell) in Form von Tensoren auf, welche es ermöglichen, beide auf frei gewählte Weise zu parametrisieren und die Rendering-Primitive als Bausteine eines komplexen Lernsystems zu nutzen.
Der differenzierbare Renderer 215 führt Deferred Shading aus, indem er zunächst für jedes Pixel die Glieder M(P(x,y)) aus Gleichung (1) berechnet und die Zwischenergebnisse in einem regelmäßigen Bildraumgitter speichert. Das Gitter wird anschließend von einer Schattierungsfunktion verwendet, um ein schattiertes Ausgangsgitter zu erzeugen, welches in den Analytik-Antialias-Filter in Gleichung (1) eingegeben wird. Es wird davon ausgegangen, dass die Schattierung in Bezug auf die Abdeckungseffekte an den Silhouettengrenzen, nicht aber in Bezug auf andere Effekte im Erscheinungsbild, konstant ist.
2B zeigt ein weiteres Blockdiagramm eines anderen beispielhaften Systems zur Wiederherstellung von 3D-Modellen 100, das für die Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist. Die differenzierbare Rendering-Pipeline 205 umfasst eine Eckpunkttransformationseinheit 210, einen Rasterizer 220, eine Interpolationseinheit 230, eine Textur-Lookup-Einheit 240 und eine Analytik-Antialias-Einheit 250. In einer Ausführungsform umfasst die differenzierbare Rendering-Pipeline 205 auch die Backward-Propagation-Pipeline 260. Die Details der Backward-Propagation-Pipeline 260 sind in 2C dargestellt. In einer Ausführungsform sind die differenzierbare Rendering-Pipeline 205 und die Backward-Propagation-Pipeline 260 kombiniert, und die von der Backward-Propagation-Pipeline 260 ausgeführten Operationen werden von einer Kombination aus der Eckpunkttransformationseinheit 210, dem Rasterizer 220, der Interpolationseinheit 230, der Textur-Lookup-Einheit 240 und der Analytik-Antialias-Einheit 250 ausgeführt.
Die 3D-Modell-Konstruktionseinheit 200 passt das 3D-Modell für jede Iteration des differenzierbaren Renderers 215 an. In einer Ausführungsform umfasst die 3D-Modell-Konstruktionseinheit 200 ein „Verformungsnetzwerk“, welches ein Basisnetz und eine Frame-Index-Darstellung des 3D-Modells aufnimmt und die Eckpunktpositionen ausgibt, um ein Antialiasing-Bild für eine Referenz-Kameraposition zu rendern. Das Verformungsnetzwerk ist nicht notwendigerweise ein universelles neuronales Netz, aber es kann effizienter lernen (d. h. es ist empfänglicher für Optimierung) als ein Array von Eckpunktpositionen separat für jedes Bild zu haben. Die 3D-Modell-Kkonstruktionseinheit 200 passt auch die globale Oberflächentextur für jede Iteration des differenzierbaren Renderers 215 an. Wie in 2B gezeigt, umfasst das 3D-Modell, welches an die Eckpunkttransformationseinheit 210 ausgegeben wird, Eckpunkte und Attribute im 3D-Modellraum.
Die Eckpunkttransformationseinheit 210 führt Welt-, Ansichts- und homogene perspektivische Transformationen durch, um transformierte Eckpunkte zu erzeugen, die an den Rasterizer 220 ausgegeben werden. Der Rasterizer 220 führt perspektivische Teilung durch und implementiert dynamisches Mapping zwischen Weltkoordinaten und diskreten Pixelkoordinaten. Hilfskoordinaten pro Pixel können in Form von baryzentrischen Koordinaten und Dreieck-IDs im Vorwärtsdurchlauf durch die Rendering-Pipeline 205 gespeichert werden. Die Verwendung von baryzentrischen Koordinaten und NDC-Tiefen (u, v, z_c/w_c) als Basiskoordinatensystem ermöglicht eine einfache Kopplung von Schattierung und Interpolation sowie die Kombination von Texturgradienten mit Geometriegradienten im Rückwärtsdurchlauf durch die Backward-Propagation-Pipeline 260.
In einer Ausführungsform verarbeitet der Rasterizer 220 Dreiecke mit Eckpunktpositionen, welche als ein Array homogener Clip-Space-Koordinaten (x_c, y_c, z_c, w_c) gegeben sind. Die Backward-Propagation-Pipeline 260 berechnet dann den Gradienten ∂L/∂{x_c, y_c, z_c, w_c} des Verlustes L in Bezug auf die Clip-Space-Positionen. Die Differenzierung in Bezug auf alle übergeordneten Parametrisierungen kann außerhalb des Systems zur Wiederherstellung von 3D-Modellen 100 durchgeführt werden.
Beim Vorwärtsdurchlauf durch die Rendering-Pipeline 205 gibt der Rasterizer 220 ein 2D-Mustergitter aus, welches mit dem gerenderten Bild verknüpft ist, wobei jede Position ein Tupel (ID, u, v, z_c/w_c) speichert, wobei ID das Dreieck identifiziert, das das Muster abdeckt, (u, v) baryzentrische Koordinaten sind, welche die relative Position entlang des Dreiecks angeben, und z/w der Tiefe in normalisierten Gerätekoordinaten (NDC) entspricht. In einer Ausführungsform ist eine spezielle ID für leere Pixel reserviert. Baryzentrische Koordinaten dienen als praktische Basisdomäne für Interpolations- und Textur-Mapping-Berechnungen für nachgelagerte Stufen in der Rendering-Pipeline 205. In einer Ausführungsform wird die NDC-Tiefe nur von der nachfolgenden Analytik-Antialias-Einheit 250 verwendet, und es werden keine Gradienten weitergegeben. In einer Ausführungsform gibt der Rasterizer 220 einen sekundären Ausgabepuffer mit dem 2x2-Jacobi-Matrix der baryzentrischen Koordinaten in Bezug auf die Bildkoordinaten ∂{u,v}/∂{x,y} für jedes Pixel aus. Der sekundäre Ausgabepuffer kann von der Interpolationseinheit 230 zur Berechnung von Bildraumableitungen von Texturkoordinaten verwendet werden, die wiederum von der Textur-Lookup-Einheit 240 zur Bestimmung der Texturfußabdrücke für gefilterte Textur-Lookups verwendet werden können.
Innerhalb des Rasterizers 220 kann die Rasterung über OpenGL erfolgen, wobei eine Hardware-Grafikpipeline genutzt wird. Durch die Verwendung der Hardware-Grafikpipeline wird sichergestellt, dass die Rasterung genau ist und es zum Beispiel keine Sichtbarkeitsverluste aufgrund von Präzisionsproblemen gibt. Außerdem sorgt die Verwendung der Hardware-Grafikpipeline automatisch für ein korrektes Clipping des Viewing-Frustums (auch Sichtvolumen oder Pyramidenstumpf genannt). Die 2x2-Pixel-Jakobi-Matrizen zwischen baryzentrischen Koordinaten und Bildkoordinaten können vom OpenGL-Fragment-Shader durch finite Differenzen in einem 2x2-Pixel-Quad berechnet werden. Alternativ können die 2x2-Jakobi-Matrizen pro Pixel auch analytisch für jedes Pixel berechnet werden.
Die Interpolationseinheit 230 dehnt die Daten pro Eckpunkt (d. h. die Eckpunktattribute) auf den Pixel- oder Bildraum aus und erzeugt interpolierte Attribute. Unter Verwendung der vom Rasterizer 220 berechneten baryzentrischen Koordinaten führt die Interpolationseinheit 230 die Abbildung in Vorwärtsrichtung durch, und die baryzentrischen Koordinaten können auch von einer entsprechenden Interpolationsoperation in der Backward-Propagation-Pipeline 260 verwendet werden, um vom Bildraum auf den NDC-Raum abzubilden.
Attributinterpolation ist ein Standardbestandteil der Grafikpipeline. Konkret beinhaltet sie die Berechnung gewichteter Summen von Eckpunktattributen, wobei die Gewichte durch die baryzentrischen Koordinaten gegeben sind, wodurch eine Zuordnung zwischen den Pixeln und den Attributen hergestellt wird. Im Allgemeinen können Eckpunktattribute für beliebige Zwecke genutzt werden. Eine typische Verwendung ist jedoch die Bereitstellung von 2D-Koordinaten für Textur-Mapping. Zusätzlich zu ihrer allgemeinen Funktion bietet die Interpolationseinheit 230 spezielle Unterstützung für die Berechnung von Bildraumableitungen von Texturkoordinaten im Vorwärtsdurchlauf, die später von Textur-Lookup-Einheit 240 bei der Bestimmung von MIP-Map-Filterfußabdrücken verwendet werden können.
Die Interpolationseinheit 230 empfängt einen Vektor von Attributen A_i, die dem i-ten Eckpunkt zugeordnet sind, wobei die Attributindizes des im Pixel (x, y) sichtbaren Dreiecks i_0,1,2 sind und die vom Rasterizer 220 erzeugten baryzentrischen Koordinaten u = u(x, y) und v = v(x, y) sind. Der interpolierte Vektor A ist definiert als $A = u A_{i_{0}} + v A_{i_{1}} + (1 - u - v) A_{i_{2}} .$
Angesichts der Ausgaben des Rasterizers (Dreiecks-IDs pro Pixel und baryzentrische Koordinaten) ist die Realisierung des Vorwärtsdurchlaufs unkompliziert. Die Bildraumableitungen für Attribute, die Ableitungen erfordern, werden unter Verwendung der vom Rasterizer ausgegebenen baryzentrischen Koordinaten - Jakobi-Matrizen berechnet, und zwar mit $\frac{\partial A}{\partial {x, y}} = [\frac{\partial {u, v}}{\partial {x, y}}] [\frac{\partial A}{\partial {u, v}}],$
wobei die letzte Jakobi-Matrix einfach aus Gleichung (2) abzuleiten ist.
Die Textur-Lookup-Einheit 240 empfängt die interpolierten Texturkoordinatenattribute und Bildraumableitungen der Texturkoordinatenattribute und liest Texel aus der globalen Oberflächentextur, welche in der 3D-Modell-Konstruktionseinheit 200 gespeichert ist. Die Texel und die Bildraumableitungen werden von der Textur-Lookup-Einheit 240 verwendet, um schattierte Pixel zu erzeugen. Gradienten können durch die Backward-Propagation-Pipeline 260 sowohl über die eingegebenen Texturkoordinaten als auch über den Inhalt der (MIP-mapped) Textur-Map korrekt rückwärts propagiert werden.
Wenn die Textur-Lookup-Einheit 240 Textur-Mapping unter Verwendung von trilinearen MIP-Mapped-Texturabfragen durchführt, wird eine (kontinuierliche) MIP-Map-Pyramidenebene (d. h. eine Detailstufe, LOD) auf der Grundlage der eingehenden Bildraumableitungen der Texturkoordinaten ausgewählt. Dann wird eine trilineare Interpolation unter Verwendung der acht nächstgelegenen Texel aus dem Paar geeigneter MIP-Pyramidenebenen durchgeführt. Die MIP-Ebene kann auf der Grundlage der Texturraumlänge der Hauptachse des durch die Ableitungen definierten Musterfußabdrucks ausgewählt werden. In einer Ausführungsform wird die MIP-Ebene von der Interpolationseinheit 230 als Teil des Interpolationsvorgangs berechnet, wenn die erforderlichen Daten ohne weiteres verfügbar sind. In einer Ausführungsform kann die Textur-Lookup-Einheit 240 konfiguriert sein, Textur-Mapping unter Verwendung bilinearer, punktabgetasteter oder anderer Arten von MIP-abgebildeten oder nicht-MIP-abgebildeten Texturabrufen durchführt.
Ein Bild, welches die von der Textur-Lookup-Einheit 240 ausgegebenen schattierten Pixel enthält, weist kein Aliasing innerhalb der Oberfläche (innerhalb der gerenderten Geometrie) auf. Die punktabgetastete Sichtbarkeit verursacht jedoch Aliasing an Sichtbarkeitsdiskontinuitäten und, was noch wichtiger ist, sie kann keine sichtbarkeitsbezogenen Gradienten zur Anpassung der Eckpunktpositionen des 3D-Modells erzeugen. Die Analytik-Antialias-Einheit 250 wandelt die Diskontinuitäten in glatte Veränderungen um, aus denen die Gradienten berechnet werden können. Es ist zu beachten, dass Antialias erst nach der Schattierung durchgeführt werden kann und daher als separater Schritt der Rendering-Pipeline 205 implementiert werden muss und nicht als Teil der Rasterung durchzuführen ist.
Die Analytik-Antialias-Einheit 250 erhält die schattierten Pixel, die sich aus Deferred Shading, den transformierten Eckpunkten, den Dreieck-IDs und der Tiefe (z_c/w_c) ergeben, und gibt ein antialiasiertes Bild aus. Die Analytik-Antialias-Einheit 250 erkennt die Sichtbarkeitsdiskontinuitäten und die damit verbundenen Eckpunktpositionen, welche zur Berechnung von Gradienten erforderlich sind. In einer Ausführungsform werden potenzielle Sichtbarkeitsdiskontinuitäten erkannt, indem alle benachbarten horizontalen und vertikalen Pixelpaare mit nicht übereinstimmenden Dreieck-IDs gefunden werden und, wie zuvor in Verbindung mit den 1C und 1D beschrieben, eine Überblendungsgewichtung berechnet wird, um Pixelfarben für Silhouettenkanten anzupassen, welche sich zwischen den Zentren der erkannten benachbarten horizontalen und vertikalen Pixelpaare kreuzen. Zur Vorbereitung der Gradientenberechnung während der Backward Propagation können die Ergebnisse der Diskontinuitätsanalyse, welche von der Analytik-Antialias-Einheit 250 während des Vorwärtsdurchlaufs durchgeführt wurde, gespeichert werden, um eine Wiederholung der Berechnungen während des Rückwärtsdurchlaufs zu vermeiden.
2C zeigt ein weiteres Blockdiagramm eines beispielhaften Systems zur Wiederherstellung von 3D-Modellen 100, welches zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist. Die Details der Backward-Propagation-Pipeline 260 sind dargestellt. Eine oder mehrere der Stufen in der Backward-Propagation-Pipeline 260 können in die entsprechende Stufe der Rendering-Pipeline 205 integriert werden. Die Stufen 250-B, 240-B, 230-B, 220-B und 210-B in der Backward-Propagation-Pipeline 260 entsprechen der Analytik-Antialias-Einheit 250, der Textur-Lookup-Einheit 240, der Interpolationseinheit 230, dem Rasterizer 220 bzw. der Eckpunkttransformationseinheit 210.
Die Stufe 250-B berechnet Gradienten unter Verwendung der gespeicherten Ergebnisse der Diskontinuitätsanalyse für jedes Pixelpaar, das von der Analytik-Antialias Antialias-Einheit 250 im Vorwärtsdurchgang analytisch antialiasiert wurde. Die Antialias-Bildgradienten für die Pixel werden in Eckpunkt-Positionsgradienten übertragen, indem bestimmt wird, wie beide Eckpunktpositionen für die Silhouettenkanten die Überblendungsgewichte beeinflussen. Die von der Stufe 250-B für das aliasierte Bild berechneten Verlustgradienten in Bezug auf schattierte Pixel werden als Gradienten für schattierte Pixel an die Stufe 240-B ausgegeben. Die Verlustgradienten in Bezug auf die Eckpunktposition werden von der Stufe 250-B an die Stufe 210-B ausgegeben, um vom Clipraum in den 3D-Modellraum transformiert zu werden.
Die Stufe 240-B berechnet die Verlustgradienten in Bezug auf die Attribute A und in Bezug auf Texel. Sobald eine MIP-Map-Ebene ausgewählt wurde, gleichen die Vorwärts- und Rückwärtsdurchläufe der Attributinterpolation: Die acht nächstgelegenen Texel nehmen den Platz der drei Dreiecksecken ein, und die drei Sub-Texel-Koordinaten, die die genaue Position innerhalb des Acht-Texel-Ensembles bestimmen, treten an die Stelle der baryzentrischen Koordinaten. Die MIP-Map-Texturierung unterscheidet sich von der Attributinterpolation durch ihren mehrskaligen Charakter: Gradienten werden im Rückwärtsdurchlauf auf verschiedenen Ebenen der MIP-Map-Pyramide akkumuliert. Da alle MIP-Map-Ebenen der MIP-Map-Pyramide während der Konstruktion im Vorwärtsdurchlauf aus der feinsten Ebene der Textur gewonnen werden, muss der Rückwärtsdurchlauf mit der Umkehrung des Konstruktionsvorgangs und der Abflachung der Gradientenpyramide abgeschlossen werden, damit der Gradient auf der feinsten Ebene dicht spezifiziert ist. Glücklicherweise lässt sich dies leicht umsetzen, indem man mit der gröbsten Stufe beginnt, das Ergebnis rekursiv nach oben abtastet und Gradienten der nächsten Stufe hinzufügt, genau wie beim Zusammenlegen einer Laplacian Pyramide. Die Stufe 240-B liefert die Texel-Gradienten an die 3D-Modell-Konstruktionseinheit 200. Die Texel-Gradienten werden verwendet, um die Texel für die globale Oberflächen-Textur-Map des 3D-Modells anzupassen.
Die Stufe 230-B ist mit der Interpolationseinheit 230 verbunden und empfängt Verlustgradienten ∂L/∂A in Bezug auf die interpolierten Attribute. Die Stufe 230-B liefert die Attributgradienten an die 3D-Modell-Konstruktionseinheit 200. Die Attributgradienten können verwendet werden, um die Texturkoordinaten für die globale Oberflächen-Textur-Map des 3D-Modells anzupassen. In einer Ausführungsform werden die Gradienten in Bezug auf den Attribut-Tensor durch eine Streuungsaddition in den Tensor berechnet, wobei die einfachen Jakobi ∂A/∂{A_i0,_i1,_i2} = {u, v, 1- u - v} auf die Eingabegradienten pro Pixel angewendet werden. Durch einfache Differenzierung sind die von der Stufe 230-B berechneten Gradienten in Bezug auf die eingegebenen baryzentrischen Koordinaten gegeben durch $[\frac{\partial L}{\partial u}] = {[A_{i_{0}} - A_{i_{2}}]}^{T} [\frac{\partial L}{\partial A}], [\frac{\partial L}{\partial A}] = {[A_{i_{1}} - A_{i_{2}}]}^{T} [\frac{\partial L}{\partial A}] .$
Der Rückwärtsdurchlauf des Rasterizers empfängt für jedes Pixel den Gradienten $\frac{\partial L}{\partial {u, v}}$
mit Bezug auf die baryzentrischen Koordinaten, ausgegeben vom Rasterizer, und berechnet die Gradienten ∂L/∂{x_c, y_c, z_c, w_c} für jeden Eingabe-Eckpunkt. Das perspektivische Mapping zwischen baryzentrischen Koordinaten und Clip-Space-Positionen lässt sich leicht analytisch differenzieren, und die erforderliche Ausgabe wird von der Stufe 220-B berechnet durch $[\frac{\partial L}{\partial {x_{c,} y_{c}, z_{c}, w_{c}}}] = [\frac{\partial L}{\partial {u, v}}] [\frac{\partial {u, v}}{{x_{c}, y_{c}, z_{c}, w_{c}}}] .$
Gleichung (4) kann als dichte Operation über Ausgabepixel implementiert sein, wobei eine Streuungs-Additionsoperation verwendet wird, um die Gradienten von den Pixeln zu den richtigen Eckpunkten auf der Grundlage der Dreieck-IDs zu akkumulieren.
Die Stufe 210-B ist mit der Eckpunkttransformationseinheit 210 verknüpft und transformiert die Clip-Raum-Gradienten für das 3D-Modell in den 3D-Modellraum, um 3D-Modell-Gradienten für die 3D-Modell-Konstruktionseinheit 100 bereitzustellen. In einer Ausführungsform stellt die 3D-Modell-Konstruktionseinheit 100 die 3D-Modellgeometrie direkt mit Hilfe von Eckpunktpositionen dar, und die Eckpunktpositionen werden auf der Grundlage der 3D-Modellgradienten angepasst. In einer anderen Ausführungsform stellt die 3D-Modell-Konstruktionseinheit 100 die 3D-Modellgeometrie als einen Satz von Gewichten für ein Deformationsnetz dar, und die Gewichte werden auf der Grundlage der 3D-Modellgradienten angepasst. Das Deformationsnetzwerk wendet den Satz von Gewichtungen auf ein Grundnetz an, um das 3D-Modell zu erzeugen, das für jede Kameraposition gerendert werden kann.
In einer Ausführungsform ist das System zur Wiederherstellung von 3D-Modellen 100 eingerichtet, ein 2D-Modell zu konstruieren, wobei das durch die Ausgangsgeometrie definierte 3D-Modell durch ein 2D-Modell ersetzt wird, welches durch polygonale 2D-Geometrie im 2D-Modellraum definiert ist. Wenn ein 2D-Modell konstruiert wird, können die tiefenbezogenen Berechnungen weggelassen werden. In einer Ausführungsform stellt das wiederhergestellte 2D-Modell eine Schrift oder ein 2D-Clipart dar, welches durch ein 2D-Netz oder gekrümmte Primitive definiert ist.
3 zeigt ein Flussdiagramm eines Verfahrens 300 zur Wiederherstellung eines 3D-Modells, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Erfindung geeignet ist. Jeder Block des hier beschriebenen Verfahrens 300 umfasst einen Rechenprozess, der unter Verwendung einer beliebigen Kombination von Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. Das Verfahren kann auch in Form computerverwendbarer Befehle, die auf Computerspeichermedien gespeichert sind, verkörpert sein. Das Verfahren kann, um nur einige zu nennen, durch eine eigenständige Anwendung, einen Dienst oder einen gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder ein Plug-in für ein anderes Produkt bereitgestellt werden. Darüber hinaus wird das Verfahren 300 beispielhaft in Bezug auf das System zur Wiederherstellung von 3D-Modellen 100 der 1A, 1B, 2A, 2B und 2C beschrieben. Dieses Verfahren kann jedoch zusätzlich oder alternativ von einem beliebigen System oder einer beliebigen Kombination von Systemen ausgeführt werden, einschließlich aber nicht beschränkt auf die hier beschriebenen Systeme. Darüber hinaus werden Fachleute wissen, dass jedes System, das die Methode 300 durchführt, in den Anwendungsbereich und Geist der Ausführungsformen der vorliegenden Erfindung fällt.
In Schritt 305 wird ein Bild des 3D-Modells, welches durch die Ausgangsgeometrie definiert ist, gerendert, wobei eine von einer Rendering-Pipeline durchgeführte Antialiasing-Operation Daten verarbeitet, die mit der Geometrie verknüpft sind, um das Bild zu Netz. In einer Ausführungsform wird die Ausgangsgeometrie durch Eckpunktstellen oder -positionen definiert. In einer anderen Ausführungsform wird die Ausgangsgeometrie durch Gewichtungen definiert, die auf ein Basisnetz angewendet werden. Die Gewichtungen können von einem Verformungsnetzwerk auf ein Basisnetz angewendet werden, um das 3D-Modell zu erzeugen.
In einer Ausführungsform ist die Antialiasing-Operation eine Analytik-Antialiasing-Operation, auf der Grundlage der mit der Geometrie verknüpften Daten folgende Operationen umfassend: Bestimmung, dass eine Silhouettenkante ein Paar benachbarter Pixel schneidet, Berechnung einer Überblendungsgewichtung zwischen den benachbarten Pixeln umfasst und Anpassung der Farben der benachbarten Pixel entsprechend der Überblendungsgewichtung. In einer Ausführungsform wird die Überblendungsgewichtung auf der Grundlage eines Schnittpunkts zwischen den benachbarten Pixeln berechnet. In einer Ausführungsform wird eine komplexere Berechnung durchgeführt, um den Überblendungsfaktor zu bestimmen, wobei beispielsweise die Ausrichtung, Länge und Position der Kantenendpunkte berücksichtigt werden. In einer Ausführungsform umfasst das Bestimmen das Identifizieren der Silhouettenkante zwischen einer ersten gerenderten Geometrie, welche mit einer ersten Kennung verknüpft ist, und einer zweiten gerenderten Geometrie, welch mit einer zweiten Kennung verknüpft ist. In einer Ausführungsform nähert die Antialiasing-Operation ein Pixelintegral auf der Grundlage einer Position einer Silhouettenkante innerhalb des Pixels an.
In Schritt 310 werden auf der Grundlage des Bildes und eines Referenzbildes Pixeldifferenzen berechnet. In einer Ausführungsform werden die Pixeldifferenzen als mittlere quadratische Pro-Pixel-Differenzen durch eine Verlustfunktion berechnet. In einer Ausführungsform werden die Pixeldifferenzen zwischen hochdimensionalen Einbettungen der Bilder berechnet, zum Beispiel unter Verwendung vortrainierter neuronaler Netze.
In Schritt 315 werden die Pixeldifferenzen durch die Antialiasing-Operation der Rendering-Pipeline rückwärts propagiert, um Geometrieänderungen zu berechnen, die einer Reduzierung der Pixeldifferenzen entsprechen. In einer Ausführungsform werden die Pixeldifferenzen verwendet, um die Gradienten pro Pixel des Aliasing-Bildes zu berechnen. In einer Ausführungsform umfassen die Geometrieänderungen Gradienten von Eckpunktpositionen. In einer Ausführungsform umfasst die Weitergabe der Pixeldifferenzen ferner die Erzeugung einer Oberflächentextur, die dem 3D-Modell entspricht. Die Oberflächentextur stellt Beleuchtungs- und/oder Materialeigenschaften des 3D-Modells dar.
In Schritt 320 wird die Ausgangsgeometrie auf der Grundlage der Geometrieänderungen angepasst, um eine modifizierte Geometrie zu erzeugen, welche das 3D-Modell definiert. Die Schritte 305, 310, 315 und 320 können für mindestens ein weiteres Referenzbild wiederholt werden. In einer Ausführungsform sind das Referenzbild und das mindestens eine zusätzliche Referenzbild jeweils mit einer anderen Kameraposition verknüpft. In einer Ausführungsform wird das Bild des 3D-Modells in Abhängigkeit von der Kameraposition gerendert.
Das primäre Ziel des Systems zur Wiederherstellung von 3D-Modellen 100 besteht darin, ein genaues 3D-Modell eines Objekts zu konstruieren. Obwohl das System zur Wiederherstellung von 3D-Modellen 100 auch Bilder des Objekts mit Antialiasing rendem kann, sollte die Erzeugung hochwertiger Bilder als sekundäres Ziel betrachtet werden. Der differenzierbare Renderer 215 stellt einen Rahmen für die programmierbare Schattierung und Geometrieverarbeitung bereit, indem er ein hohes Maß an Benutzerkontrolle und die Möglichkeit bietet, hochauflösende Bilder von Szenen zu rendern, die aus Millionen grafischer Primitive bestehen. Der differenzierbare Renderer 215 bietet benutzerdefinierte, leistungsstarke Implementierungen für: Rasterung, Attributinterpolation, Texturfilterung sowie Antialiasing- und Differenzierungsoperationen zur Erstellung eines genauen 3D-Modells.
Parallelverarbeitungsarchitektur
4 zeigt eine Parallelverarbeitungseinheit (PPU) 400 gemäß einer Ausführungsform. Die PPU 400 kann zur Implementierung des Systems zur Wiederherstellung von 3D-Modellen 100 verwendet werden. Die PPU 400 kann verwendet werden, um eine oder mehrere der folgenden Elemente innerhalb des Systems zur Wiederherstellung von 3D-Modellen 100 zu implementieren: 3D-Modell-Konstruktionseinheit 200, differenzierbarer Renderer 215, Rendering-Pipeline 205, Backward-Propagation-Pipeline 260 und Bildraumverlust-Einheit 245. In einer Ausführungsform kann ein Prozessor wie die PPU 400 ausgelegt sein, ein neuronales Netzmodell zu implementieren. Das neuronale Netzmodell kann als Softwarebefehle implementiert sein, welche vom Prozessor ausgeführt werden, oder in anderen Ausführungsformen kann der Prozessor eine Matrix von Hardwareelementen enthalten, welche eingerichtet sind, einen Satz von Eingaben (z. B. elektrische Signale, die Werte darstellen) zu verarbeiten, um einen Satz von Ausgaben zu erzeugen, die Aktivierungen des neuronalen Netzmodells darstellen können. In anderen Ausführungsformen kann das neuronale Netzmodell als Kombination aus Softwarebefehlen und Verarbeitung, ausgeführt von einer Matrix von Hardwareelementen, implementiert sein. Implementierung des neuronalen Netzmodells kann Bestimmung eines Satzes von Parametern für das neuronale Netzmodell beinhalten, beispielsweise durch überwachtes oder unüberwachtes Lernen des neuronalen Netzmodells sowie, oder alternativ, Durchführung von Schlussfolgerungen unter Verwendung des Satzes von Parametern, um neue Sätze von Eingaben zu verarbeiten.
In einer Ausführungsform ist die PPU 400 ein Multi-Thread-Prozessor, welcher auf einer oder mehreren integrierten Schaltungseinheiten implementiert ist. Die PPU 400 ist eine Architektur zur Verbergung von Latenzzeiten, welche für die parallele Verarbeitung vieler Threads ausgelegt ist. Ein Thread (z. B. ein Ausführungsstrang) ist eine Instanziierung eines Befehlssatzes, der konfiguriert ist, von der PPU 400 ausgeführt zu werden. In einer Ausführungsform ist die PPU 400 eine Grafikverarbeitungseinheit (GPU), die ausgelegt ist, eine Grafik-Rendering-Pipeline für die Verarbeitung dreidimensionaler (3D) Grafikdaten zu implementieren, um zweidimensionale (2D) Bilddaten für die Anzeige auf einem Anzeigegerät zu erzeugen. In anderen Ausführungsformen kann die PPU 400 für die Durchführung von Universalberechnungen verwendet werden. Obwohl ein beispielhafter Parallelprozessor hier zu Veranschaulichungszwecken bereitgestellt wird, wird ausdrücklich darauf hingewiesen, dass ein solcher Prozessor nur zum Zwecke der Veranschaulichung bereitgestellt wird und dass jeder beliebige Prozessor als Ergänzung und/oder Ersatz desselben verwendet werden kann.
Eine oder mehrere PPUs 400 können ausgelegt sein, Tausende von High Performance Computing (HPC)-, Rechenzentrums- und Machine-Learning-Anwendungen zu beschleunigen. Die PPU 400 kann ausgelegt sein, zahlreiche Deep-Learning-Systeme und -Anwendungen für autonome Fahrzeuge, Simulation, Computergrafik wie Strahl- oder Pfadverfolgung, Deep-Learning-, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalyse, molekulare Simulationen, Arzneimittelentdeckung, Krankheitsdiagnosen, Wettervorhersagen, Big-Data-Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung, personalisierte Benutzerempfehlungen und dergleichen zu beschleunigen.
Wie in 4 gezeigt, umfasst die PPU 400 eine Eingabe-/Ausgabeeinheit (E/A-Einheit) 405, eine Front-End-Einheit 415, eine Scheduler-Einheit 320, eine Arbeitsverteilungseinheit 425, einen Hub 430, eine Crossbar (XBar) 370, einen oder mehrere Allgemeine Verarbeitungscluster (GPCs) 450 und eine oder mehrere Speicherpartitionseinheiten 480. Die PPU 400 kann mit einem Host-Prozessor oder anderen PPUs 400 über eine oder mehrere Hochgeschwindigkeit-Kommunikationsverbindungen NVLink 410 verbunden sein. Die PPU 400 kann mit einem Host-Prozessor oder anderen Peripheriegeräten über eine Verschaltung 302 verbunden sein. Die PPU 400 kann auch mit einem lokalen Speicher 404 verbunden sein, der eine Reihe von Speichergeräten umfasst. In einer Ausführungsform kann der lokale Speicher eine Reihe dynamischer Direktzugriffsspeicher(DRAM)-Bausteine umfassen. Die DRAM-Bausteine können als High-Bandwidth Memory(HBM)-Subsystem konfiguriert sein, wobei mehrere DRAM-Chips in jedem Baustein gestapelt sind.
Die Verbindung NVLink 410 ermöglicht Skalieren von Systemen und umfasst eine oder mehrere PPUs 400 in Kombination mit einer oder mehreren CPUs, unterstützt Cache-Kohärenz zwischen den PPUs 400 und den CPUs sowie CPU-Mastering. Daten und/oder Befehle können über die Verbindung NVLink 410 durch den Hub 430 zu/von anderen Einheiten der PPU 400 übertragen werden, wie beispielsweise einem oder mehreren Kopiermodulen, einem Video-Encoder, einem Video-Decoder, einer Power-Management-Einheit usw. (nicht explizit dargestellt). Die Verbindung NVLink 410 wird mit Bezug auf 5B näher beschrieben.
Die E/A-Einheit 405 ist konfiguriert, Kommunikationen (z. B. Befehle, Daten usw.) von einem Host-Prozessor (nicht gezeigt) über die Verschaltung 402 zu senden und zu empfangen. Die E/A-Einheit 405 kann mit dem Host-Prozessor direkt über die Verschaltung 402 oder über ein oder mehrere Zwischengeräte, wie zum Beispiel eine Speicherbrücke, kommunizieren. In einer Ausführungsform kann die E/A-Einheit 405 mit einem oder mehreren anderen Prozessoren, wie einer oder mehreren PPUs 400, über die Verschaltung 402 kommunizieren. In einer Ausführungsform implementiert die E/A-Einheit 405 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus und die Verschaltung 402 ist ein PCIe-Bus. In alternativen Ausführungsformen kann die E/A-Einheit 405 andere Arten von bekannten Schnittstellen für die Kommunikation mit externen Geräten implementieren.
Die E/A-Einheit 405 dekodiert Pakete, welche über die Verschaltung 402 empfangen werden. In einer Ausführungsform stellen die Pakete Befehle dar, die konfiguriert sind, die PPU 400 zur Ausführung verschiedener Operationen zu veranlassen. Die E/A-Einheit 405 überträgt die dekodierten Befehle je nach Vorgabe der Befehle an verschiedene andere Einheiten der PPU 400. Einige Befehle können zum Beispiel an die Front-End-Einheit 415 übertragen werden. Andere Befehle können an den Hub 430 oder andere Einheiten der PPU 400 übertragen werden, wie beispielsweise ein oder mehrere Kopiermodule, einen Video-Encoder, einen Video-Decoder, eine Power-Management-Einheit usw. (nicht explizit dargestellt). Anders ausgedrückt ist die E/A-Einheit 405 konfiguriert, die Kommunikation zwischen und unter den verschiedenen logischen Einheiten der PPU 400 zu routen.
In einer Ausführungsform kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, welcher der PPU 400 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann aus mehreren Befehlen und Daten bestehen, die von diesen Befehlen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 400 zugreifen (z. B. lesen/schreiben) können. Beispielsweise kann die E/A-Einheit 405 ausgelegt sein, über Speicheranforderungen, welche über die Verschaltung 402 übertragen werden, auf den Puffer in einem mit der Verschaltung 402 verbundenen Systemspeicher zuzugreifen. In einer Ausführungsform schreibt der Host-Prozessor den Befehlsstrom in den Puffer und überträgt dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 400. Die Front-End-Einheit 415 empfängt Zeiger auf einen oder mehrere Befehlsströmen. Die Front-End-Einheit 415 verwaltet den einen oder die mehreren Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 400 weiter.
Die Front-End-Einheit 415 ist mit einer Scheduler-Einheit 420 gekoppelt, welche die verschiedenen GPCs 450 konfiguriert, die durch den einen oder die mehreren Ströme definierten Tasks zu verarbeiten. Die Scheduler-Einheit 420 ist eingerichtet, Statusinformationen in Bezug auf die verschiedenen, von der Scheduler-Einheit 420 verwalteten Tasks nachzuverfolgen. Der Status kann anzeigen, welchem GPC 450 ein Task zugewiesen ist, ob der Task aktiv oder inaktiv ist, eine mit dem Task verbundene Prioritätsstufe und so weiter. Die Scheduler-Einheit 420 verwaltet die Ausführung einer Vielzahl von Tasks auf dem einen oder den mehreren GPCs 450.
Die Scheduler-Einheit 420 ist mit einer Arbeitsverteilungseinheit 425 gekoppelt, welche ausgelegt ist, Tasks zur Ausführung auf die GPCs 450 zu versenden. Die Arbeitsverteilungseinheit 425 kann eine Reihe geplanter Tasks, welche von der Scheduler-Einheit 420 empfangen wurden, nachverfolgen. In einer Ausführungsform verwaltet die Arbeitsverteilungseinheit 425 einen Pool ausstehender Tasks und einen Pool aktiver Tasks für jeden der GPCs 450. Wenn ein GPC 450 die Ausführung eines Tasks beendet, wird dieser Task aus dem Pool der aktiven Tasks für den GPC 450 entfernt und einer der anderen Tasks aus dem Pool der anstehenden Tasks wird ausgewählt und für die Ausführung auf dem GPC 450 eingeplant. Wenn ein aktiver Task auf dem GPC 450 inaktiv war, zum Beispiel während des Wartens auf die Auflösung einer Datenabhängigkeit, dann kann der aktive Task aus dem GPC 450 entfernt und in den Pool der ausstehenden Tasks zurückgeführt werden, während ein anderer Task aus dem Pool der ausstehenden Tasks ausgewählt und zur Ausführung auf dem GPC 450 eingeplant wird.
In einer Ausführungsform führt ein Host-Prozessor einen Treiberkern aus, welcher eine Anwendungsprogrammierschnittstelle (API) implementiert, welche es einer oder mehreren auf dem Host-Prozessor ausgeführten Anwendungen ermöglicht, Operationen zur Ausführung auf der PPU 400 einzuplanen. In einer Ausführungsform werden mehrere Rechenanwendungen gleichzeitig von der PPU 400 ausgeführt und die PPU 400 stellt Isolierung, Dienstgüte (QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen bereit. Eine Anwendung kann Befehle (z. B. API-Aufrufe) erzeugen, die den Treiberkern veranlassen, eine oder mehrere Tasks zur Ausführung durch die PPU 400 zu generieren. Der Treiberkern gibt Tasks an einen oder mehrere Ströme aus, die von der PPU 400 verarbeitet werden. Jeder Task kann eine oder mehrere Gruppen zusammenhängender Threads umfassen, welche hier als Warp bezeichnet werden. In einer Ausführungsform umfasst ein Warp 32 verbundene Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, welche Befehle zur Ausführung des Tasks enthalten und Daten über einen gemeinsamen Speicher austauschen können. Die Tasks können einer oder mehreren Verarbeitungseinheiten innerhalb des GPC 450 zugewiesen werden und Befehle werden zur Ausführung von mindestens einem Warp geplant.
Die Arbeitsverteilungseinheit 425 kommuniziert mit dem einen oder den mehreren GPCs 450 über die XBar 470. Die XBar 470 ist ein Verbindungsnetzwerk, welches viele der Einheiten der PPU 400 mit anderen Einheiten der PPU 400 koppelt. Beispielsweise kann die XBar 470 konfiguriert sein, die Arbeitsverteilungseinheit 425 mit einem bestimmten GPC 450 zu koppeln. Obwohl nicht explizit dargestellt, können auch eine oder mehrere andere Einheiten der PPU 400 über den Hub 430 mit der XBar 470 verbunden sein.
Die Tasks werden von der Scheduler-Einheit 420 verwaltet und von der Arbeitsverteilungseinheit 425 an einen GPC 450 versendet. Der GPC 450 ist konfiguriert, den Task zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Tasks innerhalb des GPC 450 genutzt, über die XBar 470 an einen anderen GPC 450 weitergeleitet oder im Speicher 404 gespeichert werden. Die Ergebnisse können in den Speicher 404 über die Speicherpartitionseinheiten 480 geschrieben werden, welche eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 404 realisieren. Die Ergebnisse können über die Verbindung NVLink 410 an eine andere PPU 400 oder CPU übertragen werden. In einer Ausführungsform enthält die PPU 400 eine Anzahl U von Speicherpartitionseinheiten 480, die der Anzahl der separaten und unterschiedlichen Speichereinrichtungen des mit der PPU 400 gekoppelten Speichers 404 entspricht. Jeder GPC 450 kann eine Speicherverwaltungseinheit enthalten, um Übersetzung virtueller Adressen in physische Adressen, Speicherschutz und Arbitrierung von Speicheranforderungen bereitzustellen. In einer Ausführungsform stellt die Speicherverwaltungseinheit einen oder mehrere Übersetzungs-Lookaside-Puffer (TLBs) zur Verfügung, um die Übersetzung virtueller Adressen in physische Adressen im Speicher 404 durchzuführen.
In einer Ausführungsform umfasst die Speicherpartitionseinheit 480 eine Rasteroperations(ROP)-Einheit, einen Level-2(L2)-Cache und eine Speicherschnittstelle, die mit dem Speicher 404 gekoppelt ist. Die Speicherschnittstelle kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder dergleichen für die Hochgeschwindigkeitsdatenübertragung implementieren. Die PPU 400 kann mit bis zu Y Speichervorrichtungen verbunden sein, wie zum Beispiel Speicherstapel mit hoher Bandbreite oder Grafikspeicher mit doppelter Datenrate, Version 5, synchronem dynamischem Direktzugriffsspeicher oder anderen Arten dauerhafter Speicherung. In einer Ausführungsform implementiert die Speicherschnittstelle eine HBM2-Speicherschnittstelle und Y ist gleich die Hälfte von U. In einer Ausführungsform befinden sich die HBM2-Speicherstapel auf demselben physischen Paket wie die PPU 400, womit im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen erhebliche Energie- und Flächeneinsparungen gegeben sind. In einer Ausführungsform umfasst jeder HBM2-Stapel vier Speicherchips und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit umfasst.
In einer Ausführungsform unterstützt der Speicher 404 einen Fehlerkorrekturcode (ECC) mit Ein-Fehler-Korrektur (Single-Error Correcting) und Zwei-Fehler-Erkennung (Double-Error Detecting) (SECDED) zum Schutz der Daten. ECC bietet eine höhere Zuverlässigkeit für Datenverarbeitungsanwendungen, welche sensibel auf Datenkorruption reagieren. Zuverlässigkeit ist besonders in großen Cluster-Computerumgebungen wichtig, in denen PPUs 400 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume ausführen.
In einer Ausführungsform implementiert die PPU 400 eine mehrstufige Speicherhierarchie. In einer Ausführungsform unterstützt die Speicherpartitionseinheit 480 einen vereinheitlichten Speicher, um einen einzigen vereinheitlichten virtuellen Adressraum für den CPU- und PPU 400-Speicher bereitzustellen, womit die gemeinsame Nutzung von Daten zwischen virtuellen Speichersystemen ermöglicht wird. In einer Ausführungsform wird die Häufigkeit von Zugriffen einer PPU 400 auf einen Speicher, der sich auf anderen Prozessoren befindet, nachverfolgt um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 400, die häufiger auf die Seiten zugreift, verschoben werden. In einer Ausführungsform unterstützt die Verbindung NVLink 410 Adressübersetzungsdienste, womit der PPU 400 der direkte Zugriff auf die Seitentabellen einer CPU und der volle Zugriff auf den CPU-Speicher ermöglicht ist.
In einer Ausführungsform übertragen Kopiermodule Daten zwischen mehreren PPUs 400 oder zwischen PPUs 400 und CPUs. Die Kopiermodule können Seitenfehler für Adressen erzeugen, welche nicht in den Seitentabellen abgebildet sind. Die Speicherpartitionseinheit 480 kann dann die Seitenfehler bearbeiten und die Adressen in der Seitentabelle abbilden, wonach das Kopiermodul die Übertragung durchführen kann. In einem herkömmlichen System wird der Speicher für mehrere Kopiermodulvorgänge zwischen mehreren Prozessoren gepinnt (z. B. nicht seitenauslagerbar), womit der verfügbare Speicher erheblich reduziert wird. Mit Hardware-Seitenverwurf (Hardware Page Faulting) können Adressen an die Kopiermodule weitergegeben werden, ohne dass man sich Gedanken darüber machen muss, ob die Speicherseiten resident sind, und der Kopiervorgang ist transparent.
Daten aus dem Speicher 404 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 480 abgerufen und im L2-Cache 460, der sich auf dem Chip befindet und von den verschiedenen GPCs 450 gemeinsam genutzt wird, gespeichert werden. Wie gezeigt, enthält jede Speicherpartitionseinheit 480 einen Teil des L2-Cache, welcher mit einem entsprechenden Speicher 404 verknüpft ist. Caches der unteren Ebene können dann in verschiedenen Einheiten innerhalb der GPCs 450 implementiert werden. Zum Beispiel kann jede der Verarbeitungseinheiten einen Cache der Ebene eins (L1) implementieren. Der L1-Cache ist ein privater Speicher, der einer bestimmten Verarbeitungseinheit zugeordnet ist. Der L2-Cache 460 ist mit der Speicherschnittstelle 470 und der XBar 470 gekoppelt und Daten können aus dem L2-Cache abgerufen und in jedem der L1-Caches zur Verarbeitung gespeichert werden.
In einer Ausführungsform implementieren die Verarbeitungseinheiten innerhalb jedes GPC 450 eine SIMD-Architektur (Single-Instruction, Multiple-Data), bei der jeder Thread in einer Gruppe von Threads (z. B. einem Warp) konfiguriert ist, einen anderen Satz von Daten auf der Grundlage desselben Satzes von Befehlen zu verarbeiten. Alle Threads in der Gruppe von Threads führen die gleichen Befehle aus. In einer anderen Ausführungsform implementiert die Verarbeitungseinheit eine SIMT-Architektur (Single-Instruction, Multiple Thread), bei der jeder Thread in einer Gruppe von Threads konfiguriert ist, einen anderen Datensatz auf der Grundlage desselben Befehlssatzes zu verarbeiten, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In einer Ausführungsform werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden Warp beibehalten, wodurch Gleichzeitigkeit zwischen Warps und serielle Ausführung innerhalb von Warps ermöglicht werden, wenn Threads innerhalb des Warps divergieren. In einer anderen Ausführungsform werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden einzelnen Thread beibehalten, wodurch gleiche Gleichzeitigkeit zwischen allen Threads innerhalb und zwischen Warps ermöglicht wird. Wenn der Ausführungsstatus für jeden einzelnen Thread beibehalten wird, können Threads, welche dieselben Befehle ausführen, zur Erzielung maximaler Effizienz zusammengeführt und parallel ausgeführt werden.
Kooperative Gruppen bezeichnen ein Programmiermodell zum Organisieren von Gruppen kommunizierender Threads, welches Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads kommunizieren, womit der Ausdruck ergiebigerer, effizienterer paralleler Dekompositionen ermöglicht wird. APIs für den kooperativen Start unterstützen die Synchronisierung zwischen Thread-Blöcken für die Ausführung paralleler Algorithmen. Herkömmliche Programmiermodelle bieten ein einziges, einfaches Konstrukt für die Synchronisierung kooperierender Threads: eine Sperre über alle Threads eines Thread-Blocks (z. B. die Funktion syncthreads( )). Programmierer würden jedoch oft Gruppen von Threads mit einer kleineren Granularität als Thread-Blöcke definieren und innerhalb der definierten Gruppen synchronisieren, um eine höhere Leistung, Design-Flexibilität und Software-Wiederverwendung in Form kollektiver gruppenweiter Funktionsschnittstellen zu ermöglichen.
Kooperative Gruppen ermöglichen es Programmierern, Gruppen von Threads explizit auf Sub-Block- (z. B. so klein wie ein einzelner Thread) und Multi-Block-Granularität zu definieren und kollektive Operationen wie Synchronisation auf den Threads in einer kooperativen Gruppe durchzuführen. Das Programmiermodell unterstützt saubere Komposition über Software-Grenzen hinweg, so dass Bibliotheken und Utility-Funktionen innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz treffen zu müssen. Die Primitive Kooperativer Gruppen ermöglichen neue Muster kooperativer Parallelität, einschließlich Producer-Consumer-Parallelität, opportunistischer Parallelität und globaler Synchronisierung über ein ganzes Gitter von Thread-Blöcken.
Jede Verarbeitungseinheit umfasst eine große Anzahl (z. B. 128 usw.) verschiedener Verarbeitungskerne (Funktionseinheiten) mit Voll-Pipeline-, Einzelpräzision, Doppelpräzision und/oder gemischter Präzision, die eine Gleitkomma-Arithmetik-Logikeinheit und eine Ganzzahl-Arithmetik-Logikeinheit umfassen. In einer Ausführungsform implementieren die arithmetischen Gleitkomma-Logikeinheiten den Standard IEEE 754-2008 für Gleitkomma-Arithmetik. In einer Ausführungsform umfassen die Kerne 64 Gleitkomma-Kerne mit Einzelpräzision (32 Bit), 64 Ganzzahl-Kerne, 32 Gleitkomma-Kerne mit Doppelpräzision (64 Bit) und 8 Tensor-Kerne.
Tensor-Kerne sind für die Durchführung von Matrixoperationen konfiguriert. Insbesondere sind die Tensor-Kerne konfiguriert, Deep-Learning-Matrix-Arithmetik wie GEMM (Matrix-Matrix-Multiplikation) für Faltungsoperationen während des Trainings neuronaler Netze und Inferenzieren durchzuführen. In einer Ausführungsform arbeitet jeder Tensor-Kern mit einer 4x4-Matrix und führt eine Matrix-Multiplikations- und -Akkumulationsoperation D=A×B+C durch, wobei A, B, C und D 4x4-Matrizen sind.
In einer Ausführungsform können die Matrix-Multiplikationseingänge A und B Ganzzahl-, Festkomma- oder Gleitkommamatrizen sein, während die Akkumulationsmatrizen C und D Ganzzahl-, Festkomma- oder Gleitkommamatrizen gleicher oder höherer Bitbreite sein können. In einer Ausführungsform operieren Tensor-Kerne mit ganzzahligen Eingangsdaten von einem, vier oder acht Bit und einer ganzzahligen 32-Bit-Akkumulation. Die 8-Bit-Ganzzahl-Matrixmultiplikation erfordert 1024 Operationen und führt zu einem Produkt mit vollständiger Präzision, das dann durch 32-Bit-Ganzzahladdition mit den anderen Zwischenprodukten zu einer 8x8x16-Matrixmultiplikation akkumuliert wird. In einer Ausführungsform operieren die Tensor-Kerne mit 16-Bit-Gleitkomma-Eingangsdaten und 32-Bit-Gleitkomma-Akkumulation. Die 16-Bit-Gleitkomma-Multiplikation erfordert 64 Operationen und ergibt ein Produkt mit vollständiger Präzision, welches dann mit 32-Bit- Gleitkomma-Addition mit den anderen Zwischenprodukten für eine 4x4x4-Matrixmultiplikation akkumuliert wird. In der Praxis werden Tensor-Kerne verwendet, um viel größere zweidimensionale oder höher dimensionale MatrixOperationen, die aus diesen kleineren Elementen aufgebaut sind, auszuführen. Eine API, wie zum Beispiel die CUDA 9C++ API, stellt spezialisierte Matrix-Lade-, Matrix-Multiplikations- und Matrix-Akkumulations- und Matrix-Speicheroperationen zur Verfügung, um Tensor-Kerne effizient von einem CUDA-C++ Programm aus zu nutzen. Auf der CUDA-Ebene geht die Schnittstelle auf Warp-Ebene von Matrizen der Größe 16x16 aus, welche sich über alle 32 Threads des Warps erstrecken.
Jede Verarbeitungseinheit umfasst auch M Spezialfunktionseinheiten (SFUs) welche spezielle Funktionen ausführen (z. B. Attributauswertung, reziproke Quadratwurzel und dergleichen). In einer Ausführungsform können die SFUs eine Tree-Traversal-Einheit enthalten, die konfiguriert ist, eine hierarchische Baumdatenstruktur zu durchlaufen. In einer Ausführungsform können die SFUs eine Textur-Einheit enthalten, die konfiguriert ist, Textur-Map-Filteroperationen durchzuführen. In einer Ausführungsform sind die Textur-Einheiten konfiguriert, Textur-Maps (z. B. ein 2D-Array von Texel-Elementen) aus dem Speicher 404 zu laden und die Textur-Maps abzutasten, um abgetastete Textur-Werte zur Verwendung in von der Verarbeitungseinheit ausgeführten Shader-Programmen zu erzeugen. In einer Ausführungsform sind die Textur-Maps im gemeinsamen Speicher, der einen L1-Cache umfassen bzw. beinhalten kann, gespeichert. Die Textur-Einheiten implementieren Textur-Operationen, wie beispielsweise Filteroperationen unter Verwendung von MIP-Maps (z. B. Textur-Maps mit unterschiedlichen Detailstufen). In einer Ausführungsform umfasst jede Verarbeitungseinheit zwei Textur-Einheiten.
Jede Verarbeitungseinheit umfasst auch N Lade-Speicher-Einheiten (LSUs), welche Lade- und Speicheroperationen zwischen dem gemeinsamen Speicher und der Registerdatei implementieren. Jede Verarbeitungseinheit umfasst ein Verbindungsnetzwerk, welches jeden der Kerne mit der Registerdatei und die LSU mit der Registerdatei, dem gemeinsam genutzten Speicher verbindet. In einer Ausführungsform ist das Verbindungsnetzwerk eine Crossbar, die konfiguriert sein kann, jeden beliebigen der Kerne mit jedem beliebigen der Register in der Registerdatei und die LSUs mit der Registerdatei und Speicherplätzen im gemeinsam genutzten Speicher zu verbinden.
Der gemeinsam genutzte Speicher ist ein Array eines On-Chip-Speichers, welcher die Datenspeicherung und Kommunikation zwischen den Verarbeitungseinheiten und zwischen Threads innerhalb einer Verarbeitungseinheit ermöglicht. In einer Ausführungsform umfasst der gemeinsame Speicher 128 KB Speicherkapazität und befindet sich im Pfad von jeder der Verarbeitungseinheiten zur Speicherpartitionseinheit 480. Der gemeinsam genutzte Speicher kann zum Cachen von Lese- und Schreibvorgängen verwendet werden. Einer oder mehrere des gemeinsam genutzten Speichers, L1 -Caches, L2-Caches und des Speichers 404 sind Zusatzspeicher.
Die Kombination von Datencache- und Gemeinsamer-Speicher-Funktionalität in einem einzigen Speicherblock bietet die beste Gesamtleistung für beide Arten von Speicherzugriffen. Die Kapazität ist als Cache für Programme nutzbar, die keinen gemeinsamen Speicher verwenden. Wenn beispielsweise der gemeinsame Speicher ausgelegt ist, die Hälfte der Kapazität zu nutzen, können Textur- und Lade-/Speicheroperationen die restliche Kapazität nutzen. Durch Integration innerhalb des gemeinsamen Speichers kann der gemeinsame Speicher als durchsatzstarke Leitung für Streaming-Daten fungieren und gleichzeitig einen Zugriff mit hoher Bandbreite und niedriger Latenz auf häufig wiederverwendete Daten ermöglichen.
Bei Konfiguration für parallele Universalberechnungen kann im Vergleich zur Grafikverarbeitung eine einfachere Konfiguration verwendet werden. Insbesondere werden Grafikverarbeitungseinheiten mit festen Funktionen umgangen, wodurch ein viel einfacheres Programmiermodell entsteht. In der Konfiguration für Universalberechnungen weist und verteilt die Arbeitsverteilungseinheit 425 Blöcke von Threads direkt an die Verarbeitungseinheiten innerhalb der GPCs 450. Threads führen dasselbe Programm unter Verwendung einer eindeutigen Thread-ID in der Berechnung aus, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse erzeugt, wobei die eine oder mehreren Verarbeitungseinheiten zur Ausführung des Programms und zur Durchführung von Berechnungen, der gemeinsame Speicher zur Kommunikation zwischen den Threads und die LSU zum Lesen und Schreiben des globalen Speichers über den gemeinsamen Speicher und die Speicherpartitionseinheit 480 verwendet werden. Bei Konfiguration für parallele Universalberechnungen können die Verarbeitungseinheiten auch Befehle schreiben, welche die Scheduler-Einheit 420 verwenden kann, um neue Arbeit auf den Verarbeitungseinheiten zu starten.
Die PPUs 400 können jeweils einen oder mehrere Verarbeitungskerne und/oder Komponenten davon enthalten und/oder konfiguriert sein, Funktionen dieser Kerne auszuführen, wie beispielsweise die von Tensor-Kernen (TCs), Tensor-Prozessoren (TPUs), Pixel-Visual-Kernen (PVCs), Ray Tracing (RT)-Kernen, Bildverarbeitungseinheiten (VPUs), Graphik-Verarbeitungsclustern (GPCs), Texturverarbeitungsclustern (TPCs), Streaming-Multiprozessoren (SMs), Tree Traversal-Einheiten (TTUs), KI-Beschleuniger (AIAs), Deep-Learning-Beschleuniger (DLAs), Arithmetischer Logikeinheiten (ALUs), Anwendungsspezifischer integrierter Schaltungen (ASICs), Gleitkommaeinheiten (FPUs), Eingans-/Ausgangs (E/A)-Elementen, Peripheral Component Interconnect (PCI) oder Peripheral Component Interconnect Express (PCIe)-Elemente und/oder dergleichen.
Die PPUs 400 können in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z. B. einem drahtlosen, tragbaren Gerät), einem persönlichen digitalen Assistenten (PDA), einer Digitalkamera, einem Fahrzeug, einem Head-Mounted-Display, einem tragbaren elektronischen Gerät und dergleichen enthalten sein. In einer Ausführungsform ist die PPU 400 auf einem einzigen Halbleitersubstrat enthalten. In einer anderen Ausführungsform ist die PPU 400 in einem System-on-a-Chip (SoC) zusammen mit einer oder mehreren anderen Vorrichtungen wie zusätzlichen PPUs 400, dem Speicher 404, einem Rechner mit beschränktem Befehlssatz (RISC-CPU), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und ähnlichem enthalten.
In einer Ausführungsform kann die PPU 400 auf einer Grafikkarte enthalten sein, welche ein oder mehrere Speichergeräte umfasst. Die Grafikkarte kann konfiguriert sein, mit einem PCIe-Steckplatz auf einer Hauptplatine eines Desktop-Computers über eine Schnittstelle verbunden zu sein. In noch einer anderen Ausführungsform kann die PPU 400 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein Parallelprozessor sein, der im Chipsatz der Hauptplatine enthalten ist. In noch einer anderen Ausführungsform kann die PPU 400 in einer neu konfigurierbaren Hardware enthalten sein. In noch einer anderen Ausführungsform können Teile der PPU 400 in einer neu konfigurierbaren Hardware enthalten sein.
Beispielhaftes Rechensystem
Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen eingesetzt, da Entwickler immer mehr Parallelität in Anwendungen wie der künstlichen Intelligenz aufdecken und ausnutzen. Leistungsstarke GPU-beschleunigte Systeme mit zehn bis vielen tausend Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Da die Anzahl der Verarbeitungsgeräte innerhalb der Hochleistungssysteme steigt, müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandbreite zu unterstützen.
5A zeigt ein konzeptionelles Schema eines Verarbeitungssystems 500, das unter Verwendung der PPU 400 von 4 gemäß einer Ausführungsform implementiert ist. Das beispielhafte System 565 kann konfiguriert sein, das System zur Wiederherstellung von 3D-Modellen 100 und/oder das in 3 gezeigte Verfahren 300 zu implementieren. Das Verarbeitungssystem 500 umfasst eine CPU 530, einen Switch 510 und mehrere PPUs 300 sowie entsprechende Speicher 404.
Die Verbindung NVLink 410 stellt Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 400 bereit. Obwohl in 5B eine bestimmte Anzahl von Verbindungen NVLink 410 und Verschaltungen 402 dargestellt ist, kann die Anzahl der Verbindungen zu jeder PPU 400 und der CPU 530 variieren. Der Switch 510 bildet die Schnittstelle zwischen der Verbindung 402 und der CPU 530. Die PPUs 400, Speicher 404 und Verbindungen NVLink 410 können auf einer einzigen Halbleiterplattform angeordnet sein, um eine Parallelverarbeitungseinheit 525 zu bilden. In einer Ausführungsform unterstützt der Switch 510 zwei oder mehr Protokolle, um eine Schnittstelle zwischen verschiedenen Verbindungen und/oder Links zu bilden.
In einer anderen Ausführungsform (nicht dargestellt) stellt die Verbindung NVLink 410 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 400 und der CPU 530 bereit, und der Switch 510 bildet eine Schnittstelle zwischen der Verschaltung 402 und jeder der PPUs 400. Die PPUs 400, Speicher 404 und Verschaltung 402 können auf einer einzigen Halbleiterplattform angeordnet sein, um eine Parallelverarbeitungseinheit 525 zu bilden. In noch einer anderen Ausführungsform (nicht dargestellt) stellt die Verschaltung 402 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 400 und der CPU 530 bereit, und der Switch 510 bildet unter Verwendung der Verbindung NVLink 410 eine Schnittstelle zwischen jeder der PPUs 400, um eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 400 bereitzustellen. In einer anderen Ausführungsform (nicht dargestellt) stellt die Verbindung NVLink 410 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 400 und der CPU 530 über den Switch 510 bereit. In noch einer weiteren Ausführungsform (nicht dargestellt) stellt die Verschaltung 402 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 400 direkt bereit. Eine oder mehrere der NVLink 410-Hochgeschwindigkeits-Kommunikationsverbindungen können als physische Verbindung NVLink oder entweder als On-Chip- oder On-Die-Verbindung implementiert sein, die dasselbe Protokoll wie die Verbindung NVLink 410 verwendet.
Im Kontext der vorliegenden Beschreibung kann sich eine Einzel-Halbleiterplattform auf eine einzige einheitliche halbleiterbasierte integrierte Schaltung beziehen, die auf einem Die bzw. Chip hergestellt wurde. Es ist zu beachten, dass sich der Terminus Einzel-Halbleiterplattform auch auf Multi-Chip-Module mit erhöhter Konnektivität beziehen kann, die einen On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Bus-Implementierung bieten. Natürlich können die verschiedenen Schaltungen oder Geräte auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Benutzers angeordnet sein. Alternativ kann die Parallelverarbeitungseinheit 525 als Leiterplattensubstrat implementiert sein und jede der PPUs 400 und/oder Speicher 404 können gehauste Geräte sein. In einer Ausführungsform befinden sich die CPU 530, der Switch 510 und die Parallelverarbeitungseinheit 525 auf einer einzigen Halbleiterplattform.
In einer Ausführungsform beträgt die Signalisierungsrate jeder Verbindung NVLink 410 20 bis 25 Gigabit/Sekunde und jede PPU 400 umfasst sechs NVLink 410-Schnittstellen (wie in 5A gezeigt, sind fünf NVLink 410-Schnittstellen für jede PPU 400 enthalten). Jede Verbindung NVLink 410 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jede Richtung, wobei sechs Links 300 Gigabyte/Sekunde bereitstellen. Die Verbindungen NVLink 410 können ausschließlich für die PPU-zu-PPU-Kommunikation verwendet werden, wie in 5A gezeigt, oder für eine Kombination aus PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 530 auch eine oder mehrere NVLink 410-Schnittstellen umfasst.
In einer Ausführungsform ermöglicht die Verbindung NVLink 410 einen direkten Lade-/Speicher-/Atomaren Zugriff von der CPU 530 auf den Speicher 404 jeder PPU 400. In einer Ausführungsform unterstützt die Verbindung NVLink 410 Kohärenzoperationen, womit aus den Speichern 404 gelesene Daten in der Cache-Hierarchie der CPU 530 gespeichert werden können, womit die Cache-Zugriffslatenz für die CPU 530 reduziert wird. In einer Ausführungsform enthält die Verbindung NVLink 410 Unterstützung für Adressübersetzungsdienste (ATS), wodurch die PPU 400 direkt auf Seitentabellen innerhalb der CPU 530 zugreifen kann. Ein oder mehrere der Verbindungen NVLinks 410 können auch konfiguriert sein, in einem stromsparenden Modus zu arbeiten.
5B zeigt ein beispielhaftes System 565, in dem die verschiedenartige Architektur und/oder Funktionalität der verschiedenen vorherigen Ausführungsformen implementiert sein können. Das beispielhafte System 565 kann konfiguriert sein, das in 3 gezeigte System zur Wiederherstellung von 3D-Modellen 100 und/oder das Verfahren 300 zu implementieren.
Wie gezeigt, ist ein System 565 vorgesehen, welches mindestens eine zentrale Verarbeitungseinheit 530 umfasst, die mit einem Kommunikationsbus 575 verbunden ist. Der Kommunikationsbus 575 kann direkt oder indirekt eines oder mehrere der folgenden Geräte koppeln: Hauptspeicher 540, Netzwerkschnittstelle 535, CPU/s 530, Anzeigegerät/e 545, Eingabegerät/e 560, Switch 510 und Parallelverarbeitungseinheit 525. Der Kommunikationsbus 575 kann unter Verwendung eines beliebigen geeigneten Protokolls implementiert sein und kann eine oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Der Kommunikationsbus 575 kann einen oder mehrere Bus- oder Verbindungstypen umfassen, zum Beispiel einen ISA-Bus (Industry Standard Architecture), einen EISA-Bus (Extended Industry Standard Architecture), einen VESA-Bus (Video Electronics Standards Association), einen PCI-Bus (Peripheral Component Interconnect), einen PCIe-Bus (Peripheral Component Interconnect Express), HyperTransport und/oder eine andere Art von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen den Komponenten. So können beispielsweise die eine oder mehreren CPUs 530 direkt mit dem Hauptspeicher 540 verbunden sein. Ferner können die eine oder mehreren CPUs 530 direkt mit der Parallelverarbeitungseinheit 525 verbunden sein. Bei einer direkten oder Punkt-zu-Punkt-Verbindung zwischen Komponenten kann der Kommunikationsbus 575 eine PCIe-Verbindung enthalten, um die Verbindung herzustellen. In diesen Beispielen muss das System 565 nicht unbedingt einen PCI-Bus enthalten.
Obwohl die verschiedenen Blöcke in 5C als über den Kommunikationsbus 575 mit Leitungen verbunden dargestellt sind, ist dies nicht als einschränkend zu verstehen und dient nur der Übersichtlichkeit. In einigen Ausführungsformen kann beispielsweise eine Präsentationskomponente, wie Anzeigegerät/e 545, als E/A-Komponente, wie Eingabegerät/e 560 (z. B. wenn die Anzeige ein Touchscreen ist) betrachtet werden. Als ein weiteres Beispiel können die eine oder mehreren CPUs 530 und/oder die Parallelverarbeitungseinheit 525 Speicher enthalten (z. B. kann der Hauptspeicher 540 ein Speichergerät zusätzlich zu der Parallelverarbeitungseinheit 525, den CPUs 530 und/oder anderen Komponenten darstellen). Anders ausgedrückt dient der Rechner von 5C lediglich illustrativen Zwecken. Es wird nicht zwischen Kategorien wie „Workstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Gerät“, „mobiles Gerät“, „Handheld-Gerät“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Geräte- oder Systemtypen unterschieden, da sie alle in den Anwendungsbereich des Rechners von 5C fallen.
Das System 565 umfasst auch einen Hauptspeicher 540. Steuerlogik (Software) und Daten werden im Hauptspeicher 540 gespeichert, der die Form einer Vielzahl von computerlesbaren Medien annehmen kann. Bei den computerlesbaren Medien kann es sich um alle verfügbaren Medien handeln, auf die das System 565 zugreifen kann. Die computerlesbaren Medien können sowohl flüchtige als auch nicht-flüchtige Medien sowie Wechsel- und Nicht-Wechselmedien umfassen. Als Beispiel können die computerlesbaren Medien Computerspeichermedien und Kommunikationsmedien umfassen ohne auf diese beschränkt zu sein.
Die Computerspeichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder Wechsel- als auch Nicht-Wechselmedien umfassen, welche in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie beispielsweise von computerlesbaren Befehlen, Datenstrukturen, Programmmodulen und/oder anderen Datentypen, implementiert sind. Beispielsweise kann der Speicher 504 computerlesbare Befehle speichern (z. B. solche, die ein oder mehrere Programme und/oder ein oder mehrere Programmelemente darstellen, wie z. B. ein Betriebssystem). Computerspeichermedien können, beispielsweise und ohne darauf beschränkt zu sein RAM-, ROM-, EEPROM-, Flash-Speicher- oder andere Speichertechnologien, CD-ROM, DVDs oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium sein, welches zur Speicherung der gewünschten Informationen verwendet werden kann und auf das das System 565 zugreifen kann. Der hier verwendete Terminus „Computerspeichermedium“ umfasst nicht per se Signale
Die Computerspeichermedien können computerlesbare Befehle, Datenstrukturen, Programmmodule und/oder andere Datentypen in einem modulierten Datensignal, wie beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und umfassen beliebige Informationsübertragungsmedien. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, bei dem eine oder mehrere seiner Eigenschaften so eingestellt oder verändert wurden, dass Informationen in dem Signal kodiert sind. Computerspeichermedien können beispielsweise und ohne darauf beschränkt zu sein verdrahtete Medien, wie ein verdrahtetes Netzwerk oder eine Direktverbindung, und drahtlose Medien, wie Audio-, RF-, Infrarot- und andere drahtlose Medien, sein. Kombinationen der oben genannten Medien sollten ebenfalls in den Anwendungsbereich der computerlesbaren Medien einbezogen werden.
Wenn Computerprogramme ausgeführt werden, kann das System 565 verschiedene Funktionen ausführen. Die eine oder mehreren CPUs 530 können konfiguriert sein, zumindest einige der computerlesbaren Befehle auszuführen, um eine oder mehrere Komponenten des Systems 565 zu steuern, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Jede der einen oder mehreren CPU 530 kann einen oder mehrere Kerne (z. B. einen, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, welche in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die eine oder mehreren CPUs 530 können jede Art von Prozessor umfassen und je nach Art des implementierten Systems 565 verschiedene Arten von Prozessoren umfassen (z. B. Prozessoren mit weniger Kernen für mobile Geräte und Prozessoren mit mehr Kernen für Server). Je nach Art des Systems 565 kann der Prozessor beispielsweise ein Prozessor von Advanced RISC Machines (ARM) sein, der mit RISC (Berechnungen mit reduziertem Befehlssatz) arbeitet, oder ein x86-Prozessor, der mit CISC (Berechnungen mit komplexem Befehlssatz) arbeitet. Das System 565 kann eine oder mehrere CPUs 530 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzlichen Coprozessoren, wie zum Beispiel mathematischen Coprozessoren, umfassen.
Zusätzlich oder alternativ zu der/den CPU/s 530 kann die Parallelverarbeitungseinheit 525 konfiguriert sein, zumindest einige der computerlesbaren Befehle auszuführen, um eine oder mehrere Komponenten des Systems 565 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Die Parallelverarbeitungseinheit 525 kann vom System 565 zum Rendern von Grafiken (z. B. 3D-Grafiken) oder zum Durchführen von Universalberechnungen verwendet werden. In Ausführungsformen können die eine oder mehreren CPUs 530 und/oder die Parallelverarbeitungseinheit 524 getrennt oder gemeinsam jede beliebige Kombination von Methoden, Prozessen und/oder Teilen davon durchführen.
Das System 565 umfasst auch Eingabegerät/e 560, die Parallelverarbeitungseinheit 525 und Anzeigegerät/e 545. Das oder die Anzeigegeräte 545 können ein Display (z. B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, ein Head-up-Display (HUD), andere Anzeigetypen oder eine Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Das oder die Anzeigegeräte 545 können Daten von anderen Komponenten (z. B. der Parallelverarbeitungseinheit 525, der/den CPU/s 530 usw.) empfangen und die Daten ausgeben (z. B. als Bild, Video, Ton usw.).
Die Netzwerkschnittstelle 535 kann es dem System 565 ermöglichen, logisch mit anderen Geräten, einschließlich der Eingabegeräte 560, der oder den Anzeigegerät/en545 und/oder anderer Komponenten, von denen einige in das System 565 eingebaut (z. B. integriert) sein können, gekoppelt zu werden. Beispielhafte Eingabegeräte 560 umfassen ein Mikrofon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Gamecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, ein drahtloses Gerät usw. Die Eingabegeräte 560 können eine natürliche Benutzerschnittstelle (NUI) bereitstellen, die Luftbewegungen, Sprache oder andere physiologische Eingaben eines Benutzers verarbeitet. In einigen Fällen können die Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann eine beliebige Kombination aus Spracherkennung, Stifterkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftbewegungen, Kopf- und Augenverfolgung und Berührungserkennung (wie unten ausführlicher beschrieben) verknüpft mit einem Display des Systems 565 implementieren. Das System 565 kann Tiefenkameras, wie beispielsweise stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon, zur Gestenerkennung und -erfassung umfassen. Darüber hinaus kann das System 565 Beschleunigungsmesser oder Gyroskope enthalten (z. B. als Teil einer Trägheitsmesseinheit (IMU)), welche die Erkennung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungsmesser oder Gyroskope von dem System 565 verwendet werden, um immersive erweiterte Realität oder virtuelle Realität zu rendern.
Ferner kann das System 565 über eine Netzwerkschnittstelle 535 zu Kommunikationszwecken mit einem Netzwerk (z. B. einem Telekommunikationsnetzwerk, einem lokalen Netzwerk (LAN), einem drahtlosen Netzwerk, einem Weitverkehrsnetzwerk (WAN) wie dem Internet, einem Peer-to-Peer-Netzwerk, einem Kabelnetzwerk oder dergleichen) gekoppelt sein. Das System 565 kann in ein verteiltes Netzwerk und/oder eine Cloud-Computing-Umgebung eingebunden sein.
Die Netzwerkschnittstelle 535 kann einen oder mehrere Empfänger, Sender und/oder Transceiver enthalten, welche das System 565 befähigen, mit anderen Rechnern über ein elektronisches Kommunikationsnetzwerk, einschließlich drahtgebundener und/oder drahtloser Kommunikation, zu kommunizieren. Die Netzwerkschnittstelle 535 kann Komponenten und Funktionen enthalten, um die Kommunikation über eine Reihe verschiedener Netzwerke zu ermöglichen, wie beispielsweise drahtlose Netzwerke (z. B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z. B. Kommunikation über Ethernet oder InfiniBand), Weitverkehrsnetzwerke mit geringer Leistung (z. B. LoRaWAN, SigFox usw.) und/oder das Internet.
Das System 565 kann auch einen Sekundärspeicher (nicht dargestellt) enthalten. Der Sekundärspeicher umfasst beispielsweise ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Floppy-Disc-Laufwerk, ein Magnetbandlaufwerk, ein CD-Laufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät oder einen USB-Flash-Speicher darstellt. Das Wechselspeicherlaufwerk liest von einem Wechselspeicher und/oder schreibt auf einen Wechselspeicher in gewohnter Weise. Das System 565 kann auch eine festverdrahtete Stromversorgung, eine Batteriestromversorgung oder eine Kombination davon umfassen (nicht dargestellt). Die Stromversorgung kann das System 565 mit Strom versorgen, um den Betrieb der Komponenten des Systems 565 zu ermöglichen.
Jedes der vorgenannten Module und/oder Geräte kann sogar auf einer einzigen Halbleiterplattform angeordnet sein, um das System 565 zu bilden. Alternativ können die verschiedenen Module je nach den Wünschen des Benutzers auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen angeordnet sein. Obwohl oben verschiedene Ausführungsformen beschrieben wurden, sollten diese nur als Beispiel und nicht als Einschränkung verstanden werden. Daher sollte die Breite und der Umfang einer bevorzugten Ausführungsform nicht durch eine der oben beschriebenen beispielhaften Ausführungsformen begrenzt werden, sondern nur in Übereinstimmung mit den folgenden Ansprüchen und deren Äquivalenten definiert werden.
Beispielhafte Netzwerkumgebungen
Netzwerkumgebungen, welche für die Verwendung bei der Implementierung von Ausführungsformen der Erfindung geeignet sind, können ein oder mehrere Client-Geräte, Server, nutzergebundene Speichergeräte (NAS), andere Backend-Geräte und/oder andere Gerätetypen umfassen. Die Client-Geräte, Server und/oder anderen Gerätetypen (z. B. jedes Gerät) können auf einer oder mehreren Instanzen des Verarbeitungssystems 500 von 5A und/oder des Beispielsystems 565 von 5B implementiert werden - zum Beispiel kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität des Verarbeitungssystems 500 und/oder des Beispielsystems 565 enthalten.
Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke, die drahtgebunden, drahtlos oder beides sein können, miteinander kommunizieren. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken umfassen. So kann das Netzwerk beispielsweise ein oder mehrere Weitverkehrsnetzwerke (WANs), ein oder mehrere lokale Netzwerke ((LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Wenn das Netzwerk ein drahtloses Telekommunikationsnetz umfasst, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie andere Komponenten) drahtlose Konnektivität bereitstellen.
Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall kann ein Server nicht in einer Netzwerkumgebung enthalten sein - und eine oder mehrere Client-Server-Netzwerkumgebungen - in diesem Fall können ein oder mehrere Server in einer Netzwerkumgebung enthalten sein - umfassen. In Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Geräten implementiert werden.
In mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere cloudbasierte Netzwerkumgebungen, eine verteilte Rechenumgebung, eine Kombination davon usw. umfassen. Eine cloudbasierte Netzwerkumgebung kann eine Framework-Schicht, einen Job Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem umfassen, welche auf einem oder mehreren Servern implementiert sind, die einen oder mehrere Kernnetzwerkserver und/oder Edge-Server umfassen können. Eine Framework-Schicht kann einen Rahmen zur Unterstützung von Software einer Softwareschicht und/oder einer oder mehrerer Anwendungen einer Anwendungsschicht umfassen. Die Software oder die Anwendung/en kann/können jeweils webbasierte Dienstsoftware oder Anwendungen umfassen. In Ausführungsformen können ein oder mehrere Client-Geräte die webbasierte Dienstsoftware oder Anwendungen nutzen (z. B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Bei der Framework-Schicht kann es sich um eine Art Webanwendungs-Framework von freier und Open-Source-Software handeln, die beispielsweise ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z. B. Big Data) verwenden kann, ohne darauf beschränkt zu sein.
Eine cloudbasierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicher bereitstellen, der eine beliebige Kombination der hier beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführt. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von Zentral- oder Kernservern (z. B. von einem oder mehreren Datenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können) verteilt sein. Befindet sich eine Verbindung zu einem Benutzer (z. B. einem Client-Gerät) relativ nah an einem oder mehreren Edge-Servern, kann ein Kernserver zumindest einen Teil der Funktionalität dem oder den Edge-Servern zuweisen. Eine cloudbasierte Netzwerkumgebung kann privat (z. B. auf eine einzelne Organisation beschränkt), öffentlich (z. B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z. B. eine hybride Cloud-Umgebung) sein.
Das eine oder die mehreren Client-Geräte können zumindest einige der Komponenten, Merkmale und Funktionen des beispielhaften Verarbeitungssystems 500 von 5B und/oder des Beispielsystems 565 von 5C enthalten. Beispielhaft und ohne darauf beschränkt zu sein kann ein Client-Gerät als ein Personal Computer (PC), ein Laptop, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smartwatch, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder -Gerät, ein Videoplayer, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug, ein Boot, eine fliegende Vorrichtung, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder -system, ein Unterhaltungssystem, ein Fahrzeugcomputersystem, eine eingebettete Systemsteuerung, eine Fernbedienung, ein Apparat, ein Unterhaltungselektronikgerät, eine Workstation, ein Edge Device, eine beliebige Kombination dieser beschriebenen Geräte oder jedes andere geeignete Gerät verkörpert sein.
Maschinelles Lernen
Tiefe neuronale Netze (DNNs), welche auf Prozessoren wie der PPU 400 entwickelt wurden, wurden für verschiedene Anwendungsfälle eingesetzt, von selbstfahrenden Autos bis zur schnelleren Medikamentenentwicklung, von der automatischen Bildunterschrift in Online-Bilddatenbanken bis zur intelligenten Sprachübersetzung in Echtzeit in Video-Chat-Anwendungen. Deep Learning ist eine Technik, die den neuronalen Lernprozess des menschlichen Gehirns modelliert und dabei kontinuierlich lernt, immer intelligenter wird und mit der Zeit immer genauere Ergebnisse liefert. Ein Kind lernt anfangs von einem Erwachsenen, verschiedene Formen richtig zu identifizieren und zu klassifizieren, und ist schließlich in der Lage, Formen ohne jegliche Nachhilfe zu erkennen. In ähnlicher Weise muss ein Deep-Learning- oder neuronales Lernsystem in der Objekterkennung und -klassifizierung trainiert werden, damit es intelligenter und effizienter in der Lage ist, grundlegende Objekte, verdeckte Objekten usw. zu identifizieren und gleichzeitig einen Kontext den Objekten zuzuordnen.
Auf der einfachsten Ebene betrachten Neuronen im menschlichen Gehirn verschiedene Eingaben, die empfangen werden, jeder dieser Eingaben werden Wichtigkeitsstufen zugewiesen, und eine Ausgabe wird an andere Neuronen weitergeleitet, damit diese darauf reagieren. Ein künstliches Neuron oder Perzeptron ist das einfachste Modell eines neuronalen Netzes. In einem Beispiel kann ein Perzeptron eine oder mehrere Eingaben empfangen, die verschiedene Merkmale eines Objekts darstellen, auf deren Erkennung und Klassifizierung das Perzeptron trainiert wird, und jedem dieser Merkmale wird eine bestimmte Gewichtung zugewiesen, die auf der Wichtigkeit dieses Merkmals bei der Definition der Form eines Objekts basiert.
Ein Modell des DNN umfasst mehrere Schichten vieler miteinander verbundener Knoten (z. B. Perzeptrone, Boltzmann-Maschinen, Radialbasisfunktionen, Faltungsschichten usw.), die mit enormen Mengen von Eingabedaten trainiert werden können, um komplexe Probleme schnell und mit hoher Genauigkeit zu lösen. In einem Beispiel zerlegt eine erste Schicht des DNN-Modells ein Eingabebild eines Autos in verschiedene Abschnitte und sucht nach grundlegenden Mustern wie Linien und Winkeln. Die zweite Schicht setzt die Linien zusammen, um nach Mustern auf höherer Ebene wie Rädern, Windschutzscheiben und Spiegeln zu suchen. Die nächste Schicht identifiziert den Fahrzeugtyp, und die letzten paar Schichten erzeugen eine Kennzeichnung für das Eingabebild, die das Modell einer bestimmten Automobilmarke identifiziert.
Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Inferenz bezeichneten Prozess zu identifizieren und zu klassifizieren. Beispiele für Inferenz (der Prozess, durch den ein DNN nützliche Informationen aus einer bestimmten Eingabe extrahiert) sind Identifizierung handschriftlicher Zahlen auf Schecks, die in Geldautomaten eingezahlt wurden, Identifizierung von Bildern von Freunden auf Fotos, Bereitstellung von Filmempfehlungen für über fünfzig Millionen Benutzer, Identifizierung und Klassifizierung verschiedener Arten von Autos, Fußgängern und Gefahren im Straßenverkehr mit fahrerlosen Autos oder Übersetzung menschlicher Sprache in Echtzeit.
Während des Trainings fließen die Daten in einer Forward-Propagation-Phase durch das DNN, bis eine Vorhersage erzeugt wird, die eine der Eingabe entsprechende Kennzeichnung anzeigt. Wenn das neuronale Netz die Eingabe nicht korrekt kennzeichnet, werden die Fehler zwischen der korrekten Kennzeichnung und der vorhergesagten Kennzeichnung analysiert und die Gewichtung für jedes Merkmal während einer Backward-Propagation-Phase angepasst, bis das DNN die Eingabe und andere Eingaben in einem Trainingsdatensatz korrekt kennzeichnet. Das Training komplexer neuronaler Netze erfordert enorm viele parallele Rechenleistungen, einschließlich Gleitkommamultiplikationen und -additionen, die von der PPU 400 unterstützt werden. Inferenz ist weniger rechenintensiv als das Training, da es sich um einen latenzsensiblen Prozess handelt, bei dem ein trainiertes neuronales Netz auf neue, zuvor nicht gesehene Eingaben angewendet wird, um Bilder zu klassifizieren, Emotionen zu erkennen, Empfehlungen zu identifizieren, Sprache zu erkennen und zu übersetzen und allgemein neue Informationen abzuleiten.
Neuronale Netze sind in hohem Maße auf mathematische Matrixoperationen angewiesen, und komplexe mehrschichtige Netze erfordern enorm hohe Fließkomma-Leistung und Bandbreite für Effizienz und Geschwindigkeit. Mit Tausenden von Verarbeitungskernen, welche für mathematische Matrixoperationen optimiert sind und Leistungen von Dutzend bis Hundert TFLOPS (Billionen Gleitkomma-Berechnungen pro Sekunde) liefern, ist die PPU 400 eine Computerplattform, die in der Lage ist, die für auf tiefen neuronalen Netzen basierende Anwendungen der künstlichen Intelligenz und des maschinellen Lernens erforderliche Leistung zu erbringen.
Darüber hinaus können Bilder, welche unter Anwendung einer oder mehrerer der hier offenbarten Techniken erzeugt wurden, zum Trainieren, Testen oder Zertifizieren von DNNs verwendet werden, die zur Erkennung von Objekten und Umgebungen in der realen Welt eingesetzt werden. Solche Bilder können Szenen von Straßen, Fabriken, Gebäuden, städtischen Szenarien, ländlichen Szenarien, Menschen, Tieren und anderen physischen Objekten oder realen Umgebungen enthalten. Solche Bilder können zum Trainieren, Testen oder Zertifizieren von in Maschinen oder Robotern eingesetzten DNNs verwendet werden, um physische Objekte in der realen Welt zu manipulieren, zu bearbeiten oder zu verändern. Außerdem können solche Bilder verwendet werden, um in autonomen Fahrzeugen eingesetzte DNNs zu trainieren, zu testen oder zu zertifizieren, damit sie die Fahrzeuge durch die reale Welt navigieren und bewegen. Darüber hinaus können Bilder, welche unter Anwendung einer oder mehrerer der hier offenbarten Techniken erzeugt wurden, verwendet werden, um den Benutzern solcher Maschinen, Roboter und Fahrzeuge Informationen zu vermitteln.
5C zeigt Komponenten eines beispielhaften Systems 555, welches zum Trainieren und Verwenden maschinellen Lernens gemäß mindestens einer Ausführungsform verwendet werden kann. Wie diskutiert werden wird, können verschiedene Komponenten anhand verschiedener Kombinationen von Rechnern und Ressourcen oder eines einzigen Rechensystem bereitgestellt werden, das unter der Kontrolle einer einzelnen oder mehrerer Entitäten stehen kann. Ferner können Aspekte von verschiedenen Entitäten ausgelöst, initiiert oder angefordert werden. In mindestens einer Ausführungsform kann das Training eines neuronalen Netzes von einem Provider angewiesen werden, der mit der Provider-Umgebung 506 verbunden ist, während in mindestens einer Ausführungsform kann das Training von einem Kunden oder einem anderen Benutzer, der über ein Client-Gerät 502 oder eine andere derartige Ressource Zugriff auf eine Provider-Umgebung hat, angefordert werden. In mindestens einer Ausführungsform können Trainingsdaten (oder Daten, die von einem trainierten neuronalen Netz analysiert werden sollen) von einem Provider, einem Benutzer oder einem Drittanbieter von Inhalten 524 bereitgestellt werden. In mindestens einer Ausführungsform kann das Client-Gerät 502 ein Fahrzeug oder ein Objekt sein, das zum Beispiel im Auftrag eines Benutzers navigiert werden soll, der die Navigation eines Geräts unterstützende Anfragen senden und/oder Befehle empfangen kann.
In mindestens einer Ausführungsform können Anfragen über mindestens ein Netzwerk 504 übermittelt werden, um von einer Provider-Umgebung 506 empfangen zu werden. In mindestens einer Ausführungsform kann ein Client-Gerät ein beliebiges geeignetes elektronisches Gerät und/oder ein beliebiger geeigneter Rechner sein, wie zum Beispiel Desktop-Computer, Notebook-Computer, Computerserver, Smartphones, Tablet-Computer, Spielkonsolen (tragbar oder anderweitig), Computerprozessoren, Computerlogik und Set-Top-Boxen, ohne auf diese beschränkt zu sein, das/der es einem Benutzer ermöglicht, solche Anfragen zu erzeugen und zu senden. Das oder die Netzwerke 504 können jedes geeignete Netzwerk für die Übertragung einer Anfrage oder anderer solcher Daten umfassen, wie zum Beispiel das Internet, ein Intranet, ein Ethernet, ein zellulares Netzwerk, ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), ein persönliches Netzwerk (PAN), ein Ad-hoc-Netzwerk direkter drahtloser Verbindungen zwischen Peers und so weiter.
In mindestens einer Ausführungsform können Anforderungen an einer Schnittstellenschicht 508 empfangen werden, welche in diesem Beispiel Daten an einen Trainings- und Inferenzmanager 532 weiterleiten kann. Der Trainings- und Inferenzmanager 532 kann ein System oder ein Dienst sein, der Hardware und Software zum Verwalten von Anforderungen und dienstzugehörigen Daten oder Inhalten umfasst. In mindestens einer Ausführungsform kann der Trainings- und Inferenzmanager 532 eine Anforderung zum Trainieren eines neuronalen Netzes empfangen und Daten für eine Anforderung an ein Trainingsmodul 512 liefern. In mindestens einer Ausführungsform kann das Trainingsmodul 512 ein geeignetes Modell oder neuronales Netz auswählen, das verwendet werden soll, wenn es nicht durch die Anforderung spezifiziert wurde, und kann ein Modell unter Verwendung relevanter Trainingsdaten trainieren. In mindestens einer Ausführungsform kann es sich bei den Trainingsdaten um einen Datenstapel handeln, welcher in einem Trainingsdatenspeicher 514 gespeichert ist, vom Client-Gerät 502 empfangen oder von einem Drittanbieter 524 bezogen wird. In mindestens einer Ausführungsform kann das Trainingsmodul 512 für Trainieren der Daten verantwortlich sein. Ein neuronales Netz kann ein beliebiges geeignetes Netzwerk sein, wie beispielsweise ein rekurrentes neuronales Netz (RNN) oder ein faltbares neuronales Netz (CNN). Sobald ein neuronales Netz trainiert und erfolgreich evaluiert wurde, kann ein trainiertes neuronales Netz zum Beispiel in einem Modellspeicher 516 gespeichert werden, in dem verschiedene Modelle oder Netze für Benutzer, Anwendungen oder Dienste usw. gespeichert werden können. In mindestens einer Ausführungsform kann es mehrere Modelle für eine einzelne Anwendung oder Entität geben, die auf der Grundlage einer Reihe verschiedener Faktoren verwendet werden können.
In mindestens einer Ausführungsform kann zu einem späteren Zeitpunkt eine Anforderung von dem Client-Gerät 502 (oder einer anderen derartigen Vorrichtung) für Inhalte (z. B. Pfadbestimmungen) oder Daten empfangen werden, die zumindest teilweise von einem trainierten neuronalen Netz bestimmt oder beeinflusst werden. Diese Anforderung kann beispielsweise Eingabedaten umfassen, die mit einem neuronalen Netz verarbeitet werden sollen, um eine oder mehrere Schlussfolgerungen oder andere Ausgabewerte, Klassifizierungen oder Vorhersagen zu erhalten, oder bei mindestens einer Ausführungsform können Eingabedaten von der Schnittstellenschicht 508 empfangen und an das Schlussfolgerungsmodul 518 weitergeleitet werden, obwohl auch ein anderes System oder ein anderer Dienst verwendet werden kann. In mindestens einer Ausführungsform kann das Inferenzmodul 518 ein geeignetes trainiertes Netzwerk, wie zum Beispiel ein trainiertes tiefes neuronales Netz (DNN), wie hierin beschrieben, aus dem Modellspeicher 516 beziehen, wenn es nicht bereits lokal im Inferenzmodul 518 gespeichert ist. Das Inferenzmodul 518 kann Daten als Eingabe für ein trainiertes Netzwerk bereitstellen, das dann eine oder mehrere Schlussfolgerungen als Ausgabe erzeugen kann. Dies kann zum Beispiel eine Klassifizierung einer Instanz von Eingabedaten beinhalten. In mindestens einer Ausführungsform können die Schlussfolgerungen dann an das Client-Gerät 502 übertragen werden, um einem Benutzer angezeigt oder auf andere Weise mitgeteilt zu werden. In mindestens einer Ausführungsform können Kontextdaten für einen Benutzer auch in einem Benutzerkontextdatenspeicher 522 gespeichert werden, der Daten über einen Benutzer enthalten kann, die als Eingabe für ein Netzwerk beim Erzeugen von Schlussfolgerungen oder beim Bestimmen von Daten nützlich sein können, die nach dem Erhalten von Instanzen an einen Benutzer zurückgegeben werden. In mindestens einer Ausführungsform können relevante Daten, die zumindest einige Eingabe- oder Schlussfolgerungsdaten enthalten können, auch in einer lokalen Datenbank 534 für die Verarbeitung künftiger Anfragen gespeichert werden. In mindestens einer Ausführungsform kann ein Benutzer Kontoinformationen oder andere Informationen nutzen, um auf Ressourcen oder Funktionen einer Provider-Umgebung zuzugreifen. In mindestens einer Ausführungsform können, sofern zulässig und verfügbar, auch Benutzerdaten gesammelt und zum weiteren Trainieren von Modellen verwendet werden, um genauere Schlussfolgerungen für künftige Anfragen zu ziehen. In mindestens einer Ausführungsform können Anfragen über eine Benutzerschnittstelle zu einer Anwendung für maschinelles Lernen (526), ausgeführt auf dem Client-Gerät 502 ausgeführt, empfangen und die Ergebnisse über dieselbe Schnittstelle angezeigt werden. Ein Client-Gerät kann Ressourcen wie einen Prozessor 528 und einen Speicher 562 zur Erzeugung einer Anfrage und zur Verarbeitung von Ergebnissen oder einer Antwort sowie mindestens ein Datenspeicherelement 552 zur Speicherung von Daten für die Anwendung des maschinellen Lernens 526 enthalten.
In mindestens einer Ausführungsform ist ein Prozessor 528 (oder ein Prozessor des Trainingsmoduls 512 oder Inferenzmoduls 518) eine zentrale Verarbeitungseinheit (CPU). Wie bereits erwähnt, können jedoch Ressourcen in solchen Umgebungen GPUs verwenden, um Daten für zumindest bestimmte Arten von Anfragen zu verarbeiten. Mit Tausenden von Kernen sind GPUs, wie zum Beispiel die PPU 300, für die Bewältigung beträchtlicher paralleler Arbeitslasten ausgelegt und haben sich daher beim Deep Learning für das Training neuronaler Netze und die Erstellung von Vorhersagen durchgesetzt. Während die Verwendung von GPUs für Offline-Builds ein schnelleres Training größerer und komplexerer Modelle ermöglicht hat, impliziert die Offline-Erstellung von Vorhersagen, dass entweder Eingabe-Features zur Anfragezeit nicht verwendet werden können oder Vorhersagen für alle Permutationen von Features generiert und in einer Nachschlagetabelle gespeichert werden müssen, um Echtzeit-Anfragen zu bedienen. Wenn ein Deep-Learning-Framework einen CPU-Modus unterstützt und ein Modell klein und einfach genug ist, um eine Vorwärtskopplung (feed-forward) auf einer CPU mit einer angemessenen Latenz durchzuführen, dann könnte ein Dienst auf einer CPU-Instanz ein Modell hosten. In diesem Fall kann das Training offline auf einer GPU und die Inferenz in Echtzeit auf einer CPU durchgeführt werden. Wenn ein CPU-Ansatz nicht praktikabel ist, dann kann ein Dienst auf einer GPU-Instanz laufen. Da GPUs jedoch andere Leistungen und Kosten als CPUs haben, muss ein Dienst, welcher einen Laufzeitalgorithmus auf eine GPU auslagert, möglicherweise anders konzipiert werden als ein CPU-basierter Dienst.
In mindestens einer Ausführungsform können Videodaten vom Client-Gerät 502 zum Zwecke der Verbesserung in der Provider-Umgebung 506 bereitgestellt werden. In mindestens einer Ausführungsform können Videodaten auf dem Client-Gerät 502 zum Zwecke der Verbesserung verarbeitet werden. In mindestens einer Ausführungsform können Videodaten von einem Drittanbieter von Inhalten 524 gestreamt und vom Drittanbieter von Inhalten 524, von der Provider-Umgebung 506 oder von dem Client-Gerät 502 verbessert werden. In mindestens einer Ausführungsform können Videodaten vom Client-Gerät 502 für die Verwendung als Trainingsdaten in der Provider-Umgebung 506 bereitgestellt werden.
In mindestens einer Ausführungsform kann überwachtes und/oder unüberwachtes Lernen durch das Client-Gerät 502 und/oder die Provider-Umgebung 506 durchgeführt werden. In mindestens einer Ausführungsform wird ein Satz von Trainingsdaten 514 (z. B. klassifizierte oder gekennzeichnete Daten) als Eingabe bereitgestellt, um als Trainingsdaten zu fungieren. In einer Ausführungsform kann der Trainingsdatensatz verwendet werden, um ein oder mehrere neuronale Netze innerhalb des neuronale Kontrollvariablen-Netzsystems 100 zu trainieren. In mindestens einer Ausführungsform können die Trainingsdaten Instanzen mindestens eines Objekttyps, für den ein neuronales Netz trainiert werden soll, sowie Informationen enthalten, die diesen Objekttyp identifizieren. In mindestens einer Ausführungsform könnten die Trainingsdaten einen Satz von Bildern umfassen, welche jeweils eine Darstellung eines Objekttyps enthalten, wobei jedes Bild auch eine Kennzeichnung, Metadaten, eine Klassifizierung oder andere Informationen, die einen in einem entsprechenden Bild dargestellten Objekttyp identifizieren, enthält oder damit verknüpft ist. Verschiedene andere Datentypen können ebenfalls als Trainingsdaten verwendet werden, wie zum Beispiel Textdaten, Audiodaten, Videodaten usw. In mindestens einer Ausführungsform werden Trainingsdaten 514 als Trainingseingabe für ein Trainingsmodul 512 bereitgestellt. In mindestens einer Ausführungsform kann das Trainingsmodul 512 ein System oder ein Dienst sein, der Hardware und Software umfasst, wie zum Beispiel ein oder mehrere Rechner, die eine Trainingsanwendung ausführen, um ein neuronales Netz (oder ein anderes Modell oder einen Algorithmus usw.) zu trainieren. In mindestens einer Ausführungsform empfängt das Trainingsmodul 512 einen Befehl oder eine Anfrage, der/die einen Typ von Modell angibt, der für das Training verwendet werden soll, in mindestens einer Ausführungsform kann ein Modell ein beliebiges geeignetes statistisches Modell, Netz oder ein Algorithmus sein, das/der für solche Zwecke nützlich ist, wie beispielsweise ein künstliches neuronales Netz, ein Deep-Learning-Algorithmus, ein lernender Klassifikator, ein Bayes'sches Netz usw. In mindestens einer Ausführungsform kann das Trainingsmodul 512 ein Ausgangsmodell oder ein anderes untrainiertes Modell aus einem geeigneten Magazin 516 auswählen und Trainingsdaten 514 verwenden, um ein Modell zu trainieren, womit ein trainiertes Modell (z. B. ein trainiertes tiefes neuronales Netz) erzeugt wird, welches zur Klassifizierung ähnlicher Datentypen oder zur Erzeugung anderer derartiger Inferenzen genutzt werden kann. In mindestens einer Ausführungsform, in der keine Trainingsdaten verwendet werden, kann dennoch ein geeignetes Ausgangsmodell für das Training auf Eingangsdaten per Trainingsmodul 512 ausgewählt werden.
In mindestens einer Ausführungsform kann ein Modell auf verschiedene Weise trainiert werden, die zum Teil von einem Typ des gewählten Modells abhängen kann. In mindestens einer Ausführungsform kann einem Machine-Learning-Algorithmus ein Trainingsdatensatz bereitgestellt werden, wobei ein Modell ein Modellartefakt ist, das durch einen Trainingsprozess erstellt wurde. In mindestens einer Ausführungsform enthält jede Instanz von Trainingsdaten eine richtige Antwort (z. B. Klassifizierung), welche als Ziel oder Zielattribut bezeichnet werden kann. In mindestens einer Ausführungsform findet ein Lernalgorithmus Muster in den Trainingsdaten, die Eingabedatenattribute auf ein Ziel, eine vorherzusagende Antwort, abbilden, und es wird ein Machine-Learning-Modell ausgegeben, das diese Muster erfasst. In mindestens einer Ausführungsform kann ein Machine-Learning-Modell dann verwendet werden, um Vorhersagen für neue Daten zu erhalten, für die ein Ziel nicht spezifiziert ist.
In mindestens einer Ausführungsform kann der Trainings- und Inferenzmanager 532 aus einem Satz von Machine-Learning-Modellen, einschließlich binärer Klassifikation, Multiklassenklassifikation, generativer und Regressionsmodelle, auswählen. In mindestens einer Ausführungsform kann der Typ des zu verwendenden Modells zumindest teilweise von einer Art des vorherzusagenden Ziels abhängen.
Grafikverarbeitungspipeline
In einer Ausführungsform umfasst die PPU 400 eine Grafikverarbeitungseinheit (GPU). Die PPU 400 ist konfiguriert, Befehle zu empfangen, die Shader-Programme zur Verarbeitung von Grafikdaten spezifizieren. Grafikdaten können als ein Satz von Primitiven wie Punkte, Linien, Dreiecke, Vierecke, Dreiecksstreifen und dergleichen definiert werden. Typischerweise enthält ein Primitiv Daten, welche eine Anzahl von Eckpunkten für das Primitiv (z. B. in einem Modellraum-Koordinatensystem) sowie Attribute, die jedem Eckpunkt des Primitivs zugeordnet sind, spezifizieren. Die PPU 400 kann ausgelegt sein, die Grafikprimitive zu verarbeiten, um einen Bildspeicher zu erzeugen (z. B. Pixeldaten für jedes der Pixel der Anzeige).
Eine Anwendung schreibt Modelldaten für eine Szene (z. B. eine Sammlung von Eckpunkten und Attributen) in einen Speicher, wie einen Systemspeicher oder Speicher 404. Die Modelldaten definieren jedes der Objekte, welche auf einer Anzeige sichtbar sein können. Die Anwendung tätigt dann einen API-Aufruf an den Treiberkern, der die Modelldaten zum Rendern und Anzeigen anfordert. Der Treiberkern liest die Modelldaten und schreibt Befehle in den einen oder die mehreren Streams, um Operationen zur Verarbeitung der Modelldaten durchzuführen. Die Befehle können auf verschiedene auf den Verarbeitungseinheiten innerhalb der PPU 400 zu implementierenden Shader-Programme verweisen, einschließlich eines oder mehrerer Eckpunkt-, Hull-, Domain-, Geometrie-Shader und eines Pixel-Shaders. Beispielsweise können ein oder mehrere der Verarbeitungseinheiten konfiguriert sein, ein Eckpunkt-Shader-Programm auszuführen, welches eine durch die Modelldaten definierte Anzahl von Eckpunkten verarbeitet. In einer Ausführungsform können die verschiedenen Verarbeitungseinheiten konfiguriert sein, verschiedene Shader-Programme gleichzeitig auszuführen. Beispielsweise kann eine erste Teilmenge von Verarbeitungseinheiten eingerichtet sein, ein Eckpunkt-Shader-Programm auszuführen, während eine zweite Teilmenge von Verarbeitungseinheiten eingerichtet sein kann, ein Pixel-Shader-Programm auszuführen. Die erste Teilmenge von Verarbeitungseinheiten verarbeitet Eckpunktdaten, um verarbeitete Eckpunktdaten zu erzeugen, und schreibt die verarbeiteten Eckpunktdaten in den L2-Cache 460 und/oder den Speicher 404. Nachdem die verarbeiteten Eckpunktdaten gerastert (z. B. von dreidimensionalen Daten in zweidimensionale Daten im Bildschirmraum transformiert) wurden, um Fragmentdaten zu erzeugen, führt die zweite Teilmenge von Verarbeitungseinheiten einen Pixel-Shader aus, um verarbeitete Fragmentdaten zu erzeugen, welche dann mit anderen verarbeiteten Fragmentdaten gemischt und in den Bildspeicher im Speicher 404 geschrieben werden. Das Eckpunkt-Shader-Programm und das Pixel-Shader-Programm können gleichzeitig ausgeführt werden und verschiedene Daten aus derselben Szene in einer Pipeline verarbeiten, bis alle Modelldaten für die Szene in den Bildspeicher gerendert wurden. Dann wird der Inhalt des Bildspeichers an einen Display-Controller zur Anzeige auf einem Display-Gerät übertragen.
6A zeigt ein konzeptionelles Schema einer Grafikverarbeitungspipeline 600, die durch die PPU von 4 gemäß einer Ausführungsform implementiert ist. Die Grafikverarbeitungspipeline 600 ist ein abstraktes Flussdiagramm der Verarbeitungsschritte, die zur Erzeugung von computergenerierten 2D-Bildern aus 3D-Geometriedaten realisiert werden. Es ist bekannt, dass Pipeline-Architekturen Operationen mit langer Latenzzeit effizienter durchführen können, indem sie die Operation in eine Vielzahl von Phasen aufteilen, wobei der Ausgang jeder Phase mit dem Eingang der nächstfolgenden Phase gekoppelt ist. So empfängt die Grafikverarbeitungspipeline 600 Eingabedaten 601, welche von einer Phase zur nächsten Phase der Grafikverarbeitungspipeline 600 übertragen werden, um Ausgabedaten 602 zu erzeugen. In einer Ausführungsform kann die Grafikverarbeitungspipeline 600 eine Grafikverarbeitungspipeline darstellen, welche durch die OpenGL®-API definiert ist. Optional kann die Grafikverarbeitungspipeline 600 im Kontext der Funktionalität und Architektur der vorhergehenden Figuren und/oder jeder/aller nachfolgenden Figur/en implementiert sein.
Wie in 6A gezeigt, umfasst die Grafikverarbeitungspipeline 600 eine Pipeline-Architektur, die eine Reihe von Phasen enthält. Die Phasen umfassen unter anderem eine Datenassemblierungsphase 610, eine Eckpunkt-Shading-Phase 620, eine Primitivassemblierungsphase 630, eine Geometrie-Shading-Phase 640, eine Viewport-Skalierungs-, Cull- und Clip-Phase (VSCC) 650, eine Rasterungsphase 660, eine Fragment-Shading-Phase 670 und eine Rasteroperationsphase 680. In einer Ausführungsform umfassen die Eingabedaten 601 Befehle, welche die Verarbeitungseinheiten konfigurieren, um die Phasen der Grafikverarbeitungspipeline 600 und grafische Primitive (z. B. Punkte, Linien, Dreiecke, Vierecke, Dreiecksstreifen oder Dreiecksfächer usw.) zu implementieren, welche von den Phasen verarbeitet werden sollen. Die Ausgabedaten 602 können Pixeldaten (z. B. Farbdaten) umfassen, welche in einen Bildspeicher oder eine andere Art von Oberflächendatenstruktur in einem Speicher kopiert sind.
Die Datenassemblierungsphase 610 empfängt die Eingabedaten 601, welche Eckpunktdaten für Oberflächen höherer Ordnung, Primitive oder Ähnliches spezifizieren. Die Datenassemblierungsphase 610 sammelt die Eckpunktdaten in einem temporären Speicher oder einer Warteschlange, zum Beispiel durch Empfangen eines Befehls vom Host-Prozessor, der einen Zeiger auf einen Puffer im Speicher enthält, und Lesen der Eckpunktdaten aus dem Puffer. Die Eckpunktdaten werden dann zur Verarbeitung an die Eckpunkt-Shading-Phase 620 übertragen.
Die Eckpunkt-Shading-Phase 620 verarbeitet Eckpunktdaten, indem sie einen Satz von Operationen (z. B. einen Eckpunkt-Shader oder ein Programm) für jeden der Eckpunkte einmal ausführt. Eckpunkte können beispielsweise als 4-Koordinaten-Vektor (z. B. <x, y, z, w>) angegeben werden, welcher mit einem oder mehreren Eckpunktattributen (z. B. Farbe, Texturkoordinaten, Oberflächennormale usw.) verknüpft ist. Die Eckpunkt-Shading-Phase 620 kann einzelne Eckpunktattribute wie Position, Farbe, Texturkoordinaten und dergleichen manipulieren. Anders ausgedrückt führt die Eckpunkt-Shading-Phase 620 Operationen an den Eckpunktkoordinaten oder anderen Eckpunktattributen durch, die mit einem Eckpunkt verknüpft sind. Solche Operationen umfassen üblicherweise Beleuchtungsoperationen (z. B. Ändern von Farbattributen für einen Eckpunkt) und Transformationsoperationen (z. B. Ändern des Koordinatenraums für einen Eckpunkt). Beispielsweise können Eckpunkte in einem Objektkoordinatenraum unter Verwendung von Koordinaten angegeben werden, welche durch Multiplikation der Koordinaten mit einer Matrix transformiert werden, die die Koordinaten aus dem Objektkoordinatenraum in einen Weltraum oder einen normalisierten Gerätekoordinatenraum (NCD) überträgt. Die Eckpunkt-Shading-Phase 620 erzeugt transformierte Eckpunktdaten, welche an die Primitivassemblierungsphase 630 übertragen werden.
Die Primitivassemblierungsphase 630 sammelt die von der Eckpunkt-Shading-Phase 620 ausgegebenen Eckpunkte und gruppiert die Eckpunkte in grafische Primitive zur Verarbeitung durch die Geometrie-Shading-Phase 640. Beispielsweise kann die Primitivassemblierungsphase 630 konfiguriert sein, alle drei aufeinanderfolgenden Eckpunkte als grafisches Primitiv (z. B. ein Dreieck) zur Übertragung an die Geometrie-Shading-Phase 640 zu gruppieren. In einigen Ausführungsformen können bestimmte Eckpunkte für aufeinanderfolgende grafische Primitive wiederverwendet werden (z. B. können sich zwei aufeinanderfolgende Dreiecke in einem Dreiecksstreifen zwei Eckpunkte teilen). Die Primitivassemblierungsphase 630 überträgt grafische Primitive (z. B. eine Sammlung zugehöriger Eckpunkte) an die Geometrie-Shading-Phase 640.
Die Geometrie-Shading-Phase 640 verarbeitet grafische Primitive, indem sie eine Reihe von Operationen (z. B. einen Geometrie-Shader oder ein Programm) an den grafischen Primitiven durchführt. Tesselierungsoperationen können ein oder mehrere grafische Primitive aus jedem grafischen Primitiv erzeugen. Anders ausgedrückt kann die Geometrie-Shading-Phase 640 jedes grafische Primitiv in ein feineres Netz aus zwei oder mehr grafischen Primitiven unterteilen, das vom Rest der Grafikverarbeitungspipeline 600 verarbeitet wird. Die Geometrie-Shading-Phase 640 überträgt grafische Primitive an die Viewport-SCC-Phase 650.
In einer Ausführungsform kann die Grafikverarbeitungspipeline 600 in einem Streaming-Multiprozessor arbeiten, und die Eckpunkt-Shading-Phase 620, die Primitivassemblierungsphase 630, die Geometrie-Shading-Phase 640, die Fragment-Shading-Phase 670 und/oder die damit verknüpfte Hardware/Software können sequentiell Verarbeitungsoperationen durchführen. Sobald die sequentiellen Verarbeitungsoperationen abgeschlossen sind, kann in einer Ausführungsform die Viewport-SCC-Phase 650 die Daten verwenden. In einer Ausführungsform können Primitivdaten, welche von einer oder mehreren der Phasen in der Grafikverarbeitungspipeline 600 verarbeitet wurden, in einen Cache (z. B. L1-Cache, einen Eckpunkt-Cache usw.) geschrieben werden. In diesem Fall kann in einer Ausführungsform die Viewport-SCC-Phase 650 auf die Daten im Cache zugreifen. In einer Ausführungsform sind die Viewport-SCC-Phase 650 und die Rasterungsphase 660 als Schaltungen mit fester Funktion implementiert.
Die Viewport-SCC-Phase 650 führt Viewport-Skalierung, Culling und Clipping der grafischen Primitive durch. Jede Oberfläche, auf die gerendert wird, ist mit einer abstrakten Kameraposition verknüpft. Die Kameraposition stellt den Standort eines Betrachters dar, der auf die Szene blickt, und definiert einen Viewing-Frustum, welcher die Objekte der Szene umschließt. Der Viewing-Frustum kann eine Betrachtungsebene, eine hintere Ebene und vier Clipping-Ebenen umfassen. Jedes grafische Primitiv, welches vollständig außerhalb des Viewing-Frustums liegt, kann aussortiert (z. B. verworfen) werden, da das grafische Primitiv nicht zur endgültigen gerenderten Szene beiträgt. Jedes grafische Primitiv, welches sich teilweise innerhalb und teilweise außerhalb des Viewing-Frustums befindet, kann abgeschnitten werden (z. B. in ein neues grafisches Primitiv, welches sich innerhalb des Viewing-Frustums befindet, umgewandelt werden). Darüber hinaus können grafische Primitive jeweils auf der Grundlage einer Tiefe des Viewing-Frustums skaliert werden. Alle potentiell sichtbaren grafischen Primitive werden dann an die Rasterungsphase 660 übertragen.
Die Rasterungsphase 660 konvertiert die grafischen 3D-Primitive in 2D-Fragmente (die zum Beispiel für die Anzeige verwendet werden können usw.). Die Rasterungsphase 660 kann konfiguriert sein, die Eckpunkte der grafischen Primitive zu verwenden, um einen Satz von Ebenengleichungen aufzustellen, aus denen verschiedene Attribute interpoliert werden können. Die Rasterungsphase 660 kann auch eine Abdeckungsmaske für eine Vielzahl von Pixeln berechnen, die anzeigt, ob eine oder mehrere Abtastpositionen für das Pixel das grafische Primitiv schneiden. In einer Ausführungsform kann auch eine z-Prüfung durchgeführt werden, um festzustellen, ob das grafische Primitiv von anderen grafischen Primitiven, welche bereits gerastert wurden, verdeckt wird. Die Rasterungsphase 660 erzeugt Fragmentdaten (z. B. interpolierte Eckpunktattribute, die mit einer bestimmten Abtastposition für jedes abgedeckte Pixel verbunden sind), welche an die Fragment-Shading-Phase 670 übertragen werden.
Die Fragment-Shading-Phase 670 verarbeitet Fragmentdaten, indem sie eine Reihe von Operationen (z. B. einen Fragment-Shader oder ein Programm) auf jedem der Fragmente ausführt. Die Fragment-Shading-Phase 670 kann Pixeldaten (z. B. Farbwerte) für das Fragment erzeugen, beispielsweise durch Ausführen von Beleuchtungsoperationen oder Abtasten von Textur-Maps unter Verwendung interpolierter Texturkoordinaten für das Fragment. Die Fragment-Shading-Phase 670 erzeugt Pixeldaten, welche an die Rasteroperationsphase 680 übertragen werden.
Die Rasteroperationsphase 680 kann verschiedene Operationen an den Pixeldaten durchführen, zum Beispiel Alphatests, Schablonentests und das Mischen der Pixeldaten mit anderen Pixeldaten, welche anderen Fragmenten entsprechen, die mit dem Pixel verknüpft sind. Wenn die Rasteroperationsphase 680 die Verarbeitung der Pixeldaten (z. B. der Ausgabedaten 602) abgeschlossen hat, können die Pixeldaten in ein Rendering-Ziel geschrieben werden, wie beispielsweise einen Bildspeicher, einen Farbspeicher oder ähnliches.
Es versteht sich, dass eine oder mehrere zusätzliche Phasen in die Grafikverarbeitungspipeline 600 zusätzlich zu oder anstelle einer oder mehrerer der oben beschriebenen Phasen aufgenommen werden können. Verschiedene Implementierungen der abstrakten Grafikverarbeitungspipeline können unterschiedliche Phasen realisieren. Darüber hinaus können eine oder mehrere der oben beschriebenen Phasen in einigen Ausführungsformen aus der Grafikverarbeitungspipeline ausgeschlossen werden (z. B. die Geometrie-Shading-Phase 640). Andere Arten von Grafikverarbeitungspipelines sind im Rahmen des Umfangs der vorliegenden Erfindung denkbar. Darüber hinaus kann jede der Phasen der Grafikverarbeitungspipeline 600 durch eine oder mehrere dedizierte Hardwareeinheiten innerhalb eines Grafikprozessors wie der PPU 300 implementiert sein. Andere Phasen der Grafikverarbeitungspipeline 600 können durch programmierbare Hardwareeinheiten wie der Verarbeitungseinheit der PPU 300 implementiert sein.
Die Grafikverarbeitungspipeline 600 kann über eine Anwendung implementiert sein, die von einem Host-Prozessor, wie zum Beispiel einer CPU, ausgeführt wird. In einer Ausführungsform kann ein Gerätetreiber eine Anwendungsprogrammierschnittstelle (API) implementieren, welche verschiedene Funktionen definiert, die von einer Anwendung verwendet werden können, um grafische Daten für die Anzeige zu erzeugen. Der Gerätetreiber ist ein Softwareprogramm, das eine Vielzahl von Befehlen enthält, welche den Betrieb der PPU 400 steuern. Die API stellt eine Abstraktion für einen Programmierer bereit, die es ihm ermöglicht, spezialisierte Grafikhardware wie die PPU 400 zur Erzeugung der grafischen Daten einzusetzen, ohne dass der Programmierer den spezifischen Befehlssatz für die PPU 400 verwenden muss. Die Anwendung kann einen API-Aufruf enthalten, welcher an den Gerätetreiber für die PPU 400 weitergeleitet wird. Der Gerätetreiber interpretiert den API-Aufruf und führt verschiedene Operationen aus, um auf den API-Aufruf zu reagieren. In einigen Fällen kann der Gerätetreiber Operationen durch Ausführen von Befehlen auf der CPU durchführen. In anderen Fällen kann der Gerätetreiber, zumindest teilweise, Operationen durchführen, indem er Operationen auf der PPU 400 unter Verwendung einer Eingabe-/Ausgabeschnittstelle zwischen der CPU und der PPU startet. In einer Ausführungsform ist der Gerätetreiber ausgelegt, die Grafikverarbeitungspipeline 600 unter Verwendung der Hardware der PPU 400 zu implementieren.
Innerhalb der PPU 400 können verschiedene Programme ausgeführt werden, um die verschiedenen Phasen der Grafikverarbeitungspipeline 600 zu realisieren. Zum Beispiel kann der Gerätetreiber einen Kernel auf der PPU 400 starten, um die Eckpunkt-Shading-Phase 620 auf einer Verarbeitungseinheit (oder mehreren Verarbeitungseinheiten) auszuführen. Der Gerätetreiber (oder der von der PPU 400 ausgeführte initiale Kernel) kann auch andere Kernel auf der PPU 400 starten, um andere Phasen der Grafikverarbeitungspipeline 600, wie beispielsweise die Geometrie-Shading-Phase 640 und die Fragment-Shading-Phase 670 auszuführen. Darüber hinaus können einige der Phasen der Grafikverarbeitungspipeline 600 auf fester Hardware implementiert sein, wie beispielsweise einem Rasterizer oder einem Datenassembler, implementiert in der PPU 400. Es versteht sich, dass die Ergebnisse eines Kernels von einer oder mehreren zwischengeschalteten Hardwareeinheiten mit fester Funktion verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf einer Verarbeitungseinheit verarbeitet werden.
Bilder, welche unter Anwendung einer oder mehrerer der hier offenbarten Techniken erzeugt wurden, können auf einem Monitor oder einem anderen Anzeigegerät angezeigt werden. In einigen Ausführungsformen kann das Anzeigegerät direkt mit dem System bzw. Prozessor gekoppelt sein, der die Bilder erzeugt oder wiedergibt. In anderen Ausführungsformen kann das Anzeigegerät g indirekt mit dem System bzw. Prozessor gekoppelt sein, beispielsweise über ein Netzwerk. Beispiele für solche Netzwerke sind das Internet, mobile Telekommunikationsnetzwerke, ein WIFI-Netzwerk sowie jedes andere drahtgebundene und/oder drahtlose Netzwerksystem. Wenn das Anzeigegerät indirekt gekoppelt ist, können die vom System oder Prozessor erzeugten Bilder über das Netzwerk an das Anzeigegerät gestreamt werden. Ein solches Streaming ermöglicht es beispielsweise, dass Videospiele oder andere Anwendungen, die Bilder wiedergeben, auf einem Server, in einem Rechenzentrum oder in einer Cloud-basierten Rechenumgebung ausgeführt werden und die wiedergegebenen Bilder auf ein oder mehrere physisch vom Server oder Rechenzentrum getrennte Benutzergeräte (wie einen Computer, eine Videospielkonsole, ein Smartphone, ein anderes mobiles Gerät usw.) übertragen und angezeigt werden. Daher können die hier offenbarten Techniken zur Verbesserung der gestreamten Bilder und zur Verbesserung von Diensten, die Bilder streamen, wie NVIDIA GeForce Now (GFN), Google Stadia und dergleichen, eingesetzt werden.
Beispielhaftes Game-Streaming-System
6B zeigt ein beispielhaftes Game-Streaming-System gemäß einigen Ausführungsformen der vorliegenden Erfindung. 6B beinhaltet einen oder mehrere Spieleserver 603 (die ähnliche Komponenten, Merkmale und/oder Funktionen wie das beispielhafte Verarbeitungssystem 500 von 5A und/oder das Beispielsystem 565 von 5B enthalten können), ein oder mehrere Client-Geräte 604 (die ähnliche Komponenten, Merkmale und/oder Funktionen wie das beispielhafte Verarbeitungssystem 500 von 5A und/oder das Beispielsystem 565 von 5B enthalten können) und ein oder mehrere Netzwerke 606 (die ähnlich wie die hier beschriebenen Netzwerke sein können). In einigen Ausführungsformen der vorliegenden Erfindung kann das System 605 implementiert sein.
In dem System 605 können das eine oder die mehreren Client-Geräte 604 für eine Spielsitzung nur Eingabedaten als Reaktion auf Eingaben an das/die Eingabegerät/e empfangen, welche Eingabedaten an den/die Spieleserver 603 übertragen, kodierte Anzeigedaten von dem/den Spieleserver/n 603 empfangen und die Anzeigedaten auf der Anzeige 624 anzeigen. So werden die rechenintensiveren Berechnungen und Verarbeitungen auf den/die Spieleserver 603 verlagert (z. B. wird Rendering - insbesondere die Strahlen- oder Pfadverfolgung - für die grafische Ausgabe der Spielsitzung von der/den GPU/s des/der Spieleserver/s 603 ausgeführt). Anders ausgedrückt wird die Spielsitzung von dem/den Spieleserver/n 603 zu dem/den Client-Gerät/en 604 gestreamt, wodurch die Anforderungen des/der Client-Gerät/e 604 bezüglich Grafikverarbeitung und Rendering reduziert werden
Zum Beispiel kann ein Client-Gerät 604 in Bezug auf eine Instanziierung einer Spielsitzung einen Frame der Spielsitzung auf der Anzeige 624 basierend auf dem Empfang der Anzeigedaten von dem/den Spieleserver/n 603 anzeigen. Das Client-Gerät 604 kann eine Eingabe an eines der Eingabegeräte empfangen und als Reaktion Eingabedaten erzeugen. Das Client-Gerät 604 kann die Eingabedaten über die Kommunikationsschnittstelle 621 und über das/die Netzwerk/e 606 (z. B. das Internet) an den/die Spieleserver 603 übertragen, und der oder die Spieleserver 603 können die Eingabedaten über die Kommunikationsschnittstelle 618 empfangen. Die CPU/s können die Eingabedaten empfangen, die Eingabedaten verarbeiten und Daten an die GPU/s übertragen, die die GPU/s veranlassen, ein Rendering der Spielsitzung zu erzeugen. Die Eingabedaten können beispielsweise eine Bewegung einer Figur des Benutzers in einem Spiel, das Abfeuern einer Waffe, das Nachladen, das Passen eines Balls, das Wenden eines Fahrzeugs usw. darstellen. Die Rendering-Komponente 612 kann die Spielsitzung rendern (z. B. repräsentativ für das Ergebnis der Eingabedaten), und die Rendering-Erfassungskomponente 614 kann das Rendering der Spielsitzung als Anzeigedaten erfassen (z. B. als Bilddaten, die das gerenderte Bild der Spielsitzung erfassen). Das Rendering der Spielsitzung kann strahlen- oder pfadverfolgte Beleuchtung und/oder Schatteneffekte umfassen, welche unter Verwendung einer oder mehrerer Parallelverarbeitungseinheiten des/der Spieleserver/s 603 - wie zum Beispiel GPUs, die außerdem einen oder mehrere dedizierte Hardwarebeschleuniger oder Verarbeitungskerne zur Durchführung von Strahlen- oder Pfadverfolgungstechniken verwenden können - berechnet werden. Der Kodierer 616 kann dann die Anzeigedaten kodieren, um kodierte Anzeigedaten zu erzeugen, und die kodierten Anzeigedaten können über das/die Netzwerk/e 606 über die Kommunikationsschnittstelle 618 an das Client-Gerät 604 übertragen werden. Das Client-Gerät 604 kann die kodierten Anzeigedaten über die Kommunikationsschnittstelle 621 empfangen und der Decoder 622 kann die kodierten Anzeigedaten dekodieren, um die Anzeigedaten zu erzeugen. Das Client-Gerät 604 kann dann die Anzeigedaten über das Display 624 anzeigen.
Es wird darauf hingewiesen, dass die hier beschriebenen Techniken in ausführbaren Befehlen enthalten sein können, welche in einem computerlesbaren Medium zur Verwendung durch oder in Verbindung mit prozessorbasierten befehlsausführenden Maschinen, Systemen, Vorrichtungen oder Geräten gespeichert sind. Fachleute wissen, dass in einigen Ausführungsformen verschiedene Arten computerlesbarer Medien zur Speicherung von Daten verwendet werden können. Der hier verwendete Terminus „computerlesbares Medium“ umfasst ein oder mehrere beliebige geeignete Medien zum Speichern der ausführbaren Befehle eines Computerprogramms, so dass die befehlsausführenden Maschinen, Systeme, Vorrichtungen oder Geräte die Befehle von dem computerlesbaren Medium lesen (oder abrufen) und die Befehle zur Realisierung der beschriebenen Ausführungsformen ausführen können. Geeignete Speicherformate umfassen ein oder mehrere eines elektronischen, magnetischen, optischen und elektromagnetischen Formats. Eine nicht vollständige Liste konventioneller, beispielhafter computerlesbarer Medien umfasst: eine tragbare Computerdiskette, einen Direktzugriffsspeicher (RAM), einen Festwertspeicher (ROM), einen löschbaren programmierbaren Festwertspeicher (EPROM), eine Flash-Speichereinheit und optische Speichereinheiten, einschließlich einer tragbaren Compact Disc (CD), einer tragbaren digitalen Video-Disk (DVD) und dergleichen.
Es versteht sich, dass die in den beigefügten Figuren dargestellte Anordnung der Komponenten nur der Veranschaulichung dient und dass andere Anordnungen möglich sind. Beispielsweise können ein oder mehrere der hier beschriebenen Elemente ganz oder teilweise als elektronische Hardwarekomponente realisiert sein. Andere Elemente können in Software, Hardware oder einer Kombination aus Software und Hardware realisiert sein. Darüber hinaus können einige oder alle dieser anderen Elemente kombiniert werden, einige können insgesamt weggelassen werden, und es können zusätzliche Komponenten hinzugefügt werden, während die hier beschriebene Funktionalität dennoch erreicht wird. Somit kann der hier beschriebene Erfindungsgegenstand in vielen verschiedenen Variationen verkörpert sein, und alle solche Variationen fallen unter den Anwendungsbereich der Ansprüche.
Um das Verständnis für den hier beschriebenen Erfindungsgegenstand zu erleichtern, werden viele Aspekte in Form von Aktionsabfolgen beschrieben. Fachleute werden erkennen, dass die verschiedenen Aktionen durch spezielle Schaltungen oder Schaltkreise, durch Programmbefehle, welche von einem oder mehreren Prozessoren ausgeführt werden, oder durch eine Kombination von beiden erfolgen können. Die hier enthaltene Beschreibung einer Abfolge von Aktionen soll nicht bedeuten, dass die spezifische Reihenfolge, die für die Ausführung dieser Abfolge beschrieben wird, eingehalten werden muss. Alle hier beschriebenen Verfahren können, sofern hier nicht anders angegeben oder durch den Kontext eindeutig widerlegt, in jeder geeigneten Reihenfolge ausgeführt werden.
Die Verwendung der Termini „ein/eine“ und „der/die/das“ und ähnlicher Verweise im Zusammenhang mit der Beschreibung des Erfindungsgegenstands (insbesondere im Zusammenhang mit den folgenden Ansprüchen) ist so auszulegen, dass sie - sofern hier nicht anders angegeben oder durch den Kontext eindeutig widerlegt - sowohl die Einzahl als auch die Mehrzahl umfassen. Die Verwendung der Termini „mindestens/zumindest ein/eine“ gefolgt von einer Aufzählung von einem oder mehreren Objekten (z. B. „mindestens/zumindest ein/eine von A und B“) ist so auszulegen, dass - sofern hier nicht anders angegeben oder durch den Kontext eindeutig widerlegt - damit ein aus den aufgelisteten Objekten (A oder B) ausgewähltes Objekt oder eine beliebige Kombination von zwei oder mehreren der aufgelisteten Objekte (A und B) gemeint ist. Darüber hinaus dient die vorstehende Beschreibung nur der Veranschaulichung und nicht der Einschränkung, da der angestrebte Schutzumfang durch die nachstehend aufgeführten Ansprüche zusammen mit deren Äquivalenten definiert ist. Die Verwendung von Beispielen oder beispielhaften Ausdrücken (z. B. „wie“) dient lediglich der besseren Veranschaulichung des Erfindungsgegenstands und stellt keine Einschränkung des Umfangs dar, sofern nichts anderes beansprucht wird. Die Verwendung des Begriffs „basierend auf“ und anderer ähnlicher Ausdrücke, die eine Bedingung für das Herbeiführen eines Ergebnisses angeben, soll sowohl in den Ansprüchen als auch in der schriftlichen Beschreibung keine anderen Bedingungen ausschließen, die dieses Ergebnis herbeiführen. Keine Formulierung in der Beschreibung ist so auszulegen, dass sie ein nicht beanspruchtes Element als wesentlich für die Ausführung der beanspruchten Erfindung bezeichnet.

Claims

Computerimplementiertes Verfahren zum Konstruieren eines dreidimensionalen (3D-) Modells, umfassend: Rendern eines Bildes des 3D-Modells, welches durch eine Ausgangsgeometrie definiert ist, wobei eine Antialiasing-Operation, die von einer Rendering-Pipeline durchgeführt wird, Daten verarbeitet, die mit der Geometrie verknüpf sind, um das Bild zu antialiasieren; Berechnen von Pixeldifferenzen auf der Grundlage des Bildes und eines Referenzbildes; Rückwärtiges Propagieren der Pixeldifferenzen durch die Antialiasing-Operation der Rendering-Pipeline, um Geometrieänderungen zu berechnen, die einer Reduzierung der Pixeldifferenzen entsprechen; Anpassen der ursprünglichen Geometrie auf der Grundlage der Geometrieänderungen, um eine modifizierte Geometrie für das 3D-Modell zu erzeugen.
Computerimplementiertes Verfahren nach Anspruch 1, wobei die Ausgangsgeometrie durch Eckpunktpositionen definiert ist.
Computerimplementiertes Verfahren nach Anspruch 1 oder 2, wobei die Ausgangsgeometrie durch Gewichtungen definiert ist, die auf ein Basisnetz angewendet werden.
Computerimplementiertes Verfahren nach einem der vorangehenden Ansprüche, ferner umfassend Wiederholung des Renderns, Berechnens, Propagierens und Anpassens für mindestens ein zusätzliches Referenzbild.
Computerimplementiertes Verfahren nach Anspruch 4, wobei das Referenzbild und das mindestens eine zusätzliche Referenzbild jeweils mit einer anderen Kameraposition verknüpft sind.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei die Propagierung der Pixeldifferenzen ferner die Erzeugung einer dem 3D-Modell entsprechenden Oberflächentextur umfasst.
Computerimplementiertes Verfahren nach Anspruch 6, wobei die Oberflächentextur mindestens eine der Beleuchtungs- oder Materialeigenschaften des 3D-Modells darstellt.
Computerimplementierte Verfahren nach einem der vorhergehenden Ansprüche, wobei die Antialiasing-Operation folgende Schritte aufweist: Bestimmen, basierend auf den der Geometrie zugeordneten Daten, dass eine Silhouettenkante ein Paar benachbarter Pixel schneidet; Berechnen einer Überblendungsgewichtung zwischen den benachbarten Pixeln und Anpassen der Farben der benachbarten Pixel entsprechend der Überblendungsgewichtung.
Computerimplementiertes Verfahren nach Anspruch 8, wobei Bestimmen das Identifizieren der Silhouettenkante zwischen einer ersten gerenderten Geometrie, welche einer ersten Kennung zugeordnet ist, und einer zweiten gerenderten Geometrie, welche einer zweiten Kennung zugeordnet ist, umfasst.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei die Antialiasing-Operation ein Pixelintegral auf der Grundlage einer Position einer Silhouettenkante innerhalb des Pixels approximiert.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer der Schritte des Renderns, Berechnens, Propagierens und Anpassens in einer Cloud-Computing-Umgebung durchgeführt wird.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer der Schritte des Renderns, Berechnens, Verbreitens und Anpsassens auf einem Server oder in einem Datenzentrum durchgeführt wird, um das Bild und das 3D-Modell zu erzeugen, und mindestens eines von dem Bild und dem 3D-Modell zu einem Benutzergerät gestreamt wird.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer der Schritte des Renderns, Berechnens, Propagierens und Anpassens zum Trainieren, Testen oder Zertifizieren eines in einer Maschine, einem Roboter oder einem autonomen Fahrzeug eingesetzten neuronalen Netzes durchgeführt wird.
Computerimplementiertes Verfahren nach einem der vorhergehenden Ansprüche, wobei mindestens einer der Schritte des Renderns, Berechnens, Propagierens und Anpassens auf einer virtuellen Maschine durchgeführt wird, die einen Teil einer Grafikverarbeitungseinheit umfasst.
System, aufweisend: Prozessor, konfiguriert: ein Bild des 3D-Modells, welches durch eine Ausgangsgeometrie definiert ist, zu rendern, wobei eine Antialiasing-Operation, die von einer Rendering-Pipeline durchgeführt wird, mit der Geometrie verknüpfte Daten verarbeitet, um das Bild zu antialiasieren; Pixeldifferenzen basierend auf dem Bild und einem Referenzbild zu berechnen; Pixeldifferenzen rückwärts durch die Antialiasing-Operation der Rendering-Pipeline zu propagieren, um Geometrieänderungen zu berechnen, die einer Reduzierung der Pixeldifferenzen entsprechen; die Ausgangsgeometrie basierend auf den Geometrieänderungen anzupassen, um eine modifizierte Geometrie für das 3D-Modell zu erzeugen.
System nach Anspruch 15, ferner konfiguriert, ein Verfahren nach einem der Ansprüche 2 bis 14 durchzuführen.
Nicht-transitorisches computerlesbares Medium, welches Computerbefehle für die Konstruktion dreidimensionaler (3D-)Modelle speichert, die bei Ausführung durch einen oder mehrere Prozessoren den einen oder die mehreren Prozessoren veranlassen, die Schritte eines Verfahrens gemäß einem der Ansprüche 1 bis 14 durchzuführen.