DE102021118885A1

DE102021118885A1 - Maschinelles lernen zur steuerung von objektübergaben

Info

Publication number: DE102021118885A1
Application number: DE102021118885.7A
Authority: DE
Inventors: Wei Yang; Christopher Jason Paxton; Yu-Wei Chao; Dieter Fox
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2020-07-28
Filing date: 2021-07-21
Publication date: 2022-02-03
Anticipated expiration: 2041-07-22
Also published as: JP2022024952A; DE102021118885B4; CN114004329A; US11597078B2; US20220032454A1; US20230202031A1

Abstract

Ein Robotersteuerungssystem weist einen Roboter an, ein Objekt aus einem menschlichen Greifen zu nehmen, indem es ein Bild einer menschlichen Hand, die ein Objekt hält, erhält, die Pose der menschlichen Hand und des Objekts abschätzt und eine Greifpose für den Roboter bestimmt, die die menschliche Hand nicht beeinträchtigt. In mindestens einem Beispiel wird eine Tiefenkamera verwendet, um eine Punktwolke der menschlichen Hand, die das Objekt hält, zu erhalten. Die Punktwolke wird einem Deep Network bereitgestellt, das trainiert wird, um eine Greifpose für einen Robotergreifer zu generieren, der das Objekt aus der menschlichen Hand nehmen kann, ohne die Finger des Menschen zu quetschen oder zu berühren.

Description

HINTERGRUND
Die robotergestützte Automatisierung von Aufgaben ist ein wichtiger Entwicklungsbereich. Einige Aufgaben erfordern jedoch die Zusammenarbeit mit menschlichen Operatoren. Aufgaben wie die persönliche Pflege, die Übergabe von Objekten oder Schnittstellenoperationen zwischen robotischen und manuellen Aufgaben erfordern häufig eine Interaktion zwischen Roboter und Mensch. Ein Problem im Bereich der kollaborativen Aufgaben ist der Austausch von Objekten zwischen menschlichen Operatoren und Robotern. Bei der Ausführung einer Aufgabe kann es zu einem Austausch von Objekten zwischen Roboter und Mensch und/oder Mensch und Roboter kommen. Bei der Entnahme eines Objekts aus der Hand eines Menschen kann es zu Schwierigkeiten kommen, wenn der Roboter einen Griff wählt, der zwar ein Objekt zuverlässig greifen kann, aber mit der menschlichen Hand kollidiert. Dies kann dazu führen, dass der Roboter den Gegenstand fallenläßt und in einigen Fällen den menschlichen Operator verletzt. Daher ist die Entwicklung zuverlässiger Übergabetechniken, die es Robotern ermöglichen, Objekte von menschlichen Operatoren entgegenzunehmen, ein wichtiges Problem im Bereich der kollaborativen Aufgaben.
Figurenliste
Verschiedene Techniken werden unter Bezugnahme auf die Zeichnungen beschrieben, in welchen Folgendes gezeigt wird:

1 zeigt ein Beispiel für eine Pose einer Mensch-Roboter-Interaktion, bei der der Mensch ein Objekt mit der Handfläche nach unten ergreift, gemäß einem Ausführungsbeispiel;
2 zeigt ein Ausführungsbeispiel für eine Pose einer Mensch-Roboter-Interaktion, bei der der Mensch ein Objekt nach unten greift, gemäß einem Ausführungsbeispiel;
3 zeigt ein Beispiel für eine Pose einer Mensch-Roboter-Interaktion, bei der der Mensch ein Objekt mit der Handfläche nach oben greift, gemäß einem Ausführungsbeispiel;
4 zeigt ein Ausführungsbeispiel für eine Pose einer Mensch-Roboter-Interaktion, bei der der Mensch einen horizontalen Greifvorgang an einem Objekt ausführt, gemäß einem Ausführungsbeispiel;
5 zeigt ein Beispiel für ein Framework zur Durchführung einer Übergabe zwischen einem Roboter und einer menschlichen Hand, gemäß einem Ausführungsbeispiel;
6 zeigt ein Ausführungsbeispiel für eine Pose einer menschlichen Hand, die dazu verwendet werden kann, eine Übergabe eines Objekts von einem Roboter zu veranlassen, gemäß einem Ausführungsbeispiel;
7 zeigt ein Beispiel für Posen einer Hand, die zum Greifen eines Objekts verwendet werden können, gemäß einem Ausführungsbeispiel;
8A zeigt ein Beispiel für einen Robotergreifer, gemäß einem Ausführungsbeispiel;
8B zeigt ein Beispiel für einen Robotergreifer mit vier Fingern, gemäß einem Ausführungsbeispiel;
9 zeigt ein Beispiel für die Interaktion zwischen Roboter und Mensch, gemäß einem Ausführungsbeispiel;
10 zeigt Daten, die die Leistung eines Mensch-Roboter-Interaktionssystems beschreiben, gemäß einem Ausführungsbeispiel;
11 zeigt ein Beispiel für Handposen, die verwendet werden können, um einem Roboter ein Objekt zu präsentieren, gemäß einem Ausführungsbeispiel;
12 zeigt ein Beispiel für einen Prozess, der als Ergebnis der Ausführung durch ein Computersystem einen Transfer eines Objekts zwischen einem Roboter und einer menschlichen Hand durchführt, gemäß einem Ausführungsbeispiel;
13A illustriert eine Inferenz- und/oder Trainingslogik, gemäß mindestens einem Ausführungsbeispiel;
13B illustriert eine Inferenz- und/oder Trainingslogik, gemäß mindestens einem Ausführungsbeispiel;
14 illustriert ein Training und einen Einsatz eines neuronalen Netzwerks, gemäß mindestens einem Ausführungsbeispiel;
15 zeigt ein Beispiel für ein Rechenzentrumssystem, gemäß mindestens einem Ausführungsbeispiel;
16A zeigt ein Beispiel für ein autonomes Fahrzeug, gemäß mindestens einem Ausführungsbeispiel;
16B zeigt ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug von 16A, gemäß mindestens einem Ausführungsbeispiel;
16C zeigt ein Blockdiagramm, das eine Beispielsystemarchitektur für das autonome Fahrzeug von 16A darstellt, gemäß mindestens einem Ausführungsbeispiel;
16D zeigt ein Diagramm, das ein System für die Kommunikation zwischen dem/den Cloud-basierten Server(n) und dem autonomen Fahrzeug von 16A darstellt, gemäß mindestens einem Ausführungsbeispiel;
17 zeigt ein Blockdiagramm eines Computersystems, gemäß mindestens einem Ausführungsbeispiel;
18 zeigt ein Blockdiagramm eines Computersystems, gemäß mindestens einem Ausführungsbeispiel;
19 zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
20 zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
21A zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
21B zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
21C zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
21D zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
21E and 21F zeigen ein gemeinsames Programmiermodell, gemäß mindestens einem Ausführungsbeispiel;
22 zeigt beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, gemäß mindestens einem Ausführungsbeispiel;
23A and 23B zeigen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, gemäß mindestens einem Ausführungsbeispiel;
24A and 24B zeigen zusätzliche beispielhafte Grafikprozessorlogik, gemäß mindestens einem Ausführungsbeispiel;
25 zeigt ein Computersystem, gemäß mindestens einem Ausführungsbeispiel;
26A zeigt einen Parallelprozessor, gemäß mindestens einem Ausführungsbeispiel;
26B zeigt eine Partitionseinheit, gemäß mindestens einem Ausführungsbeispiel;
26C zeigt einen Verarbeitungscluster, gemäß mindestens einem Ausführungsbeispiel;
26D zeigt einen Grafik-Multiprozessor, gemäß mindestens einem Ausführungsbeispiel;
27 zeigt ein System mit Multi-Grafikverarbeitungseinheit (GPU), gemäß mindestens einem Ausführungsbeispiel;
28 zeigt einen Grafikprozessor, gemäß mindestens einem Ausführungsbeispiel;
29 ist ein Blockdiagramm einer Prozessor-Mikroarchitektur für einen Prozessor, gemäß mindestens einem Ausführungsbeispiel;
30 zeigt einen Prozessor für eine Deep-Learning-Anwendung, gemäß mindestens einem Ausführungsbeispiel;
31 zeigt ein Blockdiagramm eines beispielhaften neuromorphen Prozessors, gemäß mindestens einem Ausführungsbeispiel;
32 zeigt zumindest Teile eines Grafikprozessors, gemäß einem oder mehreren Ausführungsbeispielen;
33 zeigt zumindest Teile eines Grafikprozessors, gemäß einem oder mehreren Ausführungsbeispielen;
34 zeigt zumindest Teile eines Grafikprozessors, gemäß einem oder mehreren Ausführungsbeispielen;
35 zeigt ein Blockdiagramm einer Grafikverarbeitungs-Engine 3510 eines Grafikprozessors, gemäß mindestens einem Ausführungsbeispiel;
36 zeigt ein Blockdiagramm von zumindest Teilen eines Grafikprozessorkerns, gemäß mindestens einem Ausführungsbeispiel;
37A and 37B zeigen eine Thread-Ausführungslogik 3700, die ein Array von Verarbeitungselementen eines Grafikprozessorkems umfasst, gemäß mindestens einem Ausführungsbeispiel;
38 zeigt eine Parallelverarbeitungseinheit („PPU“), gemäß mindestens einem Ausführungsbeispiel;
39 zeigt einen allgemeinen Verarbeitungscluster („GPC“), gemäß mindestens einem Ausführungsbeispiel;
40 zeigt eine Speicherpartitionseinheit einer Parallelverarbeitungseinheit („PPU“), gemäß mindestens einem Ausführungsbeispiel; und
41 zeigt einen Streaming-Multiprozessor, gemäß mindestens einem Ausfiihrungsbeispiel.

DETAILLIERTE BESCHREIBUNG
Das vorliegende Dokument beschreibt ein bildgestütztes System, das es einem Roboter ermöglicht, ein von einer menschlichen Hand präsentiertes Objekt aufzunehmen. In einem Beispiel ergreift der Mensch ein Objekt und präsentiert es in einem mit einer Tiefenkamera überwachten Gesichtsfeld. Die Tiefenkamera nimmt ein 3-D-Bild der Hand auf, die das Objekt ergreift, und liefert es an das System. Das System erzeugt aus dem Bild eine Punktwolke und trennt einen Teil der Punktwolke, der der menschlichen Hand zugeordnet ist, von einem Teil der Punktwolke, der dem Objekt zugeordnet ist. Anhand dieser Informationen kann das System die Pose der menschlichen Hand und die Pose des Objekts bestimmen. Das System generiert eine Reihe von Griffen, die vom Roboter ausgeführt werden können, um das Objekt zu greifen, und wählt dann einen Griff aus der Reihe von Griffen aus, der die menschliche Hand nicht behindert. In einer Implementierung werden die menschlichen Griffe in verschiedene Arten von Handhaltungen klassifiziert, um das System bei der Auswahl eines geeigneten Robotergriffs zur Erlangung des Objekts zu unterstützen. In einer anderen Implementierung wird angesichts eines Datensatzes menschlicher Objektübergaben, die mit Grundwahrheiten für Hand- und Objektposen versehen sind, ein tiefes Netzwerk trainiert, das als Eingabe eine farbige Punktwolke nimmt, die von der Tiefenkamera beobachtet wird, um die menschliche Hand vom Objekt zu segmentieren und gute Griffe und Steuerungen für den Roboter vorzuschlagen, so dass er das Objekt von der menschlichen Hand aufnehmen kann, ohne die Finger des Menschen einzuklemmen. Die hier beschriebenen Techniken können in verschiedenen Ausführungsformen auf Systeme angewandt werden, bei denen Objekte von einem Roboter an einen anderen oder von einem Tier an einen Roboter übergeben werden, oder in einigen Beispielen, wenn ein Objekt von einem anderen Glied als der Hand eines Menschen genommen wird (z. B. beim Abnehmen eines Hutes).
Die Übergabe von Objekten zwischen Menschen und Robotern ist eine wichtige Fähigkeit von Robotern, die mit Menschen zusammenarbeiten. Sowohl die Übergabe von Roboter zu Mensch als auch die Übergabe von Mensch zu Roboter kann schwierig sein. Einige der hier beschriebenen Techniken beschreiben einen Ansatz für die Übergabe von Mensch zu Roboter, bei dem der Roboter dem Menschen auf halbem Weg entgegenkommt, indem er das Greifen des Objekts durch den Menschen klassifiziert und dementsprechend schnell eine Trajektorie plant, um das Objekt entsprechend der Absicht des Menschen aus dessen Hand zu nehmen. Mindestens ein Ausführungsbeispiel sammelt einen Datensatz zum menschlichen Greifen, der typische Arten des Haltens von Objekten mit verschiedenen Handformen und Posen abdeckt, und lernt ein Deep Learning Modell auf diesem Datensatz, um die Handgriffe in eine dieser Kategorien einzuordnen. Mindestens ein Ausführungsbeispiel stellt einen Planungs- und Ausführungsansatz bereit, der das Objekt entsprechend des detektierten Griffs und der Handposition von der menschlichen Hand übernimmt und bei einer Unterbrechung der Übergabe gegebenenfalls neu plant. Durch eine systematische Evaluierung zeigt das vorliegende Dokument, dass verschiedene Ausführungsbeispiele zu verbesserten Übergaben im Vergleich zu zwei Basislinien führen.
Die Übergabe und Entgegennahme von Objekten an bzw. von Menschen sind grundlegende Fähigkeiten für kollaborierende Roboter in allen Anwendungsbereichen, von der Fertigung bis hin zur körperlichen Unterstützung im Haushalt. Einige Techniken konzentrieren sich auf die Übergabe von Objekten vom Roboter an den Menschen, wobei davon ausgegangen wird, dass der Mensch das Objekt für den Rücktransport einfach in den Greifer des Roboters legen kann. Dieser Ansatz ist manchmal nicht durchführbar, wenn der Mensch sich auf seine Aufgabe konzentrieren muss, wie z. B. bei einer Operation, oder wenn er aufgrund einer Behinderung in seiner Mobilität und Armbewegung eingeschränkt ist. Daher stellt mindestens ein Ausführungsbeispiel eine reaktivere Übergabe bereit, die sich an die Art und Weise anpassen kann, wie der Mensch dem Roboter das Objekt präsentiert, und ihm auf halbem Weg entgegenkommt, um das Objekt zu nehmen.
In mindestens einem Ausführungsbeispiel ist eine der Herausforderungen eine Übergabe von Mensch zu Roboter reaktiv zu gestalten, die zuverlässige und kontinuierliche Wahrnehmung des Objekts und des Menschen. In mindestens einem Ausführungsbeispiel werden die Pose einer menschlichen Hand sowie die Pose eines 6D-Objekts mit Hilfe von Verfahren der computergestützten Vision abgeschätzt. Es können verschiedene Techniken verwendet werden, die auch solche umfassen, die die Handpose und die Objektpose separat abschätzen. Mindestens einige Ausführungsbeispiele schätzen die Handpose und des Objekts ab, während die Hand mit dem Objekt interagiert.
In mindestens einem Ausführungsbeispiel befassen sich die hier beschriebenen Techniken mit dem Wahmehmungsproblem bei Übergaben von Mensch zu Roboter, indem sie es als Klassifizierungsproblem für das Greifen von Händen formulieren. In einem Beispiel unterteilen die Techniken die Art und Weise, wie Menschen kleine Objekte halten können, in mehrere Kategorien, und es wird ein Datensatz gesammelt, um ein Deep-Learning-Modell zu erlernen, das eine gegebene menschliche Hand, die ein Objekt hält, in eine dieser Greifkategorien klassifiziert. Die Aufgabe der Übergabe wird als robustes logisch-dynamisches System modelliert, das Bewegungspläne generiert, die den Kontakt zwischen dem Greifer und der menschlichen Hand vermeiden, wenn die Klassifizierung des menschlichen Greifens gegeben ist. Mindestens ein Ausführungsbeispiel wird mit zwei Verfahren verglichen, von denen das eine ohne Inferenz der Pose einer menschlichen Hand auskommt und das andere auf einer unabhängigen Abschätzung der Hand- und Objektpose beruht. Mindestens ein Ausführungsbeispiel demonstriert die höhere Erfolgsrate und Zeiteffizienz unseres Ansatzes gegenüber den beiden Basisverfahren. Es wird eine Benutzerstudie vorgestellt (N=9), die die Effektivität mit naiven Benutzern demonstriert, sowohl während sie auf den Roboter aufmerksam sind als auch während sie sich auf eine sekundäre Aufgabe konzentrieren.
Mindestens ein Ausführungsbeispiel stellt einen visionsbasierten, zuverlässigen Algorithmus bereit, der für die Aufgabe der Übergabe von Mensch zu Roboter oder von Roboter zu Roboter Griffe generieren kann, um Kollisionen zu vermeiden, z. B. wie Roboter Gegenstände von Menschen oder anderen Robotern übernehmen können. Mindestens ein Ausführungsbeispiel passt die Art und Weise an, wie der Roboter ein Objekt greift, basierend darauf, wie das Objekt von einer menschlichen Hand gehalten wird. Dadurch wird in mindestens einem Ausführungsbeispiel zuverlässiger verhindert, dass der Roboter die menschliche Hand berührt.
Übergaben zwischen Mensch und Roboter sind ein wichtiges Thema in der Mensch-Roboter-Kollaboration in einer Vielzahl von Anwendungsbereichen, von der kollaborativen Fertigung bis zur Unterstützung im Haushalt. Mindestens ein Ausführungsbeispiel konzentriert sich auf die Übergabe zwischen Roboter und Mensch, bei der der Roboter mit einem Objekt in der Hand beginnt und es an den Menschen übergibt. Eine Herausforderung besteht darin, die Aktionsparameter des Roboters so zu wählen, dass eine reibungslose Übergabe möglich ist. Dies umfasst die Wahl der Objektpose und des Greifens des Objekts durch den Roboter unter Berücksichtigung des Benutzerkomforts, der auf subjektiven Rückmeldungen basierenden Präferenzen, der Möglichkeiten und der beabsichtigten Verwendung der Objekte nach der Übergabe, der Bewegungseinschränkungen des Menschen, der sozialen Rolle des Menschen und der Konfiguration des Objekts beim Greifen vor der Übergabe. In mindestens einem Ausführungsbeispiel werden die Parameter der Trajektorie zum Erreichen der Übergabepose, die Untersuchung des Annäherungswinkels, die Ausgangsposition der Trajektorie im Gegensatz zur Übergabepose, die Gleichmäßigkeit der Bewegung, die Zeit für die Freigabe des Objekts, die geschätzte menschliche Handgelenksposition, das relative Timing der Übergabephasen und die ergonomischen Präferenzen des Menschen berücksichtigt. Während sich einige Ausführungsbeispiele auf die Offline-Berechnung von Übergabeparametern konzentrieren, umfasst mindestens ein Ausführungsbeispiel die Erfassung des Menschen, um reaktive Übergaben zu ermöglichen.
Die hier beschriebenen Techniken konzentrieren sich auf die Erfassung von Menschen, um reaktive Übergaben zu ermöglichen, und nutzen Techniken zur Abschätzung der Pose einer menschlichen Hand. Die Posenabschätzung der menschlichen Hand kann sowohl mit zweidimensionalen monokularen RGB-Bildern als auch mit 3-D-Tiefenkamerainformationen abgeschätzt werden. Im Allgemeinen stellen 3-D-Tiefenkameras zusätzliche Informationen bereit, die eine präzisere Abschätzung der Handpose ermöglichen als Techniken, die sich nur auf zweidimensionale RGB-Bilder stützen.
Die hier beschriebenen Techniken implementieren ein System zur Ausführung von Aufgaben, das auf robusten logisch-dynamischen Systemen basiert, einem Ansatz zur automatischen Erstellung reaktiver Aufgabenpläne für Roboter. In mindestens einem Ausführungsbeispiel besteht die Idee darin, den aktuellen logischen Zustand ständig zu identifizieren und reaktiv umzuplanen, um mit Unsicherheiten und Änderungen des logischen Zustands umzugehen, ein Ansatz, der für den Umgang mit teilweise beobachtbaren Umgebungen nützlich ist. In einigen Beispielen kann das Aufgabenmodell ähnlich wie Behavior Trees betrachtet werden, ein Verfahren zur Darstellung komplexer Aufgaben, das für die Zusammenarbeit zwischen Mensch und Roboter nützlich ist.
Mindestens ein Ausführungsbeispiel löst dieses Problem teilweise durch die Klassifizierung menschlicher Greifposen. In mindestens einem Ausführungsbeispiel werden die menschlichen Greifposen in sieben Kategorien unterteilt, die nicht alle Möglichkeiten abdecken können, wie eine menschliche Hand ein Objekt greifen kann.
In mindestens einem Ausführungsbeispiel wird ein Datensatz menschlicher Objektübergaben generiert, der mit grundwahren Hand- und Objektposen annotiert ist. Dieser Datensatz wird verwendet, um ein Deep Network zu trainieren, das als Eingabe eine farbige, von einer RGB-Tiefenkamera erhaltene Punktwolke verwendet, um die menschliche Hand vom Objekt zu segmentieren und Greifen und Steuern für den Roboter vorzuschlagen, so dass der Roboter das Objekt von der menschlichen Hand entgegennehmen kann, ohne die Finger des Menschen einzuklemmen oder zu berühren.
Ein Vorteil der hier beschriebenen Techniken ist, dass das Modell in der Lage sein kann, Robotergriffe zu generieren, die das Objekt von der menschlichen Hand/einem anderen Roboter aufnehmen können, ohne dabei die menschliche Hand (oder den Greifer eines anderen Roboters) einzuklemmen, indem es aus einem Datensatz zur Manipulation von Objekten mit der Hand lernt. Einige Beispiele stellen eine kostengünstige Lösung bereit, die auf RGB-D-Kameras basiert, die im Vergleich zu vielen tragbaren Sensoren billig und leicht sind. Verschiedene Ausführungsbeispiele ermöglichen eine zuverlässige Übergabe, die beim Aufbau komplexerer Robotersysteme wichtig ist. Die hier beschriebenen Techniken können zum Beispiel für Altenpflegeroboter oder Kochroboter eingesetzt werden, die eng mit dem Menschen zusammenarbeiten.
Die hier beschriebenen Techniken stellen in verschiedenen Ausführungsbeispielen bereit: (1) Hand-Objekt-Interaktion als Klassifizierungsproblem für Übergaben anhand eines Datensatzes, der eine breite Palette von Handformen und -posen abdeckt; (2) ein System, das adaptiv Robotergriffe für die Entnahme des Objekts vom Menschen plant, so dass der Roboter flüssig und natürlich auf den Menschen reagieren kann; und (3) experimentelle Ergebnisse, die Verbesserungen gegenüber den Basisverfahren zeigen, sowie eine Benutzerstudie, die unseren Ansatz mit naiven Benutzern validiert.
Menschen übergeben Gegenstände auf unterschiedliche Weise. Sie können das Objekt auf der Handfläche halten oder einen zangenartigen Griff verwenden und das Objekt in verschiedenen Orientierungen präsentieren. Die hier beschriebenen Techniken können bestimmen, welchen Griff ein Mensch verwendet und sich entsprechend anpassen, um eine reaktive Übergabe zwischen Mensch und Roboter zu ermöglichen.
1 zeigt ein Beispiel für eine Pose der Mensch-Roboter-Interaktion gemäß einem Ausführungsbeispiel, bei der der Mensch ein Objekt mit der Handfläche nach unten greift. Ein Roboter 100 ist so positioniert, dass er einen Gegenstand 102 aus einer menschlichen Hand 104 nimmt. In mindestens einem Ausführungsbeispiel nimmt eine Tiefenkamera ein Bild der menschlichen Hand 104 auf, die das Objekt 102 greift, generiert eine Punktwolke aus dem Bild und stellt die Punktwolke einem trainierten neuronalen Netzwerk zur Verfügung. Das neuronale Netzwerk generiert einen geeigneten Griff für einen Robotergreifer 106, der mit dem Roboter 100 verbunden ist, so dass der Robotergreifer 106 in der Lage ist, das Objekt 102 zu greifen, ohne mit der menschlichen Hand 104 in Konflikt zu geraten.
2 zeigt ein Beispiel für eine Pose der Mensch-Roboter-Interaktion gemäß einem Ausführungsbeispiel, bei der der Mensch ein Objekt absenkend greift. Ein Roboter 200 ist so positioniert, dass er ein Objekt 202 aus einer menschlichen Hand 204 nimmt. In mindestens einem Ausführungsbeispiel nimmt eine Tiefenkamera ein Bild der menschlichen Hand 204 auf, die das Objekt 202 greift, generiert eine Punktwolke aus dem Bild und stellt die Punktwolke einem trainierten neuronalen Netzwerk zur Verfügung. Das neuronale Netzwerk generiert einen geeigneten Griff für einen Robotergreifer 206, der mit dem Roboter 200 verbunden ist, so dass der Robotergreifer 206 in der Lage ist, das Objekt 202 zu greifen, ohne die menschliche Hand 204 zu behindern.
3 zeigt ein Beispiel für eine Pose der Mensch-Roboter-Interaktion gemäß einem Ausführungsbeispiel, bei der der Mensch ein Objekt mit der Handfläche nach oben greift. Ein Roboter 300 ist so positioniert, dass er ein Objekt 302 aus einer menschlichen Hand 304 nimmt. In mindestens einem Ausführungsbeispiel nimmt eine Tiefenkamera ein Bild der menschlichen Hand 304 auf, die das Objekt 302 greift, generiert eine Punktwolke aus dem Bild und stellt die Punktwolke einem trainierten neuronalen Netzwerk zur Verfügung. Das neuronale Netzwerk generiert einen geeigneten Griff für einen Robotergreifer 306, der mit dem Roboter 300 verbunden ist, so dass der Robotergreifer 306 in der Lage ist, das Objekt 302 zu greifen, ohne mit der menschlichen Hand 304 in Konflikt zu geraten.
4 zeigt ein Beispiel für eine Pose der Mensch-Roboter-Interaktion, bei der der Mensch einen horizontalen Zangengriff an einem Objekt ausführt. Ein Roboter 400 ist so positioniert, dass er ein Objekt 402 aus einer menschlichen Hand 404 nimmt. In mindestens einem Ausführungsbeispiel nimmt eine Tiefenkamera ein Bild der menschlichen Hand 404 auf, die das Objekt 402 greift, generiert eine Punktwolke aus dem Bild und stellt die Punktwolke einem trainierten neuronalen Netzwerk zur Verfügung. Das neuronale Netzwerk generiert einen geeigneten Griff für einen Robotergreifer 406, der mit dem Roboter 400 verbunden ist, so dass der Robotergreifer 406 in der Lage ist, das Objekt 402 zu greifen, ohne mit der menschlichen Hand 404 in Konflikt zu geraten.
In mindestens einem Ausführungsbeispiel wird die Bewegung des Roboters, wenn er einen Gegenstand aus einer menschlichen Hand nimmt, an die Art und Weise angepasst, wie der Gegenstand von der menschlichen Hand gegriffen wird. Dadurch wird im Allgemeinen verhindert, dass der Roboter ein nicht intuitives Verhalten an den Tag legt oder mit den Fingern des Menschen in Konflikt oder sogar in schädlichen Kontakt gerät. In mindestens einem Ausführungsbeispiel löst ein Framework für die Übergabe dieses Problem, indem es die vom Azure Body Tracking Software Development Kit („SDK“) detektierte Punktwolke um die menschliche Hand herum nimmt und dann die Handgriffklasse basierend darauf abschätzt, wie das Objekt von der menschlichen Hand gegriffen wird. Mindestens ein Ausführungsbeispiel plant dann adaptiv Robotergriffe.
5 zeigt ein Beispiel für ein Framework zur Durchführung einer Übergabe zwischen einem Roboter und einer menschlichen Hand gemäß einem Ausführungsbeispiel. In einem Beispiel erhält das Framework ein RGBD-Bild 502, das die Hand zeigt, die das Objekt hält. Unter Verwendung des RGBD-Bildes wird eine Punktwolke 504 der Hand und des Objekts generiert. In mindestens einem Ausführungsbeispiel nimmt das Framework die Punktwolke, die um die Handerkennung zentriert ist, und verwendet dann ein Modell 506, um sie als eine von sieben Grifftypen zu klassifizieren, die verschiedene Arten des Greifens von Objekten durch den menschlichen Benutzer abdecken. Das Aufgabenmodell plant dann adaptiv 508 das Greifen des Roboters.
6 zeigt ein Beispiel für eine Pose einer menschlichen Hand, die gemäß einem Ausführungsbeispiel dazu verwendet werden kann, die Übergabe eines Objekts von einem Roboter zu veranlassen. Zum Beispiel kann eine erste Handpose 602 als eine Pose bezeichnet werden, die signalisiert, dass der Mensch bereit ist, ein Objekt aufzunehmen, und eine zweite Handpose 604 kann als eine Pose bezeichnet werden, die darstellt, dass der Mensch nicht bereit ist, ein Objekt vom Roboter aufzunehmen.
Mindestens ein Ausführungsbeispiel definiert einen diskreten Satz menschlicher Griffe, die die Art und Weise beschreiben, wie das Objekt für die Aufgabe der Übergabe von der menschlichen Hand gegriffen wird. In mindestens einem Ausführungsbeispiel werden die üblichen menschlichen Griffe für die Aufgabe der Übergabe zwischen Mensch und Roboter in sieben Kategorien eingeteilt, wie in 7 dargestellt. Greift die Hand beispielsweise einen Block, so kann die Handpose in die Kategorien Offene Handfläche, Zangengriff unten, Zangengriff oben, Zangengriff seitlich oder Heben unterteilt werden. Ein anderes Beispiel: Wenn die Hand nichts hält, könnte sie entweder darauf warten, dass der Roboter ein Objekt übergibt, oder sie tut einfach nichts Bestimmtes (etwas anderes).
7 zeigt ein Beispiel für Handposen, die gemäß einem Ausführungsbeispiel zum Greifen eines Objekts verwendet werden können. Eine erste Handpose 704 zeigt ein Objekt, das in der offenen Handfläche gehalten wird. Eine zweite Handpose 704 zeigt ein Objekt, das in einer Position gehalten wird, in der es von unten zangenartig gehalten wird. Eine dritte Handpose 706 zeigt einen Gegenstand, der in der Hebepose gehalten wird. Eine vierte Handpose 708 zeigt einen Gegenstand, der in einer Position gehalten wird, in der er von oben zangenartige gehalten wird. Eine fünfte Handpose 710 zeigt einen Gegenstand, der gehalten wird, während er von der Seite zangenartig gehalten wird. Diese und andere Handposen können vom Menschen verwendet werden, wenn er einem Roboter ein Objekt präsentiert. In einigen Implementierungen können Klassifizierungen von Handposen verwendet werden, wie z. B. die in 7 gezeigten Handposen-Kategorien. In anderen Implementierungen kann die Handpose eine freie Form haben, die verschiedene Arten von Handposen umfassen kann, die in 7 nicht gezeigt sind. In solchen Beispielen kann das System eine Punktwolke oder eine Skelettpose der Hand verwenden, um eine geeignete Pose für den Roboter zu konstruieren, der das Objekt aus der menschlichen Hand nehmen soll.
8A zeigt ein Beispiel für einen Robotergreifer gemäß einem Ausführungsbeispiel. In einem Beispiel umfasst der Robotergreifer 802 einen Satz von Zangen 804, die geschlossen und getrennt werden können. Einige Beispiele können Berührungssensoren auf der Oberfläche der Zangen 804 umfassen, so dass das System ein Maß für die Kraft erhalten kann. In einigen Beispielen umfasst der Greifer 802 ein Handgelenk, das den Satz von Zangen 804 unter der Steuerung des Systems beweglich machen und positionieren kann.
8B zeigt ein Beispiel für einen Robotergreifer 806 mit vier Fingern, der in einem Ausführungsbeispiel verwendet werden kann. Der Robotergreifer 806 umfasst einen ersten Finger 808, einen zweiten Finger 810, einen dritten Finger 812 und einen gegenüberliegenden Finger 814, die annähernd eine menschliche Hand imitieren. Der Robotergreifer 806 kann gemäß verschiedenen Ausführungsbeispielen verwendet werden, die hier beschrieben und gezeigt werden. Zum Beispiel kann der Robotergreifer 806 verwendet werden, um einen Gegenstand, der in einer menschlichen Hand gehalten wird, so zu greifen, dass er die menschliche Hand nicht behindert. Darüber hinaus können auch andere Arten von Robotergreifern mit mehr oder weniger Fingern verwendet werden. In einem Beispiel kann der Robotergreifer 2, 3, 4, 5 oder mehr Finger haben und jeder Finger kann eine Reibungsfläche haben, um das Greifen eines Objekts zu unterstützen. In einem Beispiel können die Finger eines Robotergreifers über Berührungssensoren verfügen, die das System unterstützen, indem sie den Kontakt mit dem Objekt anzeigen. In einem Beispiel kann der Greifer ein magnetisches Element umfassen, das die Entnahme eines eisenhaltigen Objekts aus der menschlichen Hand unterstützt. In einem anderen Beispiel kann der Greifer ein Vakuumaufnahmeelement umfassen, um das Objekt zu fassen.
In einem Beispiel wird zum Erlernen eines Modells zur Klassifizierung menschlicher Griffe in einem Ausführungsbeispiel ein Datensatz erstellt, der acht Probanden mit verschiedenen Handformen und Handposen unter Verwendung einer Azure Kinect RGBD-Kamera umfasst. In einer Implementierung wird dem Probanden zum Beispiel ein Beispielbild eines Handgriffs gezeigt, und die ähnlichen Posen, die der Proband einnimmt, werden zwanzig bis sechzig Sekunden lang aufgezeichnet. Die Sequenz der Bilder werden als die entsprechende Kategorie des menschlichen Greifens markiert. Während der Aufnahme kann die Testperson ihren Körper und ihre Hand in verschiedene Positionen bringen, um die Kameraperspektiven zu variieren. Für jede Versuchsperson werden sowohl die linke als auch die rechte Hand aufgenommen. In einem Beispiel besteht der Datensatz aus 151.551 Bildern.
Anstelle des Deep Learning mit ConvNets auf Tiefenbildern wird in mindestens einem Ausführungsbeispiel das PointNet++ auf Punktwolken zur Klassifizierung des menschlichen Greifens verwendet. In mindestens einem Ausführungsbeispiel besteht das Backbone-Netzwerk aus vier Satz-Abstraktionsschichten zum Erlernen von Punktmerkmalen und einem dreischichtigen Perzeptron mit Batch-Normalisierung, ReLu und Dropout zum Erlernen globaler Merkmale und zur Klassifizierung des menschlichen Greifens. Bei einer Punktwolke, die um die Hand herum abgeschnitten wurde, klassifiziert das Netzwerk diese in eine der definierten Greifkategorien, die für die weitere Planung des Robotergreifens verwendet werden können.
Mindestens ein Ausführungsbeispiel assoziiert jeden Grifftyp des Menschen mit einer kanonischen Greifrichtung des Roboters, um den Aufwand für den Menschen bei der Übergabe von Mensch zu Roboter zu minimieren. Wie in 3 dargestellt, bezeichnen die Koordinaten die Einzelbilder der kanonischen Robotergriffe im Kameraeinzelbild. Die Motivation besteht darin, die Wahrscheinlichkeit zu verringern, dass der Roboter die Hand des Menschen ergreift, und gleichzeitig seine Bewegung und Trajektorie so natürlich und reibungslos wie möglich zu gestalten.
Mindestens ein Ausführungsbeispiel eines Aufgabenmodells basiert auf Robust Logical-Dynamical Systems. Dieses stellt Aufgaben als eine Liste von reaktiv ausgeführten Operatoren o mit bestimmten Eigenschaften dar. Jeder Operator ist ein Tupel o = {L_P, L_R, L_E, π}, wobei L_P ein Satz von logischen Vorbedingungen beim Eintritt in o ist, L_R ein Satz von Laufbedingungen ist, die während der Ausführung von o erfüllt sein müssen, und L_E der Satz von logischen Wirkungen ist, die wahr sein werden. Der Operator ist auch mit einer Richtlinie π assoziiert, die die notwendigen Steuerungen generiert, um die Effekte L_E zu erreichen. In mindestens einem Ausführungsbeispiel werden die Richtlinie und die Prädikate aus Daten gelernt, aber in anderen Ausführungsbeispielen werden sie manuell spezifiziert. In mindestens einem Ausführungsbeispiel wird aus einem Plan der Operator mit der höchsten Priorität ausgewählt, dessen Voraussetzungen erfüllt sind, wobei die Bedingungen in 10 Hz überprüft werden, so dass auf Änderungen schnell reagiert werden kann.
9 zeigt ein beispielhaftes Beispiel für Interaktionen zwischen Roboter und Mensch, gemäß einem Ausführungsbeispiel. 9 gibt einen Überblick über die verschiedenen Schritte in einem finalen Aufgabenplan. In mindestens einem Ausführungsbeispiel muss sich das System an verschiedene mögliche Griffe anpassen und reaktiv den richtigen Weg wählen, um sich dem menschlichen Benutzer zu nähern und ihm das Objekt abzunehmen. In einem Beispiel bleibt es in einer „Home“-Position und wartet, bis es eine stabile Abschätzung darüber erhält, wie der Mensch den Block präsentieren möchte.
In verschiedenen Ausführungsbeispielen erfolgt die Übergabe von einem Menschen an einen Roboter in vier Stufen, wobei der Roboter darauf wartet, dass der Mensch das Objekt in einer geeigneten Pose 902 präsentiert, dann einen Plan entwickelt, der den Robotergreifer so positioniert, dass das Objekt gegriffen werden kann 904, das Objekt greift 906 und dann in einigen Beispielen das Objekt ablegt 908.

Anstatt nur eine reaktive lokale Planung zu verwenden, planen und treffen einige Implementierungen intelligente Entscheidungen basierend auf einer großen Anzahl möglicher Griffe, um denjenigen zu finden, der für den menschlichen Benutzer natürlich wäre. Die nachstehende Tabelle zeigt ein Ausführungsbeispiel des Aufgabenplans in absteigender Reihenfolge der Prioritäten. In der nachstehenden Tabelle sind die Operatoren und die entsprechenden Vorbedingungen L_P für die Ausführung der Aufgabe und die reaktive Ausführung angegeben. Die Operatoren sind in absteigender Reihenfolge ihrer Priorität aufgeführt; wenn alle Vorbedingungen erfüllt sind, führen die hier beschriebenen Techniken den assoziierten Operator aus, unabhängig davon, welcher Operator zuvor ausgeführt wurde.

Operator	Vorbedingungen
Offener Greifer	has_obj Λ gripper fully _ closed
Warten auf Mensch	(stable Λ hand_over_table Λ hand_has_obj)
Vermeiden eines	too_close_to_hand Λ
Menschen	in apporach region
Ablegen eines Objekts	at _ drop_position Λ has_obj
Gehen zu Ablegen	has_obj
Greifen eines Objekts	in approach region Λ has_goal Λ is_goal_valid
Folgen eines Plans	has_goal Λ is_goal valid
Finden eines Plans	has_feasbile_goals
Finden durchführbarer	stable Λ hand_over_table Λ
Ziele	hand_has_obj

Warten auf Mensch. Mindestens ein Ausführungsbeispiel berechnet mehrere Prädikate, die bestimmen, wie der Roboter mit der Hand interagieren soll: stable, hand_over_table, hand_has_obj und too_close_to_hand. Das Prädikat hand_over_ table spezifiziert, ob diese Beobachtungen in einem bestimmten Volumen über der oben abgebildeten Tabelle liegen oder nicht, und stable( ) ist wahr, wenn sich die Hand nicht bewegt und mindestens 5 Zeitschritte (0,5 Sekunden) lang beobachtet wurde. Dies wird mindestens teilweise basierend auf der Geschwindigkeit definiert: $s t a b l e () = {‖ x_{t - 1} - x_{t} ‖}_{2} < λ,$
wobei Position x und Zeit t für einen Schwellenwert λ gelten. Der Roboter wartet an der Ausgangsposition, wenn diese Bedingungen nicht erfüllt sind.
Vermeiden eines Menschen. In mindestens einem Ausführungsbeispiel wird der Roboter, wenn too_close_to_hand() für eine der beiden Hände zutrifft und sich der Roboter nicht in dem Bereich befindet, der einem bestimmten Griff entspricht, versuchen, der Hand auszuweichen und sich in die Ausgangspositionen zurückbewegen. Mindestens ein Ausführungsbeispiel definiert too_close_to_hand() als wahr, wenn der euklidische Abstand zwischen dem Endeffektor und der Hand weniger als 20 cm beträgt.
Finden durchführbarer Ziele. Um sicherzustellen, dass die Bewegungen des Roboters sicher sind, planen die hier beschriebenen Techniken anstelle der rein reaktiven Richtlinien ganze Trajektorien für die Ausführung. Wenn stable (), hand_over_table () und hand has obj (), dann versucht der Roboter, das Objekt aus der Hand zu nehmen, wobei er eine kanonische Greifpose wie oben beschrieben verwendet.
In mindestens einem Ausführungsbeispiel muss der Roboter, um eine gültige Trajektorie ξ zu finden, zunächst eine gültige Greifpose finden, also fügt das System die Werte has goal und is_goal_valid hinzu. Ist einer dieser Werte falsch, sucht das System nach einer sinnvollen Zielpose.
In mindestens einem Ausführungsbeispiel erstellt der Planer eine Liste von Zielposen-Kandidaten und assoziierten Standoff-Positionen. In einem Beispiel gibt es zehn Optionen, mit Rotationen von θ_y∈ {-π/4,-π/8,0,π/8,π/4} um die y-Achse in 3 und θ_z ∈ {O,π} um die z-Achse. In mindestens einem Ausführungsbeispiel müssen sowohl die Greif- als auch die Abstandsposition kollisionsfrei sein und eine gültige IK-Lösung aufweisen, um als machbare Zieloptionen zu gelten. Verschiedene Beispiele fügen auch die Einschränkung hinzu, dass der Roboter niemals seine Sicht auf das Objekt verdecken darf, wenn er bestimmt, ob die Zustände gültig sind.
Finde Plan. In mindestens einem Ausführungsbeispiel sortiert der Planer, wenn er über eine Liste von Zieloptionen verfügt, diese nach ihrem Abstand zur aktuellen Gelenkkonfiguration und versucht, mithilfe von RRT-Connect [58] einen Bewegungsplan zur Abstandsstellung zu finden. Wenn das System sowohl eine Greifpose als auch einen Bewegungsplan finden kann, führt der Roboter eine Teilrichtlinie aus, um diesem Bewegungsplan zu folgen.
Ein Mensch kann jedoch seine Hand bewegen oder die Art und Weise, wie er ein Objekt in der Hand hält, verändern. Ein Ziel gilt als gültig (gemäß dem Prädikat is_goal valid), wenn es einen assoziierten Bewegungsplan hat und wenn sich das Objekt nicht innerhalb eines bestimmten Schwellenwerts von der Stelle bewegt hat, an der es zuerst beobachtet wurde. Wenn sich das Objekt zu stark bewegt, hält der Roboter an und das Aufgabenmodell geht zurück zum Finden eines neuen Griffs.
Greifen eines Objekts. In mindestens einem Ausführungsbeispiel sollte sich der Roboter nach Abschluss eines Bewegungsplans in einer Standoff-Pose befinden und eine assoziierte Zielpose haben - die erwartete Position des Objekts in der menschlichen Hand. Diese beiden Posen definieren einen Bereich, in dem sich der Roboter bewegen kann, um sich dem Objekt zu nähern. Wenn sich der Roboter in seiner Zielpose befindet, wird das Prädikat has_obj nach dem Schließen des Greifers auf true gesetzt. Der Operator zum Greifen kann das Objekt verdecken, daher wird dies als einzige blockierende Aktion im offenen Regelkreis ausgeführt.
Öffnen des Greifers. In mindestens einem Ausführungsbeispiel kann, wenn has obj true ist und damit anzeigt, dass der Roboter glaubt, ein Objekt zu halten, diese Erfassung falsch sein, wenn sich das Objekt bewegt hat oder die Posenabschätzung falsch war. Einige Beispiele fügen ein Prädikat gripper_fülly_closed hinzu, das besagt, dass der Greifer vollständig geschlossen ist. Wenn beide Bedingungen erfüllt sind, wird has_obj auf false gesetzt, und der Roboter kehrt in einen anderen Zustand zurück.
Bewegen zum Ablegen und Ablegen des Objekts. In mindestens einem Ausführungsbeispiel handelt es sich bei der Ablegeposition um eine Position in einem einzigen Gelenkraum; der Roboter wird einen sicheren, kollisionsfreien Bewegungsplan finden. Befindet er sich in der Ablegeposition, weist das System den Roboter an, den Greifer zu öffnen und das Objekt auf den Tisch zu legen.
Wir haben ein Beispiel des gesamten Systems, das das Klassifizierungsmodell und das oben beschriebene Aufgabenmodell umfasst, systematisch an einer Reihe verschiedener Handpositionen und den in 7 gezeigten Griffen getestet. Ein Ausführungsbeispiel verwendet zwei verschiedene Franka-Panda-Roboter, die auf identischen Tischen an unterschiedlichen Orten montiert sind. Ein menschlicher Benutzer übergab dem Roboter vier farbige Blöcke, einen nach dem anderen. Während der systematischen Evaluierung wurde jeder der drei Ansätze zur Bestimmung der Greifpose getestet, die für die Entnahme eines Objekts vom Menschen zu verwenden ist:
Einfache Basislinie: Wartet, bis es den Block in einer menschlichen Hand sieht und nimmt ihn mit einer festen Orientierung des Greifens aus der Hand. Die menschliche Hand wird über den Microsoft Azure Body Tracker detektiert.
Handposenabschätzung: Eine auf Zustandsabschätzung basierende Version des Systems, bei der die Pose einer menschlichen Hand aus dem Azure Body Tracker zur Inferenz der Greifrichtung verwendet wird.
Ein Ausführungsbeispiel des vorgeschlagenen Systems: Das vorgeschlagene System, das menschliche Griffe basierend auf Tiefeninformationen klassifiziert, wie oben beschrieben.
Die Varianten führten das gleiche Aufgabenmodell aus, wie oben beschrieben. Die Reihenfolge, in der diese drei Testfälle bereitgestellt wurden, wurde randomisiert. Die Benutzer benutzten ihre rechte Hand, um dem Roboter Blöcke zu präsentieren.
Die Evaluierung der Systemleistung erfolgte anhand eines Satzes von Metriken, die während der Versuche berechnet wurden. Diese wurden automatisch berechnet und protokolliert, während die Benutzer die Aufgabe durchführten.
Erfolgsrate der Planung: Die Anzahl der Fälle, in denen der Operator follow_plan erfolgreich ausgeführt werden konnte, um den Roboter in seine Pose zu bringen, und misst die Sicherheit sowohl des Menschen als auch des Systems.
Erfolgsquote beim Greifen: Wie oft der Roboter das Objekt erfolgreich vom Menschen nehmen konnte, im Vergleich zur Gesamtzahl der Greifversuche.
Aktionsausführungszeit: Verfolgt die Zeit, die benötigt wurde, um eine einzelne geplante Trajektorie auszuführen, einen Block zu greifen und ihn auf dem Tisch abzulegen. Dieser Wert ist höher, wenn der Roboter einen längeren Weg nehmen muss, um den Block vom Menschen zu greifen.
Gesamtausführungszeit: Die Zeit, die für die Ausführung aller geplanten Pfade benötigt wurde, einschließlich der Neuplanung, weil sich der Mensch bewegt hat oder weil sich die Art des Greifens geändert hat.
Dauer des Versuchs: Zeit seit dem ersten Erkennen der menschlichen Hand bis zum Abschluss des Versuchs.
10 zeigt die Ergebnisse verschiedener Metriken während der systematischen Evaluierung. Die hier beschriebenen Techniken verbessern durchweg die Erfolgsquote und verringern die Gesamtausführungszeit und die Dauer der Versuche im Vergleich zu den beiden anderen Basisverfahren, was die Wirksamkeit und Zuverlässigkeit des Verfahrens belegt. In einem ersten Diagramm 1002 ist die Genauigkeit der Klassifizierung des Greifens der menschlichen Hand dargestellt. Das zweite Diagramm 1004 zeigt den Vergleich der Fehlversuche bei der Klassifizierung von Handzuständen mit PoseCNN. In vielen Fällen verdeckt die Hand das Objekt, so dass eine genaue Abschätzung der Pose nur schwer möglich ist.
Eine Ausnahme ist die Aktionsausführungszeit, bei der die einfache Basislinie manchmal schneller ist, weil die einfache Basislinie nicht so adaptiv plant wie die anderen; sie würde nicht versuchen, einen ungewöhnlichen Griff zu versuchen. Das bedeutet, dass die Zeit von der erfolgreichen Annäherung bis zum Ablegen des Objekts im Durchschnitt gelegentlich deutlich kürzer sein kann.
Evaluierung der Klassifizierung des menschlichen Greifens: Ein Ausführungsbeispiel evaluiert das Klassifizierungsmodell für das Greifen der Hand anhand eines Validierungssatzes, der mit einer während des Trainings ungesehenen Person erhoben wurde. Die Klassifizierungsgenauigkeit wird im ersten Diagramm 1002 dargestellt, das die gute Generalisierungsfähigkeit unseres Modells bei unbekannten Personen demonstriert.
Zusätzlich wurde ein Experiment durchgeführt, um die Erkennungsrate zu evaluieren, d.h. ob sich ein Objekt in der Hand befindet, um einen Einblick bereitzustellen, wie robust das Übergabesystem gegenüber der Verdeckung ist. Die Erkennungsrate unseres Klassifikationsmodells für das Greifen der Hand (mit/ohne Objekt) wird mit der eines alternativen Verfahrens zur Objekterkennung verglichen. Das Ergebnis ist im zweiten Diagramm 1004 dargestellt. Ein Ausführungsbeispiel des hier beschriebenen Modells für den menschlichen Griff erreicht eine höhere Erkennungsrate und ist im Vergleich zur Alternative robuster, insbesondere bei starker Verdeckung (z. B. 87,5 % gegenüber 6,8 % beim Zangengriff und 94,4 % gegenüber 11,9 % beim Heben).
Es wurde eine Nutzerstudie durchgeführt, um zu überprüfen, ob das System eine flüssige Mensch-Roboter-Kooperation ermöglicht. Es wurden neun Benutzer im Alter von 20 bis 36 Jahren rekrutiert. Zwei von ihnen waren weiblich und sieben waren männlich. Das Durchschnittsalter betrug 30,44 ± 4,74 Jahre. Die Studie bestand aus drei Runden:
Freiform: Die Benutzer erhielten vier Blöcke und wurden angewiesen, sich vor den Tisch zu stellen und die Blöcke einzeln an den Roboter zu übergeben. Sie wurden angewiesen, dass der Roboter die Blöcke nur nimmt, wenn ihre Hand stillsteht, aber sie konnten die Blöcke auf jede beliebige Weise halten.
Aufmerksam: Der in 3 gezeigte Satz von fünf menschlichen Griffen wurde demonstriert: Zangengriff oben, Zangengriff unten, Zangengriff seitlich, Heben und auf der offenen Handfläche. Die Teilnehmer wurden aufgefordert, vier Blöcke wieder abzugeben. Sie wurden ermutigt, die vordefinierten Handgriffe auszuprobieren, konnten aber auch andere verwenden.
Abgelenkt: Die Leistung des Benutzers wurde in Gegenwart einer Ablenkung getestet.

Die Ergebnisse für die Übergabeleistung anhand unserer quantitativen Metriken sind in der nachstehenden Tabelle aufgeführt. Die Planungserfolgsrate zeigt an, wie oft das System seinen Ansatz neu planen musste, während die Greiferfolgsrate angibt, wie oft das System das Objekt erfolgreich ergriffen hat.

	Planungserfolgsquote	Greiferfolgsquote	Aktionsausführungszeit(en)	Gesamtausführungszeit(en)	Versuchsdauer(n)
Einfache Baseline	42.1%	66.7%	11.37	20.93	21.59
Handposenabschätzung	29.6%	80.0%	15.10	36.34	36.46
Unsere	64.3%	100%	13.20	17.34	18.31

Zusätzlich zu den oben beschriebenen Metriken wurden während der Benutzerstudie auch die folgenden Statistiken gezählt: (a) die Anzahl der Berührungen des Robotergreifers mit den menschlichen Fingern, (b) die Anzahl der Wechsel des Griffs und (c) die Anzahl der Wechsel der Handposition. Nach jedem Versuch wurden die Teilnehmer gebeten, alle Probleme zu beschreiben, die sie bei der Übergabe der Blöcke an den Roboter hatten. Nach Abschluss aller drei Versuche wurden die Teilnehmer gebeten, einen Fragebogen auf einer Likert-Skala auszufüllen und ihre Antworten zu erläutern.
Es gab eine Reihe von Antworten, aber die Benutzer sagten, dass sie mit dem Roboter fließend arbeiten und ihm vertrauen, dass er das Richtige tut, obwohl sie einige gemeinsame Probleme bemerkten, als sie um Rückmeldungen gebeten wurden. Sie glaubten auch, dass der Roboter sich ihrer Handlungen bewusst war.
Quantitative Metriken zu den Nutzerdaten sind in der obigen Tabelle aufgeführt. Annäherungen und Greifen waren weniger erfolgreich, wenn die Benutzer abgelenkt waren, aber die Zeiten sind ähnlich. Die Nutzer zählten im Durchschnitt 12:88 ± 3:48 Gesichter in einem Musikvideo, obwohl die richtige Zahl 13 war. Dies deutet daraufhin, dass viele von ihnen eine gewisse Konfidenz in Bezug auf das Übergabesystem empfanden und dem Video eine gute Aufmerksamkeit schenkten.
In einem Ausführungsbeispiel deckt die hier beschriebene Kategorisierung menschlicher Griffe 77 % der typischen Griffe von Benutzern ab. Mindestens ein Ausführungsbeispiel kann mit den meisten ungesehenen menschlichen Griffen umgehen; sie führen in der Regel zu größerer Unsicherheit und würden manchmal bewirken, dass der Roboter zurückweicht und neu plant. Einige dieser ungesehenen Griffe sind in 11 dargestellt. 11 zeigt beispielhaft Ausreißergriffe, die in unserem Trainingsdatensatz nicht vorkommen und Beispiele für die Arten von Griffen sind, bei denen unser System eine höhere Unsicherheit aufweist, was zu einer etwas schlechteren Leistung bei der Übergabe führt.
Während des finalen, abgelenkten Tests mussten die Benutzer im Vergleich zu den ersten beiden Durchgängen häufiger ihre Greifweise umstellen oder ändern. Mehrere beschwerten sich darüber, dass ihre Finger eingeklemmt wurden oder dass der Roboter Objekte nicht greifen konnte. Einer entschied sich ausdrücklich für die Handpose mit der Handfläche nach oben, um das Risiko eines Fehlschlags zu minimieren; ein anderer musste den Roboter alle 10 Sekunden oder so ansehen.

Die folgende Tabelle stellt die quantitativen Ergebnisse der Nutzerstudie bereit. Die Nutzer waren in der Lage, Aufgaben schnell zu erledigen, auch wenn sie abgelenkt waren und sich auf ein anderes Szenario konzentrieren mussten.

	Planungserfolgsquote	Greiferfolgsquote	Aktionsausführungszeit(en)	Gesamtausführungszeit(en)	Versuchsdauer(n)
Freiform	32.7%	67.3%	13.21	25.99	26.92
Aufmerksam	40.0%	90.0%	14.85	23.84	24.75
Abgelenkt	29.8%	67.9%	11.08	26.08	27.02
Insgesamt	33.6%	73.6%	13.05	25.31	26.24

In mindestens einem Beispiel ist das System besser lesbar und zeigt an, zu welchen Blöcken der Roboter fahren will und wie er dorthin gelangen will.
Im Allgemeinen bemerken die Benutzer während der Tests schnell, wenn der Roboter versucht, den Block auf unauffällige Weise zu greifen. Manchmal bemerken sie auch eine leichte Ungenauigkeit beim Greifen und Annähern des Roboters, passen sich aber meist selbst daran an. Nach der zweiten Versuchsrunde, in der ihnen gezeigt wurde, wie sie die Objekte greifen können, war das System zuverlässiger und einfacher zu handhaben.
Die vorliegenden Ausführungsbeispiele beschreiben ein System, das die Übergabe zwischen Mensch und Roboter durch Klassifizierung verschiedener Grifftypen ermöglicht. Andere Ausführungsbeispiele machen das Planungssystem flexibler und unterstützen allgemeine Grifftypen, indem ein neuronales Netz trainiert wird, um einen Griff aus der Punktwolke der menschlichen Hand, die das Objekt hält, zu erzeugen. Variationen dieser Techniken können auf viele andere Arten der Mensch-Roboter-Kollaboration angewandt werden, z. B. bei medizinischen Operationen, in der Fertigung und bei der Körperpflege.
12 zeigt ein Beispiel für einen Prozess, der einen Transfer eines Objekts zwischen einem Roboter und einer menschlichen Hand durchführt, nachdem er von einem Computersystem ausgeführt wurde, gemäß einem Ausführungsbeispiel. Mindestens ein Ausführungsbeispiel kann unter Verwendung eines Computersystems, eines Prozessors, einer GPU oder eines Netzwerks für maschinelles Lernen implementiert werden, wie sie in 13-41 gezeigt und in der zugehörigen Beschreibung beschrieben sind. Mindestens ein Ausführungsbeispiel wird unter Verwendung eines Prozessors implementiert, der ausführbare Anweisungen aus einem computerlesbaren Speicher liest, in dem Anweisungen gespeichert sind, die als Ergebnis der Ausführung durch einen oder mehrere Prozessoren des Computersystems bewirken, dass das Computersystem die unten beschriebenen Operationen durchführt.
In mindestens einem Ausführungsbeispiel wird in Schritt 1202 ein Bild einer Hand, die ein Objekt hält, unter Verwenden einer Tiefenkamera erhalten. In verschiedenen Beispielen kann eine Tiefenkamera eine binokulare RGB-Kamera, ein medizinisches bildgebendes Gerät wie ein dreidimensionales Röntgenbild, ein Ultraschallbild, ein CAT Scan oder ein Magnetresonanzbild („MRI“) sein. In einigen Beispielen, z. B. bei selbstfahrenden Autos, kann das Bild mit einem bildgebenden Radargerät oder einem bildgebenden Lasergerät („LIDAR“) generiert werden. In mindestens einem Ausführungsbeispiel generiert das System in Schritt 1204 eine Punktwolke aus dem Bild. Die Punktwolke stellt einen dreidimensionalen Satz von Punkten bereit, die das Objekt und die Hand repräsentieren. In einem Beispiel ist die Punktwolke eine farbige Punktwolke von einer RGB-Tiefenkamera.
In mindestens einem Beispiel verarbeitet das System in Schritt 1206 die Punktwolke und identifiziert einen ersten Teil der Punktwolke, der die Hand repräsentiert, die das Objekt hält. In Schritt 1208 identifiziert das System einen zweiten Teil der Punktwolke, der das Objekt repräsentiert. Unter Verwendung der entsprechenden Teile der Punktwolke bestimmt das System in Block 1210 in mindestens einem Beispiel die Objektpose aus dem zweiten Teil der Punktwolke und bestimmt 1212 die Handpose aus dem ersten Teil der Punktwolke. In einem Beispiel umfasst die Handpose die Identifizierung einer Skelettstruktur der Hand, die Gelenke und Segmentlängen für die Finger der Hand umfasst.
In mindestens einem Ausführungsbeispiel generiert das System in Schritt 1214 einen Satz von Greifposen für einen Robotergreifer, die es dem Greifer ermöglichen, das Objekt zu fassen. Dies kann unter Verwendung des Teils der Punktwolke, der das Objekt repräsentiert, und/oder der in Schritt 1210 bestimmten Informationen zur Objektpose erfolgen. In mindestens einem Ausführungsbeispiel umfasst die Information über die Objektpose die Größe, die Form und die Orientierung des Objekts im Raum. Die Orientierung des Objekts kann eine vertikale und horizontale Rotation und Neigung umfassen. Der Satz der Greifposen kann viele Posen umfassen, die die menschliche Hand stören würden, aber dennoch bevorzugt werden, wenn die Hand nicht vorhanden ist.
Daher identifiziert das System in Schritt 1216 einen bestimmten Griff aus dem Satz der Greifposen, wobei es nicht in die Hand eingreift. Ein Eingriff in die Hand bedeutet, dass der Robotergreifer die Hand berührt oder die Hand oder einen Teil der Hand einklemmt. In mindestens einem Ausführungsbeispiel wählt das System einen Griff aus, der einen ausreichenden Sicherheitsstandard für das Objekt erfüllt und gleichzeitig den Abstand zu den Fingern der Hand maximiert. Nach der Identifizierung eines geeigneten Griffs, der die Hand nicht berührt, weist das System in Schritt 1218 den Roboter an, den identifizierten Griff auszuführen, um das Objekt aus der menschlichen Hand zu nehmen.
INFERENZ- UND TRAININGSLOGIK
13A zeigt eine Inferenz- und/oder Trainingslogik 1315, die verwendet wird, um Inferenz- und/oder Trainingsoperationen durchzuführen, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 sind unten in Verbindung mit 13A und/oder 13B bereitgestellt.
In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 ohne Einschränkung einen Code- und/oder Datenspeicher 1301 umfassen, um Vorwärts- und/oder Ausgabegewichte und/oder Eingabe-/Ausgabedaten und/oder andere Parameter zu speichern, um Neuronen oder Schichten eines neuronalen Netzwerks zu konfigurieren, das in Aspekten einer oder mehrerer Ausführungsbeispiele trainiert und/oder zum Inferenzieren verwendet wird. In mindestens einem Ausführungsbeispiel kann die Trainingslogik 1315 einen Code- und/oder Datenspeicher 1301 umfassen oder mit diesem gekoppelt sein, um einen Graphencode oder eine andere Software zu speichern, die das Timing und/oder die Reihenfolge steuert, in der die Informationen über Gewichte und/oder andere Parameter geladen werden, um die Logik zu konfigurieren, einschließlich Ganzzahl- und/oder Gleitkomma-Einheiten (zusammenfassend als arithmetische Logikeinheiten (ALUs) bezeichnet). In mindestens einem Ausführungsbeispiel lädt Code, wie z. B. Graphencode, basierend auf einer Architektur eines neuronalen Netzwerks, dem der Code entspricht, Gewichte oder andere Parameterinformationen in Prozessor-ALUs. In mindestens einem Ausführungsbeispiel speichert der Code und/oder der Datenspeicher 1301 Gewichtungsparameter und/oder Eingabe-/Ausgabedaten jeder Schicht eines neuronalen Netzwerks, das während der Vorwärtspropagierung von Eingabe-/Ausgabedaten und/oder Gewichtungsparametern während des Trainings und/oder Inferenzierens unter Verwendung von Aspekten einer oder mehrerer Ausführungsbeispiele trainiert oder in Verbindung mit einer oder mehrerer Ausführungsbeispiele verwendet wird. In mindestens einem Ausführungsbeispiel kann jeder Teil des Code- und/oder Datenspeichers 1301 von einem anderen On-Chip- oder Off-Chip-Datenspeicher umfasst sein, einschließlich des L1-, L2- oder L3-Caches eines Prozessors oder des Systemspeichers.
In mindestens einem Ausführungsbeispiel kann jeder Teil des Codes und/oder des Datenspeichers 1301 intern oder extern zu einem oder mehreren Prozessoren oder anderen Hardware-Logikgeräten oder Schaltungen sein. In mindestens einem Ausführungsbeispiel kann der Code und/oder der Code- und/oder Datenspeicher 1301 ein Cache-Speicher, ein dynamischer zufällig adressierbarer Speicher („DRAM“), ein statischer zufällig adressierbarer Speicher („SRAM“), ein nichtflüchtiger Speicher (z.B. Flash-Speicher) oder ein anderer Speicher sein. In mindestens einem Ausführungsbeispiel kann die Entscheidung, ob der Code- und/oder Code- und/oder Datenspeicher 1301 intern oder extern zu einem Prozessor ist oder DRAM, SRAM, Flash oder einen anderen Speichertyp umfasst, davon abhängen, ob Speicher auf dem Chip oder außerhalb des Chips verfügbar ist, von den Anforderungen an die Latenzzeit der ausgeführten Trainings- und/oder Inferenzierungsfunktionen, von der Größe der beim Inferenzieren und/oder Trainieren eines neuronalen Netzwerks verwendeten Datenstapel oder von einer Kombination dieser Faktoren.
In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 ohne Einschränkung einen Code- und/oder Datenspeicher 1305 umfassen, um Rückwärts- und/oder Ausgabe-Gewichtungs- und/oder Eingabe-/Ausgabedaten zu speichern, die Neuronen oder Schichten eines neuronalen Netzwerks entsprechen, das trainiert und/oder zum Inferieren in Aspekten einer oder mehrerer Ausführungsbeispiele verwendet wird. In mindestens einem Ausführungsbeispiel speichert der Code- und/oder Datenspeicher 1305 Gewichtungsparameter und/oder Eingabe-/Ausgabedaten jeder Schicht eines neuronalen Netzwerks, das während der Rückwärtspropagierung von Eingabe-/Ausgabedaten und/oder Gewichtungsparametern während des Trainings und/oder Inferenzierens unter Verwendung von Aspekten einer oder mehrerer Ausführungsbeispiele trainiert oder in Verbindung mit einer oder mehrerer Ausführungsbeispiele verwendet wird. In mindestens einem Ausführungsbeispiel kann die Trainingslogik 1315 einen Code- und/oder Datenspeicher 1305 umfassen oder mit diesem gekoppelt sein, um einen Graphencode oder eine andere Software zu speichern, die das Timing und/oder die Reihenfolge steuert, in der die Informationen über Gewichte und/oder andere Parameter geladen werden, um die Logik zu konfigurieren, einschließlich Ganzzahl- und/oder Gleitkommaeinheiten (zusammenfassend als arithmetische Logikeinheiten (ALUs) bezeichnet). In mindestens einem Ausführungsbeispiel lädt ein Code, wie z. B. ein Graphencode, basierend auf einer Architektur eines neuronalen Netzwerks, der der Code entspricht, Gewichte oder andere Parameterinformationen in Prozessor-ALUs. In mindestens einem Ausführungsbeispiel kann jeder Teil des Codes und/oder des Datenspeichers 1305 einen anderen On-Chip- oder Off-Chip-Datenspeicher umfassen, einschließlich des L1-, L2- oder L3-Cache oder des Systemspeichers eines Prozessors. In mindestens einem Ausführungsbeispiel kann ein beliebiger Teil des Codes und/oder des Datenspeichers 1305 intern oder extern in einem oder mehreren Prozessoren oder anderen Hardware-Logikgeräten oder Schaltungen enthalten sein. In mindestens einem Ausführungsbeispiel kann der Code- und/oder Datenspeicher 1305 ein Cache-Speicher, DRAM, SRAM, nichtflüchtiger Speicher (z. B. Flash-Speicher) oder ein anderer Speicher sein. In mindestens einem Ausführungsbeispiel kann die Wahl, ob der Code- und/oder Datenspeicher 1305 intern oder extern zu einem Prozessor ist, oder ob er beispielsweise DRAM, SRAM, Flash oder einen anderen Speichertyp umfasst, von dem verfügbaren Speicher auf dem Chip oder außerhalb des Chips, von den Anforderungen an die Latenzzeit der ausgeführten Trainings- und/oder Inferenzierungsfunktionen, von der Stapelgröße der beim Inferenzieren und/oder Trainieren eines neuronalen Netzwerks verwendeten Daten oder von einer Kombination dieser Faktoren abhängen.
In mindestens einem Ausführungsbeispiel können der Code- und/oder Datenspeicher 1301 und der Code- und/oder Datenspeicher 1305 separate Speicherstrukturen sein. In mindestens einem Ausführungsbeispiel können der Code- und/oder Datenspeicher 1301 und der Code- und/oder Datenspeicher 1305 dieselbe Speicherstruktur sein. In mindestens einem Ausführungsbeispiel können der Code- und/oder Datenspeicher 1301 und der Code- und/oder Datenspeicher 1305 teilweise dieselbe Speicherstruktur und teilweise separate Speicherstrukturen sein. In mindestens einem Ausführungsbeispiel kann jeder Teil des Code- und/oder Datenspeichers 1301 und des Code- und/oder Datenspeichers 1305 von einem anderen On-Chip- oder Off-Chip-Datenspeicher umfasst sein, einschließlich des L1-, L2- oder L3-Caches eines Prozessors oder des Systemspeichers.
In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 ohne Einschränkung eine oder mehrere arithmetische Logikeinheit(en) („ALU(s)“) 1310, einschließlich Ganzzahl- und/oder Gleitkommaeinheiten, umfassen, um logische und/oder mathematische Operationen durchzuführen, die zumindest teilweise auf einem Trainings- und/oder Inferenzcode (z.B, Graphencode), deren Ergebnis in einem Aktivierungsspeicher 1320 gespeicherte Aktivierungen (z. B. Ausgabewerte von Schichten oder Neuronen innerhalb eines neuronalen Netzwerks) erzeugen kann, die Funktionen von in Code- und/oder Datenspeicher 1301 und/oder Code- und/oder Datenspeicher 1305 gespeicherten Eingabe/Ausgabe- und/oder Gewichtungsparameterdaten sind. In mindestens einem Ausführungsbeispiel werden in einem Aktivierungsspeicher 1320 gespeicherte Aktivierungen gemäß linearer algebraischer und/oder matrixbasierter Mathematik generiert, die von ALU(s) 1310 als Reaktion auf Ausführungsbefehle oder anderen Code ausgeführt wird, wobei in Code- und/oder Datenspeicher 1305 und/oder Daten 1301 gespeicherte Gewichtungswerte als Operanden zusammen mit anderen Werten verwendet werden, wie beispielsweise Vorgabewerten, Gradienteninformationen, Impulswerten oder anderen Parametern oder Hyperparametern, von denen beliebige oder alle in Code- und/oder Datenspeicher 1305 oder Code- und/oder Datenspeicher 1301 oder einem anderen Speicher auf oder außerhalb des Chips gespeichert sein können.
In mindestens einem Ausführungsbeispiel sind ALU(s) 1310 in einem oder mehreren Prozessoren oder anderen Hardware-Logikgeräten oder -Schaltungen umfasst, während in einem anderen Ausführungsbeispiel ALU(s) 1310 extern zu einem Prozessor oder einem anderen Hardware-Logikgerät oder einer Schaltung sein können, die sie verwenden (z.B. ein Co-Prozessor). In mindestens einem Ausführungsbeispiel können die ALUs 1310 in den Ausführungseinheiten eines Prozessors oder anderweitig in einer Gruppe von ALUs umfasst sein, auf die die Ausführungseinheiten eines Prozessors entweder innerhalb desselben Prozessors oder verteilt auf verschiedene Prozessoren unterschiedlichen Typs (z. B. Zentraleinheiten, Grafikverarbeitungseinheiten, feste Funktionseinheiten usw.) zugreifen können. In mindestens einem Ausführungsbeispiel können sich der Datenspeicher 1301, der Code- und/oder Datenspeicher 1305 und der Aktivierungsspeicher 1320 auf demselben Prozessor oder einem anderen logischen Hardware-Gerät oder einer Schaltung befinden, während sie in einem anderen Ausführungsbeispiel in verschiedenen Prozessoren oder anderen logischen Hardware-Geräten oder Schaltungen oder in einer Kombination aus gleichen und verschiedenen Prozessoren oder anderen logischen Hardware-Geräten oder Schaltungen untergebracht sein können. In mindestens einem Ausführungsbeispiel kann ein beliebiger Teil des Aktivierungsspeichers 1320 von einem anderen On-Chip- oder Off-Chip-Datenspeicher umfasst sein, einschließlich des L1-, L2- oder L3-Cachespeichers oder Systemspeichers eines Prozessors. Darüber hinaus kann der Code zum Inferenzieren und/oder Trainieren zusammen mit anderem Code gespeichert werden, auf den ein Prozessor oder eine andere Hardware-Logik oder -Schaltung zugreifen kann und der unter Verwendung der Hol-, Dekodier-, Planungs-, Ausführungs-, Ausscheidungs- und/oder anderer logischer Schaltungen eines Prozessors geholt und/oder verarbeitet wird.
In mindestens einem Ausführungsbeispiel kann der Aktivierungsspeicher 1320 ein Cache-Speicher, DRAM, SRAM, nichtflüchtiger Speicher (z. B. Flash-Speicher) oder ein anderer Speicher sein. In mindestens einem Ausführungsbeispiel kann sich der Aktivierungsspeicher 1320 vollständig oder teilweise innerhalb oder außerhalb eines oder mehrerer Prozessoren oder anderer logischer Schaltungen befinden. In mindestens einem Ausführungsbeispiel kann die Entscheidung, ob der Aktivierungsspeicher 1320 beispielsweise innerhalb oder außerhalb eines Prozessors liegt oder DRAM, SRAM, Flash oder einen anderen Speichertyp umfasst, von dem verfügbaren Speicher auf dem Chip oder außerhalb des Chips, den Anforderungen an die Latenzzeit der ausgeführten Trainings- und/oder Inferenzierungsfunktionen, der Stapelgröße der beim Inferenzieren und/oder Trainieren eines neuronalen Netzwerks verwendeten Daten oder einer Kombination dieser Faktoren abhängen. In mindestens einem Ausführungsbeispiel kann die in 13A dargestellte Inferenz- und/oder Trainingslogik 1315 in Verbindung mit einer anwendungsspezifischen integrierten Schaltung („ASIC“) verwendet werden, wie z. B. der Tensorflow® Processing Unit von Google, einer Inferenzverarbeitungseinheit (IPU) von Graphcore™ oder einem Nervana(R)-Prozessor (z. B. „Lake Crest“) von Intel Corp. In mindestens einem Ausführungsbeispiel kann die in 13A gezeigte Inferenz- und/oder Trainingslogik 1315 in Verbindung mit Hardware der Zentraleinheit („CPU“), der Grafikverarbeitungseinheit („GPU“) oder anderer Hardware, wie feldprogrammierbaren Gate-Arrays („FPGAs“), verwendet werden.
[13B zeigt die Inferenz- und/oder Trainingslogik 1315 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 ohne Einschränkung eine Hardwarelogik umfassen, in der Rechenressourcen dediziert oder anderweitig ausschließlich in Verbindung mit Gewichtungswerten oder anderen Informationen verwendet werden, die einer oder mehreren Schichten von Neuronen innerhalb eines neuronalen Netzwerks entsprechen. In mindestens einem Ausführungsbeispiel kann die in 13B dargestellte Inferenz- und/oder Trainingslogik 1315 in Verbindung mit einer anwendungsspezifischen integrierten Schaltung (ASIC) verwendet werden, wie z. B. der Tensorflow® Processing Unit von Google, einer Inferenzverarbeitungseinheit (IPU) von Graphcore™ oder einem Nervana®-Prozessor (z. B. „Lake Crest“) von Intel Corp. In mindestens einem Ausführungsbeispiel kann die in 13B gezeigte Inferenz- und/oder Trainingslogik 1315 in Verbindung mit Hardware der Zentraleinheit (CPU), der Grafikverarbeitungseinheit (GPU) oder anderer Hardware, wie z. B. feldprogrammierbaren Gate-Arrays (FPGAs), verwendet werden. In mindestens einem Ausführungsbeispiel umfasst die Inferenz- und/oder Trainingslogik 1315 ohne Einschränkung einen Code- und/oder Datenspeicher 1301 und einen Code- und/oder Datenspeicher 1305, die zum Speichern von Code (z. B. Graphencode), Gewichtungswerten und/oder anderen Informationen, einschließlich Vorgabewerten, Gradienteninformationen, Impulswerten und/oder anderen Parameter- oder Hyperparameterinformationen, verwendet werden können. In mindestens einem Ausführungsbeispiel, das in 13B gezeigt ist, ist jeder Code- und/oder Datenspeicher 1301 und jeder Code- und/oder Datenspeicher 1305 mit einer dedizierten Rechenressource assoziiert, wie z. B. Rechenhardware 1302 bzw. Rechenhardware 1306. In mindestens einem Ausführungsbeispiel umfasst jede der Berechnungshardware 1302 und der Berechnungshardware 1306 eine oder mehrere ALUs, die mathematische Funktionen, wie lineare algebraische Funktionen, nur auf Informationen ausführen, die im Code- und/oder Datenspeicher 1301 bzw. im Code- und/oder Datenspeicher 1305 gespeichert sind, wobei das Ergebnis im Aktivierungsspeicher 1320 gespeichert wird.
In mindestens einem Ausführungsbeispiel entspricht jeder der Code- und/oder Datenspeicher 1301 und 1305 und die entsprechende Rechenhardware 1302 bzw. 1306 verschiedenen Schichten eines neuronalen Netzwerks, so dass die resultierende Aktivierung von einem „Speicher-/Rechenpaar 1301/1302“ aus Code- und/oder Datenspeicher 1301 und Rechenhardware 1302 als Eingabe für das nächste „Speicher-/Rechenpaar 1305/1306“ aus Code- und/oder Datenspeicher 1305 und Rechenhardware 1306 bereitgestellt wird, um die konzeptionelle Organisation eines neuronalen Netzwerks zu spiegeln. In mindestens einem Ausführungsbeispiel kann jedes der Speicher-/Rechnerpaare 1301/1302 und 1305/1306 mehr als einer Schicht des neuronalen Netzwerks entsprechen. In mindestens einem Ausführungsbeispiel können zusätzliche Speicher-/Rechenpaare (nicht dargestellt) aufeinanderfolgend oder parallel zu den Speicher-Rechenpaaren 1301/1302 und 1305/1306 in die Inferenz- und/oder Trainingslogik 1315 einbezogen werden.
TRAINING UND EINSATZ EINES NEURONALEN NETZWERKS
14 zeigt gemäß mindestens einem Ausführungsbeispiel das Trainieren und den Einsatz eines Deep Neural Network. In mindestens einem Ausführungsbeispiel wird das untrainierte neuronale Netzwerk 91406 unter Verwendung eines Trainingsdatensatzes 1402 trainiert. In mindestens einem Ausführungsbeispiel ist das Trainings-Framework 1404 ein PyTorch-Framework, während in anderen Ausführungsbeispielen das Trainings-Framework 1404 ein Tensorflow-, Boost-, Caffe-, Microsoft Cognitive Toolkit/CNTK-, MXNet-, Chainer-, Keras-, Deepleaming4j- oder ein anderes Trainings-Framework ist. In mindestens einem Ausführungsbeispiel trainiert das Trainings-Framework 1404 ein untrainiertes neuronales Netzwerk 1406 und ermöglicht es, dieses unter Verwendung der hierin beschriebenen Verarbeitungsressourcen zu trainieren, um ein trainiertes neuronales Netzwerk 1408 zu generieren. In mindestens einem Ausführungsbeispiel können die Gewichte nach dem Zufallsprinzip oder durch Vortraining unter Verwendung eines Deep Belief Network ausgewählt werden. In mindestens einem Ausführungsbeispiel kann das Training entweder überwacht, teilweise überwacht oder unüberwacht durchgeführt werden.
In mindestens einer Ausführungsform wird ein untrainiertes neuronales Netzwerk 1406 unter Verwendung von beaufsichtigtem Lernen trainiert, wobei der Trainingsdatensatz 1402 eine Eingabe umfasst, die mit einer gewünschten Ausgabe für eine Eingabe gepaart ist, oder wobei der Trainingsdatensatz 1402 eine Eingabe mit einer bekannten Ausgabe umfasst und eine Ausgabe des neuronalen Netzwerks 1406 manuell bewertet wird. In mindestens einem Ausführungsbeispiel wird das untrainierte neuronale Netzwerk 1406 auf überwachte Weise trainiert, verarbeitet Eingaben aus dem Trainingsdatensatz 1402 und vergleicht die resultierenden Ausgaben mit einem Satz von erwarteten oder gewünschten Ausgaben. In mindestens einem Ausführungsbeispiel werden die Fehler dann durch das untrainierte neuronale Netzwerk 1406 zurückpropagiert. In mindestens einem Ausführungsbeispiel passt das Trainings-Framework 1404 die Gewichte an, die das untrainierte neuronale Netzwerk 1406 steuern. In mindestens einem Ausführungsbeispiel umfasst das Trainings-Framework 1404 Hilfsmittel, um zu überwachen, wie gut das untrainierte neuronale Netzwerk 1406 zu einem Modell konvergiert, wie z.B. dem trainierten neuronalen Netzwerk 1408, das geeignet ist, basierend auf bekannten Eingabedaten, wie z.B. neuen Daten 1412, korrekte Antworten zu generieren, wie z.B. im Ergebnis 1414. In mindestens einem Ausführungsbeispiel trainiert das Trainings-Framework 1404 das untrainierte neuronale Netzwerk 1406 wiederholt, während es die Gewichte anpasst, um eine Ausgabe des untrainierten neuronalen Netzwerks 1406 unter Verwendung einer Verlustfunktion und eines Anpassungsalgorithmus, wie z. B. des stochastischen Gradientenabstiegs, zu verfeinern. In mindestens einem Ausführungsbeispiel trainiert das Trainings-Framework 1404 das untrainierte neuronale Netzwerk 1406, bis das untrainierte neuronale Netzwerk 1406 eine gewünschte Genauigkeit erreicht. In mindestens einem Ausführungsbeispiel kann das trainierte neuronale Netzwerk 1408 dann eingesetzt werden, um eine beliebige Anzahl von maschinellen Lernoperationen zu implementieren.
Mindestens in einem Ausführungsbeispiel wird das untrainierte neuronale Netzwerk 1406 unter Verwendung von unbeaufsichtigtem Lernen trainiert, wobei das untrainierte neuronale Netzwerk 1406 versucht, sich selbst unter Verwendung unmarkierter Daten zu trainieren. In mindestens einem Ausführungsbeispiel umfasst der Trainingsdatensatz 1402 des unbeaufsichtigten Lernens Eingabedaten ohne assoziierte Ausführungsdaten oder „Grundwahrheits“-Daten. In mindestens einem Ausführungsbeispiel kann das untrainierte neuronale Netzwerk 1406 Gruppierungen innerhalb des Trainingsdatensatzes 1402 lernen und bestimmen, wie einzelne Eingaben mit dem untrainierten Datensatz 1402 in Beziehung stehen. In mindestens einem Ausführungsbeispiel kann unüberwachtes Training verwendet werden, um eine selbstorganisierende Karte zu generieren, die eine Art trainiertes neuronales Netzwerk 1408 ist, das in der Lage ist, Operationen durchzuführen, die bei der Reduzierung der Dimensionalität neuer Daten 1412 nützlich sind. In mindestens einem Ausführungsbeispiel kann unüberwachtes Training auch dazu verwendet werden, eine Anomalieerkennung durchzuführen, die es ermöglicht, Datenpunkte in einem neuen Datensatz 1412 zu identifizieren, die von normalen Mustern des neuen Datensatzes 1412 abweichen.
In mindestens einem Ausführungsbeispiel kann halbüberwachtes Lernen verwendet werden, was eine Technik ist, bei der der Trainingsdatensatz 1402 eine Mischung aus markierten und unmarkierten Daten umfasst. In mindestens einem Ausführungsbeispiel kann das Trainings-Framework 1404 verwendet werden, um inkrementelles Lernen durchzuführen, beispielsweise durch übertragene Lerntechniken. In mindestens einem Ausführungsbeispiel ermöglicht das inkrementelle Lernen dem trainierten neuronalen Netzwerk 1408, sich an neue Daten 1412 anzupassen, ohne das Wissen zu vergessen, das dem Netzwerk während des initialen Trainings vermittelt wurde.
DATENZENTRUM
15 zeigt ein beispielhaftes Rechenzentrum 1500, in dem mindestens ein Ausführungsbeispiel verwendet werden kann. In mindestens einem Ausführungsbeispiel umfasst das Rechenzentrum 1500 eine Rechenzentrumsinfrastrukturschicht 1510, eine Framework-Schicht 1520, eine Softwareschicht 1530 und eine Anwendungsschicht 1540.
In mindestens einem Ausführungsbeispiel, wie in 15 gezeigt, kann die Rechenzentrumsinfrastrukturschicht 1510 einen Ressourcen-Orchestrator 1512, gruppierte Rechenressourcen 1514 und Knoten-Rechenressourcen („Knoten-C.R.s“) 1516(1)-1516(N) umfassen, wobei „N“ eine beliebige ganze, positive Zahl repräsentiert. In mindestens einem Ausführungsbeispiel können die Knoten C.R.s 1516(1)-1516(N) eine beliebige Anzahl von zentralen Verarbeitungseinheiten („CPUs“) oder anderen Prozessoren (einschließlich Beschleunigern, feldprogrammierbaren Gate Arrays (FPGAs), Grafikprozessoren usw.), Speichergeräten (z. B., dynamischer Festwertspeicher), Speichergeräte (z. B. Festkörper- oder Festplattenlaufwerke), Netzwerk-Eingabe-/Ausgabegeräte („NW I/O“), Netzwerk-Switches, virtuelle Maschinen („VMs“), Stromversorgungsmodule und Kühlmodule usw. In mindestens einem Ausführungsbeispiel kann es sich bei einem oder mehreren Knoten-C.R.s unter den Knoten-C.R.s 1516(1)-1516(N) um einen Server handeln, der über eine oder mehrere der oben genannten Rechenressourcen verfügt.
In mindestens einem Ausführungsbeispiel können die gruppierten Rechenressourcen 1514 separate Gruppierungen von Knoten-C.R.s umfassen, die in einem oder mehreren Schränken (nicht gezeigt) untergebracht sind, oder viele Schränke, die in Rechenzentren an verschiedenen geografischen Standorten untergebracht sind (ebenfalls nicht gezeigt). Separate Gruppierungen von Knoten-C.R.s innerhalb der gruppierten Rechenressourcen 1514 können gruppierte Rechen-, Netzwerk-, Speicher- oder Ablage-Ressourcen umfassen, die zur Unterstützung einer oder mehrerer Arbeitslasten konfiguriert oder zugewiesen werden können. In mindestens einem Ausführungsbeispiel können mehrere Knoten-C.R.s einschließlich CPUs oder Prozessoren in einem oder mehreren Schränken gruppiert werden, um Rechenressourcen zur Unterstützung einer oder mehrerer Arbeitslasten bereitzustellen. In mindestens einem Ausführungsbeispiel können ein oder mehrere Schränke auch eine beliebige Anzahl von Stromversorgungsmodulen, Kühlmodulen und Netzwerk-Switches in beliebiger Kombination umfassen.
In mindestens einem Ausführungsbeispiel kann der Ressourcen-Orchestrator 1512 einen oder mehrere Knoten C.R.s 1516(1)-1516(N) und/oder gruppierte Rechenressourcen 1514 konfigurieren oder anderweitig steuern. In mindestens einem Ausführungsbeispiel kann der Ressourcen-Orchestrator 1512 eine Verwaltungseinheit für die Software-Design-Infrastruktur („SDI“) des Rechenzentrums 1500 umfassen. In mindestens einem Ausführungsbeispiel kann der Ressourcen-Orchestrator Hardware, Software oder eine Kombination davon umfassen.
In mindestens einem Ausführungsbeispiel, wie in 15 gezeigt, umfasst die Framework-Schicht 1520 einen Aufgabenplaner 1532, einen Konfigurationsmanager 1534, einen Ressourcenmanager 1536 und ein verteiltes Dateisystem 1538. In mindestens einem Ausführungsbeispiel kann die Framework-Schicht 1520 ein Framework zur Unterstützung der Software 1532 der Software-Schicht 1530 und/oder einer oder mehrerer Anwendungen 1542 der Anwendungsschicht 1540 umfassen. In mindestens einem Ausführungsbeispiel kann die Software 1532 bzw. die Anwendung(en) 1542 webbasierte Dienstsoftware oder Anwendungen umfassen, wie sie beispielsweise von Amazon Web Services, Google Cloud und Microsoft Azure bereitgestellt werden. In mindestens einem Ausführungsbeispiel kann die Framework-Schicht 1520 eine Art kostenloses und quelloffenes Software-Webanwendungs-Framework wie Apache SparkTM (im Folgenden „Spark“) sein, das ein verteiltes Dateisystem 1538 für die Verarbeitung großer Datenmengen (z. B. „Big Data“) nutzen kann, ist aber nicht darauf beschränkt. In mindestens einem Ausführungsbeispiel kann der Aufgabenplaner 1532 einen Spark-Treiber umfassen, um die Planung von Arbeitslasten zu erleichtern, die von verschiedenen Schichten des Rechenzentrums 1500 unterstützt werden. In mindestens einem Ausführungsbeispiel kann der Konfigurationsmanager 1534 in der Lage sein, verschiedene Schichten wie die Softwareschicht 1530 und die Framework-Schicht 1520, die Spark und das verteilte Dateisystem 1538 umfasst, zu konfigurieren, um die Verarbeitung großer Datenmengen zu unterstützen. In mindestens einem Ausführungsbeispiel kann der Ressourcenmanager 1536 in der Lage sein, geclusterte oder gruppierte Rechenressourcen zu verwalten, die zur Unterstützung des verteilten Dateisystems 1538 und des Aufgabenplaners 1532 zugeordnet sind oder werden.
In mindestens einem Ausführungsbeispiel können die geclusterten oder gruppierten Rechenressourcen die gruppierte Rechenressource 1514 in der Schicht 1510 der Rechenzentrumsinfrastruktur umfassen. In mindestens einem Ausführungsbeispiel kann der Ressourcenmanager 1536 mit dem Ressourcenorchestrator 1512 koordiniert werden, um diese zugeordneten oder zugewiesenen Rechenressourcen zu verwalten.
In mindestens einem Ausführungsbeispiel kann Software 1532, die in der Softwareschicht 1530 umfasst ist, Software umfassen, die zumindest von Teilen der Knoten C.R.s 1516(1)-1516(N), der gruppierten Rechenressourcen 1514 und/oder des verteilten Dateisystems 1538 der Framework-Schicht 1520 verwendet wird. Eine oder mehrere Arten von Software können, ohne darauf beschränkt zu sein, Internet-Webseiten-Suchsoftware, Software zum Scannen von E-Mail-Viren, Datenbanksoftware und Software für Videostreams umfassen.
In mindestens einem Ausführungsbeispiel können die in der Anwendungsschicht 1540 eingeschlossene(n) Anwendung(en) 1542 eine oder mehrere Arten von Anwendungen umfassen, die von mindestens Teilen der Knoten C.R.s 1516(1)-1516(N), gruppierten Rechenressourcen 1514 und/oder dem verteilten Dateisystem 1538 der Framework-Schicht 1520 verwendet werden. Eine oder mehrere Arten von Anwendungen können eine beliebige Anzahl von Genomanwendungen, kognitiven Berechnungen und Anwendungen für maschinelles Lernen umfassen, einschließlich Software zum Trainieren oder Inferenzieren, Framework-Software für maschinelles Lernen (z. B, PyTorch, TensorFlow, Caffe, etc.) oder andere maschinelle Lemanwendungen, die in Verbindung mit einer oder mehreren Ausführungsbeispielen verwendet werden.
In mindestens einem Ausführungsbeispiel kann ein beliebiger Konfigurationsmanager 1534, Ressourcenmanager 1536 und Ressourcenorchestrator 1512 eine beliebige Anzahl und Art von selbstmodifizierenden Aktionen basierend auf einer beliebigen Menge und Art von Daten implementieren, die in einer technisch geeigneten Weise erfasst werden. In mindestens einem Ausführungsbeispiel können selbstmodifizierende Aktionen einen Rechenzentrumsbetreiber des Rechenzentrums 1500 davon entlasten, möglicherweise schlechte Konfigurationsentscheidungen zu treffen und möglicherweise nicht ausgelastete und/oder schlecht funktionierende Teile eines Rechenzentrums zu vermeiden.
In mindestens einem Ausführungsbeispiel kann das Rechenzentrum 1500 Hilfsmittel, Dienste, Software oder andere Ressourcen umfassen, um ein oder mehrere maschinelle Lernmodelle zu trainieren oder Informationen unter Verwendung eines oder mehrerer maschineller Lernmodelle gemäß einer oder mehrerer hierin beschriebener Ausführungsbeispiele vorherzusagen oder zu inferieren. Beispielsweise kann in mindestens einem Ausführungsbeispiel ein Modell des maschinellen Lernens durch Berechnung von Gewichtungsparametern gemäß einer Architektur eines neuronalen Netzwerks unter Verwendung von Software und Rechenressourcen trainiert werden, die oben in Bezug auf das Rechenzentrum 1500 beschrieben wurden. In mindestens einem Ausführungsbeispiel können trainierte maschinelle Lernmodelle, die einem oder mehreren neuronalen Netzwerken entsprechen, verwendet werden, um Informationen unter Verwendung von Ressourcen, die oben in Bezug auf das Datenzentrum 1500 beschrieben wurden, zu inferieren oder vorherzusagen, indem Gewichtungsparameter verwendet werden, die durch eine oder mehrere hierin beschriebene Trainingstechniken berechnet wurden.
In mindestens einem Ausführungsbeispiel kann das Datenzentrum CPUs, anwendungsspezifische integrierte Schaltungen (ASICs), GPUs, FPGAs oder andere Hardware verwenden, um ein Training und/oder Inferenzieren unter Verwendung der oben beschriebenen Ressourcen durchzuführen. Darüber hinaus können eine oder mehrere der oben beschriebenen Software- und/oder Hardware-Ressourcen als Dienst konfiguriert sein, um Benutzern das Trainieren oder Inferenzieren von Informationen zu ermöglichen, wie z. B. Bilderkennung, Spracherkennung oder andere Dienste der künstlichen Intelligenz.
Inferenz- und/oder Trainingslogik 1315 wird verwendet, um Inferenzieren und/oder Trainingsoperationen durchzuführen, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System 15 zum Inferenzieren oder Vorhersagen verwendet werden, die zumindest teilweise auf Gewichtsparametern basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das so trainiert ist, dass es ein Greifen eines Objekts generiert, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
Autonomes Fahrzeug
16A zeigt ein Beispiel für ein autonomes Fahrzeug 1600 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel kann das autonome Fahrzeug 1600 (hier alternativ als „Fahrzeug 1600“ bezeichnet) ohne Einschränkung ein Personenkraftwagen sein, wie z.B. ein Pkw, ein Lkw, ein Bus und/oder eine andere Art von Fahrzeug, das einen oder mehrere Fahrgäste aufnimmt. In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 ein Sattelschlepper sein, der für den Transport von Gütern verwendet wird. In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 ein Flugzeug, ein Roboterfahrzeug oder eine andere Art von Fahrzeug sein.
Autonome Fahrzeuge können in Form von Automatisierungsstufen beschrieben werden, die von der National Highway Traffic Safety Administration („NHTSA“), einer Abteilung des US-Verkehrsministeriums, und der Society of Automotive Engineers („SAE“) „Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles“ (z. B. Standard Nr. J3016-201806 , veröffentlicht am 15. Juni 2018, Standard Nr. J3016-201609 , veröffentlicht am 30. September 2016, sowie frühere und zukünftige Versionen dieses Standards) definiert werden. In einem oder mehreren Ausführungsbeispielen kann das Fahrzeug 1600 eine Funktionalität gemäß einem oder mehreren der Level 1 - Level 5 der autonomen Fahrstufen aufweisen. Zum Beispiel kann das Fahrzeug 1600 in mindestens einem Ausführungsbeispiel je nach Ausführungsbeispiel zu einer bedingten Automatisierung (Level 3), einer hohen Automatisierung (Level 4) und/oder einer vollständigen Automatisierung (Level 5) fähig sein.
Verschiedene Ausführungsbeispiele des Mensch-Roboter-Interaktionssystems können in ein Fahrzeug integriert werden, um bei Aufgaben wie der Paketzustellung und der Lagerautomatisierung zu helfen. Zum Beispiel kann ein Ausführungsbeispiel dazu verwendet werden, ein Paket von einem Menschen zur Auslieferung entgegenzunehmen oder eine Barzahlung für einen Kunden entgegenzunehmen.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 ohne Einschränkung Komponenten wie ein Fahrgestell, eine Fahrzeugkarosserie, Räder (z.B. 2, 4, 6, 8, 18, usw.), Reifen, Achsen und andere Fahrzeugkomponenten umfassen. In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 ohne Einschränkung ein Antriebssystem 1650 umfassen, wie z.B. einen Verbrennungsmotor, ein Hybrid-Elektro-Kraftwerk, einen vollelektrischen Motor und/oder einen anderen Antriebssystemtyp. In mindestens einem Ausführungsbeispiel kann das Antriebssystem 1650 mit einem Antriebsstrang des Fahrzeugs 1600 verbunden sein, der ohne Einschränkung ein Getriebe umfassen kann, um den Antrieb des Fahrzeugs 1600 zu ermöglichen. In mindestens einem Ausführungsbeispiel kann das Antriebssystem 1650 in Reaktion auf den Empfang von Signalen von einer Drosselklappe/Beschleunigungseinrichtung(en) 1652 gesteuert werden.
In mindestens einem Ausführungsbeispiel wird ein Lenksystem 1654, das ohne Einschränkung ein Lenkrad umfassen kann, verwendet, um ein Fahrzeug 1600 (z.B. entlang eines gewünschten Weges oder einer Route) zu lenken, wenn ein Antriebssystem 1650 in Betrieb ist (z.B. wenn das Fahrzeug in Bewegung ist). In mindestens einem Ausführungsbeispiel kann ein Lenksystem 1654 Signale von (einem) Lenkaktuator(en) 1656 empfangen. Das Lenkrad kann optional für eine vollautomatische Funktionalität (Level 5) sein. In mindestens einem Ausführungsbeispiel kann ein Bremssensorsystem 1646 verwendet werden, um die Fahrzeugbremsen in Reaktion auf den Empfang von Signalen von Bremsaktuator(en) 1648 und/oder Bremssensoren zu betätigen.
In mindestens einem Ausführungsbeispiel stellt (stellen) die Steuerung(en) 1636, die ohne Einschränkung ein oder mehrere System-on-a-Chips („SoCs“) (in 16A nicht dargestellt) und/oder Grafikverarbeitungseinheit(en) („GPU(s)“) umfassen kann (können), Signale (z. B. repräsentativ für Befehle) für eine oder mehrere Komponenten und/oder Systeme des Fahrzeugs 1600 bereit. In mindestens einem Ausführungsbeispiel kann (können) die Steuerung(en) 1636 beispielsweise Signale senden, um die Fahrzeugbremsen über die Bremsaktuatoren 1648 zu betätigen, das Lenksystem 1654 über den (die) Lenkaktuator(en) 1656 zu betätigen und das Antriebssystem 1650 über den (die) Gashebel/Beschleuniger 1652 zu betreiben. Die Steuerung(en) 1636 kann(en) ein oder mehrere bordseitige (z.B. integrierte) Rechengeräte (z.B. Supercomputer) umfassen, die Sensorsignale verarbeiten und Betriebsbefehle ausgeben (z.B. Signale, die Befehle repräsentieren), um autonomes Fahren zu ermöglichen und/oder einen menschlichen Fahrer beim Führen von Fahrzeug 1600 zu unterstützen. In mindestens einem Ausführungsbeispiel kann die Steuerung(en) 1636 eine erste Steuerung 1636 für autonome Fahrfunktionen, eine zweite Steuerung 1636 für funktionale Sicherheitsfunktionen, eine dritte Steuerung 1636 für Funktionen der künstlichen Intelligenz (z.B. computergestützte Vision), eine vierte Steuerung 1636 für Infotainment-Funktionen, eine fünfte Steuerung 1636 für Redundanz in Notfällen und/oder andere Steuerungen umfassen. In mindestens einem Ausführungsbeispiel kann ein einzelnes Steuergerät 1636 zwei oder mehr der oben genannten Funktionalitäten übernehmen, zwei oder mehr Steuergeräte 1636 können eine einzige Funktionalität übernehmen und/oder eine beliebige Kombination davon.
In mindestens einem Ausführungsbeispiel stellt (stellen) die Steuerung(en) 1636 Signale zur Steuerung einer oder mehrerer Komponenten und/oder Systeme des Fahrzeugs 1600 in Reaktion auf Sensordaten bereit, die von einem oder mehreren Sensoren (z.B. Sensoreingaben) empfangen werden. In mindestens einem Ausführungsbeispiel können Sensordaten beispielsweise und ohne Einschränkung von einem oder mehreren GNSS-Sensor(en) 1658 empfangen werden (z.B, Global Positioning System-Sensor(en)), RADAR-Sensor(en) 1660, Ultraschallsensor(en) 1662, LIDAR-Sensor(en) 1664, Trägheitsmesseinheit-Sensor(en) 1666 (z. B. Beschleunigungsmesser, Gyroskop(e), Magnetkompass(e), Magnetometer usw.), Mikrofon(en) 1696, Stereokamera(s) 1668, Weitwinkelkamera(s) 1670 (z. B., Fischaugenkameras), Infrarotkamera(n) 1672, Umgebungskamera(n) 1674 (z.B. 360-Grad-Kameras), Weitbereichskameras (nicht in 16A gezeigt), Mitteldistanzkamera(n) (nicht in 16A gezeigt), Geschwindigkeitssensor(en) 1644 (z.B. zur Messung der Geschwindigkeit des Fahrzeugs 1600), Vibrationssensor(en) 1642, Lenksensor(en) 1640, Bremssensor(en) (z.B. als Teil des Bremssensorsystems 1646) und/oder andere Sensortypen.
In mindestens einem Ausführungsbeispiel kann eine oder mehrere Steuerung(en) 1636 Eingaben (z.B. repräsentiert durch Eingabedaten) von einem Instrumentencluster 1632 des Fahrzeugs 1600 empfangen und Ausgaben (z.B. repräsentiert durch Ausgabedaten, Anzeigedaten usw.) über eine Mensch-Maschine-Schnittstelle („HMI“) Anzeige 1634, einen akustischen Melder, einen Lautsprecher und/oder über andere Komponenten des Fahrzeugs 1600 bereitstellen. In mindestens einem Ausführungsbeispiel können die Ausgaben Informationen wie Fahrzeuggeschwindigkeit, Geschwindigkeit, Zeit, Kartendaten (z.B. eine hochauflösende Karte (in 16A nicht dargestellt), Standortdaten (z.B. der Standort des Fahrzeugs 1600, wie auf einer Karte), Richtung, Standort anderer Fahrzeuge (z.B. ein Belegungsraster), Informationen über Objekte und den Status von Objekten, wie von der/den Steuerung(en) 1636 wahrgenommen, usw. umfassen. Zum Beispiel kann in mindestens einem Ausführungsbeispiel die HMI-Anzeige 1634 Informationen über das Vorhandensein eines oder mehrerer Objekte (z.B. ein Straßenschild, ein Warnschild, eine sich ändernde Ampel usw.) und/oder Informationen über Fahrmanöver anzeigen, die das Fahrzeug durchgeführt hat, gerade durchführt oder durchführen wird (z.B. jetzt die Spur wechseln, in zwei Meilen die Ausfahrt 34B nehmen, usw.).
In mindestens einem Ausführungsbeispiel umfasst das Fahrzeug 1600 ferner eine Netzwerkschnittstelle 1624, die drahtlose Antenne(n) 1626 und/oder Modem(e) zur Kommunikation über ein oder mehrere Netzwerke verwenden kann. Zum Beispiel kann in mindestens einem Ausführungsbeispiel die Netzwerkschnittstelle 1624 in der Lage sein, über Long-Term Evolution („LTE“), Wideband Code Division Multiple Access („WCDMA“), Universal Mobile Telecommunications System („UMTS“), Global System for Mobile Communication („GSM“), IMT-CDMA Multi-Carrier („CDMA2000“), etc. zu kommunizieren. In mindestens einem Ausführungsbeispiel können die drahtlose(n) Antenne(n) 1626 auch die Kommunikation zwischen Objekten in der Umgebung (z. B. Fahrzeuge, mobile Geräte usw.) unter Verwendung von Local Area Network(s) wie Bluetooth, Bluetooth Low Energy („LE“), Z-Wave, ZigBee usw. und/oder Low Power Wide Area Network(s) („LPWANs“) wie LoRaWAN, SigFox usw. ermöglichen.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 in dem System 16A zum Inferieren oder Vorhersagen verwendet werden, basierend zumindest teilweise auf Gewichtsparametern, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System für den Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das darauf trainiert ist, ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
16B zeigt gemäß mindestens einem Ausführungsbeispiel ein Beispiel für Kamerapositionen und Sichtfelder für das autonome Fahrzeug 1600 aus 16A. In mindestens einem Ausführungsbeispiel stellen die Kameras und die jeweiligen Sichtfelder ein Ausführungsbeispiel dar und sind nicht als einschränkend zu betrachten. Beispielsweise können in mindestens einem Ausführungsbeispiel zusätzliche und/oder alternative Kameras umfasst sein und/oder die Kameras können an verschiedenen Kamerapositionen am Fahrzeug 1600 angeordnet sein.
In mindestens einem Ausführungsbeispiel können Kameratypen für Kameras Digitalkameras umfassen, die zur Verwendung mit Komponenten und/oder Systemen des Fahrzeugs 1600 ausgebildet sein können, sind aber nicht darauf beschränkt. Die Kamera(s) kann/können auf der automobilen Sicherheitsintegritätsstufe („ASIL“) B und/oder auf einer anderen ASIL arbeiten. In mindestens einem Ausführungsbeispiel können die Kameratypen je nach Ausführungsbeispiel eine beliebige Bildaufnahmerate, wie 60 Einzelbilder pro Sekunde (fps), 1220 fps, 240 fps, usw., aufweisen. In mindestens einem Ausführungsbeispiel können die Kameras Rolling Shutter, Global Shutter, einen anderen Verschlusstyp oder eine Kombination davon verwenden. In mindestens einem Ausführungsbeispiel kann das Farbfilter Array ein Rot-Klar-Klar-Klar („RCCC“) Farbfilter Array, ein Rot-Klar-Klar-Blau („RCCB“) Farbfilter Array, ein Rot-Blau-Grün-Klar („RBGC“) Farbfilter Array, ein Foveon X3 Farbfilter Array, ein Bayer Sensoren („RGGB“) Farbfilter Array, ein Monochrom Sensor Farbfilter Array und/oder eine andere Art von Farbfilter Array umfassen. In mindestens einem Ausführungsbeispiel können zur Erhöhung der Lichtempfindlichkeit Clear-Pixel-Kameras, wie z. B. Kameras mit einem RCCC-, einem RCCB- und/oder einem RBGC-Farbfilter-Array, verwendet werden.
In mindestens einem Ausführungsbeispiel kann/können eine oder mehrere Kamera(s) verwendet werden, um Advanced Driver Assistance Systems („ADAS“)-Funktionen auszuführen (z. B. als Teil eines redundanten oder ausfallsicheren Designs). So kann in mindestens einem Ausführungsbeispiel eine Multifunktions-Monokamera installiert werden, die Funktionen wie Spurhalteassistent, Verkehrszeichenassistent und intelligente Scheinwerfersteuerung bereitstellt. In mindestens einem Ausführungsbeispiel können eine oder mehrere der Kameras (z.B. alle Kameras) gleichzeitig Bilddaten (z.B. Video) aufzeichnen und bereitstellen.
In mindestens einem Ausführungsbeispiel können eine oder mehrere Kameras in einer Montagevorrichtung, wie z. B. einer kundenspezifisch entworfenen (dreidimensionalen („3D“) gedruckten) Vorrichtung, montiert werden, um Streulicht und Reflexionen aus dem Fahrzeuginneren (z. B. Reflexionen vom Armaturenbrett, die in den Windschutzscheibenspiegeln reflektiert werden) auszuschalten, die die Fähigkeit der Kamera zur Bilddatenerfassung beeinträchtigen können. In mindestens einem Ausführungsbeispiel können die Seitenspiegel in 3D gedruckt werden, so dass die Kameramontageplatte der Form des Seitenspiegels entspricht. In mindestens einem Ausführungsbeispiel kann (können) die Kamera(s) in den Seitenspiegel integriert werden. Bei Seitenkameras kann/können die Kamera(s) auch in vier Säulen an jeder Ecke des Fahrerhauses integriert werden in mindestens einem Ausfiihrungsbeispiel.
In mindestens einem Ausführungsbeispiel können Kameras mit einem Sichtfeld, das Teile der Umgebung vor dem Fahrzeug 1600 umfasst (z.B. nach vorne gerichtete Kameras), für die Rundumsicht verwendet werden, um dabei zu helfen, nach vorne gerichtete Pfade und Hindernisse zu identifizieren, sowie dabei zu helfen, mit Hilfe von einem oder mehreren der Steuerungen 1636 und/oder Steuer-SoCs Informationen bereitzustellen, die für die Generierung eines Belegungsgitters und/oder das Bestimmen von bevorzugten Fahrzeugpfaden entscheidend sind. In mindestens einem Ausführungsbeispiel können nach vorne gerichtete Kameras verwendet werden, um viele der gleichen ADAS-Funktionen wie LIDAR auszuführen, einschließlich, ohne Einschränkung, Notbremsung, Fußgängererkennung und Kollisionsvermeidung. In mindestens einem Ausführungsbeispiel können nach vorne gerichtete Kameras auch für ADAS-Funktionen und -Systeme verwendet werden, einschließlich, ohne Einschränkung, Spurverlassenswarnungen („LDW“), autonome Geschwindigkeitsregelung („ACC“) und/oder andere Funktionen wie Verkehrszeichenerkennung.
In mindestens einem Ausführungsbeispiel kann eine Vielzahl von Kameras in einer nach vorne gerichteten Konfiguration verwendet werden, die beispielsweise eine monokulare Kameraplattform umfasst, die einen CMOS-Farbbildwandler („Complementary Metal Oxide Semiconductor“) enthält. In mindestens einem Ausführungsbeispiel kann die Weitwinkelkamera 1670 verwendet werden, um Objekte zu erkennen, die von der Peripherie her ins Blickfeld kommen (z. B. Fußgänger, kreuzende Fahrzeuge oder Fahrräder). Obwohl in 16B nur eine Weitwinkelkamera 1670 gezeigt ist, kann in anderen Ausführungsbeispielen eine beliebige Anzahl (einschließlich Null) von Weitwinkelkameras 1670 am Fahrzeug 1600 vorhanden sein. In mindestens einem Ausführungsbeispiel kann eine beliebige Anzahl von Ferndistanzkamera(s) 1698 (z.B. ein Weitwinkel-Stereokamerapaar) zur tiefenbasierten Objekterkennung verwendet werden, insbesondere für Objekte, für die ein neuronales Netzwerk noch nicht trainiert wurde. In mindestens einem Ausführungsbeispiel kann/können die Ferndistanzkamera(s) 1698 auch zur Objekterkennung und -klassifizierung sowie zur grundlegenden Objektverfolgung verwendet werden.
In mindestens einem Ausführungsbeispiel kann eine beliebige Anzahl von Stereokamera(s) 1668 auch in einer nach vorne gerichteten Konfiguration umfasst sein. In mindestens einem Ausführungsbeispiel kann eine oder mehrere der Stereokamera(s) 1668 eine integrierte Steuereinheit umfassen, die eine skalierbare Verarbeitungseinheit umfasst, die eine programmierbare Logik („FPGA“) und einen Mehrkern-Mikroprozessor mit einer integrierten Netzwerkschnittstelle („CAN“) oder Ethernet-Schnittstelle auf einem einzigen Chip bereitstellen kann. In mindestens einem Ausführungsbeispiel kann eine solche Einheit verwendet werden, um eine 3D-Karte der Umgebung des Fahrzeugs 1600 zu generieren, die eine Abschätzung der Entfernung für alle Punkte im Bild umfasst. In mindestens einem Ausführungsbeispiel kann eine oder mehrere der Stereokamera(s) 1668 ohne Einschränkung kompakte(n) Stereobildsensor(en) umfassen, die ohne Einschränkung zwei Kameralinsen (je eine links und rechts) und einen Bildverarbeitungschip umfassen können, der den Abstand zwischen dem Fahrzeug 1600 und dem Zielobjekt messen und generierte Informationen (z. B. Metadaten) verwenden kann, um autonome Notbrems- und Spurhaltewarnfunktionen zu aktivieren. In mindestens einem Ausführungsbeispiel können auch andere Arten von Stereokameras 1668 zusätzlich oder alternativ zu den hierin beschriebenen verwendet werden.
In mindestens einem Ausführungsbeispiel können Kameras mit einem Sichtfeld, das Teile der Umgebung seitlich des Fahrzeugs 1600 umfasst (z.B. Seitenkameras), für die Umgebungsansicht verwendet werden und Informationen bereitstellen, die zur Erstellung und Aktualisierung des Belegungsgitters sowie zur Generierung von Seitenaufprallwarnungen verwendet werden. Zum Beispiel könnten in mindestens einem Ausführungsbeispiel die Umgebungskamera(s) 1674 (z.B. vier Umgebungskameras 1674, wie in 16B gezeigt) am Fahrzeug 1600 positioniert werden. Die Umgebungskamera(s) 1674 kann/können ohne Einschränkung eine beliebige Anzahl und Kombination von Weitwinkelkamera(s) 1670, Fischaugenkamera(s), 360-Grad-Kamera(s) und/oder dergleichen umfassen. Zum Beispiel können in mindestens einem Ausführungsbeispiel vier Fischaugenkameras an der Vorderseite, der Rückseite und den Seiten des Fahrzeugs 1600 positioniert werden. In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 drei Surround-Kamera(s) 1674 (z.B. links, rechts und hinten) verwenden, und kann eine oder mehrere andere Kamera(s) (z.B. eine nach vorne gerichtete Kamera) als vierte Surround-View-Kamera nutzen.
In mindestens einem Ausführungsbeispiel können Kameras mit einem Sichtfeld, das Teile der Umgebung hinter dem Fahrzeug 1600 umfasst (z.B. Rückfahrkameras), für die Einparkhilfe, die Umgebungsansicht, die Heckkollisionswarnungen und das Erstellen und Aktualisieren des Belegungsgitters verwendet werden. In mindestens einem Ausführungsbeispiel kann eine Vielzahl von Kameras verwendet werden, einschließlich, aber nicht beschränkt auf, Kameras, die auch als nach vorne gerichtete Kamera(s) geeignet sind (z.B. Ferndistanzkameras 1698 und/oder Mitteldistanzkamera(s) 1676, Stereokamera(s) 1668), Infrarotkamera(s) 1672, usw.), wie hier beschrieben.
Inferenz- und/oder Trainingslogiken 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System 16B zum Inferieren oder Vorhersagen verwendet werden, basierend zumindest teilweise auf Gewichtsparametern, die unter Verwendung von Trainingsoperationen für neuronale Netzwerke, Funktionen und/oder Architekturen von neuronalen Netzwerken oder hierin beschriebenen Anwendungsfällen für neuronale Netzwerke berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das so trainiert ist, dass es ein Greifen eines Objekts generiert, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
16C ist ein Blockdiagramm, das gemäß mindestens einem Ausführungsbeispiel eine beispielhafte Systemarchitektur für das autonome Fahrzeug 1600 aus 16A zeigt. In mindestens einem Ausführungsbeispiel ist jedes der Komponenten, Merkmale und Systeme des Fahrzeugs 1600 in 16C als über einen Bus 1602 verbunden gezeigt. In mindestens einem Ausführungsbeispiel kann der Bus 1602 ohne Einschränkung eine CAN-Datenschnittstelle umfassen (hier alternativ als „CAN-Bus“ bezeichnet). In mindestens einem Ausführungsbeispiel kann ein CAN ein Netzwerk innerhalb des Fahrzeugs 1600 sein, das zur Unterstützung der Steuerung verschiedener Merkmale und Funktionalitäten des Fahrzeugs 1600 verwendet wird, wie z.B. Betätigung der Bremsen, Beschleunigung, Bremsen, Aktuator, Scheibenwischer usw. In mindestens einem Ausführungsbeispiel kann der Bus 1602 so konfiguriert sein, dass er Dutzende oder sogar Hunderte von Knoten enthält, von denen jeder seinen eigenen eindeutigen Identifikator hat (z.B. eine CAN-ID). In mindestens einem Ausführungsbeispiel kann der Bus 1602 ausgelesen werden, um Lenkradwinkel, Fahrgeschwindigkeit, Motordrehzahl, Tastenpositionen und/oder andere Fahrzeugstatusanzeigen zu ermitteln. In mindestens einem Ausführungsbeispiel kann der Bus 1602 ein CAN-Bus sein, der ASIL B-konform ist.
In mindestens einem Ausführungsbeispiel können zusätzlich zu oder alternativ zu CAN auch FlexRay und/oder Ethernet verwendet werden. In mindestens einem Ausführungsbeispiel kann es eine beliebige Anzahl von Bussen 1602 geben, die ohne Einschränkung null oder mehr CAN-Busse, null oder mehr FlexRay-Busse, null oder mehr Ethernet-Busse und/oder null oder mehr andere Arten von Bussen unter Verwendung eines anderen Protokolls umfassen können. In mindestens einem Ausführungsbeispiel können zwei oder mehr Busse 1602 verwendet werden, um unterschiedliche Funktionalitäten auszuführen, und/oder sie können zur Redundanz verwendet werden. Zum Beispiel kann ein erster Bus 1602 für die Funktionalität der Kollisionsvermeidung und ein zweiter Bus 1602 für die Steuerung der Aktuatoren verwendet werden. In mindestens einem Ausführungsbeispiel kann jeder Bus 1602 mit beliebigen Komponenten des Fahrzeugs 1600 kommunizieren, und zwei oder mehr Busse 1602 können mit denselben Komponenten kommunizieren. In mindestens einem Ausführungsbeispiel kann jedes von einer beliebigen Anzahl von System-on-a-Chip(s) („SoC(s)“) 1604, jede der Steuerungen 1636 und/oder jeder Computer innerhalb des Fahrzeugs Zugriff auf dieselben Eingabedaten haben (z.B. Eingaben von Sensoren des Fahrzeugs 1600) und kann mit einem gemeinsamen Bus, wie dem CAN-Bus, verbunden sein.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 eine oder mehrere Steuerung(en) 1636 umfassen, wie sie hier in Bezug auf 16A beschrieben sind. Die Steuerung(en) 1636 kann/können für eine Vielzahl von Funktionen verwendet werden. In mindestens einem Ausführungsbeispiel kann (können) die Steuerung(en) 1636 mit einer beliebigen von verschiedenen anderen Komponenten und Systemen des Fahrzeugs 1600 gekoppelt sein und kann (können) für die Steuerung des Fahrzeugs 1600, die künstliche Intelligenz des Fahrzeugs 1600, das Infotainment für das Fahrzeug 1600 und/oder ähnliches verwendet werden.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 eine beliebige Anzahl von SoCs 1604 umfassen. Jeder der SoCs 1604 kann, ohne Einschränkung, zentrale Verarbeitungseinheiten („CPU(s)“) 1606, Grafikverarbeitungseinheiten („GPU(s)“) 1608, Prozessor(en) 1610, Cache(s) 1612, Beschleuniger(s) 1614, Datenspeichers) 1616 und/oder andere nicht gezeigte Komponenten und Merkmale umfassen. In mindestens einem Ausführungsbeispiel können SoC(s) 1604 zur Steuerung des Fahrzeugs 1600 in einer Vielzahl von Plattformen und Systemen verwendet werden. Zum Beispiel können in mindestens einem Ausführungsbeispiel SoC(s) 1604 in einem System (z.B. System des Fahrzeugs 1600) mit einer High-Definition („HD“)-Karte 1622 kombiniert werden, die Kartenauffrischungen und/oder - aktualisierungen über die Netzwerkschnittstelle 1624 von einem oder mehreren Servern erhalten kann (in 16C nicht dargestellt).
In mindestens einem Ausführungsbeispiel kann/können die CPU(s) 1606 einen CPU-Cluster oder CPU-Komplex umfassen (hierin alternativ als „CCPLEX“ bezeichnet). In mindestens einem Ausführungsbeispiel kann (können) die CPU(s) 1606 mehrere Kerne und/oder Level-2-Caches („L2“) umfassen. In mindestens einem Ausführungsbeispiel kann (können) die CPU(s) 1606 beispielsweise acht Kerne in einer kohärenten Multiprozessorkonfiguration umfassen. In mindestens einem Ausführungsbeispiel kann (können) die CPU(s) 1606 vier Dual-Core-Cluster umfassen, wobei jeder Cluster über einen dedizierten L2-Cache (z. B. einen 2 MB L2-Cache) verfügt. In mindestens einem Ausführungsbeispiel kann (können) die CPU(s) 1606 (z.B. CCPLEX) so konfiguriert sein, dass sie einen simultanen Clusterbetrieb unterstützen, so dass jede Kombination von Clustern der CPU(s) 1606 zu einem beliebigen Zeitpunkt aktiv sein kann.
In mindestens einem Ausführungsbeispiel können eine oder mehrere der CPU(s) 1606 Energieverwaltungsfunktionen implementieren, die ohne Einschränkung eine oder mehrere der folgenden Funktionen umfassen: Einzelne Hardwareblöcke können im Leerlauf automatisch getaktet werden, um dynamische Leistung zu speichern; jeder Kerntakt kann getaktet werden, wenn der Kern aufgrund der Ausführung von Wait for Interrupt („WFI“)/Wait for Event („WFE“)-Befehlen nicht aktiv Befehle ausführt; jeder Kern kann unabhängig stromgesteuert sein; jeder Kern-Cluster kann unabhängig taktgesteuert sein, wenn alle Kerne taktgesteuert oder stromgesteuert sind; und/oder jeder Kern-Cluster kann unabhängig stromgesteuert sein, wenn alle Kerne stromgesteuert sind. In mindestens einem Ausführungsbeispiel kann/können die CPU(s) 1606 ferner einen verbesserten Algorithmus zur Verwaltung von Energiezuständen implementieren, bei dem zulässige Energiezustände und erwartete Aufwachzeiten spezifiziert werden und die Hardware/der Mikrocode den besten Energiezustand bestimmt, der für den Kern, den Cluster und CCPLEX einzunehmen ist. In mindestens einem Ausführungsbeispiel können die Kerne vereinfachte Sequenzen für die Eingabe des Energiezustands in Software unterstützen, wobei die Arbeit an den Mikrocode ausgelagert wird.
In mindestens einem Ausführungsbeispiel kann (können) die GPU(s) 1608 eine integrierte GPU umfassen (hier alternativ als „iGPU“ bezeichnet). In mindestens einem Ausführungsbeispiel kann (können) GPU(s) 1608 programmierbar sein und für parallele Arbeitslasten effizient sein. In mindestens einem Ausführungsbeispiel kann (können) die GPU(s) 1608 in mindestens einem Ausführungsbeispiel einen verbesserten Tensor-Befehlssatz verwenden. In mindestens einem Ausführungsbeispiel kann (können) GPU(s) 1608 einen oder mehrere Streaming-Mikroprozessoren umfassen, wobei jeder Streaming-Mikroprozessor einen Level-1-Cache („L1“) (z. B. einen L1-Cache mit mindestens 96 KB Speicher) umfassen kann und zwei oder mehr Streaming-Mikroprozessoren einen L2-Cache (z. B. einen L2-Cache mit 512 KB Speicher) gemeinsam nutzen können. In mindestens einem Ausführungsbeispiel können die GPU(s) 1608 mindestens acht Streaming-Mikroprozessoren umfassen. In mindestens einem Ausführungsbeispiel kann (können) GPU(s) 1608 unter Verwendung von Anwendungsprogrammierschnittstelle(n) (API(s)) rechnen. In mindestens einem Ausführungsbeispiel kann (können) GPU(s) 1608 eine oder mehrere parallele Rechenplattformen und/oder Programmiermodelle (z.B. NVIDIAs CUDA) verwenden.
In mindestens einem Ausführungsbeispiel können eine oder mehrere GPU(s) 1608 für die beste Leistung in Automobil- und eingebetteten Anwendungsfällen energieoptimiert sein. In einem Ausführungsbeispiel könnte(n) die GPU(s) 1608 beispielsweise auf einem Fin-Feldeffekttransistor („FinFET“) hergestellt werden. In mindestens einem Ausführungsbeispiel kann jeder Streaming-Mikroprozessor eine Reihe von gemischtpräzisen Verarbeitungskernen enthalten, die in mehrere Blöcke unterteilt sind. So könnten beispielsweise 64 PF32-Kerne und 32 PF64-Kerne in vier Schritte unterteilt werden. In mindestens einem Ausführungsbeispiel könnten jedem Verarbeitungsblock 16 FP32 Kerne, 8 FP64 Kerne, 16 INT32 Kerne, zwei gemischtpräzise NVIDIA TENSOR COREs für Deep Leaming-Matrixarithmetik, ein Level-Null („L0“) Befehls-Cache, ein Warp-Planer, eine Verteilungseinheit und/oder eine 64 KB große Registerdatei zugewiesen werden. In mindestens einem Ausführungsbeispiel können Streaming-Mikroprozessoren unabhängige parallele Ganzzahl- und Gleitkomma-Datenpfade umfassen, um eine effiziente Ausführung von Arbeitslasten mit einer Mischung aus Berechnungen und Adressierungsberechnungen bereitzustellen. In mindestens einem Ausführungsbeispiel können Streaming-Mikroprozessoren eine unabhängige Thread-Planungsfunktion umfassen, um eine feingranulare Synchronisierung und Zusammenarbeit zwischen parallelen Threads zu ermöglichen. In mindestens einem Ausführungsbeispiel können Streaming-Mikroprozessoren eine kombinierte L1-Datencache- und gemeinsam genutzte Speicher-Einheit umfassen, um die Leistung zu verbessern und gleichzeitig die Programmierung zu vereinfachen.
In mindestens einem Ausführungsbeispiel können eine oder mehrere GPU(s) 1608 einen Speicher mit hoher Bandbreite („HBM“) und/oder ein 16 GB HBM2-Speicher-Subsystem umfassen, um in einigen Beispielen eine Spitzen-Speicherbandbreite von etwa 900 GB/Sekunde bereitzustellen. In mindestens einem Ausführungsbeispiel kann zusätzlich oder alternativ zum HBM-Speicher ein synchroner Grafik-Direktzugriffsspeicher („SGRAM“) verwendet werden, wie z.B. ein synchroner Grafik-Doppeldatenraten-Direktzugriffsspeicher vom Typ fünf („GDDR5‟).
In mindestens einem Ausführungsbeispiel können die GPU(s) 1608 die Unified-Memory-Technologie umfassen. In mindestens einem Ausführungsbeispiel kann die Unterstützung von Adressübersetzungsdiensten („ATS“) verwendet werden, um GPU(s) 1608 den direkten Zugriff auf Seitentabellen der CPU(s) 1606 zu ermöglichen. In mindestens einem Ausführungsbeispiel kann bei einem Fehlversuch der GPU(s) 1608 Speicherverwaltungseinheit („MMU“) eine Adressübersetzungsanforderung an die CPU(s) 1606 übermittelt werden. Als Reaktion darauf kann die CPU(s) 1606 in ihren Seitentabellen nach einer virtuell-physikalischen Zuordnung der Adresse suchen und die Übersetzung in mindestens einem Ausführungsbeispiel zurück an die GPU(s) 1608 übertragen. In mindestens einem Ausführungsbeispiel kann die Technologie des einheitlichen Speichers einen einzigen einheitlichen virtuellen Adressraum für den Speicher sowohl der CPU(s) 1606 als auch der GPU(s) 1608 ermöglichen, wodurch die Programmierung der GPU(s) 1608 und der Anschluss von Anwendungen an die GPU(s) 1608 vereinfacht wird.
In mindestens einem Ausführungsbeispiel kann die GPU(s) 1608 eine beliebige Anzahl von Zugriffszählern umfassen, die die Häufigkeit des Zugriffs der GPU(s) 1608 auf den Speicher anderer Prozessoren verfolgen können. In mindestens einem Ausführungsbeispiel können Zugriffszähler dazu beitragen, dass Speicherseiten in den physischen Speicher desjenigen Prozessors verschoben werden, der am häufigsten auf Seiten zugreift, wodurch die Effizienz von Speicherbereichen, die von Prozessoren gemeinsam genutzt werden, verbessert wird.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 eine beliebige Anzahl von Cache(s) 1612 umfassen, einschließlich der hierin beschriebenen. In mindestens einem Ausführungsbeispiel könnte(n) der/die Cache(s) 1612 beispielsweise einen Level-1-Cache („L3“) umfassen, der sowohl für die CPU(s) 1606 als auch für die GPU(s) 1608 verfügbar ist (z. B. der sowohl mit der/den CPU(s) 1606 als auch mit der/den GPU(s) 1608 verbunden ist). In mindestens einem Ausführungsbeispiel kann der (die) Cache(s) 1612 einen Write-Back-Cache umfassen, der die Zustände von Zeilen verfolgen kann, etwa unter Verwendung eines Cache-Kohärenzprotokolls (z. B. MEI, MESI, MSI usw.). In mindestens einem Ausführungsbeispiel kann der L3-Cache je nach Ausführungsbeispiel 4 MB oder mehr umfassen, wobei auch kleinere Cache-Größen verwendet werden können.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 einen oder mehrere Beschleuniger 1614 umfassen (z. B. Hardwarebeschleuniger, Softwarebeschleuniger oder eine Kombination davon). In mindestens einem Ausführungsbeispiel kann (können) der (die) SoC(s) 1604 einen Hardware-Beschleunigungscluster umfassen, der optimierte Hardware-Beschleuniger und/oder einen großen On-Chip-Speicher umfassen kann. In mindestens einem Ausführungsbeispiel kann ein großer On-Chip-Speicher (z. B. 4 MB SRAM) dem Hardware-Beschleunigungscluster ermöglichen, neuronale Netzwerke und andere Berechnungen zu beschleunigen. In mindestens einem Ausführungsbeispiel kann ein Hardware-Beschleunigungscluster zur Ergänzung der GPU(s) 1608 und zur Entlastung einiger Aufgaben der GPU(s) 1608 verwendet werden (z. B. um mehr Zyklen der GPU(s) 1608 für die Durchführung anderer Aufgaben freizugeben). In mindestens einem Ausführungsbeispiel könnte(n) der/die Beschleuniger 1614 für gezielte Arbeitslasten verwendet werden (z. B. Erfassung, Convolutional Neural Networks („CNNs“), rekurrente neuronale Netzwerke („RNNs“) usw.), die stabil genug sind, um für eine Beschleunigung geeignet zu sein. In mindestens einem Ausführungsbeispiel kann ein CNN ein auf einem Bereich basierendes oder regionales Convolutional Neural Network („RCNNs“) und Fast RCNs (z. B. zur Objekterkennung verwendet) oder eine andere Art von CNN umfassen.
In mindestens einem Ausführungsbeispiel kann der/die Beschleuniger 1614 (z. B. Hardware-Beschleunigungscluster) einen Deep Learning-Beschleuniger („DLA“) umfassen. Der/die DLA(s) kann/können ohne Einschränkung eine oder mehrere Tensor Processing Units („TPUs“) umfassen, die so konfiguriert sein können, dass sie zusätzliche zehn Billionen Operationen pro Sekunde für Deep-Learning-Anwendungen und zum Inferenzieren bereitstellen. In mindestens einem Ausführungsbeispiel können TPUs Beschleuniger sein, die für die Ausführung von Bildverarbeitungsfunktionen (z. B. für CNNs, RCNNs usw.) konfiguriert und optimiert sind. DLA(s) können weiter für einen bestimmten Satz von Typen neuronaler Netzwerke und Gleitkommaoperationen sowie zum Inferenzieren optimiert sein. In mindestens einem Ausführungsbeispiel kann das Design von DLA(s) mehr Leistung pro Millimeter bereitstellen als eine typische allgemeine GPU und übertrifft in der Regel die Leistung einer CPU bei weitem. In mindestens einem Ausführungsbeispiel kann (können) die TPU(s) mehrere Funktionalitäten ausführen, einschließlich einer Einzelinstanz-Faltungsfunktion, die z. B. INT8-, INT16- und FP16-Datentypen sowohl für Merkmale als auch für Gewichte sowie Postprozessorfunktionen unterstützt. In mindestens einem Ausführungsbeispiel können DLA(s) schnell und effizient neuronale Netzwerke, insbesondere CNNs, auf verarbeiteten oder unverarbeiteten Daten für eine Vielzahl von Funktionen ausführen, einschließlich beispielsweise und ohne Einschränkung: ein CNN für die Identifizierung und Detektion von Objekten unter Verwendung von Daten von Kamerasensoren; ein CNN für die Abstandsabschätzung unter Verwendung von Daten von Kamerasensoren; ein CNN für die Erkennung und Identifizierung von Notfallfahrzeugen und die Erkennung und Abschätzung von Daten von Mikrofonen 1696; ein CNN für die Gesichtserkennung und die Identifizierung von Fahrzeugbesitzern unter Verwendung von Daten von Kamerasensoren; und/oder ein CNN für sicherheitsrelevante und/oder sicherheitsbezogene Ereignisse.
In mindestens einem Ausführungsbeispiel können DLA(s) jede Funktionalität von GPU(s) 1608 ausführen, und unter Verwendung eines Inferenzbeschleunigers kann ein Designer beispielsweise entweder DLA(s) oder GPU(s) 1608 für jede Funktionalität anvisieren. In mindestens einem Ausführungsbeispiel kann der Designer beispielsweise die Verarbeitung von CNNs und Gleitkommaoperationen auf DLA(s) konzentrieren und andere Funktionen der GPU(s) 1608 und/oder anderen Beschleunigern 1614 überlassen.
In mindestens einem Ausführungsbeispiel kann/können der/die Beschleuniger 1614 (z. B. Hardware-Beschleunigungscluster) einen programmierbaren Bildverarbeitungsbeschleuniger („PVA“) umfassen, der hier alternativ auch als Computer-Vision-Beschleuniger bezeichnet werden kann. In mindestens einem Ausführungsbeispiel kann (können) der (die) PVA(s) so gestaltet und konfiguriert sein, dass er (sie) computergestützte Vision-Algorithmen für Advanced Driver Assistance Systems („ADAS“) 1638, autonomes Fahren, Augmented Reality („AR“)-Anwendungen und/oder Virtual Reality („VR“)-Anwendungen beschleunigt. PVA(s) können ein Gleichgewicht zwischen Leistung und Flexibilität bereitstellen. In mindestens einem Ausführungsbeispiel kann jede PVA beispielsweise und ohne Einschränkung eine beliebige Anzahl von Kernen mit reduziertem Befehlssatz („RISC“), direkten Speicherzugriff („DMA“) und/oder eine beliebige Anzahl von Vektorprozessoren umfassen.
In mindestens einem Ausführungsbeispiel können RISC-Kerne mit Bildsensoren (z.B. Bildsensoren einer der hierin beschriebenen Kameras), Bildsignalprozessoren und/oder ähnlichem interagieren. In mindestens einem Ausführungsbeispiel kann jeder der RISC-Kerne eine beliebige Menge an Speicher umfassen. In mindestens einem Ausführungsbeispiel können RISC-Kerne je nach Ausführungsbeispiel eines von mehreren Protokollen verwenden. In mindestens einem Ausführungsbeispiel können RISC-Kerne ein Echtzeitbetriebssystem („RTOS“) ausführen. In mindestens einem Ausführungsbeispiel können RISC-Kerne unter Verwendung von einem oder mehreren integrierten Schaltungsgeräten, anwendungsspezifischen integrierten Schaltungen („ASICs“) und/oder Speichergeräten implementiert werden. In mindestens einem Ausführungsbeispiel könnten RISC-Kerne beispielsweise einen Befehlscache und/oder einen eng gekoppelten Arbeitsspeicher umfassen.
In mindestens einem Ausführungsbeispiel kann der DMA es den Komponenten der PVA(s) ermöglichen, unabhängig von der/den CPU(s) 1606 auf den Systemspeicher zuzugreifen. In mindestens einem Ausführungsbeispiel kann DMA eine beliebige Anzahl von Merkmalen unterstützen, die dazu verwendet werden, der PVA eine Optimierung bereitzustellen, einschließlich, aber nicht beschränkt auf, die Unterstützung von mehrdimensionaler Adressierung und/oder zirkulärer Adressierung. In mindestens einem Ausführungsbeispiel kann DMA bis zu sechs oder mehr Dimensionen der Adressierung unterstützen, die ohne Einschränkung Blockbreite, Blockhöhe, Blocktiefe, horizontale Blockschritte, vertikale Blockschritte und/oder Tiefenschritte umfassen können.
In mindestens einem Ausführungsbeispiel können Vektorprozessoren programmierbare Prozessoren sein, die so gestaltet sein können, dass sie die Programmierung für computergestützte Vision-Algorithmen effizient und flexibel ausführen und Signalverarbeitungsfunktionen bereitstellen. In mindestens einem Ausführungsbeispiel kann PVA einen PVA-Kern und zwei Vektorverarbeitungs-Subsystem-Partitionen umfassen. In mindestens einem Ausführungsbeispiel kann der PVA-Kern ein Prozessor-Subsystem, DMA-Engine(s) (z. B. zwei DMA-Engines) und/oder andere Peripheriegeräte umfassen. In mindestens einem Ausführungsbeispiel kann das Vektorverarbeitungssubsystem als primäre Verarbeitungs-Engine der PVA fungieren und eine Vektorverarbeitungseinheit („VPU“), einen Befehlscache und/oder einen Vektorspeicher (z. B. „VMEM“) umfassen. In mindestens einem Ausführungsbeispiel kann der Kern der VPU einen digitalen Signalprozessor umfassen, wie z. B. einen digitalen Signalprozessor mit einer einzigen Anweisung und mehreren Daten („SIMD“) oder einem sehr langen Anweisungswort („VLIW“). In mindestens einem Ausführungsbeispiel kann eine Kombination aus SIMD und VLIW den Durchsatz und die Geschwindigkeit verbessern.
In mindestens einem Ausführungsbeispiel kann jeder der Vektorprozessoren einen Befehlscache umfassen und mit einem dedizierten Speicher gekoppelt sein. Als Ergebnis kann in mindestens einem Ausführungsbeispiel jeder Vektorprozessor so konfiguriert sein, dass er unabhängig von anderen Vektorprozessoren arbeitet. In mindestens einem Ausführungsbeispiel können Vektorprozessoren, die in einer bestimmten PVA umfasst sind, so konfiguriert sein, dass sie Datenparallelität verwenden. Beispielsweise kann in mindestens einem Ausführungsbeispiel eine Vielzahl von Vektorprozessoren, die in einer einzigen PVA umfasst sind, denselben Algorithmus für computergestützte Vision ausführen, jedoch für unterschiedliche Bereiche eines Bildes. In mindestens einem Ausführungsbeispiel können die in einer bestimmten PVA eingeschlossenen Vektorprozessoren simultan verschiedene Algorithmen der computergestützten Vision auf demselben Bild ausführen oder sogar verschiedene Algorithmen auf sequentiellen Bildern oder Teilen eines Bildes ausführen. In mindestens einem Ausführungsbeispiel kann unter anderem eine beliebige Anzahl von PVAs in einem Hardware-Beschleunigungscluster enthalten sein und eine beliebige Anzahl von Vektorprozessoren kann in jeder PVA umfasst sein. In mindestens einem Ausführungsbeispiel können die PVA(s) einen zusätzlichen ECC-Speicher umfassen, um die allgemeine Systemsicherheit zu verbessern.
In mindestens einem Ausführungsbeispiel kann (können) der (die) Beschleuniger 1614 (z. B. Hardware-Beschleunigungscluster) ein Netzwerk für computergestützte Vision auf dem Chip und einen statischen Direktzugriffsspeicher („SRAM“) umfassen, um einen SRAM mit hoher Bandbreite und geringer Latenz für den (die) Beschleuniger 1614 bereitzustellen. In mindestens einem Ausführungsbeispiel kann der On-Chip-Speicher mindestens 4 MB SRAM umfassen, der z. B. aus acht frei konfigurierbaren Speicherblöcken besteht, auf die sowohl PVA als auch DLA zugreifen können. In mindestens einem Ausführungsbeispiel kann jedes Paar von Speicherblöcken eine erweiterte Peripheriebus-Schnittstelle („APB“), eine Schaltungsanordnung, eine Steuerung und einen Multiplexer umfassen. In mindestens einem Ausführungsbeispiel kann jede Art von Speicher verwendet werden. In mindestens einem Ausführungsbeispiel können PVA und DLA über einen Backbone auf den Speicher zugreifen, der PVA und DLA einen Hochgeschwindigkeitszugriff auf den Speicher bereitstellt. In mindestens einem Ausführungsbeispiel kann das Backbone ein Netzwerk für computergestützte Vision auf dem Chip umfassen, das PVA und DLA mit dem Speicher verbindet (z.B. unter Verwendung von APB).
In mindestens einem Ausführungsbeispiel kann das Netzwerk für computergestützte Vision auf dem Chip eine Schnittstelle umfassen, die vor der Übertragung von Steuersignalen/Adressen/Daten bestimmt, dass sowohl PVA als auch DLA einsatzbereite und gültige Signale bereitstellen. In mindestens einem Ausführungsbeispiel kann eine Schnittstelle separate Phasen und separate Kanäle für die Übertragung von Steuersignalen/Adressen/Daten sowie eine Burst-Kommunikation für die kontinuierliche Datenübertragung bereitstellen. In mindestens einem Ausführungsbeispiel kann eine Schnittstelle den Normen der International Organization for Standardization („ISO“) 26262 oder der International Electrotechnical Commission („IEC“) 61508 entsprechen, obwohl auch andere Normen und Protokolle verwendet werden können.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 einen Echtzeit-Raytracing-Hardwarebeschleuniger umfassen. In mindestens einem Ausführungsbeispiel kann der Echtzeit-Raytracing-Hardwarebeschleuniger verwendet werden, um schnell und effizient Positionen und Ausdehnungen von Objekten (z.B. innerhalb eines Weltmodells) zu bestimmen, um Echtzeit-Visualisierungssimulationen zu generieren, für RADAR-Signalinterpretation, für Schallausbreitungssynthese und/oder -analyse, für die Simulation von SONAR-Systemen, für allgemeine Wellenausbreitungssimulationen, für den Vergleich mit LIDAR-Daten zum Zwecke der Lokalisierung und/oder anderer Funktionen und/oder für andere Zwecke.
In mindestens einem Ausführungsbeispiel haben der/die Beschleuniger 1614 (z.B. Hardware-Beschleuniger-Cluster) ein breites Array an Verwendungen für das autonome Fahren. In mindestens einem Ausführungsbeispiel kann PVA ein programmierbarer Bildverarbeitungsbeschleuniger sein, der für wichtige Verarbeitungsschritte in ADAS und autonomen Fahrzeugen verwendet werden kann. In mindestens einem Ausführungsbeispiel sind die Fähigkeiten von PVA ein gutes Matching für algorithmische Bereiche, die eine vorhersehbare Verarbeitung bei geringer Leistung und geringer Latenz benötigen. Mit anderen Worten: PVA eignet sich gut für halbdichte oder dichte reguläre Berechnungen, selbst bei kleinen Datensätzen, die vorhersehbare Laufzeiten mit geringer Latenz und geringem Stromverbrauch erfordern. In mindestens einem Ausführungsbeispiel werden in autonomen Fahrzeugen, wie dem Fahrzeug 1600, PVAs für die Ausführung klassischer computergestützter Vision-Algorithmen entworfen, da sie bei der Objekterkennung effizient sind und mit ganzzahligen mathematischen Verfahren arbeiten.
Zum Beispiel wird PVA gemäß mindestens einem Ausführungsbeispiel der Technologie verwendet, um computergestützte Vision durchzuführen. In mindestens einem Ausführungsbeispiel kann in einigen Beispielen ein auf semiglobalem Matching basierender Algorithmus verwendet werden, obwohl dies nicht als Einschränkung gedacht ist. In mindestens einem Ausführungsbeispiel verwenden Anwendungen für das autonome Fahren der Stufen 3-5 die Bewegungsabschätzung/Stereo-Matching on-the-fly (z. B. Struktur aus Bewegung, Fußgängererkennung, Fahrspurerkennung usw.). In mindestens einem Ausführungsbeispiel kann PVA eine computergestützte Vision-Funktion für Eingaben von zwei monokularen Kameras ausführen.
In mindestens einem Ausführungsbeispiel kann PVA verwendet werden, um einen dichten optischen Fluss durchzuführen. Beispielsweise könnte PVA in mindestens einem Ausführungsbeispiel unbearbeitete RADAR-Daten verarbeiten (z. B. unter Verwendung einer 4D-Fast-Fourier-Transformation), um verarbeitete RADAR-Daten bereitzustellen. In mindestens einem Ausführungsbeispiel wird PVA für die Verarbeitung der Flugzeittiefe verwendet, indem unbearbeitete Daten der Laufzeit verarbeitet werden, um beispielsweise verarbeitete Daten der Laufzeit bereitzustellen.
In mindestens einem Ausführungsbeispiel kann DLA verwendet werden, um jede Art von Netzwerk zu betreiben, um die Steuerung und die Fahrsicherheit zu verbessern, einschließlich beispielsweise und ohne Einschränkung eines neuronalen Netzwerks, das ein Maß an Konfidenz für jede Objekterkennung ausgibt. In mindestens einem Ausführungsbeispiel kann die Konfidenz als Wahrscheinlichkeit repräsentiert oder interpretiert werden oder als Bereitstellen einer relativen „Gewichtung“ jeder Detektion im Vergleich zu anderen Detektionen. In mindestens einem Ausführungsbeispiel ermöglicht die Konfidenz dem System, weitere Entscheidungen darüber zu treffen, welche Erkennungen als echte positive Erkennungen und nicht als falsch positive Erkennungen zu betrachten sind. Beispielsweise kann ein System in mindestens einem Ausführungsbeispiel einen Schwellenwert für die Konfidenz festlegen und nur Erkennungen, die den Schwellenwert überschreiten, als echte positive Erkennungen betrachten. In einem Ausführungsbeispiel, in dem ein automatisches Notbremssystem („AEB“) verwendet wird, würden falsch positive Erkennungen bewirken, dass das Fahrzeug automatisch eine Notbremsung durchführt, was natürlich unerwünscht ist. In mindestens einem Ausführungsbeispiel können sehr zuverlässige Erkennungen als Auslöser für AEB in Betracht gezogen werden. In mindestens einem Ausführungsbeispiel kann DLA ein neuronales Netzwerk zur Regression des Konfidenzwertes einsetzen. In mindestens einem Ausführungsbeispiel kann das neuronale Netzwerk als Eingabe mindestens eine Teilmenge von Parametern erhalten, wie z.B. die Abmessungen der Bounding Box, die (z.B. von einem anderen Subsystem) erhaltene Schätzung der Bodenebene, die Ausgabe des/der IMU-Sensors/en 1666, die mit der Orientierung des Fahrzeugs 1600 korreliert, die Entfernung, die 3D-Positionsschätzungen des Objekts, die in mindestens einem Ausführungsbeispiel vom neuronalen Netzwerk und/oder anderen Sensoren (z.B. LIDAR-Sensor/en 1664 oder RADAR-Sensor/en 1660) abgeschätzt werden, und andere.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 einen oder mehrere Datenspeicher 1616 (z.B. Speicher) umfassen. In mindestens einem Ausführungsbeispiel kann (können) der (die) Datenspeicher 1616 ein On-Chip-Speicher des (der) SoC(s) 1604 sein, der (die) neuronale Netzwerke speichern kann (können), die auf GPU(s) 1608 und/oder DLA ausgeführt werden sollen. In mindestens einem Ausführungsbeispiel kann (können) der (die) Datenspeicher 1616 groß genug sein, um mehrere Instanzen neuronaler Netzwerke zur Redundanz und Sicherheit zu speichern. In mindestens einem Ausführungsbeispiel kann/können der/die Datenspeicher 1612 L2 oder L3 Cache(s) umfassen.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 eine beliebige Anzahl von Prozessor(en) 1610 (z.B. eingebettete Prozessoren) umfassen. Der/die Prozessor(en) 1610 kann/können einen Boot- und Energieverwaltungsprozessor umfassen, der ein dedizierter Prozessor und ein Subsystem sein kann, um die Boot-Energie- und - Verwaltungsfunktionen und die damit verbundene Sicherheitsdurchsetzung zu handhaben. In mindestens einem Ausführungsbeispiel kann der Boot- und Energieverwaltungsprozessor ein Teil der Bootsequenz des/der SoC(s) 1604 sein und kann Laufzeit-Energieverwaltungsdienste bereitstellen. In mindestens einem Ausführungsbeispiel kann der Prozessor für die Boot-Energieversorgung und -Verwaltung die Programmierung von Takt und Spannung, die Unterstützung bei Übergängen des Systems in einen Zustand mit niedriger Leistung, die Verwaltung der Thermik und der Temperatursensoren des SoC(s) 1604 und/oder die Verwaltung der Leistungszustände des SoC(s) 1604 bereitstellen. In mindestens einem Ausführungsbeispiel kann jeder Temperatursensor als Ringoszillator implementiert sein, dessen Ausgabefrequenz proportional zur Temperatur ist, und SoC(s) 1604 können Ringoszillatoren verwenden, um die Temperaturen von CPU(s) 1606, GPU(s) 1608 und/oder Beschleuniger(n) 1614 zu detektieren. In mindestens einem Ausführungsbeispiel kann der Boot- und Energieverwaltungsprozessor, wenn bestimmt wird, dass die Temperaturen einen Schwellenwert überschreiten, in eine Temperaturfehlerroutine eintreten und die SoC(s) 1604 in einen Zustand mit geringerer Leistung versetzen und/oder das Fahrzeug 1600 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen (z. B. das Fahrzeug 1600 zu einem sicheren Halt bringen).
In mindestens einem Ausführungsbeispiel kann(n) der/die Prozessor(en) 1610 ferner eine Reihe eingebetteter Prozessoren umfassen, die als Audioverarbeitungs-Engine dienen können. In mindestens einem Ausführungsbeispiel kann die Audioverarbeitungs-Engine ein Audio-Subsystem sein, das eine vollständige Hardware-Unterstützung für Mehrkanal-Audio über mehrere Schnittstellen und eine Vielzahl flexibler Audio-E/A-Schnittstellen ermöglicht. In mindestens einem Ausführungsbeispiel ist die Audioverarbeitungs-Engine ein dedizierter Prozessorkern mit einem digitalen Signalprozessor mit dediziertem RAM.
In mindestens einem Ausführungsbeispiel kann/können der/die Prozessor(en) 1610 weiter eine „Always-on“-Prozessor-Engine umfassen, die die notwendigen Hardware-Funktionen zur Unterstützung von Sensormanagement mit geringem Stromverbrauch und Aufwecken von Anwendungsfällen bereitstellen kann. In mindestens einem Ausführungsbeispiel kann die „Always-on“-Prozessor-Engine ohne Einschränkung einen Prozessorkern, ein eng gekoppeltes RAM, unterstützende Peripheriegeräte (z.B. Timer und Interrupt-Controller), verschiedene I/O-Controller-Peripheriegeräte und eine Routing-Logik umfassen.
In mindestens einem Ausführungsbeispiel kann(n) der (die) Prozessor(en) 1610 weiter eine Sicherheits-Cluster-Engine umfassen, die ohne Einschränkung ein dediziertes Prozessor-Subsystem zur Handhabung des Sicherheitsmanagements für Automobilanwendungen umfasst. In mindestens einem Ausführungsbeispiel kann die Sicherheits-Cluster-Engine ohne Einschränkung zwei oder mehr Prozessorkerne, einen eng gekoppelten Arbeitsspeicher, unterstützende Peripheriegeräte (z. B. Zeitgeber, eine Interrupt-Steuerung usw.) und/oder eine Routing-Logik umfassen. In einem Sicherheitsmodus können in mindestens einem Ausführungsbeispiel zwei oder mehr Kerne in einem Lockstep-Modus arbeiten und als ein einziger Kern mit einer Vergleichslogik funktionieren, um etwaige Unterschiede zwischen ihren Operationen zu erkennen. In mindestens einem Ausführungsbeispiel kann/können der/die Prozessor(en) 1610 weiter eine Echtzeit-Kamera Engine umfassen, die ohne Einschränkung ein dediziertes Prozessor-Subsystem zur Handhabung des Echtzeit-Kameramanagements umfassen kann. In mindestens einem Ausführungsbeispiel kann (können) der (die) Prozessor(en) 1610 ferner einen Signalprozessor mit hohem Dynamikbereich umfassen, der ohne Einschränkung einen Bildsignalprozessor umfassen kann, der eine Hardware-Engine ist, die Teil der Kameraverarbeitungspipeline ist.
In mindestens einem Ausführungsbeispiel kann(n) der (die) Prozessor(en) 1610 einen Videobildkompositor umfassen, der ein Verarbeitungsblock sein kann (z. B. auf einem Mikroprozessor implementiert), der Videonachverarbeitungsfunktionen implementiert, die von einer Videowiedergabeanwendung benötigt werden, um das finale Bild für das Wiedergabefenster zu erzeugen. In mindestens einem Ausführungsbeispiel kann der Videobildkompositor eine Linsenverzerrungskorrektur an der/den Weitwinkelkamera(s) 1670, der/den Surround-Kamera(s) 1674 und/oder an den Sensoren der Überwachungskamera(s) in der Kabine vornehmen. In mindestens einem Ausführungsbeispiel wird/werden der/die Sensor(en) der Überwachungskamera(n) in der Kabine vorzugsweise von einem neuronalen Netzwerk überwacht, das auf einer anderen Instanz des SoC 1604 läuft und so konfiguriert ist, dass es Ereignisse in der Kabine erkennt und entsprechend reagiert. In mindestens einem Ausführungsbeispiel kann ein System in der Kabine ohne Einschränkung Lippenlesen durchführen, um den Mobilfunkdienst zu aktivieren und einen Anruf zu tätigen, E-Mails zu diktieren, das Fahrzeugziel zu ändern, das Infotainmentsystem und die Einstellungen des Fahrzeugs zu aktivieren oder zu ändern oder sprachgesteuertes Surfen im Internet bereitzustellen. In mindestens einem Ausführungsbeispiel stehen dem Fahrer bestimmte Funktionen zur Verfügung, wenn das Fahrzeug in einem autonomen Modus betrieben wird, und sind ansonsten deaktiviert.
In mindestens einem Ausführungsbeispiel kann der Videobildkompositor eine verbesserte zeitliche Rauschunterdrückung umfassen, die sowohl räumliches als auch zeitliches Rauschen reduziert. Zum Beispiel, in mindestens einem Ausführungsbeispiel, wo Bewegung in einem Video auftritt, gewichtet die Rauschunterdrückung die räumliche Information angemessen, indem sie die Gewichtung der Information, die von benachbarten Einzelbildern bereitgestellt wird, verringert. In mindestens einem Ausführungsbeispiel, in dem ein Bild oder ein Teil eines Bildes keine Bewegung umfasst, kann die vom Videobildkompositor durchgeführte zeitliche Rauschreduzierung Informationen aus dem vorherigen Bild verwenden, um das Rauschen im aktuellen Bild zu reduzieren.
In mindestens einem Ausführungsbeispiel kann der Videobildkompositor auch so konfiguriert sein, dass er eine Stereorektifizierung an eingegebenen Stereoobjektiv-Einzelbildern durchführt. In mindestens einem Ausführungsbeispiel kann der Videobildkompositor weiter für die Zusammenstellung der Benutzeroberfläche verwendet werden, wenn der Desktop des Betriebssystems in Gebrauch ist und die GPU(s) 1608 nicht zum kontinuierlichen Rendern neuer Oberflächen erforderlich sind. In mindestens einem Ausführungsbeispiel kann der Videobildkompositor, wenn die GPU(s) 1608 eingeschaltet und aktiv mit dem 3D-Rendern beschäftigt sind, dazu verwendet werden, die GPU(s) 1608 zu entlasten, um die Leistung und Reaktionsfähigkeit zu verbessern.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 ferner eine serielle MIPI-Kameraschnittstelle zum Empfangen von Videos und Eingaben von Kameras, eine Hochgeschwindigkeitsschnittstelle und/oder einen Videoeingabeblock umfassen, der für Kamera- und verwandte Pixeleingabefunktionen verwendet werden kann. In mindestens einem Ausführungsbeispiel kann(n) ein oder mehrere SoC(s) 1604 ferner eine oder mehrere Eingabe/Ausgabe-Steuerungen umfassen, die durch Software gesteuert werden können und für den Empfang von E/A-Signalen verwendet werden können, die nicht an eine bestimmte Rolle gebunden sind.
In mindestens einem Ausführungsbeispiel können ein oder mehrere SoC(s) 1604 ferner eine Vielzahl von Peripherieschnittstellen umfassen, um die Kommunikation mit Peripheriegeräten, Audio-Kodierern/Dekodierern („Codecs“), der Energieverwaltung und/oder anderen Geräten zu ermöglichen. SoC(s) 1604 kann/können verwendet werden, um Daten von Kameras (z.B. verbunden über Gigabit Multimedia Serial Link und Ethernet), Sensoren (z.B. LIDAR-Sensor(en) 1664, RADAR-Sensor(en) 1660, usw., die über Ethernet verbunden sein können), Daten von Bus 1602 (z.B. Geschwindigkeit des Fahrzeugs 1600, Lenkradposition, usw.), Daten von GNSS-Sensor(en) 1658 (z.B. verbunden über Ethernet oder CAN-Bus), usw. zu verarbeiten. In mindestens einem Ausführungsbeispiel kann(n) einer oder mehrere der SoC(s) 1604 weiter dedizierte Hochleistungs-Massenspeicher-Steuerungen umfassen, die ihre eigenen DMA-Engines enthalten können und die verwendet werden können, um die CPU(s) 1606 von routinemäßigen Datenverwaltungsaufgaben zu befreien.
In mindestens einem Ausführungsbeispiel kann (können) der (die) SoC(s) 1604 eine Endto-End-Plattform mit einer flexiblen Architektur sein, die sich über die Automatisierungsstufen 3-5 erstreckt und dadurch eine umfassende funktionale Sicherheitsarchitektur bereitstellt, die computergestützte Vision- und ADAS-Techniken für Diversität und Redundanz nutzt und eine Plattform für einen flexiblen, zuverlässigen Fahrsoftwarestapel zusammen mit Deep-Learning-Tools bereitstellt. In mindestens einem Ausführungsbeispiel können die SoC(s) 1604 schneller, zuverlässiger und sogar energie- und platzsparender sein als herkömmliche Systeme. Zum Beispiel können in mindestens einem Ausführungsbeispiel der/die Beschleuniger 1614 in Kombination mit der/den CPU(s) 1606, der/den GPU(s) 1608 und dem/den Datenspeicher(n) 1616 eine schnelle, effiziente Plattform für autonome Fahrzeuge der Stufe 3-5 bereitstellen.
In mindestens einem Ausführungsbeispiel können computergestützte Vision-Algorithmen auf CPUs ausgeführt werden, die unter Verwendung von High-Level-Programmiersprachen, wie z. B. C, konfiguriert sein können, um eine Vielzahl von Verarbeitungsalgorithmen für eine Vielzahl von visuellen Daten auszuführen. In mindestens einem Ausführungsbeispiel sind CPUs jedoch oft nicht in der Lage, die Leistungsanforderungen vieler computergestützter Vision-Anwendungen zu erfüllen, wie z. B. die Anforderungen an die Ausführungszeit und den Stromverbrauch. In mindestens einem Ausführungsbeispiel sind viele CPUs nicht in der Lage, komplexe Objekterkennungsalgorithmen in Echtzeit auszuführen, was in fahrzeuginternen ADAS-Anwendungen und in praktischen autonomen Fahrzeugen der Stufe 3-5 verwendet wird.
Die hier beschriebenen Ausführungsbeispiele ermöglichen die gleichzeitige und/oder sequentielle Ausführung mehrerer neuronaler Netzwerke und die Kombination der Ergebnisse, um die Funktionalität des autonomen Fahrens der Stufe 3-5 zu ermöglichen. Zum Beispiel kann in mindestens einem Ausführungsbeispiel ein CNN, das auf einem DLA oder einer diskreten GPU (z. B. GPU(s) 1620) ausgeführt wird, eine Text- und Worterkennung umfassen, die es dem Supercomputer ermöglicht, Verkehrszeichen zu lesen und zu verstehen, einschließlich Zeichen, für die das neuronale Netzwerk nicht speziell trainiert wurde. In mindestens einem Ausführungsbeispiel kann DLA weiter ein neuronales Netzwerk umfassen, das in der Lage ist, Verkehrszeichen zu identifizieren, zu interpretieren und ein semantisches Verständnis bereitzustellen und dieses semantische Verständnis an Wegplanungsmodule weiterzugeben, die auf einem CPU-Komplex laufen.
In mindestens einem Ausführungsbeispiel können mehrere neuronale Netzwerke simultan betrieben werden, wie z.B. beim Fahren auf Level 3, 4 oder 5. Zum Beispiel kann in mindestens einem Ausführungsbeispiel ein Warnschild mit der Aufschrift „Vorsicht: Blinkende Lichter zeigen Eisglätte an“ zusammen mit einem elektrischen Licht von mehreren neuronalen Netzwerken unabhängig oder gemeinsam interpretiert werden. In mindestens einem Ausführungsbeispiel kann das Schild selbst von einem ersten eingesetzten neuronalen Netzwerk (z. B. einem trainierten neuronalen Netzwerk) als Verkehrsschild erkannt werden, der Text „Blinkende Lichter deuten auf Eisglätte hin“ kann von einem zweiten eingesetzten neuronalen Netzwerk interpretiert werden, das die (vorzugsweise auf einem CPU-Komplex ausgeführte) Wegplanungssoftware des Fahrzeugs darüber informiert, dass, wenn blinkende Lichter angezeigt werden, Eisglätte vorliegt. In mindestens einem Ausführungsbeispiel kann das Blinklicht durch den Betrieb eines dritten neuronalen Netzwerks über mehrere Einzelbilder hinweg identifiziert werden, das die Wegplanungssoftware des Fahrzeugs über das Vorhandensein (oder Fehlen) von Blinklichtern informiert. In mindestens einem Ausführungsbeispiel können alle drei neuronalen Netzwerke simultan laufen, beispielsweise innerhalb von DLA und/oder auf GPU(s) 1608.
In mindestens einem Ausführungsbeispiel kann ein CNN zur Gesichtserkennung und Identifizierung des Fahrzeugbesitzers Daten von Kamerasensoren verwenden, um die Anwesenheit eines autorisierten Fahrers und/oder Besitzers des Fahrzeugs 1600 zu identifizieren. In mindestens einem Ausführungsbeispiel kann eine Verarbeitungs-Engine für immer eingeschaltete Sensoren verwendet werden, um das Fahrzeug zu entriegeln, wenn sich der Besitzer der Fahrertür nähert und die Lichter einschaltet, und, im Sicherheitsmodus, um das Fahrzeug zu deaktivieren, wenn der Besitzer das Fahrzeug verlässt. Auf diese Weise stellen die SoC(s) 1604 die Sicherheit gegen Diebstahl und/oder Autoraub bereit.
In mindestens einem Ausführungsbeispiel kann ein CNN zur Erkennung und Identifizierung von Notfallfahrzeugen Daten von Mikrofonen 1696 verwenden, um Sirenen von Notfallfahrzeugen zu detektieren und zu identifizieren. In mindestens einem Ausführungsbeispiel verwenden die SoC(s) 1604 CNN zur Klassifizierung von Umwelt- und Stadtgeräuschen sowie zur Klassifizierung visueller Daten. In mindestens einem Ausführungsbeispiel wird CNN, das auf DLA läuft, darauf trainiert, die relative Annäherungsgeschwindigkeit eines Notfallfahrzeugs zu erkennen (z. B. unter Verwendung des Dopplereffekts). In mindestens einem Ausführungsbeispiel kann CNN auch so trainiert werden, dass es Notfallfahrzeuge erkennt, die sich in dem Gebiet befinden, in dem das Fahrzeug operiert, und die von dem/den GNSS-Sensor(en) 1658 identifiziert werden. In mindestens einem Ausführungsbeispiel wird CNN bei einem Einsatz in Europa versuchen, europäische Sirenen zu detektieren, und bei einem Einsatz in den Vereinigten Staaten wird CNN versuchen, nur nordamerikanische Sirenen zu identifizieren. In mindestens einem Ausführungsbeispiel kann, sobald ein Notfallfahrzeug detektiert wird, ein Steuerprogramm verwendet werden, um eine Notfallfahrzeug-Sicherheitsroutine auszuführen, das Fahrzeug zu verlangsamen, an den Straßenrand zu fahren, das Fahrzeug zu parken und/oder das Fahrzeug im Leerlauf zu lassen, mit Hilfe von Ultraschallsensor(en) 1662, bis das/die Notfallfahrzeug(e) vorbeifahren.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 eine oder mehrere CPU(s) 1618 (z.B. diskrete CPU(s) oder dCPU(s)) umfassen, die mit dem/den SoC(s) 1604 über eine Hochgeschwindigkeitsverbindung (z.B. PCIe) gekoppelt sein können. In mindestens einem Ausführungsbeispiel kann die CPU(s) 1618 z. B. einen X86-Prozessor umfassen. CPU(s) 1618 kann/können verwendet werden, um eine Vielzahl von Funktionen auszuführen, einschließlich der Schlichtung potenziell inkonsistenter Ergebnisse zwischen ADAS-Sensoren und SoC(s) 1604 und/oder der Überwachung von Status und Zustand der Steuerung(en) 1636 und/oder eines Infotainment-Systems auf einem Chip („Infotainment-SoC“) 1630, zum Beispiel.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 GPU(s) 1620 (z.B. diskrete GPU(s) oder dGPU(s)) umfassen, die mit dem/den SoC(s) 1604 über eine Hochgeschwindigkeitsverbindung (z.B. NVIDIAs NVLINK) gekoppelt sein können. In mindestens einem Ausführungsbeispiel kann/können GPU(s) 1620 zusätzliche Funktionalität der künstlichen Intelligenz bereitstellen, wie z.B. durch Ausführen redundanter und/oder unterschiedlicher neuronaler Netzwerke, und kann/können verwendet werden, um neuronale Netzwerke zu trainieren und/oder zu aktualisieren, basierend zumindest teilweise auf Eingaben (z.B. Sensordaten) von Sensoren des Fahrzeugs 1600.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter eine Netzwerkschnittstelle 1624 umfassen, die ohne Einschränkung eine oder mehrere drahtlose Antennen 1626 umfassen kann (z.B. eine oder mehrere drahtlose Antennen 1626 für verschiedene Kommunikationsprotokolle, wie eine Mobilfunkantenne, eine Bluetooth-Antenne, usw.). In mindestens einem Ausführungsbeispiel kann die Netzwerkschnittstelle 1624 verwendet werden, um eine drahtlose Konnektivität über das Internet mit der Cloud (z. B. mit Servern und/oder anderen Netzwerkgeräten), mit anderen Fahrzeugen und/oder mit Rechengeräten (z. B. Client-Geräten von Fahrgästen) zu ermöglichen. In mindestens einem Ausführungsbeispiel kann zur Kommunikation mit anderen Fahrzeugen eine direkte Verbindung zwischen dem Fahrzeug 160 und einem anderen Fahrzeug und/oder eine indirekte Verbindung hergestellt werden (z. B. über Netzwerke und das Internet). In mindestens einem Ausführungsbeispiel können direkte Verbindungen unter Verwendung einer Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung bereitgestellt werden. Die Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung kann dem Fahrzeug 1600 Informationen über Fahrzeuge in der Nähe des Fahrzeugs 1600 bereitstellen (z.B. Fahrzeuge vor, auf der Seite und/oder hinter dem Fahrzeug 1600). In mindestens einem Ausführungsbeispiel kann die vorgenannte Funktionalität Teil einer kooperativen adaptiven Geschwindigkeitsregelungsfunktion des Fahrzeugs 1600 sein.
In mindestens einem Ausführungsbeispiel kann die Netzwerkschnittstelle 1624 einen SoC umfassen, der eine Modulations- und Demodulationsfunktionalität bereitstellt und die Steuerung(en) 1636 in die Lage versetzt, über drahtlose Netzwerke zu kommunizieren. In mindestens einem Ausführungsbeispiel kann die Netzwerkschnittstelle 1624 ein Hochfrequenz-Frontend für die Aufwärtskonvertierung von Basisband auf Hochfrequenz und die Abwärtskonvertierung von Hochfrequenz auf Basisband umfassen. In mindestens einem Ausführungsbeispiel können die Frequenzumwandlungen in jeder technisch geeigneten Weise durchgeführt werden. Beispielsweise können Frequenzumwandlungen durch bekannte Verfahren und/oder unter Verwendung von Superheterodyn-Verfahren durchgeführt werden. In mindestens einem Ausführungsbeispiel kann die Funktionalität des Hochfrequenz-Frontends durch einen separaten Chip bereitgestellt werden. In mindestens einem Ausführungsbeispiel kann die Netzwerkschnittstelle eine drahtlose Funktionalität zur Kommunikation über LTE, WCDMA, UMTS, GSM, CDMA2000, Bluetooth, Bluetooth LE, Wi-Fi, Z-Wave, ZigBee, LoRaWAN und/oder andere drahtlose Protokolle umfassen.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter einen oder mehrere Datenspeicher 1628 umfassen, die ohne Einschränkung einen Speicher außerhalb des Chips (z.B. außerhalb des/der SoC(s) 1604) umfassen können. In mindestens einem Ausführungsbeispiel kann (können) der (die) Datenspeicher 1628 ohne Einschränkung ein oder mehrere Speicherelemente umfassen, einschließlich RAM, SRAM, Dynamic Random Access Memory („DRAM“), Video Random Access Memory („VRAM“), Flash, Festplatten und/oder andere Komponenten und/oder Geräte, die mindestens ein Datenbit speichern können.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter den/die GNSS-Sensor(en) 1658 (z.B. GPS und/oder unterstützte GPS-Sensoren) umfassen, um bei der Kartierung, Erfassung, Generierung von Belegungsrastern und/oder Pfadplanungsfunktionen zu helfen. In mindestens einem Ausführungsbeispiel kann eine beliebige Anzahl von GNSS-Sensor(en) 1658 verwendet werden, einschließlich, zum Beispiel und ohne Einschränkung, ein GPS unter Verwendung eines USB-Steckers mit einer Ethernet-zu-Seriell-Brücke (z.B. RS-232).
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter den/die RADAR-Sensor(en) 1660 umfassen. Der/die RADAR-Sensor(en) 1660 kann/können von Fahrzeug 1600 für die Detektierung von Fahrzeugen mit großer Reichweite verwendet werden, selbst bei Dunkelheit und/oder schlechten Wetterbedingungen. In mindestens einem Ausführungsbeispiel können die funktionalen RADAR-Sicherheitsstufen ASIL B sein. Der/die RADAR-Sensor(en) 1660 kann/können CAN und/oder Bus 1602 (z. B. zur Übertragung von Daten, die von dem/den RADAR-Sensor(en) 1660 generiert wurden) zur Steuerung und zum Zugriff auf Objektverfolgungsdaten verwenden, wobei in einigen Beispielen der Zugriff auf unbearbeitete Daten über Ethernet erfolgt. In mindestens einem Ausführungsbeispiel kann eine breite Palette von RADAR-Sensortypen verwendet werden. Zum Beispiel und ohne Einschränkung können RADAR-Sensor(en) 1660 für die Verwendung von Front-, Heck- und Seiten-RADAR geeignet sein. In mindestens einem Ausführungsbeispiel sind ein oder mehrere RADAR-Sensor(en) 1660 Puls-Doppler-RADAR-Sensoren.
In mindestens einem Ausführungsbeispiel kann (können) der (die) RADAR-Sensor(en) 1660 verschiedene Konfigurationen umfassen, wie z.B. Fernbereich mit engem Sichtfeld, Nahbereich mit breitem Sichtfeld, seitliche Nahbereichsabdeckung, usw. In mindestens einem Ausführungsbeispiel kann RADAR mit großer Reichweite für die Funktionalität eines adaptiven Geschwindigkeitsreglers verwendet werden. In mindestens einem Ausführungsbeispiel können RADAR-Systeme mit großer Reichweite ein breites Sichtfeld bereitstellen, das durch zwei oder mehr unabhängige Scans, z. B. innerhalb einer Reichweite von 250 m, realisiert wird. In mindestens einem Ausführungsbeispiel kann(n) der/die RADAR-Sensor(en) 1660 dabei helfen, zwischen statischen und sich bewegenden Objekten zu unterscheiden, und kann(en) vom ADAS-System 1638 zur Notbremsunterstützung und zur Vorwärtskollisionswarnung verwendet werden. Die Sensoren 1660, die in einem RADAR-System mit großer Reichweite umfasst sind, können ohne Einschränkung ein monostatisches multimodales RADAR mit mehreren (z. B. sechs oder mehr) festen RADAR-Antennen und einer Hochgeschwindigkeits-CAN- und FlexRay-Schnittstelle umfassen. In mindestens einem Ausführungsbeispiel mit sechs Antennen können die mittleren vier Antennen ein fokussiertes Strahlenmuster erzeugen, das darauf ausgelegt ist, die Umgebung des Fahrzeugs bei höheren Geschwindigkeiten mit minimalen Störungen durch den Verkehr auf den angrenzenden Fahrspuren zu erfassen. In mindestens einem Ausführungsbeispiel können zwei weitere Antennen das Sichtfeld erweitern, so dass es möglich ist, Fahrzeuge, die in die 1600er-Spur einfahren oder diese verlassen, schnell zu detektieren.
In mindestens einem Ausführungsbeispiel können RADAR-Systeme mittlerer Reichweite beispielsweise eine Reichweite von bis zu 160 m (vorne) oder 80 m (hinten) und ein Sichtfeld von bis zu 42 Grad (vorne) oder 150 Grad (hinten) umfassen. In mindestens einem Ausführungsbeispiel können Kurzstrecken-RADAR-Systeme ohne Einschränkung eine beliebige Anzahl von RADAR-Sensoren 1660 umfassen, die für den Einbau an beiden Enden des hinteren Stoßfängers ausgelegt sind. In mindestens einem Ausführungsbeispiel kann ein RADAR-Sensorsystem, wenn es an beiden Enden des hinteren Stoßfängers installiert ist, zwei Strahlen erzeugen, die ständig den toten Winkel im hinteren Bereich und neben dem Fahrzeug überwachen. In mindestens einem Ausführungsbeispiel können RADAR-Systeme mit kurzer Reichweite im ADAS-System 1638 zur Erkennung des toten Winkels und/oder zur Unterstützung beim Spurwechsel verwendet werden.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 ferner Ultraschallsensor(en) 1662 umfassen. Der/die Ultraschallsensor(en) 1662, der/die an der Vorderseite, der Rückseite und/oder den Seiten des Fahrzeugs 1600 angeordnet sein kann/können, kann/können zur Einparkhilfe und/oder zur Erstellung und Aktualisierung eines Belegungsgitters verwendet werden. In mindestens einem Ausführungsbeispiel kann eine Vielzahl von Ultraschallsensor(en) 1662 verwendet werden, und verschiedene Ultraschallsensor(en) 1662 können für verschiedene Erfassungsbereiche (z.B. 2,5 m, 4 m) verwendet werden. In mindestens einem Ausführungsbeispiel kann/können der/die Ultraschallsensor(en) 1662 in funktionalen Sicherheitsstufen von ASIL B arbeiten.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 den/die LIDAR-Sensor(en) 1664 umfassen. Der/die LIDAR-Sensor(en) 1664 kann/können zur Objekt- und Fußgängererkennung, Notbremsung, Kollisionsvermeidung und/oder anderen Funktionalitäten verwendet werden. In mindestens einem Ausführungsbeispiel kann (können) der (die) LIDAR-Sensor(en) 1664 der funktionalen Sicherheitsstufe ASIL B angehören. In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 mehrere LIDAR-Sensoren 1664 (z.B. zwei, vier, sechs usw.) umfassen, die Ethernet verwenden können (z.B. um Daten an einen Gigabit Ethernet Switch bereitzustellen).
In mindestens einem Ausführungsbeispiel kann der/die LIDAR-Sensor(en) 1664 in der Lage sein, eine Liste von Objekten und deren Entfernungen für ein 360-Grad-Sichtfeld bereitzustellen. In mindestens einem Ausführungsbeispiel kann/können der/die handelsübliche(n) LIDAR-Sensor(en) 1664 eine beworbene Reichweite von etwa 100 m haben, mit einer Genauigkeit von 2 cm bis 3 cm und mit Unterstützung für eine 100-Mbps-Ethemet-Verbindung, zum Beispiel. In mindestens einem Ausführungsbeispiel können ein oder mehrere nicht vorspringende LIDAR-Sensoren 1664 verwendet werden. In einem solchen Ausführungsbeispiel kann/können der/die LIDAR-Sensor(en) 1664 als ein kleines Gerät implementiert werden, das in die Front, das Heck, die Seiten und/oder die Ecken des Fahrzeugs 1600 eingebettet werden kann. In mindestens einem Ausführungsbeispiel kann/können der/die LIDAR-Sensor(en) 1664 in einem solchen Ausführungsbeispiel ein horizontales Sichtfeld von bis zu 120 Grad und ein vertikales Sichtfeld von bis zu 35 Grad bereitstellen, mit einer Reichweite von 200 m, selbst bei Objekten mit geringem Reflektionsvermögen. In mindestens einem Ausführungsbeispiel kann/können der/die frontmontierte(n) LIDAR-Sensor(en) 1664 für ein horizontales Sichtfeld zwischen 45 Grad und 135 Grad konfiguriert sein.
In mindestens einem Ausführungsbeispiel können auch LIDAR-Technologien, wie z. B. 3D-Blitz-LIDAR, verwendet werden. 3D-Blitz-LIDAR verwendet einen Laserblitz als Sendequelle, um die Umgebung des Fahrzeugs 1600 bis zu einer Entfernung von etwa 200 m zu beleuchten. In mindestens einem Ausführungsbeispiel umfasst eine Flash-LIDAR-Einheit ohne Einschränkung einen Rezeptor, der die Laufzeit des Laserpulses und das reflektierte Licht auf jedem Pixel aufzeichnet, was wiederum der Entfernung von Fahrzeug 1600 zu Objekten entspricht. In mindestens einem Ausführungsbeispiel kann Flash-LIDAR es ermöglichen, mit jedem Laserblitz hochgenaue und verzerrungsfreie Bilder der Umgebung zu generieren. In mindestens einem Ausführungsbeispiel können vier Flash-LIDAR-Sensoren eingesetzt werden, einer auf jeder Seite des Fahrzeugs 1600. In mindestens einem Ausführungsbeispiel umfassen 3D-Blitz-LIDAR-Systeme ohne Einschränkung eine Festkörper-LIDAR-Kamera mit 3D-Star-Array, die außer einem Gebläse keine beweglichen Teile aufweist (z. B. ein nicht scannendes LIDAR-Gerät). In mindestens einem Ausführungsbeispiel kann das Blitz-LIDAR-Gerät einen 5-Nanosekunden-Laserimpuls der Klasse I (augensicher) pro Einzelbild verwenden und das reflektierte Laserlicht in Form von 3D-Entfernungspunktwolken und co-registrierten Intensitätsdaten erfassen.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug ferner einen oder mehrere IMU-Sensoren 1666 umfassen. In mindestens einem Ausführungsbeispiel kann/können der/die IMU-Sensor(en) 1666 in mindestens einem Ausführungsbeispiel in der Mitte der Hinterachse des Fahrzeugs 1600 angeordnet sein. In mindestens einem Ausführungsbeispiel kann/können der/die IMU-Sensor(en) 1666 zum Beispiel und ohne Einschränkung einen oder mehrere Beschleunigungsmesser, Magnetometer, Gyroskop(e), Magnetkompass(e) und/oder andere Sensortypen umfassen. In mindestens einem Ausführungsbeispiel, z. B. bei sechsachsigen Anwendungen, kann/können der/die IMU-Sensor(en) 1666 ohne Einschränkung Beschleunigungsmesser und Gyroskope umfassen. In mindestens einem Ausführungsbeispiel, wie z.B. in neunachsigen Anwendungen, kann/können der/die IMU-Sensor(en) 1666 ohne Einschränkung Beschleunigungsmesser, Gyroskope und Magnetometer umfassen.
In mindestens einem Ausführungsbeispiel kann/können der/die IMU-Sensor(en) 1666 als ein miniaturisiertes, hochleistungsfähiges GPS-gestütztes Trägheitsnavigationssystem („GPS/INS“) implementiert werden, das mikroelektromechanische Systeme („MEMS“) Trägheitssensoren, einen hochempfindlichen GPS-Empfänger und fortschrittliche Kalman-Filteralgorithmen kombiniert, um Abschätzungen von Position, Geschwindigkeit und Lage bereitzustellen. In mindestens einem Ausführungsbeispiel kann/können der/die IMU-Sensor(en) 1666 das Fahrzeug 1600 in die Lage versetzen, den Kurs abzuschätzen, ohne dass eine Eingabe von einem Magnetsensor erforderlich ist, indem Änderungen der Geschwindigkeit vom GPS direkt mit dem/den IMU-Sensor(en) 1666 beobachtet und korreliert werden. In mindestens einem Ausführungsbeispiel können IMU-Sensor(en) 1666 und GNSS-Sensor(en) 1658 in einer einzigen integrierten Einheit kombiniert werden.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 das/die Mikrofon(e) 1696 umfassen, das/die im und/oder am Fahrzeug 1600 angebracht ist/sind. In mindestens einem Ausführungsbeispiel kann (können) das (die) Mikrofon(e) 1696 unter anderem zur Detektion und Identifizierung von Notfallfahrzeugen verwendet werden.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter eine beliebige Anzahl von Kameratypen umfassen, einschließlich Stereokamera(s) 1668, Weitwinkelkamera(s) 1670, Infrarotkamera(s) 1672, Umgebungskamera(s) 1674, Femdistanzkamera(s) 1698, Mitteldistanzkamera(s) 1676 und/oder andere Kameratypen. In mindestens einem Ausführungsbeispiel können Kameras verwendet werden, um Bilddaten rund um einen gesamten Umfang des Fahrzeugs 1600 zu erfassen. In mindestens einem Ausführungsbeispiel hängen die Typen der verwendeten Kameras vom Fahrzeug 1600 ab. In mindestens einem Ausführungsbeispiel kann eine beliebige Kombination von Kameratypen verwendet werden, um die erforderliche Abdeckung um das Fahrzeug 1600 bereitzustellen. In mindestens einem Ausführungsbeispiel kann die Anzahl der Kameras je nach Ausführungsbeispiel unterschiedlich sein. In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 beispielsweise sechs Kameras, sieben Kameras, zehn Kameras, zwölf Kameras oder eine andere Anzahl von Kameras umfassen. Die Kameras können in mindestens einem Ausführungsbeispiel und ohne Einschränkung Gigabit Multimedia Serial Link („GMSL“) und/oder Gigabit Ethernet unterstützen. In mindestens einem Ausführungsbeispiel wird jede der Kameras zuvor in Bezug auf 16A und 16B mit mehr Details beschrieben.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter den/die Vibrationssensor(en) 1642 umfassen. Der/die Vibrationssensor(en) 1642 kann/können Vibrationen von Komponenten des Fahrzeugs 1600, wie z.B. der Achse(n), messen. Zum Beispiel können in mindestens einem Ausführungsbeispiel Änderungen der Vibrationen eine Änderung der Straßenoberfläche anzeigen. In mindestens einem Ausführungsbeispiel, wenn zwei oder mehr Vibrationssensoren 1642 verwendet werden, können Unterschiede zwischen Vibrationen verwendet werden, um die Reibung oder den Schlupf der Straßenoberfläche zu bestimmen (z.B. wenn der Unterschied in der Vibration zwischen einer angetriebenen Achse und einer frei rotierenden Achse besteht).
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 das ADAS-System 1638 umfassen. Das ADAS-System 1638 kann in einigen Beispielen, ohne Einschränkung, einen SoC umfassen. In mindestens einem Ausführungsbeispiel kann das ADAS-System 1638 ohne Einschränkung eine beliebige Anzahl und Kombination eines autonomen/adaptiven/automatischen Geschwindigkeitsregelungssystems („ACC“), eines kooperativen adaptiven Geschwindigkeitsregelungssystems („CACC“), eines Vorwärts-Crash-Warnsystems („FCW“), eines automatischen Notbremssystems („AEB“) umfassen, ein System zur Warnung vor dem Verlassen der Fahrspur („LDW“), ein Spurhalteassistent („LKA“), ein System zur Warnung vor dem toten Winkel („BSW“), ein System zur Warnung vor rückwärtigem Querverkehr („RCTW“), ein System zur Kollisionswarnung („CW“), ein System zur Zentrierung der Fahrspur („LC“) und/oder andere Systeme, Merkmale und/oder Funktionalitäten.
In mindestens einem Ausführungsbeispiel kann das ACC-System den/die RADAR-Sensor(en) 1660, den/die LIDAR-Sensor(en) 1664 und/oder eine beliebige Anzahl von Kamera(s) verwenden. In mindestens einem Ausführungsbeispiel kann das ACC-System ein longitudinales ACC-System und/oder ein laterales ACC-System umfassen. In mindestens einem Ausführungsbeispiel überwacht und steuert das ACC-System in Längsrichtung den Abstand zu dem unmittelbar vor dem Fahrzeug 1600 befindlichen Fahrzeug und passt die Geschwindigkeit des Fahrzeugs 1600 automatisch an, um einen sicheren Abstand zu vorausfahrenden Fahrzeugen einzuhalten. In mindestens einem Ausführungsbeispiel hält das seitliche ACC-System den Abstand ein und rät dem Fahrzeug 1600, wenn nötig die Spur zu wechseln. In mindestens einem Ausführungsbeispiel ist das seitliche ACC-System mit anderen ADAS-Anwendungen wie LC und CW verbunden.
In mindestens einem Ausführungsbeispiel verwendet das CACC-System Informationen von anderen Fahrzeugen, die über die Netzwerkschnittstelle 1624 und/oder drahtlose Antenne(n) 1626 von anderen Fahrzeugen über eine drahtlose Verbindung oder indirekt über eine Netzwerkverbindung (z.B. über das Internet) empfangen werden können. In mindestens einem Ausführungsbeispiel können direkte Verbindungen durch eine Fahrzeug-zu-Fahrzeug-Kommunikationsverbindung („V2V“) bereitgestellt werden, während indirekte Verbindungen durch eine Infrastruktur-zu-Fahrzeug-Kommunikationsverbindung („I2V“) bereitgestellt werden können. Im Allgemeinen stellt das V2V-Kommunikationskonzept Informationen über unmittelbar vorhergehende Fahrzeuge bereit (z. B. Fahrzeuge, die sich unmittelbar vor und auf derselben Spur wie Fahrzeug 1600 befinden), während das I2V-Kommunikationskonzept Informationen über den weiter vorausfahrenden Verkehr bereitstellt. In mindestens einem Ausführungsbeispiel kann das CACC-System entweder eine oder beide 12V- und V2V-Informationsquellen umfassen. In mindestens einem Ausführungsbeispiel kann das CACC-System angesichts der Informationen über Fahrzeuge vor dem Fahrzeug 1600 zuverlässiger sein und es hat das Potenzial, den Verkehrsfluss zu verbessern und Staus auf der Straße zu reduzieren.
In mindestens einem Ausführungsbeispiel ist das FCW-System so gestaltet, dass es den Fahrer vor einer Gefahr warnt, so dass er korrigierend eingreifen kann. In mindestens einem Ausführungsbeispiel verwendet das FCW-System eine nach vorne gerichtete Kamera und/oder RADAR-Sensor(en) 1660, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt ist/sind, der/die elektrisch mit der Rückmeldung an den Fahrer gekoppelt ist/sind, wie z. B. eine Anzeige, ein Lautsprecher und/oder eine vibrierende Komponente. In mindestens einem Ausführungsbeispiel kann das FCW-System eine Warnung bereitstellen, z. B. in Form eines Tons, einer optischen Warnung, einer Vibration und/oder eines schnellen Bremsimpulses.
In mindestens einem Ausführungsbeispiel detektiert das AEB-System einen drohenden Zusammenstoß mit einem anderen Fahrzeug oder einem anderen Objekt und kann automatisch die Bremsen betätigen, wenn der Fahrer nicht innerhalb eines bestimmten Zeit- oder Entfernungsparameters korrigierend eingreift. In mindestens einem Ausführungsbeispiel kann das AEB-System nach vorne gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1660 verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind. In mindestens einem Ausführungsbeispiel kann das AEB-System, wenn es eine Gefahr detektiert, typischerweise zunächst den Fahrer warnen, damit er korrigierend eingreift, um eine Kollision zu vermeiden, und wenn der Fahrer nicht korrigierend eingreift, kann das AEB-System automatisch die Bremsen betätigen, um die Auswirkungen der vorhergesagten Kollision zu verhindern oder zumindest abzuschwächen. In mindestens einem Ausführungsbeispiel kann das AEB-System Techniken wie eine dynamische Bremsunterstützung und/oder eine Crash-Imminent Braking umfassen.
In mindestens einem Ausführungsbeispiel stellt das LDW-System visuelle, akustische und/oder taktile Warnungen bereit, wie z.B. Vibrationen des Lenkrads oder des Sitzes, um den Fahrer zu warnen, wenn das Fahrzeug 1600 die Fahrbahnmarkierungen überschreitet. In mindestens einem Ausführungsbeispiel wird das LDW-System nicht aktiviert, wenn der Fahrer ein absichtliches Verlassen der Fahrspur anzeigt, indem er einen Blinker betätigt. In mindestens einem Ausführungsbeispiel kann das LDW-System nach vorne gerichtete Kameras verwenden, die mit einem speziellen Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit der Rückmeldung des Fahrers gekoppelt ist, z. B. mit einer Anzeige, einem Lautsprecher und/oder einer vibrierenden Komponente. In mindestens einem Ausführungsbeispiel ist das LKA-System eine Variante des LDW-Systems. Das LKA-System stellt eine Eingabe in die Lenkung oder eine Bremsung bereit, um das Fahrzeug 1600 zu korrigieren, wenn das Fahrzeug 1600 beginnt, die Fahrspur zu verlassen.
In mindestens einem Ausführungsbeispiel detektiert und warnt das BSW-System den Fahrer vor Fahrzeugen, die sich im toten Winkel des Fahrzeugs befinden. In mindestens einem Ausführungsbeispiel kann das BSW-System ein optisches, akustisches und/oder taktiles Warnsignal bereitstellen, um anzuzeigen, dass das Einfahren oder Wechseln der Fahrspur unsicher ist. In mindestens einem Ausführungsbeispiel kann das BSW-System eine zusätzliche Warnung bereitstellen, wenn der Fahrer einen Blinker verwendet. In mindestens einem Ausführungsbeispiel kann das BSW-System eine oder mehrere nach hinten gerichtete Kamera(s) und/oder RADAR-Sensor(en) 1660 verwenden, die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt sind, der elektrisch mit einer Rückmeldung an den Fahrer gekoppelt ist, wie z.B. eine Anzeige, ein Lautsprecher und/oder eine vibrierende Komponente.
In mindestens einem Ausführungsbeispiel kann das RCTW-System eine visuelle, akustische und/oder taktile Benachrichtigung bereitstellen, wenn ein Objekt außerhalb der Reichweite der Rückfahrkamera detektiert wird, wenn das Fahrzeug 1600 rückwärts fährt. In mindestens einem Ausführungsbeispiel umfasst das RCTW-System ein AEB-System, um sicherzustellen, dass die Fahrzeugbremsen betätigt werden, um einen Unfall zu vermeiden. In mindestens einem Ausführungsbeispiel kann das RCTW-System einen oder mehrere nach hinten gerichtete(n) RADAR-Sensor(en) 1660 verwenden, der/die mit einem dedizierten Prozessor, DSP, FPGA und/oder ASIC gekoppelt ist/sind, der/die elektrisch mit einer Rückmeldung an den Fahrer gekoppelt ist/sind, wie z.B. eine Anzeige, ein Lautsprecher und/oder eine vibrierende Komponente.
In mindestens einem Ausführungsbeispiel können herkömmliche ADAS-Systeme zu falsch-positiven Ergebnissen neigen, die für einen Fahrer ärgerlich und ablenkend sein können, aber typischerweise nicht katastrophal sind, weil herkömmliche ADAS-Systeme den Fahrer warnen und ihm die Möglichkeit geben, zu entscheiden, ob ein Sicherheitszustand wirklich vorliegt und entsprechend zu handeln. In mindestens einem Ausführungsbeispiel entscheidet das Fahrzeug 1600 bei widersprüchlichen Ergebnissen selbst, ob das Ergebnis eines Primärrechners oder eines Sekundärrechners (z. B. der ersten Steuerung 1636 oder der zweiten Steuerung 1636) beachtet werden soll. Zum Beispiel kann in mindestens einem Ausführungsbeispiel das ADAS-System 1638 ein Backup- und/oder Sekundärcomputer sein, der einem Rationalitätsmodul des Backup-Computers Erfassungsinformationen bereitstellt. In mindestens einem Ausführungsbeispiel kann der Rationalitätsmonitor des Backup-Computers eine redundante, diverse Software auf Hardwarekomponenten ausführen, um Fehler bei der Erfassung und bei dynamischen Fahraufgaben zu erkennen. In mindestens einem Ausführungsbeispiel können die Ausgaben des ADAS-Systems 1638 an eine übergeordnete MCU bereitgestellt werden. In mindestens einem Ausführungsbeispiel bestimmt die überwachende MCU bei Konflikten zwischen den Ausgaben des Primärrechners und des Sekundärrechners, wie der Konflikt beigelegt werden kann, um einen sicheren Betrieb zu gewährleisten.
In mindestens einem Ausführungsbeispiel kann der Primärcomputer so konfiguriert sein, dass er der übergeordneten MCU einen Konfidenzwert bereitstellt, der die Konfidenz des Primärcomputers in das gewählte Ergebnis anzeigt. In mindestens einem Ausführungsbeispiel kann die überwachende MCU, wenn die Konfidenz einen Schwellenwert überschreitet, der Anweisung des Primärcomputers folgen, unabhängig davon, ob der Sekundärcomputer ein widersprüchliches oder inkonsistentes Ergebnis bereitstellt. In mindestens einem Ausführungsbeispiel, in dem die Konfidenz nicht den Schwellenwert erreicht und in dem der primäre und der sekundäre Computer unterschiedliche Ergebnisse anzeigen (z. B. einen Konflikt), kann die überwachende MCU zwischen den Computern vermitteln, um ein geeignetes Ergebnis zu bestimmen.
In mindestens einem Ausführungsbeispiel kann die überwachende MCU so konfiguriert sein, dass sie ein neuronales Netzwerk bzw. neuronale Netzwerke ausführt, das bzw. die trainiert und konfiguriert ist bzw. sind, um zumindest teilweise basierend auf den Ausgaben des primären Computers und des sekundären Computers die Bedingungen zu bestimmen, unter denen der sekundäre Computer einen Fehlalarm bereitstellt. In mindestens einem Ausführungsbeispiel kann (können) das (die) neuronale(n) Netzwerk(e) in der Überwachungs-MCU lernen, wann der Ausgabe des Sekundärcomputers vertraut werden kann und wann nicht. Zum Beispiel kann in mindestens einem Ausführungsbeispiel, wenn der sekundäre Computer ein RADAR-basiertes FCW-System ist, ein neuronales Netzwerk in der überwachenden MCU lernen, wenn das FCW-System metallische Objekte identifiziert, die in Wirklichkeit keine Gefahren sind, wie z. B. ein Abflussgitter oder ein Schachtdeckel, der einen Alarm auslöst. In mindestens einem Ausführungsbeispiel kann ein neuronales Netzwerk in der überwachenden MCU, wenn der sekundäre Computer ein kamerabasiertes LDW-System ist, lernen, das LDW-System außer Kraft zu setzen, wenn Radfahrer oder Fußgänger anwesend sind und ein Verlassen der Fahrspur in der Tat das sicherste Manöver ist. In mindestens einem Ausführungsbeispiel kann die überwachende MCU mindestens einen DLA oder eine GPU umfassen, der/die für die Ausführung neuronaler Netzwerke mit assoziiertem Speicher geeignet ist. In mindestens einem Ausführungsbeispiel kann die Überwachungs-MCU eine Komponente des/der SoC(s) 1604 umfassen und/oder darin enthalten sein.
In mindestens einem Ausführungsbeispiel kann das ADAS-System 1638 einen sekundären Computer umfassen, der die ADAS-Funktionalität unter Verwendung von herkömmlichen Regeln der computergestützten Vision ausführt. In mindestens einem Ausführungsbeispiel kann der sekundäre Computer klassische Regeln der computergestützten Vision (wenn-dann) verwenden, und das Vorhandensein eines neuronalen Netzwerks (von neuronalen Netzwerken) in der übergeordneten MCU kann die Zuverlässigkeit, Sicherheit und Leistung verbessern. In mindestens einem Ausführungsbeispiel wird das Gesamtsystem durch die unterschiedliche Implementierung und absichtliche Nichtidentität fehlertoleranter, insbesondere gegenüber Fehlern, die durch die Funktionalität der Software (oder der Software-Hardware-Schnittstelle) bewirkt werden. Wenn beispielsweise in mindestens einem Ausführungsbeispiel ein Softwarefehler in der auf dem Primärcomputer laufenden Software auftritt und ein nicht identischer Softwarecode, der auf dem Sekundärcomputer läuft, dasselbe Gesamtergebnis bereitstellt, dann kann die überwachende MCU eine größere Konfidenz haben, dass das Gesamtergebnis korrekt ist und der Fehler in der Software oder Hardware auf dem Primärcomputer keinen wesentlichen Fehler bewirkt.
In mindestens einem Ausführungsbeispiel kann die Ausgabe des ADAS-Systems 1638 in den Wahrnehmungsblock des Primärrechners und/oder in den Block für dynamische Fahraufgaben des Primärrechners eingespeist werden. Wenn beispielsweise in mindestens einem Ausführungsbeispiel das ADAS-System 1638 eine Vorwärtscrash-Warnung aufgrund eines unmittelbar vorausfahrenden Objekts anzeigt, kann der Erfassungsblock diese Information bei der Identifizierung von Objekten verwenden. In mindestens einem Ausführungsbeispiel kann der Sekundärcomputer ein eigenes neuronales Netzwerk enthalten, das trainiert wird und so das Risiko von Fehlalarmen reduziert, wie hier beschrieben.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter einen Infotainment-SoC 1630 umfassen (z. B. ein bordeigenes Infotainment-System (IVI)). Obwohl beispielhaft als ein SoC gezeigt und beschrieben, kann das Infotainment-System 1630 in mindestens einem Ausführungsbeispiel kein SoC sein und kann ohne Einschränkung zwei oder mehr diskrete Komponenten umfassen. In mindestens einem Ausführungsbeispiel kann das Infotainment-SoC 1630 ohne Einschränkung eine Kombination aus Hardware und Software umfassen, die verwendet werden kann, um Audio (z. B. Musik, einen persönlichen digitalen Assistenten, Navigationsanweisungen, Nachrichten, Radio usw.), Video (z. B. Fernsehen, Filme, Streaming usw.), Telefon (z. B, Freisprecheinrichtung), Netzkonnektivität (z. B. LTE, WiFi usw.) und/oder Informationsdienste (z. B. Navigationssysteme, Einparkhilfe hinten, ein Radiodatensystem, fahrzeugbezogene Informationen wie Kraftstoffstand, zurückgelegte Gesamtstrecke, Bremskraftstoffstand, Ölstand, Tür öffnen/schließen, Luftfilterinformationen usw.) an Fahrzeug 1600. Der Infotainment-SoC 1630 könnte beispielsweise Radios, Plattenspieler, Navigationssysteme, Videoplayer, USB- und Bluetooth-Konnektivität, Carputer, In-Car-Entertainment, WiFi, Audiobedienelemente am Lenkrad, Freisprecheinrichtung, ein Heads-Up-Display („HUD“), eine HMI-Anzeige 1634, ein Telematikgerät, ein Steuerungspaneel (z. B. zur Steuerung und/oder Interaktion mit verschiedenen Komponenten, Funktionen und/oder Systemen) und/oder andere Komponenten umfassen. In mindestens einem Ausführungsbeispiel kann der Infotainment-SoC 1630 weiter verwendet werden, um Informationen (z.B. visuell und/oder akustisch) für den/die Benutzer des Fahrzeugs bereitzustellen, wie z.B. Informationen vom ADAS-System 1638, Informationen zum autonomen Fahren, wie z.B. geplante Fahrzeugmanöver, Trajektorien, Umgebungsinformationen (z.B. Kreuzungsinformationen, Fahrzeuginformationen, Straßeninformationen, usw.), und/oder andere Informationen.
In mindestens einem Ausführungsbeispiel kann der Infotainment-SoC 1630 eine beliebige Menge und Art von GPU-Funktionalität umfassen. In mindestens einem Ausführungsbeispiel kann der Infotainment-SoC 1630 über den Bus 1602 (z.B. CAN-Bus, Ethernet, etc.) mit anderen Geräten, Systemen und/oder Komponenten des Fahrzeugs 1600 kommunizieren. In mindestens einem Ausführungsbeispiel kann der Infotainment-SoC 1630 mit einer Überwachungs-MCU gekoppelt sein, so dass die GPU des Infotainment-Systems einige selbstfahrende Funktionen ausführen kann, falls die primäre(n) Steuerung(en) 1636 (z.B. primäre und/oder Backup-Computer des Fahrzeugs 1600) ausfallen. In mindestens einem Ausführungsbeispiel kann das Infotainment-SoC 1630 das Fahrzeug 1600 in einen Chauffeur-zu-sicherem-Halt-Modus versetzen, wie hierin beschrieben.
In mindestens einem Ausführungsbeispiel kann das Fahrzeug 1600 weiter ein Instrumentencluster 1632 umfassen (z.B. ein digitales Armaturenbrett, ein elektronisches Instrumentencluster, eine digitale Instrumententafel usw.). Das Instrumentencluster 1632 kann ohne Einschränkung eine Steuerung und/oder einen Supercomputer umfassen (z.B. eine diskrete Steuerung oder einen Supercomputer). In mindestens einem Ausführungsbeispiel kann das Instrumentencluster 1632 ohne Einschränkung eine beliebige Anzahl und Kombination von Instrumenten umfassen, wie z. B. Tachometer, Kraftstoffstand, Öldruck, Drehzahlmesser, Kilometerzähler, Blinker, Schaltstellungsanzeige, Sicherheitsgurt-Warnleuchte(n), Handbrems-Warnleuchte(n), Motor-Fehlfunktionsleuchte(n), Informationen über zusätzliche Rückhaltesysteme (z. B. Airbag), Beleuchtungssteuerungen, Sicherheitssystemsteuerungen, Navigationsinformationen usw. In einigen Beispielen können Informationen angezeigt und/oder gemeinsam von Infotainment SoC 1630 und Instrumentencluster 1632 genutzt werden. In mindestens einem Ausführungsbeispiel kann das Instrumentencluster 1632 als Teil des Infotainment-SoC 1630 umfasst sein, oder umgekehrt.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 in dem System 16C zum Inferieren oder Vorhersagen verwendet werden, basierend zumindest teilweise auf Gewichtsparametern, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
16D ist ein Diagramm eines Systems 1676 zur Kommunikation zwischen Cloudbasierten Servern und dem autonomen Fahrzeug 1600 aus 16A, gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel kann das System 1676 ohne Einschränkung den/die Server 1678, das/die Netzwerk(e) 1690 und eine beliebige Anzahl und Art von Fahrzeugen, einschließlich des Fahrzeugs 1600, umfassen. Der/die Server 1678 kann/können ohne Einschränkung eine Vielzahl von GPUs 1684(A)-1684(H) (hierin kollektiv als GPUs 1684 bezeichnet), PCIe-Switches 1682(A)-1682(H) (hierin kollektiv als PCIe-Switches 1682 bezeichnet), und/oder CPUs 1680(A)-1680(B) (hierin kollektiv als CPUs 1680 bezeichnet) umfassen. GPUs 1684, CPUs 1680 und PCIe-Switches 1682 können mit Hochgeschwindigkeits-Interconnects verbunden werden, wie z. B. und ohne Einschränkung mit den von NVIDIA entwickelten NVLink-Schnittstellen 1688 und/oder PCIe-Verbindungen 1686. In mindestens einem Ausführungsbeispiel sind die GPUs 1684 über ein NVLink- und/oder NVSwitch-SoC verbunden, und die GPUs 1684 und die PCIe-Switches 1682 sind über PCIe-Verbindungen verbunden. In mindestens einem Ausführungsbeispiel werden zwar acht GPUs 1684, zwei CPUs 1680 und vier PCIe-Switches 1682 gezeigt, dies ist jedoch nicht als Einschränkung zu verstehen. In mindestens einem Ausführungsbeispiel kann jeder der Server 1678 ohne Einschränkung eine beliebige Anzahl von GPUs 1684, CPUs 1680 und/oder PCIe-Switches 1682 in beliebiger Kombination umfassen. In mindestens einem Ausführungsbeispiel könnte(n) der/die Server 1678 beispielsweise jeweils acht, sechzehn, zweiunddreißig und/oder mehr GPUs 1684 umfassen.
In mindestens einem Ausführungsbeispiel kann(n) der (die) Server 1678 über das (die) Netzwerk(e) 1690 und von Fahrzeugen Bilddaten empfangen, die Bilder repräsentieren, die unerwartete oder veränderte Straßenzustände zeigen, wie z.B. kürzlich begonnene Straßenbauarbeiten. In mindestens einem Ausführungsbeispiel kann(n) der/die Server 1678 über das/die Netzwerk(e) 1690 und an Fahrzeuge neuronale Netzwerke 1692, aktualisierte neuronale Netzwerke 1692 und/oder Kartendaten 1694 übertragen, die ohne Einschränkung Informationen über den Verkehr und die Straßenbedingungen umfassen. In mindestens einem Ausführungsbeispiel können die Aktualisierungen der Kartendaten 1694 ohne Einschränkung Aktualisierungen für die HD-Karte 1622 umfassen, wie z. B. Informationen über Baustellen, Schlaglöcher, Umleitungen, Überschwemmungen und/oder andere Hindernisse. In mindestens einem Ausführungsbeispiel können neuronale Netzwerke 1692, aktualisierte neuronale Netzwerke 1692 und/oder Kartendaten 1694 aus neuem Training und/oder Erfahrungen resultieren, die in Daten repräsentiert werden, die von einer beliebigen Anzahl von Fahrzeugen in der Umgebung empfangen werden, und/oder zumindest teilweise auf Training basieren, das in einem Datenzentrum durchgeführt wird (z.B. unter Verwendung von Server(n) 1678 und/oder anderen Servern).
In mindestens einem Ausführungsbeispiel kann/können der/die Server 1678 verwendet werden, um maschinelle Lernmodelle (z.B. neuronale Netzwerke) zu trainieren, die zumindest teilweise auf Trainingsdaten basieren. Trainingsdaten können von Fahrzeugen generiert werden und/oder können in einer Simulation generiert werden (z.B. unter Verwendung einer Game Engine). In mindestens einem Ausführungsbeispiel wird eine beliebige Menge von Trainingsdaten mit Tags versehen (z. B. wenn das assoziierte neuronale Netzwerk von beaufsichtigtem Lernen profitiert) und/oder einer anderen Vorverarbeitung unterzogen. In mindestens einem Ausführungsbeispiel wird eine beliebige Menge von Trainingsdaten nicht mit Tags versehen und/oder vorverarbeitet (z. B. wenn das assoziierte neuronale Netzwerk kein beaufsichtigtes Lernen benötigt). In mindestens einem Ausführungsbeispiel können die maschinellen Lernmodelle, sobald sie trainiert sind, von den Fahrzeugen verwendet werden (z.B. können sie über das/die Netzwerk(e) 1690 an die Fahrzeuge übertragen werden, und/oder die maschinellen Lernmodelle können von dem/den Server(n) 1678 zur Fernüberwachung der Fahrzeuge verwendet werden).
In mindestens einem Ausführungsbeispiel kann(n) der/die Server 1678 Daten von Fahrzeugen empfangen und Daten auf aktuelle neuronale Netzwerke zum intelligenten Inferenzieren in Echtzeit anwenden. In mindestens einem Ausführungsbeispiel kann(n) der/die Server 1678 Deep Learning-Supercomputer und/oder dedizierte KI-Computer umfassen, die von GPU(s) 1684 angetrieben werden, wie z. B. von NVIDIA entwickelte DGX- und DGX Station-Maschinen. In mindestens einem Ausführungsbeispiel kann der/die Server 1678 jedoch eine Deep Learning-Infrastruktur umfassen, die CPU-betriebene Rechenzentren verwendet.
In mindestens einem Ausführungsbeispiel kann die Deep-Learning-Infrastruktur des/der Server(s) 1678 zu schnellem Inferenzieren in Echtzeit fähig sein und diese Fähigkeit zum Evaluieren und Verifizieren des Zustands von Prozessoren, Software und/oder assoziierter Hardware im Fahrzeug 1600 verwenden. Zum Beispiel kann in mindestens einem Ausführungsbeispiel die Deep Leaming-Infrastruktur periodische Aktualisierungen vom Fahrzeug 1600 empfangen, wie eine Sequenz von Bildern und/oder Objekten, die das Fahrzeug 1600 in dieser Sequenz von Bildern lokalisiert hat (z. B. über computergestützte Vision und/oder andere maschinelle Objektklassifizierungstechniken). In mindestens einem Ausführungsbeispiel kann die Deep Neural Network-Infrastruktur ihr eigenes neuronales Netzwerk betreiben, um Objekte zu identifizieren und sie mit den vom Fahrzeug 1600 identifizierten Objekten zu vergleichen, und wenn die Ergebnisse nicht übereinstimmen und die Deep Neural Network-Infrastruktur zu dem Schluss kommt, dass die KI im Fahrzeug 1600 eine Fehlfunktion aufweist, dann kann/können der/die Server 1678 ein Signal an das Fahrzeug 1600 senden, das einen ausfallsicheren Computer des Fahrzeugs 1600 anweist, die Steuerung zu übernehmen, die Fahrgäste zu benachrichtigen und ein sicheres Parkmanöver durchzuführen.
In mindestens einem Ausführungsbeispiel kann(n) der/die Server 1678 GPU(s) 1684 und einen oder mehrere programmierbare Inferenzbeschleuniger (z. B. NVIDIAs TensorRT 3) umfassen. In mindestens einem Ausführungsbeispiel kann die Kombination von GPUbetriebenen Servern und Inferenzbeschleunigung eine Reaktionsfähigkeit in Echtzeit ermöglichen. In mindestens einem Ausführungsbeispiel, z. B. wenn die Leistung weniger kritisch ist, können zum Inferenzieren Server verwendet werden, die von CPUs, FPGAs und anderen Prozessoren betrieben werden. In mindestens einem Ausführungsbeispiel wird/werden die Hardwarestruktur(en) 1315 verwendet, um ein oder mehrere Ausführungsbeispiele durchzuführen. Details bezüglich der Hardwarestruktur(en) 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt.
COMPUTERSYSTEME
17 ist ein Blockdiagramm, das ein exemplarisches Computersystem veranschaulicht, das ein System mit miteinander verbundenen Geräten und Komponenten, ein System-on-a-Chip (SOC) oder eine Kombination davon 1700 sein kann, das mit einem Prozessor gebildet wird, der gemäß mindestens einem Ausführungsbeispiel Ausführungseinheiten zur Ausführung eines Befehls umfasst. In mindestens einer Ausführungsform kann das Computersystem 1700 ohne Einschränkung eine Komponente, wie z. B. einen Prozessor 1702, umfassen, um Ausführungseinheiten einschließlich Logik zur Durchführung von Algorithmen zur Verarbeitung von Daten gemäß der vorliegenden Offenbarung, wie z. B. in der hierin beschriebenen Ausführungsform, einzusetzen. In mindestens einem Ausführungsbeispiel kann das Computersystem 1700 Prozessoren umfassen, wie z. B. die PENTIUM®-Prozessorfamilie, XeonTM, Itanium®, XScaleTM und/oder StrongARMTM, Intel® Core™ oder Intel® Nervana™-Mikroprozessoren, die von der Intel Corporation in Santa Clara, Kalifornien, erhältlich sind, obwohl auch andere Systeme (einschließlich PCs mit anderen Mikroprozessoren, technische Workstations, Set-Top-Boxen und dergleichen) verwendet werden können. In mindestens einem Ausführungsbeispiel kann das Computersystem 1700 eine Version des WINDOWS-Betriebssystems ausführen, das von der Microsoft Corporation in Redmond, Washington, erhältlich ist, obwohl auch andere Betriebssysteme (z. B. UNIX und Linux), eingebettete Software und/oder grafische Benutzeroberflächen verwendet werden können.
Ausführungsbeispiele können auch in anderen Geräten wie Handheld-Geräten und eingebetteten Anwendungen verwendet werden. Einige Beispiele für tragbare Geräte umfassen Mobiltelefone, Internet-Protokoll-Geräte, Digitalkameras, persönliche digitale Assistenten („PDAs“) und Handheld-PCs. In mindestens einem Ausführungsbeispiel können eingebettete Anwendungen einen Mikrocontroller, einen digitalen Signalprozessor („DSP“), System-on-a-Chip, Netzwerkcomputer („NetPCs“), Set-Top-Boxen, Netzwerk-Hubs, Wide Area Network („WAN“)-Switches oder jedes andere System umfassen, das gemäß mindestens einem Ausführungsbeispiel einen oder mehrere Befehle ausführen kann.
In mindestens einem Ausführungsbeispiel kann das Computersystem 1700 ohne Einschränkung einen Prozessor 1702 umfassen, der ohne Einschränkung eine oder mehrere Ausführungseinheiten 1708 umfassen kann, um ein maschinelles Lernmodelltraining und/oder Inferenzieren gemäß den hier beschriebenen Techniken durchzuführen. In mindestens einem Ausführungsbeispiel handelt es sich bei dem System 17 um ein Desktop- oder Serversystem mit einem Prozessor, in einem anderen Ausführungsbeispiel kann das System 17 jedoch ein Multiprozessorsystem sein. In mindestens einem Ausführungsbeispiel kann der Prozessor 1702 ohne Einschränkung einen CISC-Mikroprozessor (Complex Instruction Set Computer), einen RISC-Mikroprozessor (Reduced Instruction Set Computing), einen VLIW-Mikroprozessor (Very Long Instruction Word), einen Prozessor, der eine Kombination von Befehlssätzen implementiert, oder ein beliebiges anderes Gerät, wie z. B. einen digitalen Signalprozessor, umfassen. In mindestens einem Ausführungsbeispiel kann der Prozessor 1702 mit einem Prozessorbus 1710 gekoppelt sein, der Datensignale zwischen dem Prozessor 1702 und anderen Komponenten im Computersystem 1700 übertragen kann.
In mindestens einem Ausführungsbeispiel kann der Prozessor 1702 ohne Einschränkung einen Level 1 („L1“) internen Cache-Speicher („Cache“) 1704 umfassen. In mindestens einem Ausführungsbeispiel kann der Prozessor 1702 einen einzigen internen Cache oder mehrere Ebenen eines internen Cache aufweisen. In mindestens einem Ausführungsbeispiel kann sich der Cache-Speicher außerhalb des Prozessors 1702 befinden. Andere Ausführungsbeispiele können auch eine Kombination aus internen und externen Cachespeichern umfassen, abhängig von der jeweiligen Implementierung und den Bedürfnissen. In mindestens einem Ausführungsbeispiel kann die Registerdatei 1706 verschiedene Datentypen in verschiedenen Registern speichern, darunter, ohne Einschränkung, Ganzzahlregister, Gleitkommaregister, Statusregister und Befehlszeigerregister.
In mindestens einem Ausführungsbeispiel befindet sich die Ausführungseinheit 1708, die ohne Einschränkung eine Logik zur Durchführung von Ganzzahl- und Gleitkommaoperationen umfasst, ebenfalls im Prozessor 1702. Der Prozessor 1702 kann auch einen Nur-Lese-Speicher („ROM“) mit Mikrocode („ucode“) umfassen, der Mikrocode für bestimmte Makrobefehle speichert. In mindestens einem Ausführungsbeispiel kann die Ausführungseinheit 1708 eine Logik zur Handhabung eines gepackten Befehlssatzes 1709 umfassen. In mindestens einem Ausführungsbeispiel können durch das Umfassen des gepackten Befehlssatzes 1709 im Befehlssatz eines allgemeinen Prozessors 1702 zusammen mit einer assoziierten Schaltungsanordnung zur Ausführung von Befehlen Operationen, die von vielen Multimedia-Anwendungen verwendet werden, unter Verwendung von gepackten Daten in einem allgemeinen Prozessor 1702 durchgeführt werden. In einem oder mehreren Ausführungsbeispielen können viele Multimedia-Anwendungen beschleunigt und effizienter ausgeführt werden, indem die volle Breite des Datenbusses eines Prozessors zur Durchführung von Operationen mit gepackten Daten verwendet wird, wodurch die Notwendigkeit entfällt, kleinere Einheiten von Daten über den Datenbus des Prozessors zu übertragen, um eine oder mehrere Operationen ein Datenelement nach dem anderen durchzuführen.
In mindestens einem Ausführungsbeispiel kann die Ausführungseinheit 1708 auch in Mikrocontrollern, eingebetteten Prozessoren, Grafikgeräten, DSPs und anderen Arten von logischen Schaltungen verwendet werden. In mindestens einem Ausführungsbeispiel kann das Computersystem 1700, ohne Einschränkung, einen Speicher 1720 umfassen. In mindestens einem Ausführungsbeispiel kann der Speicher 1720 als Dynamic Random Access Memory („DRAM“)-Gerät, als Static Random Access Memory („SRAM“)-Gerät, als Flash-Speichergerät oder als anderes Speichergerät implementiert sein. Der Speicher 1720 kann Anweisungen 1719 und/oder Daten 1721 speichern, die durch Datensignale repräsentiert werden, die vom Prozessor 1702 ausgeführt werden können.
In mindestens einem Ausführungsbeispiel kann der Systemlogik-Chip mit dem Prozessorbus 1710 und dem Speicher 1720 gekoppelt sein. In mindestens einem Ausführungsbeispiel kann der Systemlogik-Chip ohne Einschränkung einen Speichersteuerungs-Hub („MCH“) 1716 umfassen, und der Prozessor 1702 kann mit MCH 1716 über den Prozessorbus 1710 kommunizieren. In mindestens einem Ausführungsbeispiel kann der MCH 1716 einen Speicherpfad 1718 mit hoher Bandbreite zum Speicher 1720 für die Speicherung von Befehlen und Daten sowie für die Speicherung von Grafikbefehlen, Daten und Texturen bereitstellen. In mindestens einem Ausführungsbeispiel kann der MCH 1716 Datensignale zwischen dem Prozessor 1702, dem Speicher 1720 und anderen Komponenten im Computersystem 1700 leiten und Datensignale zwischen dem Prozessorbus 1710, dem Speicher 1720 und einem System-E/A 1722 überbrücken. In mindestens einem Ausführungsbeispiel kann der Systemlogik-Chip einen Grafikanschluss zum Anschluss an eine Grafiksteuerung bereitstellen. In mindestens einem Ausführungsbeispiel kann der MCH 1716 mit dem Speicher 1720 über einen Speicherpfad 1718 mit hoher Bandbreite gekoppelt sein, und die Grafik-/Videokarte 1712 kann mit dem MCH 1716 über einen Anschluss 1714 für einen beschleunigten Grafikport („AGP“) gekoppelt sein.
In mindestens einem Ausführungsbeispiel kann das Computersystem 1700 System-E/A 1722 verwenden, das ein proprietärer Hub-Schnittstellenbus ist, um MCH 1716 mit dem E/A-Hub („ICH“) 1730 zu koppeln. In mindestens einem Ausführungsbeispiel kann ICH 1730 direkte Verbindungen zu einigen Geräten über einen lokalen E/A-Bus bereitstellen. In mindestens einem Ausführungsbeispiel kann der lokale E/A-Bus ohne Einschränkung einen Hochgeschwindigkeits-E/A-Bus zur Verbindung von Peripheriegeräten mit dem Speicher 1720, dem Chipsatz und dem Prozessor 1702 umfassen. Beispiele können ohne Einschränkung einen Audiocontroller 1729, einen Firmware-Hub („Flash-BIOS“) 1728, einen drahtlosen Transceiver 1726, einen Datenspeicher 1724, einen Legacy-I/O-Controller 1723, der Benutzereingabe- und Tastaturschnittstellen enthält, einen seriellen Erweiterungsanschluss 1727, wie Universal Serial Bus („USB“), und eine Netzwerksteuerung 1734 umfassen. Der Datenspeicher 1724 kann ein Festplattenlaufwerk, ein Diskettenlaufwerk, ein CD-ROM-Gerät, ein Flash-Speichergerät oder ein anderes Massenspeichergerät umfassen.
In mindestens einem Ausführungsbeispiel zeigt 17 ein System, das miteinander verbundene Hardware-Geräte oder „Chips“ umfasst, während in anderen Ausführungsbeispielen 17 ein beispielhaftes System-on-a-Chip („SoC“) zeigen kann. In mindestens einem Ausführungsbeispiel können die in 17 dargestellten Geräte mit proprietären Verbindungen, standardisierten Verbindungen (z. B. PCIe) oder einer Kombination davon verbunden sein. In mindestens einem Ausführungsbeispiel sind eine oder mehrere Komponenten des Systems 1700 unter Verwendung von Compute Express Link (CXL)-Verbindungen miteinander verbunden.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System 17 zum Inferenzieren oder Vorhersagen verwendet werden, die zumindest teilweise auf Gewichtsparametem basieren, die unter Verwendung von Trainingsoperationen für neuronale Netzwerke, Funktionen und/oder Architekturen von neuronalen Netzwerken oder hierin beschriebenen Anwendungsfällen für neuronale Netzwerke berechnet wurden.
Die oben beschriebenen Techniken können beispielsweise zur Implementierung eines Systems für den Austausch von Objekten zwischen Mensch und Roboter verwendet werden. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das darauf trainiert ist, einen Griff eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
18 ist ein Blockdiagramm, das ein elektronisches Gerät 1800 zur Verwendung eines Prozessors 1810 gemäß mindestens einem Ausführungsbeispiel zeigt. In mindestens einem Ausführungsbeispiel kann das elektronische Gerät 1800 zum Beispiel und ohne Einschränkung ein Notebook, ein Tower-Server, ein Schrank-Server, ein Blade-Server, ein Laptop, ein Desktop, ein Tablet, ein mobiles Gerät, ein Telefon, ein eingebetteter Computer oder ein anderes geeignetes elektronisches Gerät sein.
In mindestens einem Ausführungsbeispiel kann das System 1800 ohne Einschränkung einen Prozessor 1810 umfassen, der kommunikativ mit jeder geeigneten Anzahl oder Art von Komponenten, Peripheriegeräten, Modulen oder Geräten gekoppelt ist. In mindestens einem Ausführungsbeispiel ist der Prozessor 1810 unter Verwendung eines Busses oder einer Schnittstelle gekoppelt, wie z.B. eines 1°C-Busses, eines System-Management-Busses („SMBus“), eines Low-Pin-Count-Busses (LPC), eines Serial-Peripheral-Interface („SPI“), eines High-Definition-Audio-Busses („HDA“), eines Serial-Advance-Technology-Attachment-Busses („SATA“), eines Universal-Serial-Bus („USB“) (Versionen 1, 2, 3) oder eines Universal-Asynchron-Receiver/Transmitter-Busses („UART“). In mindestens einem Ausführungsbeispiel zeigt 18 ein System, das miteinander verbundene Hardware-Geräte oder „Chips“ umfasst, während in anderen Ausführungsbeispielen 18 ein beispielhaftes System-on-a-Chip („SoC“) zeigen kann. In mindestens einem Ausführungsbeispiel können die in 18 dargestellten Geräte mit proprietären Verbindungen, standardisierten Verbindungen (z. B. PCIe) oder einer Kombination davon verbunden sein. In mindestens einem Ausführungsbeispiel sind eine oder mehrere Komponenten von 18 unter Verwendung von Compute Express Link (CXL)-Verbindungen miteinander verbunden.
In mindestens einem Ausführungsbeispiel kann 18 eine Anzeige 1824, einen Touchscreen 1825, ein Touchpad 1830, eine Near-Field-Communications Einheit („NFC“) 1845, einen Sensor-Hub 1840, einen Wärmesensor 1846, einen Express-Chipsatz („EC“) 1835, ein Trusted Platform Module („TPM“) 1838, BIOS/Firmware/Flash-Speicher („BIOS, FW Flash“) 1822, ein DSP 1860, ein Laufwerk („SSD oder HDD“) 1820 wie eine Solid State Disk („SSD“) oder ein Festplattenlaufwerk („HDD“), eine Einheit für ein drahtloses lokales Netzwerk („WLAN“) 1850, eine Bluetooth-Einheit 1852, eine Einheit für ein drahtloses Wide Area Network („WWAN“) 1856, ein Global Positioning System (GPS) 1855, eine Kamera („USB 3. 0-Kamera“) 1854, wie z. B. eine USB 3.0-Kamera, oder eine Low Power Double Data Rate („LPDDR“)-Speichereinheit („LPDDR3“) 1815, die z. B. im LPDDR3-Standard implementiert ist. Diese Komponenten können jeweils auf jede geeignete Weise implementiert werden.
In mindestens einem Ausführungsbeispiel können andere Komponenten mit dem Prozessor 1810 über die oben beschriebenen Komponenten kommunikativ gekoppelt sein. In mindestens einem Ausführungsbeispiel können ein Beschleunigungsmesser 1841, ein Umgebungslichtsensor („ALS“) 1842, ein Kompass 1843 und ein Gyroskop 1844 kommunikativ mit dem Sensor-Hub 1840 gekoppelt sein. In mindestens einem Ausführungsbeispiel können ein Wärmesensor 1839, ein Lüfter 1837, eine Tastatur 1846 und ein Touchpad 1830 kommunikativ mit dem EC 1835 gekoppelt sein. In mindestens einem Ausführungsbeispiel können ein Lautsprecher 1863, ein Kopfhörer 1864 und ein Mikrofon („mic“) 1865 kommunikativ mit einer Audioeinheit („audio codec and class d amp“) 1864 gekoppelt sein, die ihrerseits kommunikativ mit dem DSP 1860 gekoppelt sein kann. In mindestens einem Ausführungsbeispiel kann die Audioeinheit 1864 beispielsweise und ohne Einschränkung einen Audiokodierer/-dekodierer („Codec“) und einen Verstärker der Klasse D umfassen. In mindestens einem Ausführungsbeispiel kann die SIM-Karte („SIM“) 1857 mit der WWAN-Einheit 1856 kommunikativ gekoppelt sein. In mindestens einem Ausführungsbeispiel können Komponenten wie die WLAN-Einheit 1850 und die Bluetooth-Einheit 1852 sowie die WWAN-Einheit 1856 in einem Next Generation Form Factor („NGFF“) implementiert sein.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System 18 zum Inferenzieren oder Vorhersagen verwendet werden, die zumindest teilweise auf Gewichtsparametem basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das so trainiert ist, dass es einen Griff eines Objekts generiert, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
19 zeigt ein Computersystem 1900 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist das Computersystem 1900 so konfiguriert, dass es verschiedene Prozesse und Verfahren implementiert, die in dieser Offenbarung beschrieben sind.
In mindestens einem Ausführungsbeispiel umfasst das Computersystem 1900 ohne Einschränkung mindestens eine zentrale Verarbeitungseinheit („CPU“) 1902, die an einen Kommunikationsbus 1910 angeschlossen ist, der unter Verwendung eines beliebigen geeigneten Protokolls, wie PCI („Peripheral Component Interconnect“), Peripheral Component Interconnect Express („PCI-Express“), AGP („Accelerated Graphics Port“), HyperTransport oder eines anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokolls, implementiert ist. In mindestens einem Ausführungsbeispiel umfasst das Computersystem 1900 ohne Einschränkung einen Hauptspeicher 1904 und eine Steuerlogik (z. B. implementiert als Hardware, Software oder eine Kombination davon), und die Daten werden im Hauptspeicher 1904 gespeichert, der die Form eines Direktzugriffsspeichers („RAM“) annehmen kann. In mindestens einem Ausführungsbeispiel stellt ein Netzwerkschnittstellen-Subsystem („Netzwerkschnittstelle“) 1922 eine Schnittstelle zu anderen Rechengeräten und Netzwerken bereit, um Daten von anderen Systemen zu empfangen und Daten an andere Systeme vom Computersystem 1900 zu senden.
In mindestens einem Ausführungsbeispiel umfasst das Computersystem 1900 in mindestens einem Ausführungsbeispiel ohne Einschränkung Eingabegeräte 1908, ein Parallelverarbeitungssystem 1912 und Anzeigegeräte 1906, die unter Verwendung einer herkömmlichen Kathodenstrahlröhre („CRT“), einer Flüssigkristallanzeige („LCD“), einer lichtemittierenden Diode („LED“), einer Plasmaanzeige oder anderer geeigneter Anzeigetechnologien implementiert werden können. In mindestens einem Ausführungsbeispiel werden Benutzereingaben von Eingabegeräten 1908 wie Tastatur, Maus, Touchpad, Mikrofon und anderen empfangen. In mindestens einem Ausführungsbeispiel kann jedes der vorgenannten Module auf einer einzigen Halbleiterplattform angeordnet sein, um ein Verarbeitungssystem zu bilden.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System 19 zum Inferenzieren oder Vorhersagen verwendet werden, die zumindest teilweise auf Gewichtsparametem basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Das oben beschriebene Computersystem kann beispielsweise verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert ist, um einen Griff eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
20 zeigt ein Computersystem 2000 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel umfasst das Computersystem 2000, ohne Einschränkung, einen Computer 2010 und einen USB-Stick 2020. In mindestens einem Ausführungsbeispiel kann der Computer 2010 ohne Einschränkung eine beliebige Anzahl und Art von Prozessor(en) (nicht dargestellt) und einen Speicher (nicht dargestellt) umfassen. In mindestens einem Ausführungsbeispiel umfasst der Computer 2010, ohne Einschränkung, einen Server, eine Cloud-Instanz, einen Laptop und einen Desktop-Computer.
In mindestens einem Ausführungsbeispiel umfasst der USB-Stick 2020, ohne Einschränkung, eine Verarbeitungseinheit 2030, eine USB-Schnittstelle 2040 und eine USB-Schnittstellenlogik 2050. In mindestens einem Ausführungsbeispiel kann die Verarbeitungseinheit 2030 ein beliebiges Befehlsausführungssystem, -gerät oder -vorrichtung sein, das in der Lage ist, Befehle auszuführen. In mindestens einem Ausführungsbeispiel kann die Verarbeitungseinheit 2030 ohne Einschränkung eine beliebige Anzahl und Art von Verarbeitungskernen umfassen (nicht dargestellt). In mindestens einem Ausführungsbeispiel umfasst der Verarbeitungskern 2030 eine anwendungsspezifische integrierte Schaltung („ASIC“), die so optimiert ist, dass sie eine beliebige Anzahl und Art von Operationen ausführen kann, die mit dem maschinellen Lernen assoziiert sind. In mindestens einem Ausführungsbeispiel ist der Verarbeitungskern 2030 beispielsweise eine Tensor Processing Unit („TPC“), die für die Durchführung von Inferenz-Operationen im Rahmen des maschinellen Lernens optimiert ist. In mindestens einem Ausführungsbeispiel ist der Verarbeitungskern 2030 eine Bildverarbeitungseinheit („VPU“), die für die Durchführung von maschinellem Sehen und maschinellem Lernen inferenezierender Operationen optimiert ist.
In mindestens einem Ausführungsbeispiel kann die USB-Schnittstelle 2040 eine beliebige Art von USB-Stecker oder USB-Buchse sein. Beispielsweise ist in mindestens einem Ausführungsbeispiel die USB-Schnittstelle 2040 eine USB 3.0 Typ-C-Buchse für Daten und Strom. In mindestens einem Ausführungsbeispiel ist die USB-Schnittstelle 2040 ein USB-3.0-Typ-A-Stecker. In mindestens einem Ausführungsbeispiel kann die USB-Schnittstellenlogik 2050 eine beliebige Menge und Art von Logik umfassen, die es der verarbeitenden Einheit 2030 ermöglicht, über den USB-Anschluss 2040 mit anderen Geräten (z.B. Computer 2010) zu kommunizieren.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System 20 zum Inferenzieren oder Vorhersagen verwendet werden, die zumindest teilweise auf Gewichtsparametem basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können beispielsweise zur Implementierung eines Systems zum Austausch von Objekten zwischen Mensch und Roboter verwendet werden. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das so trainiert ist, dass es ein Greifen eines Objekts generiert, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
21A zeigt eine exemplarische Architektur, bei der eine Vielzahl von GPUs 2110-2113 mit einer Vielzahl von Multi-Kern-Prozessoren 2105-2106 über Hochgeschwindigkeitsverbindungen 2140-2143 (z.B. Busse, Punkt-zu-Punkt-Verbindungen usw.) kommunikativ gekoppelt ist. In einem Ausführungsbeispiel unterstützen die Hochgeschwindigkeitsverbindungen 2140-2143 einen Kommunikationsdurchsatz von 4 GB/s, 30 GB/s, 80 GB/s oder mehr. Es können verschiedene Verbindungsprotokolle verwendet werden, die unter anderem PCIe 4.0 oder 5.0 und NVLink 2.0 umfassen.
Zusätzlich und in einem Ausführungsbeispiel sind zwei oder mehr GPUs 2110-2113 über Hochgeschwindigkeitsverbindungen 2129-2130 miteinander verbunden, die unter Verwendung von gleichen oder anderen Protokollen/Leitungen als die für Hochgeschwindigkeitsverbindungen 2140-2143 verwendeten implementiert werden können. In ähnlicher Weise können zwei oder mehr der Mehrkernprozessoren 2105-2106 über Hochgeschwindigkeitsverbindungen 2128 verbunden sein, bei denen es sich um symmetrische Multiprozessorbusse (SMP) handeln kann, die mit 20 GB/s, 30 GB/s, 120 GB/s oder mehr arbeiten. Alternativ kann die gesamte Kommunikation zwischen den verschiedenen in 21A gezeigten Systemkomponenten unter Verwendung von gleichen Protokollen/Verbindungen (z.B. über eine gemeinsame Verbindungsstruktur) durchgeführt werden.
In einem Ausführungsbeispiel ist jeder Multi-Core-Prozessor 2105-2106 kommunikativ mit einem Prozessorspeicher 2101-2102 über Speicherverbindungen 2126-2127 gekoppelt, und jede GPU 2110-2113 ist kommunikativ mit dem GPU-Speicher 2120-2123 über GPU-Speicherverbindungen 2150-2153 gekoppelt. Die Speicherverbindungen 2126-2127 und 2150-2153 können gleiche oder unterschiedliche Speicherzugriffstechnologien verwenden. Bei den Prozessorspeichern 2101-2102 und den GPU-Speichern 2120-2123 kann es sich beispielsweise um flüchtige Speicher wie Dynamic Random Access Memory (DRAMs) (einschließlich gestapelter DRAMs), Graphics DDR SDRAM (GDDR) (z. B. GDDR5, GDDR6) oder High Bandwidth Memory (HBM) und/oder um nichtflüchtige Speicher wie 3D XPoint oder Nano-Ram handeln. In einem Ausführungsbeispiel kann ein Teil der Prozessorspeicher 2101-2102 ein flüchtiger Speicher und ein anderer Teil ein nichtflüchtiger Speicher sein (z.B. unter Verwendung einer zweistufigen Speicherhierarchie (2LM)).
Wie hierin beschrieben, können zwar verschiedene Prozessoren 2105-2106 und GPUs 2110-2113 physisch mit einem bestimmten Speicher 2101-2102 bzw. 2120-2123 gekoppelt sein, doch kann eine einheitliche Speicherarchitektur implementiert werden, bei der ein und derselbe virtuelle Systemadressraum (auch als „effektiver Adressraum“ bezeichnet) auf verschiedene physische Speicher verteilt wird. Beispielsweise können die Prozessorspeicher 2101-2102 jeweils 64 GB Systemadressraum und die GPU-Speicher 2120-2123 jeweils 32 GB Systemadressraum umfassen (was in diesem Beispiel zu einem adressierbaren Gesamtspeicher von 256 GB führt).
21B zeigt zusätzliche Details für eine Verbindung zwischen einem Multi-Core-Prozessor 2107 und einem Grafikbeschleunigungsmodul 2146 gemäß einem exemplarischen Ausführungsbeispiel. Das Grafikbeschleunigungsmodul 2146 kann einen oder mehrere GPU-Chips umfassen, die auf einer Leitungskarte integriert sind, die über eine Hochgeschwindigkeitsverbindung 2140 mit dem Prozessor 2107 gekoppelt ist. Alternativ kann das Grafikbeschleunigungsmodul 2146 in demselben Gehäuse oder Chip wie der Prozessor 2107 integriert sein.
In mindestens einem Ausführungsbeispiel umfasst der dargestellte Prozessor 2107 eine Vielzahl von Kernen 2160A-2160D, jeder mit einem Übersetzungs-Lookaside-Puffer 2161A-2161D und einem oder mehreren Caches 2162A-2162D. In mindestens einem Ausführungsbeispiel können die Kerne 2160A-2160D verschiedene andere Komponenten zur Ausführung von Befehlen und Verarbeitung von Daten umfassen, die nicht gezeigt werden. Die Caches 2162A-2162D können Level-1- (LI) und Level-2- (L2) Caches umfassen. Darüber hinaus können ein oder mehrere gemeinsam genutzte Caches 2156 in den Caches 2162A-2162D umfasst sein und von Gruppen von Kernen 2160A-2160D gemeinsam genutzt werden. Ein Ausführungsbeispiel des Prozessors 2107 umfasst beispielsweise 24 Kerne, jeder mit seinem eigenen L1-Cache, zwölf gemeinsam genutzten L2-Caches und zwölf gemeinsam genutzten L3-Caches. In diesem Ausführungsbeispiel werden ein oder mehrere L2- und L3-Caches von zwei benachbarten Kernen gemeinsam genutzt. Prozessor 2107 und Grafikbeschleunigungsmodul 2146 sind mit dem Systemspeicher 2114 verbunden, der die Prozessorspeicher 2101-2102 von 21A umfassen kann.
Die Kohärenz von Daten und Befehlen, die in verschiedenen Caches 2162A-2162D, 2156 und im Systemspeicher 2114 gespeichert sind, wird durch Kommunikation zwischen den Kernen über einen Kohärenzbus 2164 aufrechterhalten. Beispielsweise kann jeder Cache über eine damit assoziierte Cache-Kohärenzlogik/Schaltungsanordnung verfügen, um als Reaktion auf detektierte Lese- oder Schreibvorgänge in bestimmten Cache-Zeilen über den Kohärenzbus 2164 zu kommunizieren. In einer Implementierung wird ein Cache-Snooping-Protokoll über den Kohärenzbus 2164 implementiert, um Cache-Zugriffe auszuspähen.
In einem Ausführungsbeispiel ist das Grafikbeschleunigungsmodul 2146 über eine Proxy-Schaltung 2125 kommunikativ mit dem Kohärenzbus 2164 gekoppelt, so dass das Grafikbeschleunigungsmodul 2146 an einem Cache-Kohärenzprotokoll als Peer der Kerne 2160A-2160D teilnehmen kann. Insbesondere stellt eine Schnittstelle 2135 eine Verbindung zur Proxy-Schaltung 2125 über eine Hochgeschwindigkeitsverbindung 2140 (z. B. PCIe-Bus, NVLink usw.) bereit, und eine Schnittstelle 2137 verbindet das Grafikbeschleunigungsmodul 2146 mit der Verbindung 2140.
In einer Implementierung stellt ein Beschleuniger-Integrationsschaltkreis 2136 Cache-Verwaltung, Speicherzugriff, Kontextverwaltung und Interrupt-Verwaltungsdienste für eine Vielzahl von Grafikverarbeitungs-Engines 2131, 2132, N des Grafikbeschleunigungsmoduls 2146 bereit. Die Grafikverarbeitungs-Engines 2131, 2132, N können jeweils eine separate Grafikverarbeitungs-Einheit (GPU) umfassen. Alternativ können die Grafikverarbeitungs-Engines 2131, 2132, N verschiedene Arten von Grafikverarbeitungs-Engines innerhalb einer GPU umfassen, wie z. B. Grafikausführungseinheiten, Medienverarbeitungs-Engines (z. B. Video-Kodierer/Dekodierer), Sampler und Blit-Engines. In mindestens einem Ausführungsbeispiel kann das Grafikbeschleunigungsmodul 2146 eine GPU mit einer Vielzahl von Grafikverarbeitungs-Engines 2131-2132, N sein, oder die Grafikverarbeitungs-Engines 2131-2132, N können einzelne GPUs sein, die in ein gemeinsames Gehäuse, eine Linecard oder einen Chip integriert sind.
In einem Ausführungsbeispiel umfasst der Beschleuniger-Integrationsschaltkreis 2136 eine Speicherverwaltungseinheit (MMU) 2139 zur Durchführung verschiedener Speicherverwaltungsfunktionen, wie z. B. Übersetzungen von virtuellem in physischen Speicher (auch als Übersetzungen von effektivem in realen Speicher bezeichnet) und Speicherzugriffsprotokolle für den Zugriff auf den Systemspeicher 2114. Die MMU 2139 kann auch einen Übersetzungs-Lookaside-Puffer (TLB) (nicht gezeigt) umfassen, um Übersetzungen von virtuellen/effektiven in physische/reale Adressen zwischenzuspeichern. In einem Ausführungsbeispiel werden in einem Cache 2138 Befehle und Daten für den effizienten Zugriff der Grafikverarbeitungs-Engines 2131-2132, N gespeichert. In einem Ausführungsbeispiel werden die im Cache 2138 und in den Grafikspeichern 2133-2134, M gespeicherten Daten mit den Kern-Caches 2162A-2162D, 2156 und dem Systemspeicher 2114 kohärent gehalten. Wie bereits erwähnt, kann dies über eine Proxy-Schaltung 2125 im Namen des Cache 2138 und der Speicher 2133-2134, M erfolgen (z. B. Senden von Aktualisierungen an den Cache 2138 im Zusammenhang mit Änderungen/Zugriffen auf Cache-Zeilen in den Prozessor-Caches 2162A-2162D, 2156 und Empfangen von Aktualisierungen vom Cache 2138).
Ein Satz von Registern 2145 speichert Kontextdaten für Threads, die von Grafikverarbeitungs-Engines 2131-2132, N ausgeführt werden, und eine Kontextverwaltungsschaltung 2148 verwaltet Thread-Kontexte. Die Schaltung zur Kontextverwaltung 2148 kann beispielsweise Operationen zum Speichern und Wiederherstellen von Kontexten verschiedener Threads während eines Context Switches durchführen (z. B. wenn ein erster Thread gespeichert und ein zweiter Thread gespeichert wird, damit ein zweiter Thread von einer Grafikverarbeitungs-Engine ausgeführt werden kann). Bei einem Kontext-Switch kann die Schaltung zur Kontextverwaltung 2148 beispielsweise die aktuellen Registerwerte in einem bestimmten Bereich im Speicher speichern (z. B. identifiziert durch einen Kontextzeiger). Sie kann dann die Registerwerte wiederherstellen, wenn sie zu einem Kontext zurückkehrt. In einem Ausführungsbeispiel empfängt und verarbeitet eine Schaltung zur Unterbrechungsverwaltung 2147 von Systemgeräten empfangene Unterbrechungen.
In einer Implementierung werden virtuelle/effektive Adressen von einer Grafikverarbeitungs-Engine 2131 durch MMU 2139 in reale/physische Adressen im Systemspeicher 2114 übersetzt. Ein Ausführungsbeispiel des Beschleuniger-Integrationsschaltkreises 2136 unterstützt mehrere (z.B. 4, 8, 16) Grafikbeschleunigermodule 2146 und/oder andere Beschleunigergeräte. Das Grafikbeschleunigermodul 2146 kann für eine einzelne, auf dem Prozessor 2107 ausgeführte Anwendung bestimmt sein oder von mehreren Anwendungen gemeinsam genutzt werden. In einem Ausführungsbeispiel wird eine virtualisierte Grafikausführungsumgebung vorgestellt, in der die Ressourcen der Grafikverarbeitungs-Engines 2131-2132, N gemeinsam mit mehreren Anwendungen oder virtuellen Maschinen (VMs) genutzt werden. In mindestens einem Ausführungsbeispiel können die Ressourcen in „Abschnitte“ unterteilt werden, die verschiedenen VMs und/oder Anwendungen basierend auf Verarbeitungsanforderungen und Prioritäten, die mit VMs und/oder Anwendungen assoziiert sind, zugewiesen werden.
In mindestens einem Ausführungsbeispiel fungiert der Beschleuniger-Integrationsschaltkreis 2136 als Brücke zu einem System für das Grafikbeschleunigungsmodul 2146 und stellt Adressübersetzungs- und Systemspeicher-Cache-Dienste bereit. Darüber hinaus kann der Beschleuniger-Integrationsschaltkreis 2136 Virtualisierungseinrichtungen für einen Host-Prozessor bereitstellen, um die Virtualisierung der Grafikverarbeitungs-Engines 2131-2132, Interrupts und die Speicherverwaltung zu verwalten.
Da die Hardwareressourcen der Grafikverarbeitungs-Engines 2131-2132, N explizit einem realen Adressraum zugeordnet sind, den der Host-Prozessor 2107 sieht, kann jeder Host-Prozessor diese Ressourcen direkt unter Verwendung eines effektiven Adresswertes adressieren. Eine Funktion des Beschleuniger-Integrationsschaltkreises 2136 ist in einem Ausführungsbeispiel die physische Trennung der Grafikverarbeitungs-Engines 2131-2132, N, so dass sie für ein System als unabhängige Einheiten erscheinen.
In mindestens einem Ausführungsbeispiel sind ein oder mehrere Grafikspeicher 2133-2134, M jeweils mit jeder der Grafikverarbeitungs-Engines 2131-2132, N gekoppelt. Grafikspeicher 2133-2134, M speichern Befehle und Daten, die von jeder der Grafikverarbeitungs-Engines 2131-2132, N verarbeitet werden. Grafikspeicher 2133-2134, M können flüchtige Speicher wie DRAMs (einschließlich gestapelter DRAMs), GDDR-Speicher (z. B. GDDR5, GDDR6) oder HBM sein und/oder können nichtflüchtige Speicher wie 3D XPoint oder Nano-Ram sein.
In mindestens einem Ausführungsbeispiel werden zur Verringerung des Datenverkehrs über die Verbindung 2140 Vorgabetechniken verwendet, um sicherzustellen, dass die in den Grafikspeichern 2133-2134, M gespeicherten Daten Daten sind, die am häufigsten von den Grafikverarbeitungs-Engines 2131-2132, N verwendet werden und vorzugsweise nicht von den Kernen 2160A-2160D (zumindest nicht häufig) verwendet werden. In ähnlicher Weise versucht ein Vorgabe-Mechanismus, Daten, die von Kernen (und vorzugsweise nicht von Grafikverarbeitungs-Engines 2131-2132, N) benötigt werden, in den Caches 2162A-2162D, 2156 der Kerne und des Systemspeichers 2114 zu halten.
21C zeigt ein weiteres exemplarisches Ausführungsbeispiel, bei dem der Beschleuniger-Integrationsschaltkreis 2136 in den Prozessor 2107 integriert ist. In diesem Ausführungsbeispiel kommunizieren die Grafikverarbeitungs-Engines 2131-2132, N direkt über die Hochgeschwindigkeitsverbindung 2140 mit dem Beschleuniger-Integrationsschaltkreis 2136 über die Schnittstelle 2137 und die Schnittstelle 2135 (die wiederum eine beliebige Form von Bus oder Schnittstellenprotokoll verwenden kann). Der Beschleuniger-Integrationsschaltkreis 2136 kann dieselben Operationen durchführen, wie sie in 21B beschrieben sind, jedoch möglicherweise mit einem höheren Durchsatz, da er sich in unmittelbarer Nähe zum Kohärenzbus 2164 und den Caches 2162A-2162D, 2156 befindet. Ein Ausführungsbeispiel unterstützt verschiedene Programmiermodelle, einschließlich eines Programmiermodells für dedizierte Prozesse (ohne Virtualisierung des Grafikbeschleunigungsmoduls) und gemeinsam genutzte Programmiermodelle (mit Virtualisierung), die Programmiermodelle umfassen können, die vom Beschleuniger-Integrationsschaltkreis 2136 gesteuert werden, und Programmiermodelle, die vom Grafikbeschleunigungsmodul 2146 gesteuert werden.
In mindestens einem Ausführungsbeispiel sind die Grafikverarbeitungs-Engines 2131-2132, N für eine einzige Anwendung oder einen einzigen Prozess unter einem einzigen Betriebssystem vorgesehen. In mindestens einem Ausführungsbeispiel kann eine einzelne Anwendung andere Anwendungsanforderungen an die Grafikverarbeitungs-Engines 2131-2132, N weiterleiten, wodurch eine Virtualisierung innerhalb einer VM/Partition bereitgestellt wird.
In mindestens einem Ausführungsbeispiel können Grafikverarbeitungs-Engines 2131-2132, N, von mehreren VM-/Anwendungspartitionen gemeinsam genutzt werden. In mindestens einem Ausführungsbeispiel können gemeinsam genutzte Modelle einen Systemhypervisor zur Virtualisierung der Grafikverarbeitungs-Engines 2131-2132, N verwenden, um den Zugriff durch jedes Betriebssystem zu ermöglichen. Bei Systemen mit einer einzigen Partition ohne Hypervisor sind die Grafikverarbeitungs-Engines 2131-2132, N im Besitz eines Betriebssystems. In mindestens einem Ausführungsbeispiel kann ein Betriebssystem die Grafikverarbeitungs-Engines 2131-2132, N virtualisieren, um den Zugriff auf jeden Prozess oder jede Anwendung bereitzustellen.
In mindestens einem Ausführungsbeispiel wählt das Grafikbeschleunigungsmodul 2146 oder eine individuelle Grafikverarbeitungs-Engine 2131-2132, N ein Prozesselement unter Verwendung eines Prozesshandles aus. In einem Ausführungsbeispiel werden Prozesselemente im Systemspeicher 2114 gespeichert und sind unter Verwendung der hierin beschriebenen Techniken zur Übersetzung von effektiven Adressen in reale Adressen adressierbar. In mindestens einem Ausführungsbeispiel kann ein Prozesshandle ein implementierungsspezifischer Wert sein, der einem Host-Prozess bereitgestellt wird, wenn er seinen Kontext bei der Grafikverarbeitungs-Engine 2131-2132, N registriert (d. h. wenn er die Systemsoftware aufruft, um ein Prozesselement zu einer verknüpften Prozesselementliste hinzuzufügen). In mindestens einem Ausführungsbeispiel können die unteren 16 Bits eines Prozesshandles ein Offset des Prozesselements innerhalb einer verknüpften Prozesselementliste sein.
21D zeigt einen exemplarischen Beschleuniger-Integrationsabschnitt 2190. Wie hier verwendet, umfasst ein „Abschnitt“ einen spezifizierten Teil der Verarbeitungsressourcen des Beschleuniger-Integrationsschaltkreises 2136. Der effektive Anwendungsadressraum 2182 im Systemspeicher 2114 speichert Prozesselemente 2183. In einem Ausführungsbeispiel werden Prozesselemente 2183 als Reaktion auf GPU-Aufrufe 2181 von auf dem Prozessor 2107 ausgeführten Anwendungen 2180 gespeichert. Ein Prozesselement 2183 enthält den Prozessstatus für die entsprechende Anwendung 2180. Ein im Prozesselement 2183 enthaltener Arbeitsdeskriptor (WD) 2184 kann ein einzelner, von einer Anwendung angeforderter Auftrag sein oder einen Zeiger auf eine Warteschlange von Aufträgen enthalten. In mindestens einem Ausführungsbeispiel ist der WD 2184 ein Zeiger auf eine Auftragsanforderungs-Warteschlange im Adressraum 2182 einer Anwendung.
Das Grafikbeschleunigungsmodul 2146 und/oder einzelne Grafikverarbeitungs-Engines 2131-2132, N können von allen oder einer Teilmenge von Prozessen in einem System gemeinsam genutzt werden. In mindestens einem Ausführungsbeispiel kann eine Infrastruktur zum Einrichten des Prozessstatus und zum Senden eines WD 2184 an ein Grafikbeschleunigungsmodul 2146 zum Starten eines Auftrags in einer virtualisierten Umgebung umfasst sein.
In mindestens einem Ausführungsbeispiel ist ein Programmiermodell für dedizierte Prozesse implementierungsspezifisch. In diesem Modell enthält ein einzelner Prozess das Grafikbeschleunigungsmodul 2146 oder eine individuelle Grafikverarbeitungs-Engine 2131. Da das Grafikbeschleunigungsmodul 2146 im Besitz eines einzelnen Prozesses ist, initialisiert ein Hypervisor den Beschleuniger-Integrationsschaltkreis 2136 für eine besitzende Partition und ein Betriebssystem initialisiert den Beschleuniger-Integrationsschaltkreis 2136 für einen besitzenden Prozess, wenn das Grafikbeschleunigungsmodul 2146 zugewiesen wird.
Im Betrieb holt eine Hol-Einheit 2191 im Beschleuniger-Integrationsabschnitt 2190 den nächsten WD 2184, der eine Anzeige der Arbeit umfasst, die von einer oder mehreren Grafikverarbeitungs-Engines des Grafikbeschleunigungsmoduls 2146 zu erledigen ist. Die Daten aus dem WD 2184 können in Registern 2145 gespeichert und von der MMU 2139, der Interrupt-Management-Schaltung 2147 und/oder der Kontext-Management-Schaltung 2148 wie gezeigt verwendet werden. Ein Ausführungsbeispiel der MMU 2139 umfasst beispielsweise eine Schaltungsanordnung für den Zugriff auf Segment-/Seitentabellen 2186 im virtuellen Adressraum 2185 des Betriebssystems. Die Schaltung zur Unterbrechungsverwaltung 2147 kann vom Grafikbeschleunigungsmodul 2146 empfangene Unterbrechungsereignisse 2192 verarbeiten. Bei der Durchführung von Grafikoperationen wird eine von einer Grafikverarbeitungs-Engine 2131-2132, N generierte effektive Adresse 2193 von der MMU 2139 in eine reale Adresse übersetzt.

In einem Ausführungsbeispiel wird für jede Grafikverarbeitungs-Engine 2131-2132, N und/oder jedes Grafikbeschleunigungsmodul 2146 ein und derselbe Satz von Registern 2145 dupliziert und kann von einem Hypervisor oder Betriebssystem initialisiert werden. Jedes dieser duplizierten Register kann in einem Beschleuniger-Integrationsabschnitt 2190 umfasst sein. Beispielhafte Register, die von einem Hypervisor initialisiert werden können, sind in Tabelle 1 aufgeführt. Tabelle 1 - Vom Hypervisor initialisierte Register

1	Slice Control Register
2	Real Address (RA) Scheduled Processes Area Pointer
3	Authority Mask Override Register
4	Interrupt Vector Table Entry Offset
5	Interrupt Vector Table Entry Limit
6	State Register
7	Logical Partition ID
8	Real address (RA) Hypervisor Accelerator Utilization Record Pointer
9	Storage Description Register

Exemplarische Register, die von einem Betriebssystem initialisiert werden können, sind in Tabelle 2 aufgeführt. Tabelle 2 - Vom Betriebssystem initialisierte Register

1	Process and Thread Identification
2	Effective Address (EA) Context Save/Restore Pointer
3	Virtual Address (VA) Accelerator Utilization Record Pointer
4	Virtual Address (VA) Storage Segment Table Pointer
5	Authority Mask
6	Work descriptor

In einem Ausführungsbeispiel ist jedes WD 2184 spezifisch für ein bestimmtes Grafikbeschleunigungsmodul 2146 und/oder die Grafikverarbeitungs-Engines 2131-2132, N. Es enthält alle Informationen, die von einer Grafikverarbeitungs-Engine 2131-2132, N für die Ausführung von Arbeiten benötigt werden, oder es kann ein Zeiger auf einen Speicherplatz sein, an dem eine Anwendung eine Befehlswarteschlange für zu erledigende Arbeiten eingerichtet hat.
21E zeigt zusätzliche Details für ein exemplarisches Ausführungsbeispiel eines gemeinsam genutzten Modells. Dieses Ausführungsbeispiel umfasst einen realen Hypervisor-Adressraum 2198, in dem eine Prozesselementliste 2199 gespeichert ist. Der reale Hypervisor-Adressraum 2198 ist über einen Hypervisor 2196 zugänglich, der Grafikbeschleunigungsmodul-Engines für das Betriebssystem 2195 virtualisiert.
In mindestens einem Ausführungsbeispiel ermöglichen gemeinsam genutzte Programmiermodelle, dass alle oder eine Untermenge von Prozessen aus allen oder einer Untermenge von Partitionen in einem System ein Grafikbeschleunigungsmodul 2146 verwenden. Es gibt zwei Programmiermodelle, bei denen das Grafikbeschleunigungsmodul 2146 von mehreren Prozessen und Partitionen gemeinsam genutzt wird: zeitabschnittweise gemeinsame Nutzung und gezielte gemeinsame Nutzung von Grafiken.
Bei diesem Modell enthält der System-Hypervisor 2196 das Grafikbeschleunigungsmodul 2146 und stellt seine Funktionalität allen Betriebssystemen 2195 zur Verfügung. Damit ein Grafikbeschleunigungsmodul 2146 die Virtualisierung durch den Systemhypervisor 2196 unterstützen kann, kann das Grafikbeschleunigungsmodul 2146 die folgenden Bedingungen erfüllen: 1) Die Auftragsanforderung einer Anwendung muss autonom sein (d. h. der Zustand muss zwischen den Aufträgen nicht aufrechterhalten werden), oder das Grafikbeschleunigungsmodul 2146 muss einen Mechanismus zum Speichern und Wiederherstellen des Kontexts bereitstellen. 2) Das Grafikbeschleunigungsmodul 2146 garantiert, dass die Auftragsanforderung einer Anwendung in einer bestimmten Zeitspanne abgeschlossen wird, die auch eventuelle Übersetzungsfehler umfasst, oder das Grafikbeschleunigungsmodul 2146 stellt die Möglichkeit bereit, die Verarbeitung eines Auftrags vorzuziehen. 3) Dem Grafikbeschleunigungsmodul 2146 muss eine Ausgeglichenheit zwischen den Prozessen garantiert werden, wenn es in einem gerichteten, gemeinsam genutzten Programmiermodell arbeitet.
In mindestens einem Ausführungsbeispiel wird von der Anwendung 2180 verlangt, dass sie einen Systemaufruf des Betriebssystems 2195 mit einem Grafikbeschleunigungsmodul 2146-Typ, einem Arbeitsdeskriptor (WD), einem AMR-Wert (Authority Mask Register) und einem CSRP-Zeiger (Context Save/Restore Area Pointer) durchführt. In mindestens einem Ausführungsbeispiel beschreibt der Typ des Grafikbeschleunigungsmoduls 2146 eine gezielte Beschleunigungsfunktion für einen Systemaufruf. In mindestens einem Ausführungsbeispiel kann der Typ des Grafikbeschleunigungsmoduls 2146 ein systemspezifischer Wert sein. In mindestens einem Ausführungsbeispiel ist WD speziell für das Grafikbeschleunigungsmodul 2146 formatiert und kann in Form eines Grafikbeschleunigungsmodul-2146-Befehls, eines effektiven Adresszeigers auf eine benutzerdefinierte Struktur, eines effektiven Adresszeigers auf eine Befehlswarteschlange oder einer anderen Datenstruktur vorliegen, die die vom Grafikbeschleunigungsmodul 2146 zu verrichtende Arbeit beschreibt. In einem Ausführungsbeispiel ist ein AMR-Wert ein AMR-Zustand, der für einen aktuellen Prozess zu verwenden ist. In mindestens einem Ausführungsbeispiel ist ein Wert, der an ein Betriebssystem übergeben wird, vergleichbar mit der Einstellung eines AMR durch eine Anwendung. Wenn die Implementierungen des Beschleuniger-Integrationsschaltkreises 2136 und des Grafikbeschleunigungsmoduls 2146 kein User Authority Mask Override Register (UAMOR) unterstützen, kann ein Betriebssystem einen aktuellen UAMOR-Wert auf einen AMR-Wert anwenden, bevor ein AMR in einem Hypervisor-Aufruf übergeben wird. Der Hypervisor 2196 kann optional einen aktuellen AMOR-Wert (Authority Mask Override Register) anwenden, bevor ein AMR in das Prozesselement 2183 gestellt wird. In mindestens einem Ausführungsbeispiel ist CSRP eines der Register 2145, die eine effektive Adresse eines Bereichs im Adressraum 2182 einer Anwendung für das Grafikbeschleunigungsmodul 2146 enthalten, um den Kontextstatus zu speichern und wiederherzustellen. Dieser Zeiger ist optional, wenn kein Zustand zwischen Aufträgen gespeichert werden muss oder wenn ein Auftrag vorzeitig beendet wird. In mindestens einem Ausführungsbeispiel kann der Kontextspeicher-/Wiederherstellungsbereich ein fest angebundener Systemspeicher sein.

Beim Empfang eines Systemaufrufs kann das Betriebssystem 2195 überprüfen, ob die Anwendung 2180 registriert ist und die Berechtigung hat, das Grafikbeschleunigungsmodul 2146 zu verwenden. Das Betriebssystem 2195 ruft dann den Hypervisor 2196 mit den in Tabelle 3 aufgeführten Informationen auf. Tabelle 3 - Aufrufparameter zwischen Betriebssystem und Hypervisor

1	Work descriptor (WD)
2	Authority Mask Register (AMR) value (potentially masked)
3	Effective address (EA) Context Save/Restore Area Pointer (CSRP)
4	Process ID (PID) and optional thread ID (TID)
5	Virtual address (VA) accelerator utilization record pointer (AURP)
6	Virtual address of storage segment table pointer (SSTP)
7	Logical interrupt service number (LISN)

Beim Empfang eines Hypervisor-Aufrufs überprüft der Hypervisor 2196, ob das Betriebssystem 2195 registriert ist und die Berechtigung hat, das Grafikbeschleunigungsmodul 2146 zu verwenden. Hypervisor 2196 fügt dann das Prozesselement 2183 in eine mit Prozesselementen verknüpfte Liste für einen entsprechenden Grafikbeschleunigungsmodultyp 2146 ein. Ein Prozesselement kann die in Tabelle 4 dargestellten Informationen umfassen. Tabelle 4 - Prozesselementinformationen

1	Work descriptor (WD)
2	Authority Mask Register (AMR) value (potentially masked).
3	Effective address (EA) Context Save/Restore Area Pointer (CSRP)
4	Process ID (PID) and optional thread ID (TID)
5	Virtual address (VA) accelerator utilization record pointer (AURP)
6	Virtual address of storage segment table pointer (SSTP)
7	Logical interrupt service number (LISN)
8	Interrupt vector table, derived from hypervisor call parameters
9	State register (SR) value
10	Logical partition ID (LPID)
11	Real address (RA) hypervisor accelerator utilization record pointer
12	Storage Descriptor Register (SDR)

In mindestens einem Ausführungsbeispiel initialisiert der Hypervisor eine Vielzahl von Registern 2145 des Beschleuniger-Integrationsabschnitts 2190.
Wie in 21F beispielhaft gezeigt, wird in mindestens einem Ausführungsbeispiel ein einheitlicher Speicher verwendet, der über einen gemeinsamen virtuellen Adressraum adressierbar ist, der für den Zugriff auf physische Prozessorspeicher 2101-2102 und GPU-Speicher 2120-2123 verwendet wird. Bei dieser Implementierung verwenden Operationen, die auf den GPUs 2110-2113 ausgeführt werden, denselben virtuellen/effektiven Speicheradressraum für den Zugriff auf die Prozessorspeicher 2101-2102 und umgekehrt, wodurch die Programmierbarkeit vereinfacht wird. In einem Ausführungsbeispiel wird ein erster Teil eines virtuellen/effektiven Adressraums dem Prozessorspeicher 2101 zugewiesen, ein zweiter Teil dem zweiten Prozessorspeicher 2102, ein dritter Teil dem GPU-Speicher 2120 usw. In mindestens einem Ausführungsbeispiel wird dadurch ein gesamter virtueller/effektiver Speicherraum (manchmal auch als effektiver Adressraum bezeichnet) über jeden der Prozessorspeicher 2101-2102 und GPU-Speicher 2120-2123 verteilt, wodurch jeder Prozessor oder jede GPU auf jeden physischen Speicher mit einer diesem Speicher zugeordneten virtuellen Adresse zugreifen kann.
In einem Ausführungsbeispiel stellt die Schaltungsanordnung zur Vorgabe-/Kohärenzverwaltung 2194A-2194E innerhalb einer oder mehrerer MMUs 2139A-2139E die Cache-Kohärenz zwischen den Caches eines oder mehrerer Host-Prozessoren (z. B. 2105) und GPUs 2110-2113 sicher und implementiert Vorgabetechniken, die anzeigen, in welchen physischen Speichern bestimmte Datentypen gespeichert werden sollten. Während mehrere Instanzen der Schaltungsanordnung zur Vorgabe-/Kohärenzverwaltung 2194A-2194E in 21F gezeigt sind, kann die Schaltungsanordnung zur Vorgabe-/Kohärenzverwaltung innerhalb einer MMU eines oder mehrerer Host-Prozessoren 2105 und/oder innerhalb des Beschleuniger-Integrationsschaltkreises 2136 implementiert sein.
Ein Ausführungsbeispiel ermöglicht es, GPU-gebundenen Speicher 2120-2123 als Teil des Systemspeichers zuzuordnen und unter Verwendung von gemeinsam genutztem virtuellem Speicher (SVM) zuzugreifen, ohne jedoch Leistungsnachteile zu erleiden, die mit vollständiger System-Cache-Kohärenz verbunden sind. In mindestens einem Ausführungsbeispiel wird durch die Möglichkeit des Zugriffs auf den GPU-gebundenen Speicher 2120-2123 als Systemspeicher ohne lästigen Cache-Kohärenz-Overhead eine vorteilhafte Betriebsumgebung für die GPU-Auslagerung bereitgestellt. Diese Anordnung ermöglicht es der Software des Host-Prozessors 2105, Operanden aufzubauen und auf Berechnungsergebnisse zuzugreifen, ohne den Overhead herkömmlicher E/A-DMA-Datenkopien. Solche herkömmlichen Kopien beinhalten Treiberaufrufe, Unterbrechungen und speicherzugeordnete E/A-Zugriffe (MMIO), die alle im Vergleich zu einfachen Speicherzugriffen ineffizient sind. In mindestens einem Ausführungsbeispiel kann die Fähigkeit, auf GPU-gebundenen Speicher 2120-2123 ohne Cache-Kohärenz-Overhead zuzugreifen, entscheidend für die Ausführungszeit einer ausgelagerten Berechnung sein. In Fällen mit erheblichem Streaming-Schreibspeicherverkehr kann der Cache-Kohärenz-Overhead beispielsweise die effektive Schreibbandbreite einer GPU 2110-2113 signifikant reduzieren. In mindestens einem Ausführungsbeispiel können die Effizienz des Operandenaufbaus, die Effizienz des Ergebniszugriffs und die Effizienz der GPU-Berechnung eine Rolle beim Bestimmen der Effektivität eines GPU-Offloads spielen.
In mindestens einem Ausführungsbeispiel wird die Auswahl der GPU-Vorgabe und der Host-Prozessor-Vorgabe durch eine Bias-Tracker-Datenstruktur gesteuert. Es kann z.B. eine Vorgabetabelle verwendet werden, die eine seitengranulare Struktur sein kann (d.h. mit der Granularität einer Speicherseite gesteuert), die 1 oder 2 Bits pro GPU-gebundene Speicherseite umfasst. In mindestens einem Ausführungsbeispiel kann eine Vorgabetabelle in einem gestohlenen Speicherbereich eines oder mehrerer GPU-gebundener Speicher 2120-2123 implementiert werden, mit oder ohne Vorgabe-Cache in GPU 2110-2113 (z. B. um häufig/kürzlich verwendete Einträge einer Vorgabetabelle zu cachen). Alternativ kann eine gesamte Vorgabetabelle in einer GPU geführt werden.
In mindestens einem Ausführungsbeispiel wird vor dem tatsächlichen Zugriff auf einen GPU-gebundenen Speicher 2120-2123 auf einen Eintrag in der Vorgabetabelle zugegriffen, der mit jedem Zugriff auf diesen Speicher assoziiert ist, was die folgenden Vorgänge bewirkt. Erstens werden lokale Anforderungen von GPU 2110-2113, die ihre Seite in GPU-Vorgaben finden, direkt an einen entsprechenden GPU-Speicher 2120-2123 weitergeleitet. Lokale Anfragen von einer GPU, die ihre Seite in der Host-Vorgabe finden, werden an den Prozessor 2105 weitergeleitet (z. B. über eine Hochgeschwindigkeitsverbindung wie oben beschrieben). In einem Ausführungsbeispiel schließen Anforderungen von Prozessor 2105, die eine angeforderte Seite in der Vorspannung des Host-Prozessors finden, eine Anforderung wie eine normale Speicherlesung ab. Alternativ können Anforderungen, die an eine GPU-vorgegebene Seite gerichtet sind, an die GPU 2110-2113 weitergeleitet werden. In mindestens einem Ausführungsbeispiel kann eine GPU dann eine Seite in eine Host-Prozessor-Vorgabe überführen, wenn sie die Seite gerade nicht verwendet. In mindestens einem Ausführungsbeispiel kann der Vorspannungszustand einer Seite entweder durch einen softwarebasierten Mechanismus, einen hardwareunterstützten softwarebasierten Mechanismus oder, für eine begrenzte Anzahl von Fällen, einen rein hardwarebasierten Mechanismus geändert werden.
Ein Mechanismus zum Ändern des Vorgabe-Zustands verwendet einen API-Aufruf (z. B. OpenCL), der wiederum den Gerätetreiber einer GPU aufruft, der wiederum eine Nachricht (oder einen Befehlsdeskriptor) an eine GPU sendet, die sie anweist, einen Vorgabe-Zustand zu ändern und für einige Übergänge eine Cache-Löschoperation in einem Host durchzuführen. In mindestens einem Ausführungsbeispiel wird die Cache-Löschoperation für einen Übergang von der Vorgabe des Host-Prozessors 2105 zur Vorgabe der GPU verwendet, aber nicht für einen entgegengesetzten Übergang.
In einem Ausführungsbeispiel wird die Cache-Kohärenz dadurch aufrechterhalten, dass GPU-vorgegebene Seiten vom Host-Prozessor 2105 vorübergehend nicht gecacht werden können. Um auf diese Seiten zuzugreifen, kann der Prozessor 2105 den Zugriff von der GPU 2110 anfordern, die den Zugriff sofort gewähren kann oder auch nicht. Um die Kommunikation zwischen Prozessor 2105 und GPU 2110 zu reduzieren, ist es daher vorteilhaft, sicherzustellen, dass GPU-vorgegebene Seiten diejenigen sind, die von einer GPU, aber nicht vom Host-Prozessor 2105 benötigt werden, und umgekehrt.
Hardware-Struktur(en) 1315 werden verwendet, um ein oder mehrere Ausführungsbeispiele durchzuführen. Details bezüglich der Hardwarestruktur(en) 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt.
22 zeigt exemplarische integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Verwendung von einem oder mehreren IP-Kernen gemäß verschiedenen hier beschriebenen Ausführungsbeispielen hergestellt werden können. Zusätzlich zu dem, was beispielhaft gezeigt ist, können in mindestens einem Ausführungsbeispiel weitere Logik und Schaltungen umfasst sein, einschließlich zusätzlicher Grafikprozessoren/Keme, peripherer Schnittstellensteuerungen oder allgemeiner Prozessorkerne.
22 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-a-Chip-Schaltung 2200 zeigt, die gemäß mindestens einem Ausführungsbeispiel unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. In mindestens einem Ausführungsbeispiel umfasst die integrierte Schaltung 2200 einen oder mehrere Anwendungsprozessor(en) 2205 (z. B. CPUs), mindestens einen Grafikprozessor 2210 und kann zusätzlich einen Bildprozessor 2215 und/oder einen Videoprozessor 2220 umfassen, von denen jeder ein modularer IP-Kern sein kann. In mindestens einem Ausführungsbeispiel umfasst die integrierte Schaltung 2200 eine Peripherie- oder Buslogik, einschließlich einer USB-Steuerung 2225, einer UART-Steuerung 2230, einer SPI/SDIO-Steuerung 2235 und einer I.sup.2S/I.sup.2C-Steuerung 2240. In mindestens einem Ausführungsbeispiel kann die integrierte Schaltung 2200 ein Anzeigegerät 2245 umfassen, das mit einer oder mehreren der folgenden Steuerungen gekoppelt ist: einer HDMI-Steuerung (High-Definition Multimedia Interface) 2250 und einer MIPI-Schnittstelle (Mobile Industry Processor Interface) 2255. In mindestens einem Ausführungsbeispiel kann der Speicher durch ein Flash-Speicher-Subsystem 2260 bereitgestellt werden, das einen Flash-Speicher und eine Flash-Speicher-Steuerung umfasst. In mindestens einem Ausführungsbeispiel kann die Speicherschnittstelle über eine Speichersteuerung 2265 für den Zugriff auf SDRAM- oder SRAM-Speichergeräte bereitgestellt werden. In mindestens einem Ausführungsbeispiel umfassen einige integrierte Schaltungen zusätzlich eine eingebettete Sicherheits-Engine 2270.
Inferenz- und/oder Trainingslogiken 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 in der integrierten Schaltung 2200 zum Inferenzieren oder für Vorhersageoperationen verwendet werden, die zumindest teilweise auf Gewichtungsparametern basieren, die unter Verwendung von Trainingsoperationen für ein neuronales Netzwerk, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen für ein neuronales Netzwerk berechnet wurden.
Die oben beschriebenen Techniken können beispielsweise zur Implementierung eines Systems für den Austausch von Objekten zwischen Mensch und Roboter verwendet werden. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
23A-23B zeigen exemplarische integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Verwendung von einem oder mehreren IP-Kernen gemäß verschiedenen hier beschriebenen Ausführungsbeispielen hergestellt werden können. Zusätzlich zu dem, was beispielhaft gezeigt ist, können in mindestens einem Ausführungsbeispiel weitere Logik und Schaltungen umfasst sein, einschließlich zusätzlicher Grafikprozessoren/Kerne, peripherer Schnittstellensteuerungen oder allgemeiner Prozessorkerne.
23A-23B sind Blockdiagramme, die exemplarische Grafikprozessoren zur Verwendung innerhalb eines SoCs gemäß den hier beschriebenen Ausführungsbeispielen zeigen. 23A zeigt einen exemplarischen Grafikprozessor 2310 einer integrierten System-on-a-Chip-Schaltung, der gemäß mindestens einem Ausführungsbeispiel unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. 23B zeigt einen weiteren beispielhaften Grafikprozessor 2340 einer integrierten System-on-a-Chip-Schaltung, die gemäß mindestens einem Ausführungsbeispiel unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 2310 aus 23A ein stromsparender Grafikprozessorkern. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 2340 von 23B ein Grafikprozessorkern mit höherer Leistung. In mindestens einem Ausführungsbeispiel kann jeder der Grafikprozessoren 2310, 2340 eine Variante des Grafikprozessors 2210 von 22 sein.
In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2310 einen Vertexprozessor 2305 und einen oder mehrere Fragmentprozessor(en) 2315A-2315N (z.B. 2315A, 2315B, 2315C, 2315D, bis 2315N-1 und 2315N). In mindestens einem Ausführungsbeispiel kann der Grafikprozessor 2310 verschiedene Schattierungsprogramme über eine separate Logik ausführen, so dass der Vertexprozessor 2305 für die Ausführung von Operationen für Schattierungsprogramme optimiert ist, während ein oder mehrere Fragmentprozessoren 2315A-2315N Schattierungsoperationen für Fragment- oder Pixel-Schattierungsprogramme ausführen (z. B. Pixel). In mindestens einem Ausführungsbeispiel führt der Vertex-Prozessor 2305 eine Vertex-Verarbeitungsstufe einer 3D-Grafik-Pipeline aus und generiert Primitive und Vertex-Daten. In mindestens einem Ausführungsbeispiel verwenden der/die Fragmentprozessor(en) 2315A-2315N die vom Vertexprozessor 2305 generierten Primitiv- und Vertexdaten, um einen Framebuffer zu erzeugen, der auf einem Anzeigegerät angezeigt wird. In mindestens einem Ausführungsbeispiel sind der/die Fragmentprozessor(en) 2315A-2315N für die Ausführung von Fragment-Schattierungsprogrammen optimiert, wie sie in einer OpenGL-API bereitgestellt werden, die zur Durchführung ähnlicher Operationen wie ein Pixel-Schattierungsprogramm verwendet werden können, wie es in einer Direct 3D-API bereitgestellt wird.
In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2310 zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 2320A-2320B, Cache(s) 2325A-2325B und Schaltungs-Verbindungseinheiten 2330A-2330B. In mindestens einem Ausführungsbeispiel stellen eine oder mehrere MMU(s) 2320A-2320B die Zuordnung von virtuellen zu physischen Adressen für den Grafikprozessor 2310 bereit, einschließlich für den Vertexprozessor 2305 und/oder den/die Fragmentprozessor(en) 2315A-2315N, die zusätzlich zu den in einem oder mehreren Cache(s) 2325A-2325B gespeicherten Vertex- oder Bild/Texturdaten auf im Speicher gespeicherte Vertex- oder Bild/Texturdaten verweisen können. In mindestens einem Ausführungsbeispiel können eine oder mehrere MMU(s) 2320A-2320B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs, die einem oder mehreren Anwendungsprozessoren 2205, Bildprozessoren 2215 und/oder Videoprozessoren 2220 von 22 zugeordnet sind, so dass jeder Prozessor 2205-2220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. In mindestens einem Ausführungsbeispiel ermöglichen eine oder mehrere Schaltungsverbindung(en) 2330A-2330B dem Grafikprozessor 2310 die Verbindung mit anderen IP-Kernen innerhalb des SoC, entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2340 eine oder mehrere MMU(s) 2320A-2320B, Caches 2325A-2325B und Schaltungsverbindungen 2330A-2330B des Grafikprozessors 2310 von 23A. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2340 einen oder mehrere Schattierungskerne 2355A-2355N (z. B. 2355A, 2355B, 2355C, 2355D, 2355E, 2355F bis 2355N-1 und 2355N), die eine einheitliche Schattierungskern-Architektur bereitstellen, bei der ein einziger Kern oder Typ oder Kern alle Arten von programmierbarem Schattierungscode ausführen kann, einschließlich Schattierungsprogramm-Code zur Implementierung von Vertex-Shadern, Fragment-Shadern und/oder Compute-Shadern. In mindestens einem Ausführungsbeispiel kann eine Anzahl von Schattierungskernen variieren. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2340 einen Inter-Core-Task-Manager 2345, der als Thread-Verteiler fungiert, um Ausführungs-Threads an einen oder mehrere Schattierungskerne 2355A-2355N und eine Kachel-Einheit 2358 zu verteilen, um Kachel-Operationen für das kachelbasierte Rendern zu beschleunigen, bei dem die Rendering-Operationen für eine Szene in den Bildraum unterteilt werden, um beispielsweise die lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Nutzung der internen Caches zu optimieren.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 in der integrierten Schaltung 23A und/oder 23B zum Inferieren oder Vorhersagen von Operationen verwendet werden, die zumindest teilweise auf Gewichtungsparametern basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
24A-24B zeigen eine weitere exemplarische Grafikprozessorlogik gemäß den hier beschriebenen Ausführungsbeispielen. 24A zeigt einen Grafikkern 2400, der in mindestens einem Ausführungsbeispiel in den Grafikprozessor 2210 von 22 eingeschlossen sein kann und in mindestens einem Ausführungsbeispiel ein einheitlicher Schattierungskern 2355A-2355N wie in 23B sein kann. 24B zeigt in mindestens einem Ausführungsbeispiel eine hochparallele allgemeine Grafikverarbeitungseinheit 2430, die für den Einsatz auf einem Multi-Chip-Modul geeignet ist.
In mindestens einem Ausführungsbeispiel umfasst der Grafikkern 2400 einen gemeinsam genutzten Befehlscache 2402, eine Textureinheit 2418 und einen Cache/gemeinsam genutzten Speicher 2420, die gemeinsam für Ausführungsressourcen innerhalb des Grafikkerns 2400 genutzt werden. In mindestens einem Ausführungsbeispiel kann der Grafikkern 2400 mehrere Abschnitte 2401A-2401N oder Partitionen für jeden Kern umfassen, und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 2400 umfassen. Die Abschnitte 2401A-2401N können eine Unterstützungslogik umfassen, einschließlich eines lokalen Befehlscaches 2404A-2404N, eines Thread-Planers 2406A-2406N, eines Thread-Verteilers 2408A-2408N und eines Satzes von Registern 2410A-2410N. In mindestens einem Ausführungsbeispiel können die Abschnitte 2401A-2401N einen Satz zusätzlicher Funktionseinheiten (AFUs 2412A-2412N), Gleitkommaeinheiten (FPU 2414A-2414N), ganzzahlige arithmetische Logikeinheiten (ALUs 2416-2416N), Adressberechnungseinheiten (ACU 2413A-2413N), doppeltgenaue Gleitkommaeinheiten (DPFPU 2415A-2415N) und Matrixverarbeitungseinheiten (MPU 2417A-2417N) umfassen.
In mindestens einem Ausführungsbeispiel können die FPUs 2414A-2414N Gleitkommaoperationen mit einfacher Genauigkeit (32 Bit) und halber Genauigkeit (16 Bit) durchführen, während die DPFPUs 2415A-2415N Gleitkommaoperationen mit doppelter Genauigkeit (64 Bit) durchführen. In mindestens einem Ausführungsbeispiel können die ALUs 2416A-2416N Integer-Operationen mit variabler Präzision bei 8-Bit-, 16-Bit- und 32-Bit-Präzision durchführen und für Operationen mit gemischter Präzision konfiguriert werden. In mindestens einem Ausführungsbeispiel können die MPUs 2417A-2417N auch für Matrixoperationen mit gemischter Genauigkeit konfiguriert sein, die Gleitkomma- und 8-Bit-Ganzzahloperationen mit halber Genauigkeit umfassen. In mindestens einem Ausführungsbeispiel können die MPUs 2417-2417N eine Vielzahl von Matrixoperationen durchführen, um Anwendungs-Frameworks für maschinelles Lernen zu beschleunigen, was die Unterstützung für eine beschleunigte allgemeine Matrix-Matrix-Multiplikation (GEMM) umfasst. In mindestens einem Ausführungsbeispiel können die AFUs 2412A-2412N zusätzliche logische Operationen durchführen, die von Gleitkomma- oder Ganzzahl-Einheiten nicht unterstützt werden, einschließlich trigonometrischer Operationen (z. B. Sinus, Kosinus usw.).
Inferenz- und/oder Trainingslogiken 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im Grafikkern 2400 zum Inferenzieren oder für Vorhersageoperationen verwendet werden, die zumindest teilweise auf Gewichtungsparametern basieren, die unter Verwendung von Trainingsoperationen für neuronale Netzwerke, Funktionen und/oder Architekturen von neuronalen Netzwerken oder hierin beschriebenen Anwendungsfällen für neuronale Netzwerke berechnet wurden.
Die oben beschriebenen Techniken können z. B. verwendet werden, um ein System für den Austausch von Objekten zwischen Mensch und Roboter zu implementieren. In einigen Beispielen wird die Inferenz- und/oder Trainingslogik verwendet, um ein neuronales Netzwerk zu erstellen, das darauf trainiert ist, einen Greifvorgang für ein Objekt zu erzeugen, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
24B zeigt eine allgemeine Verarbeitungseinheit (GPGPU) 2430, die so konfiguriert sein kann, dass in mindestens einem Ausführungsbeispiel hochparallele Rechenoperationen von einem Array von Grafikverarbeitungseinheiten durchgeführt werden können. In mindestens einem Ausführungsbeispiel kann die GPGPU 2430 direkt mit anderen Instanzen der GPGPU 2430 verbunden werden, um einen Multi-GPU-Cluster zu bilden und die Trainingsgeschwindigkeit für Deep Neural Networks zu verbessern. In mindestens einem Ausführungsbeispiel umfasst die GPGPU 2430 eine Host-Schnittstelle 2432, um eine Verbindung mit einem Host-Prozessor zu ermöglichen. In mindestens einem Ausführungsbeispiel handelt es sich bei der Host-Schnittstelle 2432 um eine PCI-Express-Schnittstelle. In mindestens einem Ausführungsbeispiel kann es sich bei der Host-Schnittstelle 2432 um eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur handeln. In mindestens einem Ausführungsbeispiel empfängt die GPGPU 2430 Befehle von einem Host-Prozessor und plant unter Verwendung eines globalen Planers 2434 die Verteilung von mit diesen Befehlen assoziierten Ausführungsthreads auf eine Reihe von Rechenclustern 2436A-2436H. In mindestens einem Ausführungsbeispiel nutzen die Rechencluster 2436A-2436H gemeinsam einen Cache-Speicher 2438. In mindestens einem Ausführungsbeispiel kann der Cache-Speicher 2438 als übergeordneter Cache für Cache-Speicher innerhalb von Rechenclustern 2436A-2436H dienen.
In mindestens einem Ausführungsbeispiel umfasst die GPGPU 2430 den Speicher 2444A-2444B, der mit den Rechenclustern 2436A-2436H über einen Satz von Speichersteuerungen 2442A-2442B gekoppelt ist. In mindestens einem Ausführungsbeispiel kann der Speicher 2444A-2444B verschiedene Arten von Speichergeräten umfassen, einschließlich Dynamic Random Access Memory (DRAM) oder Grafik-Direktzugriffsspeicher, wie synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafik-Doppeldatenraten-Speicher (GDDR).
In mindestens einem Ausführungsbeispiel umfassen die Rechencluster 2436A-2436H jeweils einen Satz von Grafikkernen, wie z. B. den Grafikkern 2400 von 24A, der mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten umfassen kann, die Rechenoperationen mit einer Reihe von Genauigkeiten durchführen können, die auch für maschinelle Lemberechnungen geeignet sind. Beispielsweise kann in mindestens einem Ausführungsbeispiel mindestens eine Teilmenge von Gleitkommaeinheiten in jedem der Rechencluster 2436A-2436H so konfiguriert sein, dass sie 16-Bit- oder 32-Bit-Gleitkommaoperationen durchführen, während eine andere Teilmenge von Gleitkommaeinheiten so konfiguriert sein kann, dass sie 64-Bit-Gleitkommaoperationen durchführen kann.
In mindestens einem Ausführungsbeispiel können mehrere Instanzen der GPGPU 2430 für den Betrieb als Rechencluster konfiguriert sein. In mindestens einem Ausführungsbeispiel variiert die von den Rechenclustern 2436A-2436H für die Synchronisation und den Datenaustausch verwendete Kommunikation zwischen den Ausführungsbeispielen. In mindestens einem Ausführungsbeispiel kommunizieren mehrere Instanzen der GPGPU 2430 über die Host-Schnittstelle 2432. In mindestens einem Ausführungsbeispiel umfasst die GPGPU 2430 einen E/A-Hub 2439, der die GPGPU 2430 mit einer GPU-Verbindung 2440 koppelt, die eine direkte Verbindung zu anderen Instanzen der GPGPU 2430 ermöglicht. In mindestens einem Ausführungsbeispiel ist die GPU-Verbindung 2440 mit einer dedizierten GPU-zu-GPU-Brücke gekoppelt, die die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 2430 ermöglicht. In mindestens einem Ausführungsbeispiel ist die GPU-Verbindung 2440 mit einem Hochgeschwindigkeits-Interconnect gekoppelt, um Daten an andere GPGPUs oder Parallelprozessoren zu senden und zu empfangen. In mindestens einem Ausführungsbeispiel befinden sich mehrere GPGPU 2430 in separaten Datenverarbeitungssystemen und kommunizieren über ein Netzwerkgerät, das über die Host-Schnittstelle 2432 zugänglich ist. In mindestens einem Ausführungsbeispiel kann die GPU-Verbindung 2440 so konfiguriert sein, dass sie zusätzlich oder alternativ zur Host-Schnittstelle 2432 eine Verbindung zu einem Host-Prozessor ermöglicht.
In mindestens einem Ausführungsbeispiel kann die GPGPU 2430 zum Trainieren neuronaler Netzwerke konfiguriert sein. In mindestens einem Ausführungsbeispiel kann GPGPU 2430 innerhalb einer Inferenzplattform verwendet werden. In mindestens einem Ausführungsbeispiel, in dem GPGPU 2430 zum Inferenzieren verwendet wird, kann GPGPU weniger Rechencluster 2436A-2436H umfassen, als wenn GPGPU zum Trainieren eines neuronalen Netzwerks verwendet wird. In mindestens einem Ausführungsbeispiel kann sich die mit dem Speicher 2444A-2444B assoziierte Speichertechnologie zwischen Konfigurationen zum Inferenzieren und zum Trainieren unterscheiden, wobei den Trainingskonfigurationen Speichertechnologien mit höherer Bandbreite zugewiesen werden. In mindestens einem Ausführungsbeispiel kann die Konfiguration der GPGPU 2430 zum Inferenzieren bestimmte Anweisungen unterstützen. Beispielsweise kann in mindestens einem Ausführungsbeispiel eine Inferenzierungskonfiguration Unterstützung für einen oder mehrere 8-Bit-Ganzzahlpunktprodukt-Befehle bereitstellen, die bei Inferenzierungsoperationen zum Einsatz neuronaler Netzwerke verwendet werden können.
Die Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 in der GPGPU 2430 zum Inferenzieren oder für Vorhersageoperationen verwendet werden, die zumindest teilweise auf Gewichtungsparametern basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System für den Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
25 zeigt ein Blockdiagramm, das ein Computersystem 2500 gemäß mindestens einem Ausführungsbeispiel zeigt. In mindestens einem Ausführungsbeispiel umfasst das Rechensystem 2500 ein Verarbeitungssubsystem 2501 mit einem oder mehreren Prozessoren 2502 und einem Systemspeicher 2504, die über einen Verbindungspfad kommunizieren, der einen Speicher-Hub 2505 umfassen kann. In mindestens einem Ausführungsbeispiel kann der Speicher-Hub 2505 eine separate Komponente innerhalb einer Chipsatzkomponente sein oder in einen oder mehrere Prozessor(en) 2502 integriert sein. In mindestens einem Ausführungsbeispiel ist der Speicher-Hub 2505 mit einem E/A-Subsystem 2511 über eine Kommunikationsverbindung 2506 gekoppelt. In mindestens einem Ausführungsbeispiel umfasst das E/A-Subsystem 2511 einen E/A-Hub 2507, der es dem Rechensystem 2500 ermöglichen kann, Eingaben von einem oder mehreren Geräten 2508 zu empfangen. In mindestens einem Ausführungsbeispiel kann der E/A-Hub 2507 eine Anzeigensteuerung, die in einem oder mehreren Prozessor(en) 2502 umfasst sein kann, in die Lage versetzen, Ausgaben für ein oder mehrere Anzeigegeräte 2510A bereitzustellen. In mindestens einem Ausführungsbeispiel kann ein oder mehrere mit dem E/A-Hub 2507 gekoppelte(s) Anzeigegerät(e) 2510A ein lokales, internes oder eingebettetes Anzeigegerät umfassen.
In mindestens einem Ausführungsbeispiel umfasst das Verarbeitungssubsystem 2501 einen oder mehrere Parallelprozessoren 2512, die über einen Bus oder eine andere Kommunikationsverbindung 2513 mit dem Speicher-Hub 2505 gekoppelt sind. In mindestens einem Ausführungsbeispiel kann es sich bei der Verbindung 2513 um eine beliebige Anzahl von auf Standards basierenden Kommunikationsverbindungstechnologien oder -protokollen handeln, wie z. B. PCI Express, aber nicht darauf beschränkt, oder um eine herstellerspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur. In mindestens einem Ausführungsbeispiel bilden ein oder mehrere Parallelprozessor(en) 2512 ein rechenintensives Parallel- oder Vektorverarbeitungssystem, das eine große Anzahl von Verarbeitungskemen und/oder Verarbeitungsclustern umfassen kann, wie z. B. einen Prozessor mit vielen integrierten Kernen (MIC). In mindestens einem Ausführungsbeispiel bilden ein oder mehrere Parallelprozessor(en) 2512 ein Grafikverarbeitungs-Subsystem, das Pixel an eines oder mehrere Anzeigegeräte 2510A ausgeben kann, die über einen E/A-Hub 2507 gekoppelt sind. In mindestens einem Ausführungsbeispiel kann ein oder mehrere Parallelprozessor(en) 2512 auch eine Anzeigensteuerung und eine Anzeigeschnittstelle (nicht gezeigt) umfassen, um eine direkte Verbindung mit einem oder mehreren Anzeigegerät(en) 2510B zu ermöglichen.
In mindestens einem Ausführungsbeispiel kann eine Systemspeichereinheit 2514 mit dem E/A-Hub 2507 verbunden werden, um einen Speichermechanismus für das Rechensystem 2500 bereitzustellen. In mindestens einem Ausführungsbeispiel kann ein E/A-Switch 2516 verwendet werden, um einen Schnittstellenmechanismus bereitzustellen, um Verbindungen zwischen dem E/A-Hub 2507 und anderen Komponenten zu ermöglichen, wie z. B. einem Netzwerkadapter 2518 und/oder einem drahtlosen Netzwerkadapter 2519, die in die Plattform integriert werden können, und verschiedenen anderen Geräten, die über ein oder mehrere Add-in-Geräte 2520 hinzugefügt werden können. In mindestens einem Ausführungsbeispiel kann der Netzwerkadapter 2518 ein Ethernet-Adapter oder ein anderer kabelgebundener Netzwerkadapter sein. In mindestens einem Ausführungsbeispiel kann der drahtlose Netzwerkadapter 2519 eines oder mehrere der folgenden Geräte umfassen: Wi-Fi, Bluetooth, Near Field Communication (NFC) oder andere Netzwerkgeräte, die ein oder mehrere drahtlose Funkgeräte umfassen.
In mindestens einem Ausführungsbeispiel kann das Rechengerät 2500 weitere, nicht explizit dargestellte Komponenten umfassen, einschließlich USB- oder andere Anschlüsse, optische Speicher, Videoaufnahmegeräte und dergleichen, die ebenfalls mit dem E/A-Hub 2507 verbunden sein können. In mindestens einem Ausführungsbeispiel können Verbindungspfade, die verschiedene Komponenten in 25 miteinander verbinden, unter Verwendung beliebiger geeigneter Protokolle implementiert werden, wie z.B. auf PCI (Peripheral Component Interconnect) basierende Protokolle (z.B. PCI-Express) oder andere Bus- oder Punkt-zu-Punkt-Kommunikationsschnittstellen und/oder Protokolle, wie z.B. NV-Link-Hochgeschwindigkeitsverbindung oder Verbindungsprotokolle.
In mindestens einem Ausführungsbeispiel umfassen ein oder mehrere Parallelprozessor(en) 2512 eine Schaltungsanordnung, die für die Grafik- und Videoverarbeitung optimiert ist, z. B. eine Videoausführungsschaltung, und stellen eine Grafikverarbeitungseinheit (GPU) dar. In mindestens einem Ausführungsbeispiel enthalten ein oder mehrere Parallelprozessor(en) 2512 eine Schaltungsanordnung, die für die allgemeine Verarbeitung optimiert ist. In mindestens einem Ausführungsbeispiel können Komponenten des Rechnersystems 2500 mit einem oder mehreren anderen Systemelementen auf einer einzigen integrierten Schaltung integriert sein. Beispielsweise können in mindestens einem Ausführungsbeispiel ein oder mehrere Parallelprozessor(en) 2512, Speicher-Hub 2505, Prozessor(en) 2502 und E/A-Hub 2507 in eine System-on-a-Chip (SoC)-integrierte Schaltung integriert werden. In mindestens einem Ausführungsbeispiel können die Komponenten des Rechensystems 2500 in ein einziges Gehäuse integriert werden, um eine System-in-Package-Konfiguration (SIP) zu bilden. In mindestens einem Ausführungsbeispiel kann mindestens ein Teil der Komponenten des Rechensystems 2500 in ein Multi-Chip-Modul (MCM) integriert werden, das mit anderen Multi-Chip-Modulen zu einem modularen Rechensystem zusammengeschaltet werden kann.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im System FIG. 2500 zum Inferenzieren oder Vorhersagen verwendet werden, die zumindest teilweise auf Gewichtsparametem basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
PROZESSOREN
26A zeigt einen Parallelprozessor 2600 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel können verschiedene Komponenten des Parallelprozessors 2600 unter Verwendung von einem oder mehreren Geräten mit integrierter Schaltung, wie z. B. programmierbaren Prozessoren, anwendungsspezifischen integrierten Schaltungen (ASICs) oder feldprogrammierbaren Gate Arrays (FPGA), implementiert werden. In mindestens einem Ausführungsbeispiel ist der dargestellte Parallelprozessor 2600 eine Variante eines oder mehrerer Parallelprozessoren 2512, die in 25 gemäß einem exemplarischen Ausführungsbeispiel dargestellt sind.
In mindestens einem Ausführungsbeispiel umfasst der Parallelprozessor 2600 eine Parallelverarbeitungseinheit 2602. In mindestens einem Ausführungsbeispiel umfasst die Parallelverarbeitungseinheit 2602 eine E/A-Einheit 2604, die die Kommunikation mit anderen Geräten, einschließlich anderer Instanzen der Parallelverarbeitungseinheit 2602, ermöglicht. In mindestens einem Ausführungsbeispiel kann die E/A-Einheit 2604 direkt mit anderen Geräten verbunden werden. In mindestens einem Ausführungsbeispiel ist die E/A-Einheit 2604 unter Verwendung einer Hub- oder Switch-Schnittstelle, wie z. B. dem Memory Hub 2505, mit anderen Geräten verbunden. In mindestens einem Ausführungsbeispiel bilden die Verbindungen zwischen dem E/A-Hub 2505 und der E/A-Einheit 2604 eine Kommunikationsverbindung 2513. In mindestens einem Ausführungsbeispiel ist die E/A-Einheit 2604 mit einer Host-Schnittstelle 2606 und einer Speicher-Crossbar 2616 verbunden, wobei die Host-Schnittstelle 2606 Befehle zur Durchführung von Verarbeitungsoperationen und die Speicher-Crossbar 2616 Befehle zur Durchführung von Speicheroperationen empfängt.
In mindestens einem Ausführungsbeispiel, wenn die Host-Schnittstelle 2606 einen Befehlspuffer über die I/O-Einheit 2604 empfängt, kann die Host-Schnittstelle 2606 Arbeitsoperationen zur Durchführung dieser Befehle an ein Frontend 2608 leiten. In mindestens einem Ausführungsbeispiel ist das Front-End 2608 mit einem Planer 2610 gekoppelt, der so konfiguriert ist, dass er Befehle oder andere Arbeitsaufgaben an ein Verarbeitungscluster-Array 2612 verteilt. In mindestens einem Ausführungsbeispiel stellt der Planer 2610 sicher, dass das Verarbeitungscluster-Array 2612 ordnungsgemäß konfiguriert ist und sich in einem gültigen Zustand befindet, bevor Aufgaben an das Verarbeitungscluster-Array 2612 des Verarbeitungscluster-Arrays 2612 verteilt werden. In mindestens einem Ausführungsbeispiel ist der Planer 2610 über eine Firmware-Logik implementiert, die auf einem Mikrocontroller ausgeführt wird. In mindestens einem Ausführungsbeispiel ist der mikrocontrollerimplementierte Planer 2610 so konfigurierbar, dass er komplexe Planungs- und Arbeitsverteilungsoperationen mit grober und feiner Granularität durchführen kann, was eine schnelle Vorkaufsberechtigung und Kontextumschaltung von Threads ermöglicht, die auf dem Processing Array 2612 ausgeführt werden. In mindestens einem Ausführungsbeispiel kann die Host-Software Arbeitslasten für die Planung auf dem Array 2612 über eine von mehreren Grafikverarbeitungs-Türglocken nachweisen. In mindestens einem Ausführungsbeispiel können Arbeitslasten dann automatisch über das verarbeitende Array 2612 durch die Logik des Planers 2610 innerhalb eines Mikrocontrollers, der den Planer 2610 umfasst, verteilt werden.
In mindestens einem Ausführungsbeispiel kann das Verarbeitungscluster-Array 2612 bis zu „N“ Verarbeitungscluster umfassen (z.B. Cluster 2614A, Cluster 2614B, bis Cluster 2614N). In mindestens einem Ausführungsbeispiel kann jeder Cluster 2614A-2614N des Verarbeitungscluster-Arrays 2612 eine große Anzahl von gleichzeitigen Threads ausführen. In mindestens einem Ausführungsbeispiel kann der Planer 2610 den Clustern 2614A-2614N des Verarbeitungscluster-Arrays 2612 Arbeit unter Verwendung verschiedener Allokations- und/oder Arbeitsverteilungsalgorithmen zuweisen, die in Abhängigkeit von der Arbeitslast variieren können, die für jede Art von Programm oder Berechnung anfällt. In mindestens einem Ausführungsbeispiel kann die Planung dynamisch durch den Planer 2610 erfolgen oder teilweise durch die Compilerlogik während der Kompilierung der Programmlogik, die für die Ausführung durch das Verarbeitungscluster-Array 2612 konfiguriert ist, unterstützt werden. In mindestens einem Ausführungsbeispiel können verschiedene Cluster 2614A-2614N des Verarbeitungscluster-Arrays 2612 für die Verarbeitung verschiedener Programmtypen oder für die Durchführung verschiedener Rechentypen allokiert werden.
In mindestens einem Ausführungsbeispiel kann das Verarbeitungscluster-Array 2612 so konfiguriert sein, dass es verschiedene Arten von parallelen Verarbeitungsvorgängen durchführt. In mindestens einem Ausführungsbeispiel ist das Verarbeitungscluster-Array 2612 so konfiguriert, dass es allgemeine parallele Rechenoperationen durchführt. Zum Beispiel kann in mindestens einem Ausführungsbeispiel das Verarbeitungscluster-Array 2612 eine Logik zur Ausführung von Verarbeitungsaufgaben umfassen, die das Filtern von Video- und/oder Audiodaten, die Durchführung von Modellierungsoperationen, einschließlich physikalischer Operationen, und die Durchführung von Datentransformationen umfasst.
In mindestens einem Ausführungsbeispiel ist das Verarbeitungscluster-Array 2612 so konfiguriert, dass es parallele Grafikverarbeitungsoperationen durchführt. In mindestens einem Ausführungsbeispiel kann das Verarbeitungscluster-Array 2612 zusätzliche Logik umfassen, um die Ausführung solcher Grafikverarbeitungsoperationen zu unterstützen, einschließlich, aber nicht beschränkt auf Textur-Sampling-Logik, um Texturoperationen durchzuführen, sowie Tesselations-Logik und andere Vertex-Verarbeitungslogik. In mindestens einem Ausführungsbeispiel kann das Verarbeitungscluster-Array 2612 so konfiguriert sein, dass es grafikverarbeitungsbezogene Schattierungsprogramme ausführt, wie z. B. Vertex-Schattierer, Tessellierungs-Schattierer, Geometrie-Schattierer und Pixel-Schattierer, aber nicht darauf beschränkt. In mindestens einem Ausführungsbeispiel kann die Parallelverarbeitungseinheit 2602 über die System-E/A-Einheit 2604 Daten aus dem Systemspeicher zur Verarbeitung übertragen. In mindestens einem Ausführungsbeispiel können die übertragenen Daten während der Verarbeitung im On-Chip-Speicher (z. B. im Parallelprozessorspeicher 2622) gespeichert und dann in den Systemspeicher zurückgeschrieben werden.
In mindestens einem Ausführungsbeispiel, wenn die Parallelverarbeitungseinheit 2602 zur Durchführung der Grafikverarbeitung verwendet wird, kann der Planer 2610 so konfiguriert sein, dass er eine Arbeitslast in annähernd gleich große Aufgaben unterteilt, um eine bessere Verteilung der Grafikverarbeitungsvorgänge auf mehrere Cluster 2614A-2614N des Verarbeitungscluster-Arrays 2612 zu ermöglichen. In mindestens einem Ausführungsbeispiel können Teile des Verarbeitungscluster-Arrays 2612 so konfiguriert sein, dass sie verschiedene Verarbeitungstypen ausführen. Beispielsweise kann in mindestens einem Ausführungsbeispiel ein erster Teil konfiguriert sein, um Vertex-Shading und Topologie-Generierung durchzuführen, ein zweiter Teil kann konfiguriert sein, um Tesselation und Geometrie-Shading durchzuführen, und ein dritter Teil kann konfiguriert sein, um Pixel-Shading oder andere Bildschirmraum-Operationen durchzuführen, um ein gerendertes Bild für die Anzeige zu erzeugen. In mindestens einem Ausführungsbeispiel können Zwischendaten, die von einem oder mehreren Clustern 2614A-2614N erzeugt wurden, in Puffern gespeichert werden, damit Zwischendaten zur weiteren Verarbeitung zwischen den Clustern 2614A-2614N übertragen werden können.
In mindestens einem Ausführungsbeispiel kann das Verarbeitungscluster-Array 2612 über den Planer 2610, der Befehle zur Definition von Verarbeitungsaufgaben vom Frontend 2608 erhält, auszuführende Verarbeitungsaufgaben empfangen. In mindestens einem Ausführungsbeispiel können die Verarbeitungsaufgaben Indizes der zu verarbeitenden Daten umfassen, z. B. Oberflächen- (Patch-) Daten, Primitivdaten, Vertexdaten und/oder Pixeldaten, sowie Zustandsparameter und Befehle, die definieren, wie die Daten verarbeitet werden sollen (z. B. welches Programm ausgeführt werden soll). In mindestens einem Ausführungsbeispiel kann der Planer 2610 so konfiguriert sein, dass er Indizes holt, die Aufgaben entsprechen, oder er kann Indizes vom Front-End 2608 empfangen. In mindestens einem Ausführungsbeispiel kann das Front-End 2608 so konfiguriert sein, dass sichergestellt wird, dass das Verarbeitungscluster-Array 2612 in einen gültigen Zustand versetzt wird, bevor eine durch eingehende Befehlspuffer (z. B. Batch-Puffer, Push-Puffer usw.) spezifizierte Arbeitslast eingeleitet wird.
In mindestens einem Ausführungsbeispiel kann jede von einer oder mehreren Instanzen der Parallelverarbeitungseinheit 2602 mit dem Parallelprozessorspeicher 2622 gekoppelt sein. In mindestens einem Ausführungsbeispiel kann auf den Parallelprozessorspeicher 2622 über die Speicher-Crossbar 2616 zugegriffen werden, die Speicheranforderungen vom Verarbeitungscluster-Array 2612 sowie von der I/O-Einheit 2604 empfangen kann. In mindestens einem Ausführungsbeispiel kann die Speicher-Crossbar 2616 über eine Speicherschnittstelle 2618 auf den parallelen Prozessorspeicher 2622 zugreifen. In mindestens einem Ausführungsbeispiel kann die Speicherschnittstelle 2618 mehrere Partitionseinheiten umfassen (z.B. Partitionseinheit 2620A, Partitionseinheit 2620B bis Partitionseinheit 2620N), die jeweils mit einem Teil (z.B. Speichereinheit) des Parallelprozessorspeichers 2622 gekoppelt sein können. In mindestens einem Ausführungsbeispiel ist eine Anzahl von Partitionseinheiten 2620A-2620N so konfiguriert, dass sie einer Anzahl von Speichereinheiten entspricht, so dass eine erste Partitionseinheit 2620A eine entsprechende erste Speichereinheit 2624A hat, eine zweite Partitionseinheit 2620B eine entsprechende Speichereinheit 2624B hat und eine N-te Partitionseinheit 2620N eine entsprechende N-te Speichereinheit 2624N hat. In mindestens einem Ausführungsbeispiel kann eine Anzahl von Partitionseinheiten 2620A-2620N nicht gleich einer Anzahl von Speichergeräten sein.
In mindestens einem Ausführungsbeispiel können die Speichereinheiten 2624A-2624N verschiedene Arten von Speichergeräten umfassen, einschließlich Dynamic Random Access Memory (DRAM) oder Grafik-Direktzugriffsspeicher, wie synchroner Grafik-Direktzugriffsspeicher (SGRAM), einschließlich Grafik-Doppeldatenraten-Speicher (GDDR). In mindestens einem Ausführungsbeispiel können die Speichereinheiten 2624A-2624N auch 3D-Stapelspeicher umfassen, einschließlich, aber nicht beschränkt auf Hochbreitenspeicher (HBM). In mindestens einem Ausführungsbeispiel können Rendering-Ziele, wie Einzelbildpuffer oder Texturkarten, über die Speichereinheiten 2624A-2624N hinweg gespeichert werden, so dass die Partitionseinheiten 2620A-2620N Teile jedes Rendering-Ziels parallel schreiben können, um die verfügbare Bandbreite des Parallelprozessorspeichers 2622 effizient zu verwenden. In mindestens einem Ausführungsbeispiel kann eine lokale Instanz des parallelen Prozessorspeichers 2622 zugunsten eines vereinheitlichten Designs ausgeschlossen werden, das den Systemspeicher in Verbindung mit dem lokalen Cache-Speicher nutzt.
In mindestens einem Ausführungsbeispiel kann jeder der Cluster 2614A-2614N des Verarbeitungscluster-Arrays 2612 Daten verarbeiten, die in jede der Speichereinheiten 2624A-2624N innerhalb des Parallelprozessorspeichers 2622 geschrieben werden. In mindestens einem Ausführungsbeispiel kann die Speicher-Crossbar 2616 so konfiguriert sein, dass sie eine Ausgabe jedes Clusters 2614A-2614N an eine beliebige Partitionseinheit 2620A-2620N oder an einen anderen Cluster 2614A-2614N überträgt, der zusätzliche Verarbeitungsoperationen an einer Ausgabe durchführen kann. In mindestens einem Ausführungsbeispiel kann jeder Cluster 2614A-2614N mit der Speicherschnittstelle 2618 über die Speicher-Crossbar 2616 kommunizieren, um von verschiedenen externen Speichergeräten zu lesen oder in diese zu schreiben. In mindestens einem Ausführungsbeispiel verfügt die Speicher-Crossbar 2616 über eine Verbindung zur Speicherschnittstelle 2618, um mit der E/A-Einheit 2604 zu kommunizieren, sowie über eine Verbindung zu einer lokalen Instanz des Parallelverarbeitungsspeichers 2622, so dass die Verarbeitungseinheiten innerhalb der verschiedenen Verarbeitungscluster 2614A-2614N mit dem Systemspeicher oder einem anderen Speicher kommunizieren können, der nicht lokal zur Parallelverarbeitungseinheit 2602 gehört. In mindestens einem Ausführungsbeispiel kann die Speicher-Crossbar 2616 virtuelle Kanäle verwenden, um Verkehrsströme zwischen Clustern 2614A-2614N und Partitionseinheiten 2620A-2620N zu trennen.
In mindestens einem Ausführungsbeispiel können mehrere Instanzen der Parallelverarbeitungseinheit 2602 auf einer einzigen Erweiterungskarte bereitgestellt werden, oder es können mehrere Erweiterungskarten miteinander verbunden werden. In mindestens einem Ausführungsbeispiel können verschiedene Instanzen der Parallelverarbeitungseinheit 2602 so konfiguriert sein, dass sie zusammenarbeiten, selbst wenn die verschiedenen Instanzen eine unterschiedliche Anzahl von Verarbeitungskernen, unterschiedliche Mengen an lokalem Parallelprozessorspeicher und/oder andere Konfigurationsunterschiede aufweisen. Beispielsweise können in mindestens einem Ausführungsbeispiel einige Instanzen der Parallelverarbeitungseinheit 2602 im Vergleich zu anderen Instanzen Gleitkommaeinheiten mit höherer Präzision umfassen. In mindestens einem Ausführungsbeispiel können Systeme, die eine oder mehrere Instanzen der Parallelverarbeitungseinheit 2602 oder des Parallelprozessors 2600 enthalten, in einer Vielzahl von Konfigurationen und Formfaktoren implementiert werden, einschließlich, aber nicht beschränkt auf Desktop-, Laptop- oder Handheld-PCs, Server, Workstations, Spielkonsolen und/oder eingebettete Systeme.
26B zeigt ein Blockdiagramm einer Partitionseinheit 2620 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist die Partitionseinheit 2620 eine Instanz einer der Partitionseinheiten 2620A-2620N aus 26A. In mindestens einem Ausführungsbeispiel umfasst die Partitionseinheit 2620 einen L2-Cache 2621, eine Framebildpuffer-Schnittstelle 2625 und eine ROP 2626 (Rasteroperationseinheit). Der L2-Cache 2621 ist ein Lese-/Schreib-Cache, der so konfiguriert ist, dass er von der Speicher-Crossbar 2616 und der ROP 2626 empfangene Lade- und Speicheroperationen durchführt. In mindestens einem Ausführungsbeispiel werden Fehlversuche beim Lesen und dringende Rückschreibanforderungen vom L2-Cache 2621 an die Framebuffer-Schnittstelle 2625 zur Verarbeitung ausgegeben. In mindestens einem Ausführungsbeispiel können Aktualisierungen auch über die Framebuffer-Schnittstelle 2625 zur Verarbeitung an einen Einzelbildpuffer gesendet werden. In mindestens einem Ausführungsbeispiel ist die Framebuffer-Schnittstelle 2625 mit einer der Speichereinheiten im Parallelprozessorspeicher verbunden, wie z.B. den Speichereinheiten 2624A-2624N von 26 (z.B. im Parallelprozessorspeicher 2622).
In mindestens einem Ausführungsbeispiel ist ROP 2626 eine verarbeitende Einheit, die Rasteroperationen wie Schablone, Z-Test, Blending und ähnliches durchführt. In mindestens einem Ausführungsbeispiel gibt ROP 2626 dann verarbeitete Grafikdaten aus, die im Grafikspeicher abgelegt werden. In mindestens einem Ausführungsbeispiel umfasst ROP 2626 eine Komprimierungslogik zur Komprimierung von Tiefen- oder Farbdaten, die in den Speicher geschrieben werden, und zur Dekomprimierung von Tiefen- oder Farbdaten, die aus dem Speicher gelesen werden. In mindestens einem Ausführungsbeispiel kann die Komprimierungslogik eine verlustfreie Komprimierungslogik sein, die unter Verwendung von einem oder mehreren von mehreren Komprimierungsalgorithmen arbeitet. Die Art der von ROP 2626 durchgeführten Komprimierung kann basierend auf den statistischen Eigenschaften der zu komprimierenden Daten variieren. In mindestens einem Ausführungsbeispiel wird beispielsweise eine Delta-Farbkomprimierung für Tiefen- und Farbdaten auf einer Kachelbasis durchgeführt.
In mindestens einem Ausführungsbeispiel ist ROP 2626 in jedem Verarbeitungscluster (z. B. Cluster 2614A-2614N von 26) statt in der Partitionseinheit 2620 umfasst. In mindestens einem Ausführungsbeispiel werden Lese- und Schreibanforderungen für Pixeldaten über die Speicher-Crossbar 2616 anstelle von Pixelfragmentdaten übertragen. In mindestens einem Ausführungsbeispiel können verarbeitete Grafikdaten auf einem Ausführungsbeispiel, wie einem von einem oder mehreren Ausführungsbeispielen 2510 von 25, zur weiteren Verarbeitung durch Prozessor(en) 2502 weitergeleitet werden, oder zur weiteren Verarbeitung durch eine der Verarbeitungseinheiten innerhalb des Parallelprozessors 2600 von 26A weitergeleitet werden.
26C zeigt ein Blockdiagramm eines Verarbeitungsclusters 2614 innerhalb einer Parallelverarbeitungseinheit gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist ein Verarbeitungscluster eine Instanz von einem der Verarbeitungscluster 2614A-2614N von 26. In mindestens einem Ausführungsbeispiel kann der Verarbeitungscluster 2614 so konfiguriert sein, dass viele Threads parallel ausgeführt werden, wobei sich der Begriff „Thread“ auf eine Instanz eines bestimmten Programms bezieht, das auf einem bestimmten Satz von Eingabedaten ausgeführt wird. In mindestens einem Ausführungsbeispiel werden SIMD-Befehlsausgabetechniken (Single-Instruction, Multiple-Data) verwendet, um die parallele Ausführung einer großen Anzahl von Threads zu unterstützen, ohne mehrere unabhängige Befehlseinheiten bereitzustellen. In mindestens einem Ausführungsbeispiel werden Single-Instruction-Multiple-Thread (SIMT)-Techniken verwendet, um die parallele Ausführung einer großen Anzahl von im Allgemeinen synchronisierten Threads zu unterstützen, unter Verwendung einer gemeinsamen Befehlseinheit, die so konfiguriert ist, dass sie Befehle an einen Satz von Verarbeitungs-Engines innerhalb jedes der Verarbeitungscluster ausgibt.
In mindestens einem Ausführungsbeispiel kann der Betrieb des Verarbeitungsclusters 2614 über einen Pipeline-Manager 2632 gesteuert werden, der die Verarbeitungsaufgaben auf parallele SIMT-Prozessoren verteilt. In mindestens einem Ausführungsbeispiel empfängt der Pipeline-Manager 2632 Anweisungen vom Planer 2610 von 26 und verwaltet die Ausführung dieser Anweisungen über einen Grafik-Multiprozessor 2634 und/oder eine Textureinheit 2636. In mindestens einem Ausführungsbeispiel ist der Grafikmultiprozessor 2634 ein exemplarisches Beispiel für einen SIMT-Parallelprozessor. In mindestens einem Ausführungsbeispiel können jedoch verschiedene Arten von SIMT-Parallelprozessoren mit unterschiedlichen Architekturen im Verarbeitungscluster 2614 umfasst sein. In mindestens einem Ausführungsbeispiel können eine oder mehrere Instanzen des Grafik-Multiprozessors 2634 in einem Verarbeitungscluster 2614 umfasst sein. In mindestens einem Ausführungsbeispiel kann der Grafikmultiprozessor 2634 Daten verarbeiten, und eine Daten-Crossbar 2640 kann verwendet werden, um verarbeitete Daten an eines von mehreren möglichen Zielen, einschließlich anderer Schattierungseinheiten, zu verteilen. In mindestens einem Ausführungsbeispiel kann der Pipeline-Manager 2632 die Verteilung verarbeiteter Daten erleichtern, indem er Ziele für verarbeitete Daten spezifiziert, die über die Daten-Crossbar 2640 verteilt werden sollen.
In mindestens einem Ausführungsbeispiel kann jeder Grafik-Multiprozessor 2634 innerhalb des Verarbeitungsclusters 2614 einen identischen Satz funktionaler Ausführungslogik umfassen (z. B. arithmetische Logikeinheiten, Lastspeichereinheiten usw.). In mindestens einem Ausführungsbeispiel kann die funktionale Ausführungslogik in einer Pipeline konfiguriert sein, in der neue Befehle ausgegeben werden können, bevor vorherige Befehle abgeschlossen sind. In mindestens einem Ausführungsbeispiel unterstützt die funktionale Ausführungslogik eine Vielzahl von Funktionalitäten, darunter Ganzzahl- und Gleitkommaarithmetik, Vergleichsoperationen, boolesche Operationen, Bitverschiebung und die Berechnung verschiedener algebraischer Funktionen. In mindestens einem Ausführungsbeispiel kann dieselbe Hardware mit funktionalen Einheiten genutzt werden, um verschiedene Operationen durchzuführen, und es kann eine beliebige Kombination von funktionalen Einheiten vorhanden sein.
In mindestens einem Ausführungsbeispiel bilden die an den Verarbeitungscluster 2614 übertragenen Anweisungen einen Thread. In mindestens einem Ausführungsbeispiel ist ein Satz von Threads, die über einen Satz von parallelen Verarbeitungs-Engines ausgeführt werden, eine Thread-Gruppe. In mindestens einem Ausführungsbeispiel führt die Thread-Gruppe ein Programm auf verschiedenen Eingabedaten aus. In mindestens einem Ausführungsbeispiel kann jeder Thread innerhalb einer Thread-Gruppe einer anderen Verarbeitungs-Engine innerhalb eines Grafik-Multiprozessors 2634 zugewiesen werden. In mindestens einem Ausführungsbeispiel kann eine Thread-Gruppe weniger Threads umfassen als eine Anzahl von Verarbeitungs-Engines innerhalb des Grafik-Multiprozessors 2634. In mindestens einem Ausführungsbeispiel kann, wenn eine Thread-Gruppe weniger Threads als eine Anzahl von Verarbeitungs-Engines umfasst, eine oder mehrere der Verarbeitungs-Engines während der Zyklen, in denen diese Thread-Gruppe verarbeitet wird, im Leerlauf sein. In mindestens einem Ausführungsbeispiel kann eine Thread-Gruppe auch mehr Threads umfassen als eine Anzahl von Verarbeitungs-Engines im Grafik-Multiprozessor 2634. In mindestens einem Ausführungsbeispiel kann, wenn eine Thread-Gruppe mehr Threads umfasst als die Anzahl der Verarbeitungs-Engines innerhalb des Grafik-Multiprozessors 2634, die Verarbeitung über aufeinanderfolgende Taktzyklen erfolgen. In mindestens einem Ausführungsbeispiel können mehrere Thread-Gruppen gleichzeitig auf einem Grafik-Multiprozessor 2634 ausgeführt werden.
In mindestens einem Ausführungsbeispiel umfasst der Grafikmultiprozessor 2634 einen internen Cache-Speicher zur Durchführung von Lade- und Speicheroperationen. In mindestens einem Ausführungsbeispiel kann der Grafik-Multiprozessor 2634 auf einen internen Cache verzichten und einen Cache-Speicher (z. B. L1-Cache 2648) innerhalb des Verarbeitungsclusters 2614 verwenden. In mindestens einem Ausführungsbeispiel hat jeder Grafik-Multiprozessor 2634 auch Zugriff auf L2-Caches innerhalb von Partitionseinheiten (z. B. Partitionseinheiten 2620A-2620N von 26), die von allen Verarbeitungsclustern 2614 gemeinsam genutzt werden und zur Datenübertragung zwischen Threads verwendet werden können. In mindestens einem Ausführungsbeispiel kann der Grafik-Multiprozessor 2634 auch auf den globalen Speicher außerhalb des Chips zugreifen, der einen oder mehrere lokale parallele Prozessorspeicher und/oder Systemspeicher umfassen kann. In mindestens einem Ausführungsbeispiel kann jeder Speicher außerhalb der Parallelverarbeitungseinheit 2602 als globaler Speicher verwendet werden. In mindestens einem Ausführungsbeispiel umfasst der Verarbeitungscluster 2614 mehrere Instanzen des Grafik-Multiprozessors 2634, die gemeinsame Anweisungen und Daten nutzen können, die im L1-Cache 2648 gespeichert werden können.
In mindestens einem Ausführungsbeispiel kann jeder Verarbeitungscluster 2614 eine MMU 2645 (Memory Management Unit) umfassen, die so konfiguriert ist, dass sie virtuelle Adressen physischen Adressen zuordnet. In mindestens einem Ausführungsbeispiel können sich eine oder mehrere Instanzen der MMU 2645 innerhalb der Speicherschnittstelle 2618 von 26 befinden. In mindestens einem Ausführungsbeispiel umfasst MMU 2645 einen Satz von Seitentabelleneinträgen (PTEs), die verwendet werden, um eine virtuelle Adresse einer physikalischen Adresse einer Kachel zuzuordnen (mehr über Kacheln), und optional einen Cache-Zeilenindex. In mindestens einem Ausführungsbeispiel kann die MMU 2645 Adressübersetzungs-Lookaside-Puffer (TLB) oder Caches umfassen, die sich im Grafik-Multiprozessor 2634 oder im L1-Cache oder Verarbeitungscluster 2614 befinden können. In mindestens einem Ausführungsbeispiel wird die physikalische Adresse verarbeitet, um die Lokalität des Oberflächendatenzugriffs so zu verteilen, dass ein effizientes Request Interleaving zwischen den Partitionseinheiten möglich ist. In mindestens einem Ausführungsbeispiel kann der Cachezeilenindex verwendet werden, um zu bestimmen, ob eine Anforderung für eine Cachezeile ein Treffer oder ein Fehlversuch ist.
In mindestens einem Ausführungsbeispiel kann ein Verarbeitungscluster 2614 so konfiguriert sein, dass jeder Grafik-Multiprozessor 2634 mit einer Textureinheit 2636 gekoppelt ist, um Texturabbildungsoperationen durchzuführen, z. B. Bestimmen von Texturabtastpositionen, Lesen von Texturdaten und Filtern von Texturdaten. In mindestens einem Ausführungsbeispiel werden die Texturdaten aus einem internen Textur-L1-Cache (nicht dargestellt) oder aus einem L1-Cache innerhalb des Grafikmultiprozessors 2634 gelesen und je nach Bedarf aus einem L2-Cache, einem lokalen Parallelprozessorspeicher oder dem Systemspeicher geholt. In mindestens einem Ausführungsbeispiel gibt jeder Grafikmultiprozessor 2634 verarbeitete Aufgaben an die Daten-Crossbar 2640 aus, um die verarbeitete Aufgabe einem anderen Verarbeitungscluster 2614 zur weiteren Verarbeitung bereitzustellen oder die verarbeitete Aufgabe über die Speicher-Crossbar 2616 in einem L2-Cache, einem lokalen Parallelprozessorspeicher oder im Systemspeicher zu speichern. In mindestens einem Ausführungsbeispiel ist preROP 2642 (Pre-Raster-Operations-Einheit) so konfiguriert, dass es Daten vom Grafik-Multiprozessor 2634 empfängt und Daten an ROP-Einheiten weiterleitet, die sich in den hier beschriebenen Partitionseinheiten befinden können (z. B. die Partitionseinheiten 2620A-2620N in 26). In mindestens einem Ausführungsbeispiel kann die Einheit PreROP 2642 Optimierungen für die Farbmischung durchführen, Pixelfarbdaten organisieren und Adressübersetzungen durchführen.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im Grafikverarbeitungscluster 2614 zum Inferieren oder Vorhersagen verwendet werden, basierend zumindest teilweise auf Gewichtungsparametern, die unter Verwendung von Trainingsoperationen für neuronale Netzwerke, Funktionen und/oder Architekturen neuronaler Netzwerke oder hierin beschriebenen Anwendungsfällen neuronaler Netzwerke berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
26D zeigt einen Grafikmultiprozessor 2634 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist der Grafik-Multiprozessor 2634 mit dem Pipeline-Manager 2632 des Verarbeitungsclusters 2614 gekoppelt. In mindestens einem Ausführungsbeispiel verfügt der Grafikmultiprozessor 2634 über eine Ausführungspipeline, die unter anderem einen Befehlscache 2652, eine Befehlseinheit 2654, eine Adresszuordnungseinheit 2656, eine Registerdatei 2658, einen oder mehrere GPGPU-Kerne 2662 und eine oder mehrere Lade-/Speichereinheiten 2666 umfasst. Die GPGPU-Kerne 2662 und die Lade-/Speichereinheiten 2666 sind mit dem Cache-Speicher 2672 und dem gemeinsam genutzten Speicher 2670 über eine Speicher- und Cache-Verbindung 2668 gekoppelt.
In mindestens einem Ausführungsbeispiel empfängt der Befehlscache 2652 einen Strom von auszuführenden Befehlen vom Pipeline-Manager 2632. In mindestens einem Ausführungsbeispiel werden die Befehle im Befehlscache 2652 zwischengespeichert und von der Einheit 2654 zur Ausführung weitergeleitet. In mindestens einem Ausführungsbeispiel kann die Befehlseinheit 2654 Befehle in Form von Thread-Gruppen (z. B. Warps) versenden, wobei jeder Thread der Thread-Gruppe einer anderen Ausführungseinheit innerhalb des GPGPU-Kerns 2662 zugewiesen wird. In mindestens einem Ausführungsbeispiel kann ein Befehl auf einen lokalen, gemeinsam genutzten oder globalen Adressraum zugreifen, indem er eine Adresse innerhalb eines einheitlichen Adressraums spezifiziert. In mindestens einem Ausführungsbeispiel kann die Adressenzuordnungseinheit 2656 dazu verwendet werden, Adressen in einem einheitlichen Adressraum in eine eindeutige Speicheradresse zu übersetzen, auf die die Lade-/Speichereinheiten 2666 zugreifen können.
In mindestens einem Ausführungsbeispiel stellt die Registerdatei 2658 einen Satz von Registern für funktionale Einheiten des Grafik-Multiprozessors 2634 bereit. In mindestens einem Ausführungsbeispiel stellt die Registerdatei 2658 einen temporären Speicher für Operanden bereit, die mit Datenpfaden von Funktionseinheiten (z. B. GPGPU-Kerne 2662, Lade-/Speichereinheiten 2666) des Grafikmultiprozessors 2634 verbunden sind. In mindestens einem Ausführungsbeispiel wird die Registerdatei 2658 zwischen den einzelnen funktionalen Einheiten aufgeteilt, so dass jeder funktionalen Einheit ein eigener Teil der Registerdatei 2658 zugewiesen wird. In mindestens einem Ausführungsbeispiel ist die Registerdatei 2658 auf verschiedene Warps aufgeteilt, die vom Grafikmultiprozessor 2634 ausgeführt werden.
In mindestens einem Ausführungsbeispiel können die GPGPU-Kerne 2662 jeweils Gleitkommaeinheiten (FPUs) und/oder ganzzahlige arithmetische Logikeinheiten (ALUs) umfassen, die zur Ausführung von Befehlen des Grafikmultiprozessors 2634 verwendet werden. Die GPGPU-Kerne 2662 können sich in ihrer Architektur ähneln oder unterscheiden. In mindestens einem Ausführungsbeispiel umfasst ein erster Teil der GPGPU-Kerne 2662 eine FPU mit einfacher Genauigkeit und eine Ganzzahl-ALU, während ein zweiter Teil der GPGPU-Kerne eine FPU mit doppelter Genauigkeit umfasst. In mindestens einem Ausführungsbeispiel können FPUs den IEEE 754-2008-Standard für Gleitkommaarithmetik implementieren oder Gleitkommaarithmetik mit variabler Genauigkeit ermöglichen. In mindestens einem Ausführungsbeispiel kann der Grafikmultiprozessor 2634 zusätzlich eine oder mehrere Einheiten mit festen Funktionen oder Sonderfunktionen umfassen, um bestimmte Funktionen wie das Kopieren von Rechtecken oder das Überblenden von Pixeln durchzuführen. In mindestens einem Ausführungsbeispiel kann einer oder mehrere der GPGPU-Kerne auch eine feste oder spezielle Funktionslogik umfassen.
In mindestens einem Ausführungsbeispiel umfassen die GPGPU-Kerne 2662 eine SIMD-Logik, die in der Lage ist, einen einzigen Befehl für mehrere Datensätze auszuführen. In mindestens einem Ausführungsbeispiel können GPGPU-Kerne 2662 physikalisch SIMD4-, SIMD8- und SIMD16-Befehle und logisch SIMD1-, SIMD2- und SIMD32-Befehle ausführen. In mindestens einem Ausführungsbeispiel können SIMD-Befehle für GPGPU-Kerne zur Kompilierungszeit von einem Schattierungscompiler generiert werden oder automatisch generiert werden, wenn Programme ausgeführt werden, die für SPMD- oder SIMT-Architekturen (Single Program Multiple Data) geschrieben und kompiliert wurden. In mindestens einem Ausführungsbeispiel können mehrere Threads eines Programms, das für ein SIMT-Ausführungsmodell konfiguriert ist, über eine einzige SIMD-Anweisung ausgeführt werden. Beispielsweise können in mindestens einem Ausführungsbeispiel acht SIMT-Threads, die gleiche oder ähnliche Operationen ausführen, parallel über eine einzige SIMD8-Logikeinheit ausgeführt werden.
In mindestens einem Ausführungsbeispiel ist die Speicher- und Cache-Verbindung 2668 ein Verbindungsnetz, das jede funktionale Einheit des Grafik-Multiprozessors 2634 mit der Registerdatei 2658 und dem gemeinsam genutzten Speicher 2670 verbindet. In mindestens einem Ausführungsbeispiel ist die Speicher- und Cache-Verbindung 2668 eine Crossbar-Verbindung, die es der Lade-/Speichereinheit 2666 ermöglicht, Lade- und Speicheroperationen zwischen dem gemeinsam genutzten Speicher 2670 und der Registerdatei 2658 durchzuführen. In mindestens einem Ausführungsbeispiel kann die Registerdatei 2658 mit der gleichen Frequenz wie die GPGPU-Kerne 2662 arbeiten, so dass die Datenübertragung zwischen den GPGPU-Kernen 2662 und der Registerdatei 2658 eine sehr geringe Latenzzeit aufweist. In mindestens einem Ausführungsbeispiel kann gemeinsam genutzter Speicher 2670 genutzt werden, um die Kommunikation zwischen Threads zu ermöglichen, die auf funktionalen Einheiten innerhalb des Grafik-Multiprozessors 2634 ausgeführt werden. In mindestens einem Ausführungsbeispiel kann der Cache-Speicher 2672 beispielsweise als Datencache verwendet werden, um Texturdaten zu cachen, die zwischen funktionalen Einheiten und der Textureinheit 2636 ausgetauscht werden. In mindestens einem Ausführungsbeispiel kann der gemeinsam genutzte Speicher 2670 auch als programmverwalteter Cache-Speicher genutzt werden. In mindestens einem Ausführungsbeispiel können Threads, die auf GPGPU-Kernen 2662 ausgeführt werden, zusätzlich zu den automatisch zwischengespeicherten Daten, die im Cache-Speicher 2672 gespeichert sind, programmatisch Daten im gemeinsam genutzten Speicher speichern.
In mindestens einem Ausführungsbeispiel ist ein Parallelprozessor oder eine GPGPU, wie hierin beschrieben, kommunikativ mit Host-/Prozessorkemen gekoppelt, um Grafikoperationen, Operationen des maschinellen Lernens, Musteranalyseoperationen und verschiedene allgemeine GPU (GPGPU)-Funktionen zu beschleunigen. In mindestens einem Ausführungsbeispiel kann die GPU über einen Bus oder eine andere Verbindung (z. B. eine Hochgeschwindigkeitsverbindung wie PCIe oder NVLink) mit dem Host-Prozessor/den Kernen kommunikativ gekoppelt sein. In mindestens einem Ausführungsbeispiel kann die GPU in demselben Gehäuse oder Chip wie die Kerne integriert und über einen internen Prozessorbus/Interconnect (d. h. innerhalb des Gehäuses oder Chips) mit den Kernen gekoppelt sein. In mindestens einem Ausführungsbeispiel können die Prozessorkerne unabhängig von der Art des Anschlusses der GPU der GPU Arbeit in Form von Sequenzen von Befehlen/Befehlen zuweisen, die in einem Arbeitsdeskriptor enthalten sind. In mindestens einem Ausführungsbeispiel verwendet die GPU dann eine dedizierte Schaltungsanordnung/Logik zur effizienten Verarbeitung dieser Befehle/Anweisungen.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im Grafik-Multiprozessor 2634 zum Inferenzieren oder für Vorhersageoperationen verwendet werden, die zumindest teilweise auf Gewichtungsparametern basieren, die unter Verwendung von Trainingsoperationen eines neuronalen Netzwerks, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen eines neuronalen Netzwerks berechnet wurden.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System für den Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
27 zeigt gemäß mindestens einem Ausführungsbeispiel ein Multi-GPU-Rechnersystem 2700. In mindestens einem Ausführungsbeispiel kann das Multi-GPU-Rechnersystem 2700 einen Prozessor 2702 umfassen, der über einen Host-Interface-Switch 2704 mit mehreren allgemeinen Grafikverarbeitungseinheiten (GPUs) 2706A-D gekoppelt ist. In mindestens einem Ausführungsbeispiel ist der Host-Interface-Switch 2704 ein PCI-Express-Switch-Gerät, das den Prozessor 2702 mit einem PCI-Express-Bus koppelt, über den der Prozessor 2702 mit den GPGPUs 2706A-D kommunizieren kann. Die GPGPUs 2706A-D können über eine Reihe von Hochgeschwindigkeits-Punkt-zu-Punkt-GPU-zu-GPU-Verbindungen 2716 miteinander verbunden werden. In mindestens einem Ausführungsbeispiel sind die GPU-zu-GPU-Verbindungen 2716 mit jeder der GPGPUs 2706A-D über eine eigene GPU-Verbindung verbunden. In mindestens einem Ausführungsbeispiel ermöglichen die P2P-GPU-Verbindungen 2716 eine direkte Kommunikation zwischen den einzelnen GPGPUs 2706A-D, ohne dass eine Kommunikation über den Host-Schnittstellenbus 2704 erforderlich ist, an den der Prozessor 2702 angeschlossen ist. In mindestens einem Ausführungsbeispiel, bei dem der GPU-zu-GPU-Verkehr auf P2P-GPU-Verbindungen 2716 geleitet wird, bleibt der Host-Schnittstellenbus 2704 für den Zugriff auf den Systemspeicher oder für die Kommunikation mit anderen Instanzen des Multi-GPU-Rechensystems 2700 verfügbar, beispielsweise über ein oder mehrere Netzwerkgeräte. Während in mindestens einem Ausführungsbeispiel die GPGPUs 2706A-D über den Host-Interface-Switch 2704 mit dem Prozessor 2702 verbunden sind, umfasst der Prozessor 2702 in mindestens einem Ausführungsbeispiel eine direkte Unterstützung für P2P-GPU-Verbindungen 2716 und kann direkt mit den GPGPUs 2706A-D verbunden werden.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im Multi-GPU-Computersystem 2700 zum Inferenzieren oder Vorhersagen verwendet werden, basierend zumindest teilweise auf Gewichtungsparametern, die unter Verwendung von neuronalen Netzwerk-Trainingsoperationen, neuronalen Netzwerkfunktionen und/oder -architekturen oder hierin beschriebenen Anwendungsfällen für neuronale Netzwerke berechnet werden.
Die oben beschriebenen Techniken können z. B. zur Implementierung eines Systems für den Austausch von Objekten zwischen Mensch und Roboter verwendet werden. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
28 ist ein Blockdiagramm eines Grafikprozessors 2800 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2800 eine Ringverbindung 2802, ein Pipeline-Frontend 2804, eine Medienengine 2837 und Grafikkerne 2880A-2880N. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 2800 über die Ringverbindung 2802 mit anderen Verarbeitungseinheiten gekoppelt, die andere Grafikprozessoren oder einen oder mehrere allgemeine Prozessorkerne umfassen. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 2800 einer von vielen Prozessoren, die in ein Multi-Core-Verarbeitungssystem integriert sind.
In mindestens einem Ausführungsbeispiel empfängt der Grafikprozessor 2800 Stapel von Befehlen über die Ringverbindung 2802. In mindestens einem Ausführungsbeispiel werden die eingehenden Befehle von einem Befehlsstreamer 2803 im Pipeline-Frontend 2804 interpretiert. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2800 eine skalierbare Ausführungslogik zur Durchführung der 3D-Geometrieverarbeitung und der Medienverarbeitung über den/die Grafikkern(e) 2880A-2880N. In mindestens einem Ausführungsbeispiel liefert der Befehlsstreamer 2803 für 3D-Geometrieverarbeitungsbefehle Befehle an die Geometrie-Pipeline 2836. In mindestens einem Ausführungsbeispiel liefert der Befehlsstreamer 2803 für mindestens einige Medienverarbeitungsbefehle Befehle an ein Video-Frontend 2834, das mit einer Medienengine 2837 gekoppelt ist. In mindestens einem Ausführungsbeispiel umfasst die Medienengine 2837 eine Video Quality Engine (VQE) 2830 für die Video- und Bildnachbearbeitung und eine Multi-Format Encode/Decode (MFX) 2833 Engine, um eine hardwarebeschleunigte Kodierung und Dekodierung von Mediendaten bereitzustellen. In mindestens einem Ausführungsbeispiel generieren die Geometrie-Pipeline 2836 und die Medienengine 2837 jeweils Ausführungsthreads für Thread-Ausführungsressourcen, die von mindestens einem Grafikkern 2880A bereitgestellt werden.
In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2800 skalierbare Thread-Ausführungsressourcen mit modularen Kernen 2880A-2880N (manchmal als Kernabschnitte bezeichnet), die jeweils mehrere Unterkeme 2850A-550N, 2860A-2860N (manchmal als Kernabschnitte bezeichnet) aufweisen. In mindestens einem Ausführungsbeispiel kann der Grafikprozessor 2800 eine beliebige Anzahl von Grafikkernen 2880A bis 2880N haben. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2800 einen Grafikkern 2880A mit mindestens einem ersten Unterkern 2850A und einem zweiten Unterkern 2860A. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 2800 ein Niedrigleistungsprozessor mit einem einzigen Unterkern (z. B. 2850A). In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 2800 mehrere Grafikkerne 2880A-2880N, die jeweils einen Satz von ersten Unterkemen 2850A-2850N und einen Satz von zweiten Unterkemen 2860A-2860N umfassen. In mindestens einem Ausführungsbeispiel umfasst jeder Unterkern in den ersten Unterkemen 2850A-2850N mindestens einen ersten Satz von Ausführungseinheiten 2852A-2852N und Medien/Textureinheiten 2854A-2854N. In mindestens einem Ausführungsbeispiel umfasst jeder Unterkern in den zweiten Unterkemen 2860A-2860N mindestens eine zweite Gruppe von Ausführungseinheiten 2862A-2862N und Abtastern 2864A-2864N. In mindestens einem Ausführungsbeispiel nutzt jeder Unterkern 2850A-2850N, 2860A-2860N gemeinsam einen Satz von gemeinsam genutzten Ressourcen 2870A-2870N. In mindestens einem Ausführungsbeispiel umfassen die gemeinsam genutzten Ressourcen einen gemeinsam genutzten Cache-Speicher und eine Pixeloperationslogik.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel kann die Inferenz- und/oder Trainingslogik 1315 im Grafikprozessor 2800 zum Inferenzieren oder für Vorhersageoperationen verwendet werden, die zumindest teilweise auf Gewichtungsparametern basieren, die unter Verwendung von Trainingsoperationen für ein neuronales Netzwerk, Funktionen und/oder Architekturen eines neuronalen Netzwerks oder hierin beschriebenen Anwendungsfällen für ein neuronales Netzwerk berechnet wurden.
Die oben beschriebenen Techniken können beispielsweise zur Implementierung eines Systems für den Austausch von Objekten zwischen Mensch und Roboter verwendet werden. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
29 zeigt ein Blockdiagramm, das die Mikroarchitektur eines Prozessors 2900 zeigt, der gemäß mindestens einem Ausführungsbeispiel logische Schaltungen zur Ausführung von Befehlen umfassen kann. In mindestens einem Ausführungsbeispiel kann der Prozessor 2900 Befehle ausführen, einschließlich x86-Befehle, ARM-Befehle, spezielle Befehle für anwendungsspezifische integrierte Schaltungen (ASICs) usw. In mindestens einem Ausführungsbeispiel kann der Prozessor 2910 Register zur Speicherung gepackter Daten umfassen, wie z. B. 64-Bit breite MMXTM-Register in Mikroprozessoren, die mit der MMX-Technologie der Intel Corporation aus Santa Clara, Kalifornien, ausgestattet sind. In mindestens einem Ausführungsbeispiel können MMX-Register, die sowohl als Ganzzahl- als auch als Gleitkommaregister verfügbar sind, mit gepackten Datenelementen arbeiten, die Single Instruction, Multiple Data („SIMD“) und Streaming SIMD Extensions („SSE“) Anweisungen begleiten. In mindestens einem Ausführungsbeispiel können 128-Bit breite XMM-Register, die sich auf SSE2-, SSE3-, SSE4-, AVX- oder darüber hinausgehende Technologien beziehen (allgemein als „SSEx“ bezeichnet), solche gepackten Datenoperanden enthalten. In mindestens einem Ausführungsbeispiel können die Prozessoren 2910 Befehle zur Beschleunigung von Algorithmen für maschinelles Lernen oder Deep Learning, zum Trainieren oder Inferenzieren ausführen.
In mindestens einem Ausführungsbeispiel umfasst der Prozessor 2900 ein in der Reihenfolge angeordnetes Front-End („Front-End“) 2901, um auszuführende Befehle zu holen und Befehle vorzubereiten, die später in der Prozessor-Pipeline verwendet werden sollen. In mindestens einem Ausführungsbeispiel kann das Front-End 2901 mehrere Einheiten umfassen. In mindestens einem Ausführungsbeispiel holt ein Befehlsvorbereiter 2926 Befehle aus dem Speicher und leitet sie an einen Befehlsdekodierer 2928 weiter, der seinerseits Befehle dekodiert oder interpretiert. In mindestens einem Ausführungsbeispiel dekodiert der Befehlsdekodierer 2928 beispielsweise einen empfangenen Befehl in eine oder mehrere Operationen, die als „Mikrobefehle“ oder „Mikrooperationen“ (auch „Mikro-Ops“ oder „Uops“ genannt) bezeichnet werden und von der Maschine ausgeführt werden können. In mindestens einem Ausführungsbeispiel zerlegt der Befehlsdekodierer 2928 den Befehl in einen Op-Code und entsprechende Daten- und Steuerfelder, die von der Mikroarchitektur zur Durchführung von Operationen gemäß mindestens einem Ausführungsbeispiel verwendet werden können. In mindestens einem Ausführungsbeispiel kann ein Spur-Cache 2930 dekodierte Uops in programmgesteuerte Sequenzen oder Spuren in einer Uop-Warteschlange 2934 zur Ausführung zusammenstellen. In mindestens einem Ausführungsbeispiel stellt ein Mikrocode-ROM 2932 Uops bereit, die zur Vervollständigung der Operation benötigt werden, wenn der Spur-Cache 2930 auf einen komplexen Befehl trifft.
In mindestens einem Ausführungsbeispiel können einige Befehle in ein einziges Mikro-OP umgewandelt werden, während andere mehrere Mikro-Ops benötigen, um den Betrieb vollständig abzuschließen. In mindestens einem Ausführungsbeispiel kann der Befehlsdekodierer 2928 auf den Mikrocode-ROM 2932 zugreifen, wenn mehr als vier Mikro-Ops für die Ausführung eines Befehls erforderlich sind, um den Befehl auszuführen. In mindestens einem Ausführungsbeispiel kann ein Befehl in eine kleine Anzahl von Mikro-Ops zur Verarbeitung im Befehlsdekodierer 2928 dekodiert werden. In mindestens einem Ausführungsbeispiel kann ein Befehl im Mikrocode-ROM 2932 gespeichert werden, falls eine Anzahl von Mikro-Ops zur Ausführung des Vorgangs erforderlich ist. In mindestens einem Ausführungsbeispiel bezieht sich der Spur-Cache 2930 auf ein programmierbares Logik-Array („PLA“) als Einstiegspunkt, um gemäß mindestens einem Ausführungsbeispiel einen korrekten Mikrobefehlszeiger zum Lesen von Mikrocode-Sequenzen zur Vervollständigung eines oder mehrerer Befehle aus dem Mikrocode-ROM 2932 zu bestimmen. In mindestens einem Ausführungsbeispiel kann das Front-End 2901 der Maschine, nachdem das Mikrocode-ROM 2932 die Sequenzierung von Mikro-Ops für einen Befehl beendet hat, das Holen von Mikro-Ops aus dem Spur-Cache 2930 wieder aufnehmen.
In mindestens einem Ausführungsbeispiel kann die Engine für die Ausführung außerhalb der Reihenfolge („out of order engine“) 2903 Anweisungen für die Ausführung vorbereiten. In mindestens einem Ausführungsbeispiel verfügt die Ausführungslogik außerhalb der Reihenfolge über eine Reihe von Puffern, um den Fluss der Befehle zu glätten und neu zu ordnen, um die Leistung zu optimieren, während sie die Pipeline hinunterlaufen und zur Ausführung geplant werden. Die Engine für die Ausführung außerhalb der Reihenfolge 2903 umfasst ohne Einschränkung einen Allokator/Register-Renamer 2940, eine Speicher-Uop-Warteschlange 2942, eine Ganzzahl/Fließkomma-Uop-Warteschlange 2944, einen Speicherplaner 2946, einen schnellen Planer 2902, einen langsamen/allgemeinen Gleitkomma-Planer („slow/general FP scheduler“) 2904 und einen einfachen Gleitkomma-Planer („simple FP scheduler“) 2906. In mindestens einem Ausführungsbeispiel werden der schnelle Planer 2902, der langsame/allgemeine Gleitkomma-Planer 2904 und der einfache Gleitkomma-Planer 2906 hier auch gemeinsam als „Uop-Planer 2902, 2904, 2906“ bezeichnet. Der Allokator/Register Renamer 2940 weist Maschinenpuffer und Ressourcen zu, die jedes Uop zur Ausführung benötigt. In mindestens einem Ausführungsbeispiel benennt der Allokator/Register Renamer 2940 logische Register auf Einträge in einer Registerdatei um. In mindestens einem Ausführungsbeispiel weist der Allokator/Register Renamer 2940 außerdem jedem Uop einen Eintrag in einer von zwei Uop-Warteschlangen zu, der Memory-Uop-Warteschlange 2942 für Speicheroperationen und der Integer/Floating-Point-Uop-Warteschlange 2944 für Nicht-Speicheroperationen, und zwar vor dem Memory Scheduler 2946 und den Uop-Planern 2902, 2904, 2906. In mindestens einem Ausführungsbeispiel bestimmen die Uop-Scheduler 2902, 2904, 2906 basierend auf der Bereitschaft ihrer abhängigen Eingaberegister-Operandenquellen und der Verfügbarkeit der Ausführungsressourcen, die die uops für den Abschluss ihrer Operation benötigen, wann ein uop zur Ausführung bereit ist. In mindestens einem Ausführungsbeispiel kann der schnelle Planer 2902 in jeder Hälfte des Haupttaktzyklus planen, während der langsame/allgemeine Gleitkomma-Planer 2904 und der einfache Gleitkomma-Planer 2906 einmal pro Hauptprozessortaktzyklus planen können. In mindestens einem Ausführungsbeispiel vermitteln die Planer 2902, 2904 und 2906 zwischen den Anschlüssen, um die Ausführung von Uops zu planen.
In mindestens einem Ausführungsbeispiel umfasst der Ausführungsblock b11 ohne Einschränkung eine Ganzzahl-Registerdatei/ein Bypass-Netzwerk 2908, eine Gleitkomma-Registerdatei/ein Bypass-Netzwerk („FP-Registerdatei/Bypass-Netzwerk“) 2910, Adressgenerierungseinheiten („AGUs“) 2912 und 2914, schnelle arithmetische Logikeinheiten (ALUs) („fast ALUs“) 2916 und 2918, eine langsame arithmetische Logikeinheit („slow ALU“) 2920, eine Gleitkomma-ALU („FP“) 2922 und eine Gleitkomma-Bewegungseinheit („FP move“) 2924. In mindestens einem Ausführungsbeispiel werden Ganzzahl-Registerdatei/Bypass-Netzwerk 2908 und Gleitkomma-Registerdatei/Bypass-Netzwerk 2910 hier auch als „Registerdateien 2908, 2910“ bezeichnet. In mindestens einem Ausführungsbeispiel werden die AGUSs 2912 und 2914, die schnellen ALUs 2916 und 2918, die langsame ALU 2920, die Gleitkomma-ALU 2922 und die Gleitkomma-Bewegungseinheit 2924 hier auch als „Ausführungseinheiten 2912, 2914, 2916, 2918, 2920, 2922 und 2924“ bezeichnet. In mindestens einem Ausführungsbeispiel kann der Ausführungsblock b 11 ohne Einschränkung eine beliebige Anzahl (einschließlich Null) und Art von Registerdateien, Bypass-Netzwerken, Adressgenerierungseinheiten und Ausführungseinheiten in beliebiger Kombination umfassen.
In mindestens einem Ausführungsbeispiel können Registerdateien 2908, 2910 zwischen Uop-Planern 2902, 2904, 2906 und Ausführungseinheiten 2912, 2914, 2916, 2918, 2920, 2922 und 2924 angeordnet sein. In mindestens einem Ausführungsbeispiel führt das Ganzzahl-Registerdatei/Bypass-Netzwerk 2908 Ganzzahloperationen durch. In mindestens einem Ausführungsbeispiel führt das Gleitkommaregisterdatei/Bypass-Netzwerk 2910 Gleitkommaoperationen durch. In mindestens einem Ausführungsbeispiel kann jede der Registerdateien 2908, 2910 ohne Einschränkung ein Umgehungsnetzwerk umfassen, das gerade abgeschlossene Ergebnisse, die noch nicht in die Registerdatei geschrieben wurden, umgeht oder an neue abhängige Uops weiterleitet. In mindestens einem Ausführungsbeispiel können die Registerdateien 2908, 2910 Daten miteinander austauschen. In mindestens einem Ausführungsbeispiel kann das Integer-Registerdatei/Bypass-Netzwerk 2908 ohne Einschränkung zwei separate Registerdateien umfassen, eine Registerdatei für Daten mit zweiunddreißig Bit in niedriger Reihenfolge und eine zweite Registerdatei für Daten mit zweiunddreißig Bit in hoher Reihenfolge. In mindestens einem Ausführungsbeispiel kann das Gleitkomma-Registerdatei/Bypass-Netzwerk 2910 ohne Einschränkung 128 Bit breite Einträge umfassen, da Gleitkomma-Befehle typischerweise Operanden mit einer Breite von 64 bis 128 Bit haben.
In mindestens einem Ausführungsbeispiel können Ausführungseinheiten 2912, 2914, 2916, 2918, 2920, 2922, 2924 Befehle ausführen. In mindestens einem Ausführungsbeispiel speichern die Registerdateien 2908, 2910 Ganzzahl- und Gleitkommadaten-Operandenwerte, die für die Ausführung von Mikrobefehlen erforderlich sind. In mindestens einem Ausführungsbeispiel kann der Prozessor 2900 ohne Einschränkung eine beliebige Anzahl und Kombination von Ausführungseinheiten 2912, 2914, 2916, 2918, 2920, 2922, 2924 umfassen. In mindestens einem Ausführungsbeispiel können die Gleitkomma-ALU 2922 und die Gleitkomma-Bewegungseinheit 2924 Gleitkomma-, MMX-, SIMD-, AVX- und SSE- oder andere Operationen ausführen, einschließlich spezieller maschineller Lernbefehle. In mindestens einem Ausführungsbeispiel kann die Gleitkomma-ALU 2922 ohne Einschränkung einen 64-Bit-mal-64-Bit-Gleitkomma-Teiler umfassen, um Divisions-, Quadratwurzel- und Restmikrooperationen auszuführen. In mindestens einem Ausführungsbeispiel können Befehle, die einen Gleitkommawert beinhalten, mit Gleitkomma-Hardware verarbeitet werden. In mindestens einem Ausführungsbeispiel können ALU-Operationen an schnelle ALUs 2916, 2918 weitergegeben werden. In mindestens einem Ausführungsbeispiel können schnelle ALUS 2916, 2918 schnelle Operationen mit einer effektiven Latenzzeit von einem halben Taktzyklus ausführen. In mindestens einem Ausführungsbeispiel gehen die meisten komplexen ganzzahligen Operationen an die langsame ALU 2920, da die langsame ALU 2920 ohne Einschränkung ganzzahlige Ausführungshardware für Operationen mit langer Latenzzeit umfassen kann, wie z. B. einen Multiplikator, Verschiebungen, Flag-Logik und Verzweigungsverarbeitung. In mindestens einem Ausführungsbeispiel können Speicherlade-/Speicheroperationen von AGUS 2912, 2914 ausgeführt werden. In mindestens einem Ausführungsbeispiel können die schnelle ALU 2916, die schnelle ALU 2918 und die langsame ALU 2920 Ganzzahloperationen mit 64-Bit-Datenoperanden durchführen. In mindestens einem Ausführungsbeispiel können die schnelle ALU 2916, die schnelle ALU 2918 und die langsame ALU 2920 so implementiert werden, dass sie eine Vielzahl von Datenbitgrößen unterstützen, darunter sechzehn, zweiunddreißig, 128, 256, usw. In mindestens einem Ausführungsbeispiel können die Gleitkomma-ALU 2922 und die Gleitkomma-Bewegungseinheit 2924 so implementiert werden, dass sie einen Bereich von Operanden mit Bits unterschiedlicher Breite unterstützen. In mindestens einem Ausführungsbeispiel können die Gleitkomma-ALU 2922 und die Gleitkomma-Bewegungseinheit 2924 mit 128 Bit breiten gepackten Datenoperanden in Verbindung mit SIMD- und Multimedia-Befehlen arbeiten.
In mindestens einem Ausführungsbeispiel planen die Uop-Planer 2902, 2904, 2906 abhängige Operationen, bevor die Ausführung der übergeordneten Last beendet ist. In mindestens einem Ausführungsbeispiel, in dem Uops spekulativ geplant und im Prozessor 2900 ausgeführt werden können, kann der Prozessor 2900 auch eine Logik zur Behandlung von Fehlversuchen im Speicher umfassen. In mindestens einem Ausführungsbeispiel können bei einem Fehlversuch einer Datenlast im Datencache abhängige Operationen in der Pipeline laufen, die den Planer mit vorübergehend falschen Daten zurückgelassen haben. In mindestens einem Ausführungsbeispiel führt ein Wiederholungsmechanismus die Verfolgung und erneute Ausführung von Anweisungen durch, die falsche Daten verwenden. In mindestens einem Ausführungsbeispiel müssen abhängige Operationen möglicherweise erneut ausgeführt werden, während unabhängige Operationen zu Ende geführt werden können. In mindestens einem Ausführungsbeispiel können Planer und Wiederholungsmechanismen mindestens eines Ausführungsbeispiels eines Prozessors auch so geplant sein, dass sie Befehlssequenzen für Textstring-Vergleichsoperationen abfangen.
In mindestens einem Ausführungsbeispiel kann sich der Begriff „Register“ auf prozessorinteme Speicherplätze beziehen, die als Teil von Befehlen verwendet werden können, um Operanden zu identifizieren. In mindestens einem Ausführungsbeispiel kann es sich bei den Registern um solche handeln, die von außerhalb des Prozessors (aus der Sicht eines Programmierers) verwendet werden können. In mindestens einem Ausführungsbeispiel können die Register nicht auf eine bestimmte Art von Schaltung beschränkt sein. Vielmehr kann ein Register in mindestens einem Ausführungsbeispiel Daten speichern, Daten bereitstellen und die hierin beschriebenen Funktionen ausführen. In mindestens einem Ausführungsbeispiel können die hierin beschriebenen Register in einer Schaltungsanordnung innerhalb eines Prozessors unter Verwendung einer beliebigen Anzahl verschiedener Techniken implementiert werden, wie z. B. dedizierte physische Register, dynamisch zugewiesene physische Register unter Verwendung von Registerumbenennung, Kombinationen aus dedizierten und dynamisch zugewiesenen physischen Registern usw. In mindestens einem Ausführungsbeispiel werden in Ganzzahlregistern 32-Bit-Ganzzahldaten gespeichert. Eine Registerdatei in mindestens einem Ausführungsbeispiel enthält auch acht Multimedia-SIMD-Register für gepackte Daten.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in den EXE-Block 2911 und andere gezeigte oder nicht gezeigte Speicher oder Register integriert werden. Beispielsweise können in mindestens einem Ausführungsbeispiel die hier beschriebenen Techniken zum Trainieren und/oder Inferenzieren eine oder mehrere der in EXE-Block 2911 gezeigten ALUs verwenden. Darüber hinaus können Gewichtungsparameter in On-Chip- oder Off-Chip-Speicher und/oder Registern (gezeigt oder nicht gezeigt) gespeichert werden, die ALUs des EXE-Blocks 2911 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lemalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
30 zeigt gemäß mindestens einem Ausführungsbeispiel einen Deep Learning-Anwendungsprozessor 3000. In mindestens einem Ausführungsbeispiel verwendet der Deep-Learning-Anwendungsprozessor 3000 Befehle, die, wenn sie vom Deep-Learning-Anwendungsprozessor 3000 ausgeführt werden, bewirken, dass der Deep-Learning-Anwendungsprozessor 3000 einige oder alle der in dieser Offenbarung beschriebenen Prozesse und Techniken ausführt. In mindestens einem Ausführungsbeispiel handelt es sich bei dem Deep Learning-Anwendungsprozessor 3000 um eine anwendungsspezifische integrierte Schaltung (ASIC). In mindestens einem Ausführungsbeispiel führt der Anwendungsprozessor 3000 Matrixmultiplikationsoperationen entweder „fest verdrahtet“ in Hardware als Ergebnis der Ausführung eines oder mehrerer Befehle oder beides durch. In mindestens einem Ausführungsbeispiel umfasst der Deep Learning-Anwendungsprozessor 3000 ohne Einschränkung Verarbeitungscluster 3010(1)-3010(12), Inter-Chip-Verbindungen („ICLs“) 3020(1)-3020(12), Inter-Chip-Steuerungen („ICCs“) 3030(1)-3030(2), Speicher mit hoher Bandbreite der zweiten Generation („HBM2“) 3040(1)-3040(4), Speichersteuerungen („Mem Ctrlrs“) 3042(1)-3042(4), physikalische Schicht für Speicher mit hoher Bandbreite („HBM PHY“) 3044(1)-3044(4), eine Management-Controller-Zentraleinheit („Management-Controller-CPU“) 3050, einen Block für serielle periphere Schnittstellen, integrierte Schaltungen und allgemeine Eingaben/Ausgaben („SPI, I2C, GPIO“) 3060, eine Express-Steuerung für periphere Komponentenverbindungen und einen Block für direkten Speicherzugriff („PCIe-Steuerung und DMA“) 3070 und einen Express-Anschluss für periphere Komponentenverbindungen mit sechzehn Lanes („PCI Express x 16“) 3080.
In mindestens einem Ausführungsbeispiel können Verarbeitungscluster 3010 Operationen für Deep Learning durchführen, einschließlich Inferenz- oder Vorhersageoperationen basierend auf Gewichtungsparametern, die mit einer oder mehreren Trainingstechniken, einschließlich der hierin beschriebenen, berechnet wurden. In mindestens einem Ausführungsbeispiel kann jeder Verarbeitungscluster 3010 ohne Einschränkung eine beliebige Anzahl und Art von Prozessoren umfassen. In mindestens einem Ausführungsbeispiel kann der Deep-Learning-Anwendungsprozessor 3000 eine beliebige Anzahl und Art von Verarbeitungsclustern 3000 umfassen. In mindestens einem Ausführungsbeispiel sind die Inter-Chip-Verbindungen 3020 bidirektional. In mindestens einem Ausführungsbeispiel ermöglichen die Inter-Chip-Verbindungen 3020 und die Inter-Chip-Steuerungen 3030 mehreren Deep Learning-Anwendungsprozessoren 3000, Informationen auszutauschen, einschließlich Aktivierungsinformationen, die aus der Ausführung eines oder mehrerer maschineller Lernalgorithmen resultieren, die in einem oder mehreren neuronalen Netzwerken verkörpert sind. In mindestens einem Ausführungsbeispiel kann der Deep Learning-Anwendungsprozessor 3000 eine beliebige Anzahl (einschließlich Null) und einen beliebigen Typ von ICLs 3020 und ICCs 3030 umfassen.
In mindestens einem Ausführungsbeispiel stellen die HBM2s 3040 insgesamt 32 Gigabyte (GB) Speicher bereit. HBM2 3040(i) ist sowohl mit der Speichersteuerung 3042(i) als auch mit HBM PHY 3044(i) assoziiert. In mindestens einem Ausführungsbeispiel kann eine beliebige Anzahl von HBM2 3040 einen beliebigen Typ und eine beliebige Gesamtmenge an Speicher mit hoher Bandbreite bereitstellen und mit einer beliebigen Anzahl (einschließlich Null) und einem beliebigen Typ von Speichersteuerungen 3042 und HBM PHYs 3044 assoziiert sein. In mindestens einem Ausführungsbeispiel können SPI, I2C, GPIO 3060, PCIe-Steuerung und DMA 3070 und/oder PCIe 3080 durch eine beliebige Anzahl und Art von Schritten ersetzt werden, die eine beliebige Anzahl und Art von Kommunikationsstandards in einer technisch geeigneten Weise ermöglichen.
Die Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel wird der Deep Learning-Anwendungsprozessor dazu verwendet, ein maschinelles Lemmodell, wie z. B. ein neuronales Netzwerk, zu trainieren, um Informationen vorherzusagen oder zu inferieren, die dem Deep Learning-Anwendungsprozessor 3000 bereitgestellt werden. In mindestens einem Ausführungsbeispiel wird der Deep Learning-Anwendungsprozessor 3000 verwendet, um Informationen basierend auf einem trainierten maschinellen Lernmodell (z. B. einem neuronalen Netzwerk), das von einem anderen Prozessor oder System oder vom Deep Learning-Anwendungsprozessor 3000 trainiert wurde, zu inferieren oder vorherzusagen. In mindestens einem Ausführungsbeispiel kann der Prozessor 3000 verwendet werden, um einen oder mehrere hierin beschriebene Anwendungsfälle eines neuronalen Netzwerks durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
31 zeigt ein Blockdiagramm eines neuromorphen Prozessors 3100, gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel kann der neuromorphe Prozessor 3100 eine oder mehrere Eingaben von Quellen außerhalb des neuromorphen Prozessors 3100 empfangen. In mindestens einem Ausführungsbeispiel können diese Eingaben an ein oder mehrere Neuronen 3102 innerhalb des neuromorphen Prozessors 3100 übertragen werden. In mindestens einem Ausführungsbeispiel können die Neuronen 3102 und ihre Komponenten unter Verwendung von Schaltungsanordnungen oder Logik, einschließlich einer oder mehrerer arithmetischer Logikeinheiten (ALUs), implementiert werden. In mindestens einem Ausführungsbeispiel kann der neuromorphe Prozessor 3100 ohne Einschränkung Tausende oder Millionen von Instanzen von Neuronen 3102 umfassen, aber jede geeignete Anzahl von Neuronen 3102 kann verwendet werden. In mindestens einem Ausführungsbeispiel kann jede Instanz von Neuron 3102 eine Neuroneneingabe 3104 und eine Neuronenausgabe 3106 umfassen. In mindestens einem Ausführungsbeispiel können die Neuronen 3102 Ausgaben generieren, die an Eingaben anderer Instanzen von Neuronen 3102 übertragen werden können. Zum Beispiel können in mindestens einem Ausführungsbeispiel die Eingaben 3104 und Ausgaben 3106 der Neuronen über Synapsen 3108 miteinander verbunden sein.
In mindestens einem Ausführungsbeispiel können Neuronen 3102 und Synapsen 3108 so miteinander verbunden sein, dass der neuromorphe Prozessor 3100 arbeitet, um vom neuromorphen Prozessor 3100 empfangene Informationen zu verarbeiten oder zu analysieren. In mindestens einem Ausführungsbeispiel können die Neuronen 3102 einen Ausgabeimpuls (oder „Feuer“ oder „Spike“) senden, wenn die über die Neuroneneingabe 3104 empfangenen Eingaben einen Schwellenwert überschreiten. In mindestens einem Ausführungsbeispiel können die Neuronen 3102 die an den Neuroneneingängen 3104 empfangenen Signale summieren oder integrieren. In mindestens einem Ausführungsbeispiel können die Neuronen 3102 beispielsweise als undichte Integrations- und Feuerneuronen implementiert werden, wobei das Neuron 3102 eine Ausgabe (oder „Feuer“) unter Verwendung einer Übertragungsfunktion wie einer Sigmoid- oder Schwellenfunktion generieren kann, wenn eine Summe (als „Membranpotential“ bezeichnet) einen Schwellenwert überschreitet. In mindestens einem Ausführungsbeispiel kann ein „leaky integrate-and-fire“-Neuron die an den Eingängen 3104 des Neurons empfangenen Signale zu einem Membranpotential summieren und auch einen Abklingfaktor (oder ein Leck) anwenden, um das Membranpotential zu reduzieren. In mindestens einem Ausführungsbeispiel kann ein „leaky integrate-and-fire“-Neuron feuern, wenn mehrere Eingangssignale an den Neuroneneingängen 3104 schnell genug empfangen werden, um einen Schwellenwert zu überschreiten (d. h. bevor ein Membranpotenzial zu niedrig abklingt, um zu feuern). In mindestens einem Ausführungsbeispiel können die Neuronen 3102 unter Verwendung von Schaltungen oder Logik implementiert werden, die Eingaben empfangen, Eingaben in ein Membranpotential integrieren und ein Membranpotential abklingen lassen. In mindestens einem Ausführungsbeispiel können die Eingaben gemittelt werden, oder es kann jede andere geeignete Übertragungsfunktion verwendet werden. Darüber hinaus können die Neuronen 3102 in mindestens einem Ausführungsbeispiel ohne Einschränkung Komparatorschaltungen oder eine Logik umfassen, die einen Ausgangsspike am Neuronenausgang 3106 generieren, wenn das Ergebnis der Anwendung einer Übertragungsfunktion auf die Neuroneneingabe 3104 einen Schwellenwert überschreitet. In mindestens einem Ausführungsbeispiel kann das Neuron 3102, sobald es feuert, zuvor erhaltene Eingaben ignorieren, indem es beispielsweise ein Membranpotenzial auf 0 oder einen anderen geeigneten Standardwert zurücksetzt. In mindestens einem Ausführungsbeispiel kann das Neuron 3102, sobald das Membranpotenzial auf 0 zurückgesetzt ist, nach einer geeigneten Zeitspanne (oder Refraktärzeit) den normalen Betrieb wieder aufnehmen.
In mindestens einem Ausführungsbeispiel können die Neuronen 3102 über Synapsen 3108 miteinander verbunden sein. In mindestens einem Ausführungsbeispiel können Synapsen 3108 arbeiten, um Signale von einer Ausgabe eines ersten Neurons 3102 zu einer Eingabe eines zweiten Neurons 3102 zu übertragen. In mindestens einem Ausführungsbeispiel können die Neuronen 3102 Informationen über mehr als eine Instanz der Synapse 3108 übertragen. In mindestens einem Ausführungsbeispiel können ein oder mehrere Ausführungsbeispiele der neuronalen Ausgabe 3106 über ein Ausführungsbeispiel der Synapse 3108 mit einem Ausführungsbeispiel der neuronalen Eingabe 3104 in demselben Neuron 3102 verbunden sein. In mindestens einem Ausführungsbeispiel kann ein Neuron 3102, das eine über ein Synapseninstanz 3108 zu übertragende Ausgabe generiert, als „präsynaptisches Neuron“ in Bezug auf diese Synapseninstanz 3108 bezeichnet werden. In mindestens einem Ausführungsbeispiel kann ein Neuron 3102, das eine über eine Synapse 3108 übertragene Eingabe empfängt, als „postsynaptisches Neuron“ in Bezug auf diese Synapse 3108 bezeichnet werden. Da ein Neuron 3102 Eingaben von einem oder mehreren Synapseninstanzen 3108 empfangen und auch Ausgaben über eine oder mehrere Synapseninstanzen 3108 übertragen kann, kann ein einzelnes Neuron 3102 in mindestens einem Ausführungsbeispiel sowohl ein „präsynaptisches Neuron“ als auch ein „postsynaptisches Neuron“ in Bezug auf verschiedene Synapseninstanzen 3108 sein.
In mindestens einem Ausführungsbeispiel können die Neuronen 3102 in einer oder mehreren Schichten organisiert sein. Jede Instanz des Neurons 3102 kann eine Neuronenausgabe 3106 haben, die sich über eine oder mehrere Synapsen 3108 zu einer oder mehreren Eingaben 3104 auffächern kann. In mindestens einem Ausführungsbeispiel können die Ausgaben 3106 der Neuronen 3102 in einer ersten Schicht 3110 mit den Eingaben 3104 der Neuronen 3102 in einer zweiten Schicht 3112 verbunden sein. In mindestens einem Ausführungsbeispiel kann die Schicht 3110 als „Feed-Forward-Schicht“ bezeichnet werden. In mindestens einem Ausführungsbeispiel kann sich jedes Neuron 3102 in einem Ausführungsbeispiel der ersten Schicht 3110 zu jedem Neuron 3102 in der zweiten Schicht 3112 auffächern. In mindestens einem Ausführungsbeispiel kann die erste Schicht 3110 als „vollständig vernetzte vorwärtsgerichtete Schicht“ bezeichnet werden. In mindestens einem Ausführungsbeispiel kann jedes Ausführungsbeispiel des Neurons 3102 in einem Ausführungsbeispiel der zweiten Schicht 3112 zu weniger als allen Ausführungsbeispielen des Neurons 3102 in einer dritten Schicht 3114 auffächern. In mindestens einem Ausführungsbeispiel kann die zweite Schicht 3112 als eine „spärlich verbundene Vorwärtsschicht“ bezeichnet werden. In mindestens einem Ausführungsbeispiel können sich Neuronen 3102 in der zweiten Schicht 3112 zu Neuronen 3102 in mehreren anderen Schichten auffächern, einschließlich zu Neuronen 3102 in (derselben) zweiten Schicht 3112. In mindestens einem Ausführungsbeispiel kann die zweite Schicht 3112 als eine „rekurrente Schicht“ bezeichnet werden. Der neuromorphe Prozessor 3100 kann ohne Einschränkung jede geeignete Kombination von rekurrenten Schichten und Feedforward-Schichten umfassen, einschließlich, ohne Einschränkung, sowohl spärlich vernetzte Feedforward-Schichten als auch vollständig vernetzte Feedforward-Schichten.
In mindestens einem Ausführungsbeispiel kann der neuromorphe Prozessor 3100 ohne Einschränkung eine rekonfigurierbare Verbindungsarchitektur oder dedizierte festverdrahtete Verbindungen umfassen, um Synapsen 3108 mit Neuronen 3102 zu verbinden. In mindestens einem Ausführungsbeispiel kann der neuromorphe Prozessor 3100 ohne Einschränkung eine Schaltungsanordnung oder Logik umfassen, die es ermöglicht, dass Synapsen je nach Bedarf basierend auf der Topologie des neuronalen Netzwerks und dem Fan-in/-out von Neuronen verschiedenen Neuronen 3102 zugewiesen werden können. Beispielsweise können in mindestens einem Ausführungsbeispiel Synapsen 3108 unter Verwendung einer Verbindungsstruktur, wie z. B. Network-on-Chip, oder mit dedizierten Verbindungen mit Neuronen 3102 verbunden werden. In mindestens einem Ausführungsbeispiel können die Synapsenverbindungen und deren Komponenten unter Verwendung von Schaltungsanordnungen oder Logik implementiert werden.
Die oben beschriebenen Techniken können beispielsweise zur Implementierung eines Systems für den Austausch von Objekten zwischen Mensch und Roboter verwendet werden. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
32 zeigt ein Blockdiagramm eines Verarbeitungssystems gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel umfasst das System 3200 einen oder mehrere Prozessoren 3202 und einen oder mehrere Grafikprozessoren 3208 und kann ein Einzelprozessor-Desktop-System, ein Multiprozessor-Workstation-System oder ein Server-System mit einer großen Anzahl von Prozessoren 3202 oder Prozessorkernen 3207 sein. In mindestens einem Ausführungsbeispiel ist das System 3200 eine Verarbeitungsplattform, die in eine integrierte Schaltung eines System-on-a-Chip (SoC) zur Verwendung in mobilen, tragbaren oder eingebetteten Geräten integriert ist.
In mindestens einem Ausführungsbeispiel kann das System 3200 eine serverbasierte Spielplattform, eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, eine mobile Spielkonsole, eine Handheld-Spielkonsole oder eine Online-Spielkonsole umfassen oder darin integriert sein. In mindestens einem Ausführungsbeispiel ist das System 3200 ein Mobiltelefon, Smartphone, Tablet-Rechengerät oder mobiles Internetgerät. In mindestens einem Ausführungsbeispiel kann das Verarbeitungssystem 3200 auch ein tragbares Gerät umfassen, mit einem solchen gekoppelt sein oder in ein solches integriert werden, wie z. B. ein tragbares Gerät für eine intelligente Uhr, eine intelligente Brille, ein Augmented-Reality-Gerät oder ein Virtual-Reality-Gerät. In mindestens einem Ausführungsbeispiel ist das Verarbeitungssystem 3200 ein Fernsehgerät oder eine Set-Top-Box mit einem oder mehreren Prozessoren 3202 und einer grafischen Oberfläche, die von einem oder mehreren Grafikprozessoren 3208 generiert wird.
In mindestens einem Ausführungsbeispiel umfassen ein oder mehrere Prozessoren 3202 jeweils einen oder mehrere Prozessorkerne 3207 zur Verarbeitung von Befehlen, die bei ihrer Ausführung Operationen für System- und Benutzersoftware durchführen. In mindestens einem Ausführungsbeispiel ist jeder von einem oder mehreren Prozessorkernen 3207 so konfiguriert, dass er einen bestimmten Befehlssatz 3209 verarbeitet. In mindestens einem Ausführungsbeispiel kann der Befehlssatz 3209 das Complex Instruction Set Computing (CISC), das Reduced Instruction Set Computing (RISC) oder das Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. In mindestens einem Ausführungsbeispiel können die Prozessorkerne 3207 jeweils einen anderen Befehlssatz 3209 verarbeiten, der Befehle umfassen kann, die die Emulation anderer Befehlssätze erleichtern. In mindestens einem Ausführungsbeispiel kann der Prozessorkern 3207 auch andere verarbeitende Geräte umfassen, wie z.B. einen digitalen Signalprozessor (DSP).
In mindestens einem Ausführungsbeispiel umfasst der Prozessor 3202 einen Cache-Speicher 3204. In mindestens einem Ausführungsbeispiel kann der Prozessor 3202 einen einzigen internen Cache oder mehrere Ebenen von internen Caches aufweisen. In mindestens einem Ausführungsbeispiel wird der Cache-Speicher gemeinsam von verschiedenen Komponenten des Prozessors 3202 genutzt. In mindestens einem Ausführungsbeispiel verwendet der Prozessor 3202 auch einen externen Cache (z.B. einen Level-3 (L3) Cache oder Last Level Cache (LLC)). (nicht gezeigt), der unter Verwendung von bekannten Cache-Kohärenztechniken von den Prozessorkernen 3207 gemeinsam genutzt werden kann. In mindestens einem Ausführungsbeispiel ist im Prozessor 3202 zusätzlich eine Registerdatei 3206 umfasst, die verschiedene Arten von Registern zur Speicherung unterschiedlicher Datentypen umfassen kann (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister). In mindestens einem Ausführungsbeispiel kann die Registerdatei 3206 allgemeine Register oder andere Register umfassen.
In mindestens einem Ausführungsbeispiel ist (sind) ein oder mehrere Prozessor(en) 3202 mit einem oder mehreren Schnittstellenbus(en) 3210 gekoppelt, um Kommunikationssignale wie Adress-, Daten- oder Steuersignale zwischen Prozessor 3202 und anderen Komponenten im System 3200 zu übertragen. In mindestens einem Ausführungsbeispiel kann der Schnittstellenbus 3210 ein Prozessorbus sein, wie beispielsweise eine Version eines Direct Media Interface (DMI)-Busses. In mindestens einem Ausführungsbeispiel ist die Schnittstelle 3210 nicht auf einen DMI-Bus beschränkt und kann einen oder mehrere Peripheral Component Interconnect-Busse (z. B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. In mindestens einem Ausführungsbeispiel umfasst der/die Prozessor(en) 3202 eine integrierte Speichersteuerung 3216 und einen Plattformsteuerungs-Hub 3230. In mindestens einem Ausführungsbeispiel erleichtert die Speichersteuerung 3216 die Kommunikation zwischen einem Speichergerät und anderen Komponenten des Systems 3200, während der Plattformsteuerungs-Hub (PCH) 3230 Verbindungen zu E/A-Geräten über einen lokalen E/A-Bus bereitstellt.
In mindestens einem Ausführungsbeispiel kann das Speichergerät 3220 ein Dynamic Random Access Memory (DRAM)-Gerät, ein statisches Random Access Memory (SRAM)-Gerät, ein Flash-Speichergerät, ein Phase-Change-Speichergerät oder ein anderes Speichergerät mit geeigneter Leistung sein, um als Prozessspeicher zu dienen. In mindestens einem Ausführungsbeispiel kann das Speichergerät 3220 als Systemspeicher für das System 3200 arbeiten, um Daten 3222 und Befehle 3221 zur Verwendung zu speichern, wenn ein oder mehrere Prozessoren 3202 eine Anwendung oder einen Prozess ausführen. In mindestens einem Ausführungsbeispiel ist die Speichersteuerung 3216 auch mit einem optionalen externen Grafikprozessor 3212 gekoppelt, der mit einem oder mehreren Grafikprozessoren 3208 in Prozessoren 3202 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In mindestens einem Ausführungsbeispiel kann ein Anzeigegerät 3211 mit Prozessor(en) 3202 verbunden werden. In mindestens einem Ausführungsbeispiel kann die Anzeige 3211 ein oder mehrere interne Geräte umfassen, wie z. B. ein mobiles elektronisches Gerät oder einen Laptop, oder ein externes Anzeigegerät, das über eine Anzeigeschnittstelle (z. B. DisplayPort usw.) angeschlossen ist. In mindestens einem Ausführungsbeispiel kann die Anzeigevorrichtung 3211 eine kopfmontierte Anzeige (HMD) umfassen, wie z.B. eine stereoskopische Anzeigevorrichtung zur Verwendung in Virtual Reality (VR) Anwendungen oder Augmented Reality (AR) Anwendungen.
In mindestens einem Ausführungsbeispiel ermöglicht der Plattformsteuerungs-Hub 3230 den Anschluss von Peripheriegeräten an das Speichergerät 3220 und den Prozessor 3202 über einen Hochgeschwindigkeits-E/A-Bus. In mindestens einem Ausführungsbeispiel umfassen die E/A-Peripheriegeräte unter anderem eine Audio-Steuerung 3246, eine Netzwerkschnittstelle 3234, eine Firmware-Schnittstelle 3228, einen drahtlosen Transceiver 3226, Berührungssensoren 3225, ein Datenspeichergerät 3224 (z.B. Festplattenlaufwerk, Flash-Speicher, etc.). In mindestens einem Ausführungsbeispiel kann das Gerät 3224 über eine Speicherschnittstelle (z. B. SATA) oder über einen Peripheriebus, wie einen Peripheral Component Interconnect Bus (z. B. PCI, PCI Express), angeschlossen werden. In mindestens einem Ausführungsbeispiel können die Berührungssensoren 3225 Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. In mindestens einem Ausführungsbeispiel kann der drahtlose Transceiver 3226 ein Wi-Fi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilfunk-Transceiver wie ein 3G-, 4G- oder Long Term Evolution (LTE)-Transceiver sein. In mindestens einem Ausführungsbeispiel ermöglicht die Firmware-Schnittstelle 3228 die Kommunikation mit der System-Firmware und kann z. B. eine einheitliche erweiterbare Firmware-Schnittstelle (UEFI) sein. In mindestens einem Ausführungsbeispiel kann die Netzwerksteuerung 3234 eine Netzwerkverbindung mit einem kabelgebundenen Netzwerk ermöglichen. In mindestens einem Ausführungsbeispiel ist eine Hochleistungsnetzwerksteuerung (nicht dargestellt) mit dem Schnittstellenbus 3210 gekoppelt. In mindestens einem Ausführungsbeispiel handelt es sich bei der Audio-Steuerung 3246 um eine mehrkanalige High-Definition-Audio-Steuerung. In mindestens einem Ausführungsbeispiel umfasst das System 3200 eine optionale System-E/A-Steuerung 3240 zum Koppeln von älteren Geräten (z. B. Personal System 2 (PS/2)) mit dem System. In mindestens einem Ausführungsbeispiel kann der Plattformsteuerungs-Hub 3230 auch an eine oder mehrere Universal Serial Bus (USB)-Steuerungen 3242 angeschlossen werden, die Eingabegeräte wie Tastatur- und Mauskombinationen 3243, eine Kamera 3244 oder andere USB-Eingabegeräte verbinden.
In mindestens einem Ausführungsbeispiel kann eine Instanz der Speichersteuerung 3216 und des Plattformsteuerungs-Hubs 3230 in einen diskreten externen Grafikprozessor, wie den externen Grafikprozessor 3212, integriert sein. In mindestens einem Ausführungsbeispiel können Plattformsteuerungs-Hub 3230 und/oder Speichersteuerung 3216 extern zu einem oder mehreren Prozessor(en) 3202 sein. Beispielsweise kann das System 3200 in mindestens einem Ausführungsbeispiel eine externe Speichersteuerung 3216 und einen Plattformsteuerungs-Hub 3230 umfassen, der als Speichersteuerungs-Hub und als Peripherie-Steuerungs-Hub innerhalb eines System-Chipsatzes konfiguriert sein kann, der mit dem/den Prozessor(en) 3202 in Verbindung steht.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in den Grafikprozessor 3200 integriert werden. Beispielsweise können in mindestens einem Ausführungsbeispiel die hier beschriebenen Techniken zum Trainieren und/oder Inferenzieren eine oder mehrere ALUs verwenden, die in der 3D-Pipeline 3212 enthalten sind. Darüber hinaus können in mindestens einem Ausführungsbeispiel die hierin beschriebenen Inferenzieren- und/oder Trainingsoperationen unter Verwendung von anderer Logik als der in 13A oder 13B gezeigten Logik durchgeführt werden. In mindestens einem Ausführungsbeispiel können Gewichtungsparameter in einem On-Chip- oder Off-Chip-Speicher und/oder Registern (dargestellt oder nicht dargestellt) gespeichert sein, die ALUs des Grafikprozessors 3200 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lernalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
[33 zeigt ein Blockdiagramm eines Prozessors 3300 mit einem oder mehreren Prozessorkemen 3302A-3302N, einer integrierten Speichersteuerung 3314 und einem integrierten Grafikprozessor 3308, gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel kann der Prozessor 3300 zusätzliche Kerne bis zu und einschließlich des zusätzlichen Kerns 3302N umfassen, die durch gestrichelte Kästen repräsentiert werden. In mindestens einem Ausführungsbeispiel umfasst jeder der Prozessorkerne 3302A-3302N eine oder mehrere interne Cache-Einheiten 3304A-3304N. In mindestens einem Ausführungsbeispiel hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 3306.
In mindestens einem Ausführungsbeispiel repräsentieren die internen Cache-Einheiten 3304A-3304N und die gemeinsam genutzten Cache-Einheiten 3306 eine Cache-SpeicherHierarchie innerhalb des Prozessors 3300. In mindestens einem Ausführungsbeispiel können die Cache-Speichereinheiten 3304A-3304N mindestens eine Ebene von Befehls- und Datencache innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Mid-Level-Cache umfassen, wie z. B. eine Ebene 2 (L2), Ebene 3 (L3), Ebene 4 (L4) oder andere Cache-Ebenen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert ist. In mindestens einem Ausführungsbeispiel hält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 3306 und 3304A-3304N aufrecht.
In mindestens einem Ausführungsbeispiel kann der Prozessor 3300 auch einen Satz von einer oder mehreren Bussteuerungseinheiten 3316 und einen Systemdienst-Kern 3310 umfassen. In mindestens einem Ausführungsbeispiel verwalten eine oder mehrere Bussteuerungseinheiten 3316 einen Satz von Peripheriebussen, wie einen oder mehrere PCI- oder PCI-Express-Busse. In mindestens einem Ausführungsbeispiel stellt der Systemdienst-Kern 3310 eine Verwaltungsfunktionalität für verschiedene Prozessorkomponenten bereit. In mindestens einem Ausführungsbeispiel umfasst der Systemdienst-Kern 3310 eine oder mehrere integrierte Speichersteuerungen 3314 zur Verwaltung des Zugriffs auf verschiedene externe Speichergeräte (nicht dargestellt).
In mindestens einem Ausführungsbeispiel umfasst einer oder mehrere der Prozessorkerne 3302A-3302N Unterstützung für simultanes Multithreading. In mindestens einem Ausführungsbeispiel umfasst der Systemdienst-Kern 3310 Komponenten zur Koordinierung und zum Betrieb der Kerne 3302A-3302N während der Multithreading-Verarbeitung. In mindestens einem Ausführungsbeispiel kann der Systemdienst-Kern 3310 zusätzlich eine Leistungssteuerungseinheit (PCU) umfassen, die Logik und Komponenten zur Regelung eines oder mehrerer Leistungszustände der Prozessorkerne 3302A-3302N und des Grafikprozessors 3308 umfasst.
In mindestens einem Ausführungsbeispiel umfasst der Prozessor 3300 zusätzlich den Grafikprozessor 3308 zur Ausführung von Grafikverarbeitungsoperationen. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 3308 mit gemeinsam genutzten Cache-Einheiten 3306 und dem Systemdienst-Kern 3310 gekoppelt, der eine oder mehrere integrierte Speichersteuerungen 3314 umfasst. In mindestens einem Ausführungsbeispiel umfasst der Systemdienstkem 3310 auch eine Anzeigensteuerung 3311, um die Ausgabe des Grafikprozessors an eine oder mehrere gekoppelte Anzeigen zu steuern. In mindestens einem Ausführungsbeispiel kann die Anzeigensteuerung 3311 auch ein separates Modul sein, das mit dem Grafikprozessor 3308 über mindestens eine Zwischenverbindung gekoppelt ist, oder sie kann in den Grafikprozessor 3308 integriert sein.
In mindestens einem Ausführungsbeispiel wird eine auf einem Ring basierende Verbindungseinheit 3312 verwendet, um interne Komponenten des Prozessors 3300 zu koppeln. In mindestens einem Ausführungsbeispiel kann eine alternative Verbindungseinheit verwendet werden, wie z. B. eine Punkt-zu-Punkt-Verbindung, eine Switch-Verbindung oder andere Techniken. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor 3308 mit der Ringverbindung 3312 über eine E/A-Verbindung 3313 gekoppelt.
In mindestens einem Ausführungsbeispiel repräsentiert die I/O-Verbindung 3313 mindestens eine von mehreren Arten von I/O-Verbindungen, einschließlich einer On-Package-I/O-Verbindung, die die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsspeichermodul 3318, wie einem eDRAM-Modul, erleichtert. In mindestens einem Ausführungsbeispiel nutzen jeder der Prozessorkerne 3302A-3302N und der Grafikprozessor 3308 eingebettete Speichermodule 3318 als gemeinsam genutzten Last Level Cache.
In mindestens einem Ausführungsbeispiel sind die Prozessorkerne 3302A-3302N homogene Kerne, die eine gemeinsame Befehlssatzarchitektur ausführen. In mindestens einem Ausführungsbeispiel sind die Prozessorkerne 3302A-3302N in Bezug auf die Befehlssatzarchitektur (ISA) heterogen, wobei ein oder mehrere Prozessorkerne 3302A-3302N einen gemeinsamen Befehlssatz ausführen, während ein oder mehrere andere Kerne der Prozessorkerne 3302A-3302N eine Teilmenge eines gemeinsamen Befehlssatzes oder einen anderen Befehlssatz ausführen. In mindestens einem Ausführungsbeispiel sind die Prozessorkerne 3302A-3302N in Bezug auf die Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einem relativ höheren Stromverbrauch mit einem oder mehreren Leistungskernen mit einem niedrigeren Stromverbrauch gekoppelt sind. In mindestens einem Ausführungsbeispiel kann der Prozessor 3300 auf einem oder mehreren Chips oder als integrierte SoC-Schaltung implementiert werden.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in den Grafikprozessor 3310 integriert sein. Beispielsweise können in mindestens einem Ausführungsbeispiel die hier beschriebenen Techniken zum Trainieren und/oder Inferenzieren eine oder mehrere der in der 3D-Pipeline 3212 enthaltenen ALUs, den/die Grafikkern(e) 3315A, die gemeinsam genutzte(n) Funktionslogik(en) 3316, den/die Grafikkern(e) 3315B, die gemeinsam genutzte Funktionslogik 3320 oder eine andere Logik aus 33 verwenden. Darüber hinaus können in mindestens einem Ausführungsbeispiel die hier beschriebenen Inferenzieren und/oder Trainieren unter Verwendung einer anderen als der in 13A oder 13B gezeigten Logik erfolgen. In mindestens einem Ausführungsbeispiel können Gewichtungsparameter in einem On-Chip- oder Off-Chip-Speicher und/oder Registern (dargestellt oder nicht dargestellt) gespeichert sein, die ALUs des Grafikprozessors 3310 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lernalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System für den Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um das Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
34 zeigt ein Blockdiagramm eines Grafikprozessors 3400, bei dem es sich um eine diskrete Grafikverarbeitungseinheit oder um einen Grafikprozessor handeln kann, der mit einer Vielzahl von Rechenkernen integriert ist. In mindestens einem Ausführungsbeispiel kommuniziert der Grafikprozessor 3400 über eine dem Speicher zugeordnete E/A-Schnittstelle mit Registern des Grafikprozessors 3400 und mit Befehlen, die im Speicher abgelegt sind. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 3400 eine Speicherschnittstelle 3414 für den Zugriff auf den Speicher. In mindestens einem Ausführungsbeispiel ist die Speicherschnittstelle 3414 eine Schnittstelle zum lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder zum Systemspeicher.
In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 3400 auch eine Anzeigensteuerung 3402, um Anzeige-Ausgabedaten zu einem Anzeigegerät 3420 zu steuern. In mindestens einem Ausführungsbeispiel umfasst die Anzeigensteuerung 3402 Hardware für eine oder mehrere Überlagerungsebenen für das Anzeigegerät 3420 und die Zusammensetzung mehrerer Schichten von Video- oder Benutzerschnittstellenelementen. In mindestens einem Ausführungsbeispiel kann es sich bei dem Anzeigegerät 3420 um ein internes oder externes Anzeigegerät handeln. In mindestens einem Ausführungsbeispiel handelt es sich bei dem Anzeigegerät 3420 um ein kopfmontiertes Anzeigegerät, wie z. B. ein Virtual-Reality- (VR-) Anzeigegerät oder ein Augmented-Reality- (AR-) Anzeigegerät. In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 3400 eine Videocodec Engine 3406 zum Kodieren, Dekodieren oder Transkodieren von Medien in, aus oder zwischen einem oder mehreren Medienkodierformaten, einschließlich, aber nicht beschränkt auf Moving Picture Experts Group (MPEG) Formate wie MPEG-2, Advanced Video Coding (AVC) Formate wie H.264 /MPEG-4 AVC, sowie die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group (JPEG) Formate wie JPEG und Motion JPEG (MJPEG) Formate.
In mindestens einem Ausführungsbeispiel umfasst der Grafikprozessor 3400 eine BLIT-Engine 3404 (Block Image Transfer) zur Durchführung von zweidimensionalen (2D) Rasterisierungsoperationen, einschließlich z. B. Bit-Boundary-Block-Transfers. In mindestens einem Ausführungsbeispiel werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 3410 durchgeführt. In mindestens einem Ausführungsbeispiel ist die GPE 3410 eine Compute Engine zur Durchführung von Grafikoperationen, die dreidimensionale (3D) Grafikoperationen und Medienoperationen umfasst.
In mindestens einem Ausführungsbeispiel umfasst die GPE 3410 eine 3D-Pipeline 3412 zur Durchführung von 3D-Operationen, wie das Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Primitivformen (z. B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 3412 umfasst programmierbare und feste Funktionselemente, die verschiedene Aufgaben ausführen und/oder Ausführungsthreads für ein 3D/Media-Subsystem 3415 erzeugen. Während die 3D-Pipeline 3412 zur Durchführung von Medienoperationen verwendet werden kann, umfasst GPE 3410 in mindestens einem Ausführungsbeispiel auch eine Medien-Pipeline 3416, die zur Durchführung von Medienoperationen, wie Videonachbearbeitung und Bildverbesserung, verwendet wird.
In mindestens einem Ausführungsbeispiel umfasst die Medienpipeline 3416 feste Funktions- oder programmierbare Logikeinheiten, um eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie z. B. Videodekodierbeschleunigung, Videoentflechtung und Videokodierbeschleunigung anstelle oder im Auftrag der Videocodec Engine 3406. In mindestens einem Ausführungsbeispiel umfasst die Medienpipeline 3416 zusätzlich eine Einheit zum Erzeugen von Threads für die Ausführung im 3D/Media-Subsystem 3415. In mindestens einem Ausführungsbeispiel führen die gespawnten Threads Berechnungen für Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Media-Subsystem 3415 umfasst sind.
In mindestens einem Ausführungsbeispiel umfasst das 3D/Media-Subsystem 3415 eine Logik zum Ausführen von Threads, die von der 3D-Pipeline 3412 und der Media-Pipeline 3416 erzeugt werden. In mindestens einem Ausführungsbeispiel senden die 3D-Pipeline 3412 und die Media-Pipeline 3416 Thread-Ausführungsanforderungen an das 3D/Media-Subsystem 3415, das eine Thread-Verteilerlogik umfasst, um verschiedene Anforderungen an verfügbare Thread-Ausführungsressourcen zu vermitteln und zu verteilen. In mindestens einem Ausführungsbeispiel umfassen die Ausführungsressourcen ein Array von Grafikausführungseinheiten zur Verarbeitung von 3D- und Medienthreads. In mindestens einem Ausführungsbeispiel umfasst das 3D/Media-Subsystem 3415 einen oder mehrere interne Caches für Thread-Anweisungen und -Daten. In mindestens einem Ausführungsbeispiel umfasst das Subsystem 3415 auch gemeinsam genutzte Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads gemeinsam zu nutzen und um Ausführungsdaten zu speichern.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in den Grafikprozessor 3400 integriert werden. Beispielsweise können in mindestens einem Ausführungsbeispiel die hier beschriebenen Techniken zum Trainieren und/oder Inferenzieren eine oder mehrere ALUs verwenden, die in der 3D-Pipeline 3412 enthalten sind. Darüber hinaus können in mindestens einem Ausführungsbeispiel die hierin beschriebenen Inferenzieren- und/oder Trainingsoperationen unter Verwendung von anderer Logik als der in 13A oder 13B gezeigten Logik durchgeführt werden. In mindestens einem Ausführungsbeispiel können Gewichtungsparameter in einem On-Chip- oder Off-Chip-Speicher und/oder Registern (gezeigt oder nicht gezeigt) gespeichert sein, die ALUs des Grafikprozessors 3400 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lernalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um das Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
35 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 3510 eines Grafikprozessors gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist die Grafikverarbeitungs-Engine (GPE) 3510 eine Version der in 34 dargestellten GPE 3410. In mindestens einem Ausführungsbeispiel ist die Medienpipeline 3416 optional und kann nicht explizit in GPE 3510 umfasst sein. In mindestens einem Ausführungsbeispiel ist ein separater Medien- und/oder Bildprozessor mit GPE 3510 gekoppelt.
In mindestens einem Ausführungsbeispiel ist GPE 3510 mit einem Befehlsstreamer 3503 gekoppelt oder umfasst diesen, der einen Befehlsstrom für die 3D-Pipeline 3412 und/oder die Medienpipelines 3416 bereitstellt. In mindestens einem Ausführungsbeispiel ist der Befehlsstreamer 3503 mit einem Speicher gekoppelt, bei dem es sich um einen Systemspeicher oder um einen oder mehrere interne Cache-Speicher und gemeinsam genutzte Cache-Speicher handeln kann. In mindestens einem Ausführungsbeispiel empfängt der Befehlsstreamer 3503 Befehle aus dem Speicher und sendet Befehle an die 3D-Pipeline 3412 und/oder die Medien-Pipeline 3416. In mindestens einem Ausführungsbeispiel handelt es sich bei den Befehlen um Anweisungen, Primitive oder Mikrooperationen, die aus einem Ringpuffer geholt werden, in dem Befehle für die 3D-Pipeline 3412 und die Media-Pipeline 3416 gespeichert sind. In mindestens einem Ausführungsbeispiel kann ein Ringpuffer zusätzlich Batch-Befehlspuffer umfassen, die Stapel von mehreren Befehlen speichern. In mindestens einem Ausführungsbeispiel können die Befehle für die 3D-Pipeline 3412 auch Verweise auf im Speicher gespeicherte Daten umfassen, wie z. B. Scheitelpunkt- und Geometriedaten für die 3D-Pipeline 3412 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 3416, ohne darauf beschränkt zu sein. In mindestens einem Ausführungsbeispiel verarbeiten die 3D-Pipeline 3412 und die Medien-Pipeline 3416 Befehle und Daten, indem sie Operationen durchführen oder einen oder mehrere Ausführungsthreads an ein Grafikkern-Array 3514 weiterleiten. In mindestens einem Ausführungsbeispiel umfasst das Grafikkern-Array 3514 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 3515A, Grafikkern(e) 3515B), wobei jeder Block einen oder mehrere Grafikkerne umfasst. In mindestens einem Ausführungsbeispiel umfasst jeder Grafikkern einen Satz von Grafikausführungsressourcen, der eine allgemeine und eine grafikspezifische Ausführungslogik zur Durchführung von Grafik- und Rechenoperationen sowie eine Logik für die Texturverarbeitung mit fester Funktion und/oder eine Logik für maschinelles Lernen und künstliche Intelligenz zur Beschleunigung umfasst, einschließlich einer Inferenz- und/oder Trainingslogik 1315 in 13A und 13B.
In mindestens einem Ausführungsbeispiel umfasst die 3D-Pipeline 3412 eine fest funktionierende und programmierbare Logik zur Verarbeitung eines oder mehrerer Schattierungsprogramme, wie z. B. Vertex-Schattierer, Geometrie-Schattierer, Pixel-Schattierer, Fragment-Schattierer, Rechen-Schattierer oder andere Schattierungsprogramme, durch die Verarbeitung von Befehlen und die Verteilung von Ausführungsthreads an das Grafikkern-Array 3514. In mindestens einem Ausführungsbeispiel stellt das Grafikkern-Array 3514 einen einheitlichen Schritt von Ausführungsressourcen zur Verwendung bei der Verarbeitung von Schattierungsprogrammen bereit. In mindestens einem Ausführungsbeispiel umfasst die Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) innerhalb des/der Grafikkerns/Kerne 3515A-3515B des Grafikkern-Arrays 3514 Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere simultane Ausführungs-Threads ausführen, die mit mehreren Shadern assoziiert sind.
In mindestens einem Ausführungsbeispiel umfasst das Grafikkern-Array 3514 auch eine Ausführungslogik zur Ausführung von Medienfunktionen, wie z. B. Video- und/oder Bildverarbeitung. In mindestens einem Ausführungsbeispiel umfassen die Ausführungseinheiten zusätzlich eine allgemeine Logik, die so programmiert werden kann, dass sie zusätzlich zu den Grafikverarbeitungsoperationen parallele allgemeine Rechenoperationen durchführt.
In mindestens einem Ausführungsbeispiel können von Threads, die auf dem Grafikkern-Array 3514 ausgeführt werden, generierte Ausgabedaten an den Speicher in einem Unified Return Buffer (URB) 3518 ausgegeben werden. Der URB 3518 kann Daten für mehrere Threads speichern. In mindestens einem Ausführungsbeispiel kann der URB 3518 dazu verwendet werden, Daten zwischen verschiedenen Threads zu senden, die auf dem Grafikkern-Array 3514 ausgeführt werden. In mindestens einem Ausführungsbeispiel kann URB 3518 zusätzlich zur Synchronisierung zwischen Threads auf dem Grafikkern-Array 3514 und der festen Funktionslogik innerhalb der gemeinsam genutzten Funktionslogik 3520 genutzt werden.
In mindestens einem Ausführungsbeispiel ist das Grafikkern-Array 3514 skalierbar, so dass das Grafikkern-Array 3514 eine variable Anzahl von Grafikkernen umfasst, von denen jeder eine variable Anzahl von Ausführungseinheiten basierend auf einem angestrebten Energie- und Leistungsniveau des GPE 3510 aufweist. In mindestens einem Ausführungsbeispiel sind die Ausführungsressourcen dynamisch skalierbar, so dass die Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
In mindestens einem Ausführungsbeispiel ist das Grafikkern-Array 3514 mit einer gemeinsam genutzten Funktionslogik 3520 gekoppelt, die mehrere Ressourcen umfasst, die von den Grafikkernen im Grafikkern-Array 3514 gemeinsam genutzt werden. In mindestens einem Ausführungsbeispiel sind die gemeinsam genutzten Funktionen, die von der gemeinsam genutzten Funktionslogik 3520 ausgeführt werden, in Hardware-Logikeinheiten verkörpert, die dem Grafikkern-Array 3514 eine spezielle zusätzliche Funktionalität bereitstellen. In mindestens einem Ausführungsbeispiel umfasst die gemeinsam genutzte Funktionslogik 3520 unter anderem den Sampler 3521, die Mathematik 3522 und die Inter-Thread-Kommunikation (ITC) 3523. In mindestens einem Ausführungsbeispiel sind ein oder mehrere Cache(s) 3525 in der gemeinsam genutzten Funktionslogik 3520 umfasst oder mit dieser gekoppelt.
In mindestens einem Ausführungsbeispiel wird eine gemeinsam genutzte Funktion verwendet, wenn die Nachfrage nach einer speziellen Funktion nicht ausreicht, um sie in das Grafikkern-Array 3514 aufzunehmen. In mindestens einem Ausführungsbeispiel wird eine einzelne Instanziierung einer spezialisierten Funktion in der gemeinsam genutzten Funktionslogik 3520 verwendet und gemeinsam mit anderen Ausführungsressourcen innerhalb des Grafikkern-Arrays 3514 genutzt. In mindestens einem Ausführungsbeispiel können bestimmte gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 3520, die in großem Umfang von Grafikkern-Array 3514 verwendet werden, in der gemeinsam genutzten Funktionslogik 3516 innerhalb des Grafikkern-Arrays 3514 umfasst sein. In mindestens einem Ausführungsbeispiel kann die gemeinsame Funktionslogik 3516 im Grafikkern-Array 3514 einige oder alle Funktionen der gemeinsamen Funktionslogik 3520 umfassen. In mindestens einem Ausführungsbeispiel können alle Logikelemente der gemeinsam genutzten Funktionslogik 3520 in der gemeinsam genutzten Funktionslogik 3516 des Grafikkern-Arrays 3514 dupliziert werden. In mindestens einem Ausführungsbeispiel wird die gemeinsam genutzte Funktionslogik 3520 zugunsten der gemeinsam genutzten Funktionslogik 3516 innerhalb des Grafikkern-Arrays 3514 ausgeschlossen.
Inferenz- und/oder Trainingslogik 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in den Grafikprozessor 3510 integriert werden. Beispielsweise können in mindestens einem Ausführungsbeispiel die hier beschriebenen Techniken zum Trainieren und/oder Inferenzieren eine oder mehrere ALUs in der 3D-Pipeline 3412, Grafikkern(e) 3515A, gemeinsame Funktionslogik 3516, Grafikkern(e) 3515B, gemeinsame Funktionslogik 3520 oder andere Logik in 35 verwenden. Darüber hinaus können in mindestens einem Ausführungsbeispiel die hierin beschriebenen Inferenzieren- und/oder Trainieren-Vorgänge unter Verwendung einer anderen als der in 13A oder 13B gezeigten Logik durchgeführt werden. In mindestens einem Ausführungsbeispiel können Gewichtungsparameter in einem On-Chip- oder Off-Chip-Speicher und/oder Registern (dargestellt oder nicht dargestellt) gespeichert sein, die ALUs des Grafikprozessors 3510 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lemalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
36 zeigt ein Blockdiagramm der Hardwarelogik eines Grafikprozessorkems 3600 gemäß mindestens einem hierin beschriebenen Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist der Grafikprozessorkern 3600 in ein Grafikkern-Array eingeschlossen. In mindestens einem Ausführungsbeispiel kann der Grafikprozessorkern 3600, der manchmal auch als Kernabschnitt bezeichnet wird, ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. In mindestens einem Ausführungsbeispiel ist der Grafikprozessor-Kern 3600 exemplarisch für einen Kernabschnitt, und ein hierin beschriebener Grafikprozessor kann mehrere Kernabschnitte umfassen, basierend auf den angestrebten Energie- und Leistungsumfängen. In mindestens einem Ausführungsbeispiel kann jeder Grafikkern 3600 einen festen Funktionsblock 3630 umfassen, der mit mehreren Unterkemen 3601A-3601F gekoppelt ist, die auch als Unterabschnitte bezeichnet werden und modulare Blöcke einer allgemeinen und festen Funktionslogik umfassen.
In mindestens einem Ausführungsbeispiel umfasst der Festfunktionsblock 3630 eine Geometrie-/Festfunktionspipeline 3636, die von allen Unterkemen im Grafikprozessor 3600 gemeinsam genutzt werden kann, z. B. in Grafikprozessorimplementierungen mit geringerer Leistung und/oder geringerem Energieverbrauch. In mindestens einem Ausführungsbeispiel umfasst die Geometrie/Festfunktionspipeline 3636 eine 3D-Festfunktionspipeline, eine Video-Front-End-Einheit, einen Thread-Spawner und Thread-Verteiler sowie einen Unified-Return-Puffer-Manager, der Unified-Return-Puffer verwaltet.
In mindestens einem Ausführungsbeispiel umfasst der feste Funktionsblock 3630 auch eine Grafik-SoC-Schnittstelle 3637, einen Grafik-Mikrocontroller 3638 und eine Medienpipeline 3639. Die Grafik-SoC-Schnittstelle 3637 stellt eine Schnittstelle zwischen dem Grafikkern 3600 und anderen Prozessorkemen innerhalb einer integrierten System-on-a-Chip-Schaltung bereit. In mindestens einem Ausführungsbeispiel ist der Grafik-Mikrocontroller 3638 ein programmierbarer Unterprozessor, der so konfiguriert werden kann, dass er verschiedene Funktionen des Grafikprozessors 3600 verwaltet, einschließlich Thread-Versand, Planen und Preemption. In mindestens einem Ausführungsbeispiel umfasst die Medienpipeline 3639 eine Logik zur Erleichterung der Dekodierung, Kodierung, Vorverarbeitung und/oder Nachverarbeitung von Multimediadaten, einschließlich Bild- und Videodaten. In mindestens einem Ausführungsbeispiel implementiert die Medienpipeline 3639 Medienoperationen über Anforderungen an die Rechen- oder Sampling-Logik innerhalb der Unterkeme 3601-3601 F.
In mindestens einem Ausführungsbeispiel ermöglicht die SoC-Schnittstelle 3637 dem Grafikkern 3600, mit allgemeinen Anwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC zu kommunizieren, einschließlich Speicherhierarchieelementen wie einem gemeinsam genutzten Cache-Speicher der letzten Ebene, System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. In mindestens einem Ausführungsbeispiel kann die SoC-Schnittstelle 3637 auch die Kommunikation mit Geräten mit fester Funktion innerhalb eines SoC ermöglichen, wie z. B. Kamera-Bildgebungspipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atomik, die gemeinsam von Grafikkern 3600 und CPUs innerhalb eines SoC genutzt werden kann. In mindestens einem Ausführungsbeispiel kann die SoC-Schnittstelle 3637 auch Energieverwaltungssteuerungen für den Grafikkern 3600 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 3600 und anderen Taktdomänen innerhalb eines SoCs ermöglichen. In mindestens einem Ausführungsbeispiel ermöglicht die SoC-Schnittstelle 3637 den Empfang von Befehlspuffern von einem Befehlsstreamer und einem globalen Thread-Verteiler, die so konfiguriert sind, dass sie Befehle und Anweisungen für jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitstellen. In mindestens einem Ausführungsbeispiel können Befehle und Anweisungen an die Medienpipeline 3639 gesendet werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktionspipeline (z. B. Geometrie- und Festfunktionspipeline 3636, Geometrie- und Festfunktionspipeline 3614), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
In mindestens einem Ausführungsbeispiel kann der Grafik-Mikrocontroller 3638 konfiguriert sein, um verschiedene Planungs- und Verwaltungsaufgaben für den Grafikkern 3600 auszuführen. In mindestens einem Ausführungsbeispiel kann der Grafik-Mikrocontroller 3638 die Planung von Grafik- und/oder Rechen-Arbeitslasten auf verschiedenen parallelen Engines innerhalb der Arrays der Ausführungseinheiten (EU) 3602A-3602F, 3604A-3604F innerhalb der Unterkeme 3601A-3601F durchführen. In mindestens einem Ausführungsbeispiel kann die Host-Software, die auf einem CPU-Kern eines SoC ausgeführt wird, der den Grafikkern 3600 umfasst, Arbeitslasten an eine von mehreren Grafikprozessor-Türglocken senden, die einen Planungsvorgang auf einer geeigneten Grafik-Engine aufrufen. In mindestens einem Ausführungsbeispiel umfassen die Planungsvorgänge das Bestimmen der als nächstes auszuführenden Arbeitslast, das Übermitteln einer Arbeitslast an einen Befehlsstreamer, das Vorziehen bestehender Arbeitslasten, die auf einer Engine laufen, das Überwachen des Fortschritts einer Arbeitslast und das Benachrichtigen der Host-Software, wenn eine Arbeitslast abgeschlossen ist. In mindestens einem Ausführungsbeispiel kann der Grafik-Mikrocontroller 3638 auch stromsparende oder Leerlaufzustände für den Grafikkern 3600 erleichtern, indem er dem Grafikkern 3600 die Fähigkeit bereitstellt, Register innerhalb des Grafikkerns 3600 über stromsparende Zustandsübergänge hinweg unabhängig von einem Betriebssystem und/oder einer Grafiktreibersoftware auf einem System zu speichern und wiederherzustellen.
In mindestens einem Ausführungsbeispiel kann der Grafikkern 3600 mehr oder weniger als die beispielhaft gezeigten Unterkeme 3601A-3601F haben, bis zu N modulare Unterkeme. Für jeden Satz von N Unterkernen kann der Grafikkern 3600 in mindestens einem Ausführungsbeispiel auch eine gemeinsam genutzte Funktionslogik 3610, einen gemeinsam genutzten und/oder Cache-Speicher 3612, eine Geometrie-/Festfunktionspipeline 3614 sowie eine zusätzliche Festfunktionslogik 3616 umfassen, um verschiedene Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. In mindestens einem Ausführungsbeispiel kann die gemeinsam genutzte Funktionslogik 3610 logische Einheiten umfassen (z. B. Abtaster-, Mathematik- und/oder Inter-Thread-Kommunikationslogik), die von allen N Unterkemen innerhalb des Grafikkerns 3600 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 3612 kann ein Cache der letzten Ebene für N Unterkeme 3601A-3601F innerhalb des Grafikkerns 3600 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Unterkeme zugreifen können. In mindestens einem Ausführungsbeispiel kann die Geometrie-/Festfunktionspipeline 3614 anstelle der Geometrie-/Festfunktionspipeline 3636 innerhalb des Festfunktionsblocks 3630 umfasst sein und kann gleiche oder ähnliche logische Einheiten umfassen.
In mindestens einem Ausführungsbeispiel umfasst der Grafikkern 3600 zusätzliche feste Funktionslogik 3616, die verschiedene feste Funktionsbeschleunigungslogik zur Verwendung durch den Grafikkern 3600 umfassen kann. In mindestens einem Ausführungsbeispiel umfasst die zusätzliche feste Funktionslogik 3616 eine zusätzliche Geometrie-Pipeline zur Verwendung beim positionsabhängigen Schattieren. Bei der positionsabhängigen Schattierung gibt es mindestens zwei Geometrie-Pipelines, nämlich eine vollständige Geometrie-Pipeline innerhalb der Geometrie-/Festfunktions-Pipeline 3616, 3636, und eine Cull-Pipeline, eine zusätzliche Geometrie-Pipeline, die in der zusätzlichen Festfunktionslogik 3616 umfasst sein kann. In mindestens einem Ausführungsbeispiel ist die Cull-Pipeline eine abgespeckte Version einer vollständigen Geometrie-Pipeline. In mindestens einem Ausführungsbeispiel können eine vollständige Pipeline und eine Cull-Pipeline verschiedene Instanzen einer Anwendung ausführen, wobei jede Instanz einen separaten Kontext hat. In mindestens einem Ausführungsbeispiel kann die positionsabhängige Schattierung lange Ausblendungen von verworfenen Dreiecken verbergen, wodurch die Schattierung in einigen Fällen früher abgeschlossen werden kann. Beispielsweise kann in mindestens einem Ausführungsbeispiel die Cull-Pipeline-Logik innerhalb der zusätzlichen festen Funktionslogik 3616 Positions-Schattierer parallel zu einer Hauptanwendung ausführen und generiert kritische Ergebnisse im Allgemeinen schneller als eine vollständige Pipeline, da die Cull-Pipeline die Positionsattribute von Vertices holt und schattiert, ohne eine Rasterung und ein Rendern von Pixeln in einen Einzelbildpuffer durchzuführen. In mindestens einem Ausführungsbeispiel kann die Cull-Pipeline die generierten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, unabhängig davon, ob diese Dreiecke ausgeblendet sind. In mindestens einem Ausführungsbeispiel kann die vollständige Pipeline (die in diesem Fall als Wiederführungspipeline bezeichnet werden kann) Sichtbarkeitsinformationen verwenden, um ausgeblendete Dreiecke zu überspringen, um nur sichtbare Dreiecke zu schattieren, die schließlich an eine Rasterisierungsphase übergeben werden.
In mindestens einem Ausführungsbeispiel kann die zusätzliche feste Funktionslogik 3616 auch eine Logik zur Beschleunigung des maschinellen Lernens umfassen, wie z. B. eine feste Funktions-Matrixmultiplikationslogik, für Implementierungen, die Optimierungen für das Trainieren oder Inferenzieren des maschinellen Lernens beinhalten.
In mindestens einem Ausführungsbeispiel umfasst jeder grafische Unterkern 3601A-3601F einen Satz von Ausführungsressourcen, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von Grafikpipeline-, Medienpipeline- oder Schattierungsprogrammen durchzuführen. In mindestens einem Ausführungsbeispiel umfassen die Grafik-Unterkerne 3601A-3601F mehrere EU-Arrays 3602A-3602F, 3604A-3604F, Thread-Verteiler- und Inter-Thread-Kommunikationslogik (TD/IC) 3603A-3603F, einen 3D-Sampler (z. B. Textur) 3605A-3605F, einen Medien-Sampler 3606A-3606F, einen Schattierungsprozessor 3607A-3607F und gemeinsam genutzten lokalen Speicher (SLM) 3608A-3608F. Die EU-Arrays 3602A-3602F, 3604A-3604F umfassen jeweils mehrere Ausführungseinheiten, bei denen es sich um allgemeine Grafikverarbeitungseinheiten handelt, die in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienste einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Schattierungsprogrammen. In mindestens einem Ausführungsbeispiel führt die TD/IC-Logik 3603A-3603F lokale Thread-Verteiler- und Thread-Steuerungsoperationen für Ausführungseinheiten innerhalb eines Unterkerns durch und erleichtert die Kommunikation zwischen Threads, die auf Ausführungseinheiten eines Unterkerns ausgeführt werden. In mindestens einem Ausführungsbeispiel kann der 3D-Sampler 3605A-3605F Textur- oder andere 3D-Grafikdaten in den Speicher einlesen. In mindestens einem Ausführungsbeispiel kann der 3D-Sampler basierend auf einem konfigurierten Sampling-Zustand und einem mit einer bestimmten Textur assoziierten Texturformat unterschiedliche Texturdaten lesen. In mindestens einem Ausführungsbeispiel kann der Medienabtaster 3606A-3606F basierend auf einem Typ und einem Format, das mit den Mediendaten assoziiert ist, ähnliche Lesevorgänge durchführen. In mindestens einem Ausführungsbeispiel kann jeder Grafik-Unterkern 3601A-3601F abwechselnd einen vereinheitlichten 3D- und Medien-Sampler umfassen. In mindestens einem Ausführungsbeispiel können Threads, die auf Ausführungseinheiten innerhalb jedes der Unterkeme 3601A-3601F ausgeführt werden, den gemeinsam genutzten lokalen Speicher 3608A-3608F innerhalb jedes Unterkerns nutzen, um Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, die Ausführung unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher zu ermöglichen.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einer oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in den Grafikprozessor 3610 integriert werden. Zum Beispiel können in mindestens einem Ausführungsbeispiel die hier beschriebenen Techniken zum Trainieren und/oder Inferenzieren eine oder mehrere der ALUs verwenden, die in der 3D-Pipeline 3610, dem Grafik-Mikrocontroller 3638, der Geometrie- und FestfunktionsPipeline 3614 und 3636 oder einer anderen Logik in 33 enthalten sind. Darüber hinaus können in mindestens einem Ausführungsbeispiel die hier beschriebenen Inferenzieren- und/oder Trainieren-Vorgänge unter Verwendung einer anderen als der in 13A oder 13B gezeigten Logik durchgeführt werden. In mindestens einem Ausführungsbeispiel können Gewichtungsparameter in einem On-Chip- oder Off-Chip-Speicher und/oder Registern (dargestellt oder nicht dargestellt) gespeichert sein, die ALUs des Grafikprozessors 3600 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lemalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
37A-37B zeigen die Thread-Ausführungslogik 3700, die in mindestens einem Ausführungsbeispiel ein Array von Verarbeitungselementen eines Grafikprozessorkerns umfasst. 37A zeigt mindestens ein Ausführungsbeispiel, in dem die Thread-Ausführungslogik 3700 verwendet wird. 37B zeigt exemplarisch interne Details einer Ausführungseinheit in mindestens einem Ausführungsbeispiel.
Wie in 37A dargestellt, umfasst die Thread-Ausführungslogik 3700 in mindestens einem Ausführungsbeispiel einen Schattierungsprozessor 3702, einen Thread-Verteiler 3704, einen Befehls-Cache 3706, ein skalierbares Ausführungseinheit-Array mit einer Vielzahl von Ausführungseinheiten 3708A-3708N, einen Sampler 3710, einen Daten-Cache 3712 und einen Datenanschluss 3714. In mindestens einem Ausführungsbeispiel kann ein Array skalierbarer Ausführungseinheiten dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z. B. eine der Ausführungseinheiten 3708A, 3708B, 3708C, 3708D bis 3708N-1 und 3708N) basierend auf den rechnerischen Anforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In mindestens einem Ausführungsbeispiel sind die skalierbaren Ausführungseinheiten über eine Verbindungsstruktur miteinander verbunden, die mit jeder Ausführungseinheit eine Verbindung herstellt. In mindestens einem Ausführungsbeispiel umfasst die Thread-Ausführungslogik 3700 eine oder mehrere Verbindungen zum Speicher, z. B. zum Systemspeicher oder zum Cache-Speicher, über einen oder mehrere der Befehlscaches 3706, den Datenanschluss 3714, den Abtaster 3710 und die Ausführungseinheiten 3708A-3708N. In mindestens einem Ausführungsbeispiel ist jede Ausführungseinheit (z. B. 3708A) eine eigenständige programmierbare allgemeine Recheneinheit, die in der Lage ist, mehrere simultane Hardware-Threads auszuführen und dabei mehrere Datenelemente parallel für jeden Thread zu verarbeiten. In mindestens einem Ausführungsbeispiel ist das Array der Ausführungseinheiten 3708A-3708N so skalierbar, dass es eine beliebige Anzahl einzelner Ausführungseinheiten umfasst.
In mindestens einem Ausführungsbeispiel werden die Ausführungseinheiten 3708A-3708N hauptsächlich zur Ausführung von Schattierungsprogrammen verwendet. In mindestens einem Ausführungsbeispiel kann der Schattierungsprozessor 3702 verschiedene Schattierungsprogramme verarbeiten und den Schattierungsprogrammen assoziierte Ausführungsthreads über einen Thread-Verteiler 3704 verteilen. In mindestens einem Ausführungsbeispiel umfasst der Thread-Verteiler 3704 eine Logik zur Vermittlung von Thread-Initiierungsanforderungen von Grafik- und Medienpipelines und zur Instanziierung angeforderter Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 3708A-3708N. Beispielsweise kann in mindestens einem Ausführungsbeispiel eine Geometrie-Pipeline Vertex-, Tesselations- oder Geometrie-Schattierer zur Verarbeitung an die Thread-Ausführungslogik weiterleiten. In mindestens einem Ausführungsbeispiel kann der Thread-Verteiler 3704 auch Laufzeit-Thread-Spawning-Anforderungen von ausführenden Schattierungsprogrammen verarbeiten.
In mindestens einer Ausführungseinheit 3708A-3708N wird ein Befehlssatz unterstützt, der eine native Unterstützung für viele Standard-3D-Grafik-Shader-Befehle umfasst, so dass Schattierungsprogramme aus Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. In mindestens einem Ausführungsbeispiel unterstützen die Ausführungseinheiten die Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertex-Schattierer), die Pixelverarbeitung (z. B. Pixel-Schattierer, Fragment-Schattierer) und die allgemeine Verarbeitung (z. B. Rechen- und Medien-Schattierer). In mindestens einem Ausführungsbeispiel ist jede der Ausführungseinheiten 3708A-3708N, die eine oder mehrere arithmetische Logikeinheiten (ALUs) umfassen, in der Lage, SIMD (Single Instruction Multiple Data) auszuführen, und der Multi-Thread-Betrieb ermöglicht eine effiziente Ausführungsumgebung trotz höherer Latenz bei Speicherzugriffen. In mindestens einem Ausführungsbeispiel verfügt jeder Hardware-Thread innerhalb jeder Ausführungseinheit über eine dedizierte Registerdatei mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand. In mindestens einem Ausführungsbeispiel erfolgt die Ausführung in Pipelines, die Ganzzahl-, Gleitkomma- und Doppelpräzisionsoperationen, SIMD-Verzweigungsfähigkeit, logische Operationen, transzendentale Operationen und andere verschiedene Operationen ausführen können, mit mehreren Ausführungsbeispielen pro Takt. In mindestens einem Ausführungsbeispiel bewirkt die Abhängigkeitslogik innerhalb der Ausführungseinheiten 3708A-3708N beim Warten auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen, dass ein wartender Thread schläft, bis die angeforderten Daten zurückgegeben wurden. In mindestens einem Ausführungsbeispiel können, während ein wartender Thread schläft, Hardware-Ressourcen für die Verarbeitung anderer Threads verwendet werden. Beispielsweise kann in mindestens einem Ausführungsbeispiel eine Ausführungseinheit während einer Verzögerung, die mit einer Vertex-Schattierer-Operation assoziiert ist, Operationen für einen Pixel-Schattierer, Fragment-Schattierer oder eine andere Art von Schattierungsprogramm, einschließlich eines anderen Vertex-Schattierers, durchführen.
In mindestens einem Ausführungsbeispiel arbeitet jede Ausführungseinheit in den Ausführungseinheiten 3708A-3708N mit Arrays von Datenelementen. In mindestens einem Ausführungsbeispiel ist eine Anzahl von Datenelementen die „Ausführungsgröße“ oder die Anzahl von Kanälen für einen Befehl. In mindestens einem Ausführungsbeispiel ist ein Ausführungskanal eine logische Ausführungseinheit für den Zugriff auf Datenelemente, die Maskierung und die Flusssteuerung innerhalb von Befehlen. In mindestens einem Ausführungsbeispiel kann die Anzahl der Kanäle unabhängig von der Anzahl der physischen Arithmetic Logic Units (ALUs) oder Floating Point Units (FPUs) eines bestimmten Grafikprozessors sein. In mindestens einem Ausführungsbeispiel unterstützen die Ausführungseinheiten 3708A-3708N Ganzzahl- und Gleitkomma-Datentypen.
In mindestens einem Ausführungsbeispiel umfasst ein Befehlssatz der Ausführungseinheit SIMD-Befehle. In mindestens einem Ausführungsbeispiel können verschiedene Datenelemente als gepackter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit wird verschiedene Elemente basierend auf der Datengröße der Elemente verarbeiten. Beispielsweise werden in mindestens einem Ausführungsbeispiel bei der Bearbeitung eines 256 Bit breiten Vektors 256 Bits eines Vektors in einem Register gespeichert, und eine Ausführungseinheit bearbeitet einen Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente der Größe Quad-Word (QW)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente der Größe Double Word (DW)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente der Größe Word (W)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente der Größe Byte (B)). In mindestens einem Ausführungsbeispiel sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
In mindestens einem Ausführungsbeispiel können eine oder mehrere Ausführungseinheiten zu einer fusionierten Ausführungseinheit 3709A-3709N mit einer Thread-Steuerungslogik (3707A-3707N) kombiniert werden, die den fusionierten EUs gemeinsam ist. In mindestens einem Ausführungsbeispiel können mehrere EUs zu einer EU-Gruppe fusioniert werden. In mindestens einem Ausführungsbeispiel kann jede EU in einer fusionierten EU-Gruppe so konfiguriert werden, dass sie einen separaten SIMD-Hardware-Thread ausführt. Die Anzahl der EUs in einer fusionierten EU-Gruppe kann gemäß verschiedenen Ausführungsbeispielen variieren. In mindestens einem Ausführungsbeispiel können verschiedene SIMD-Breiten pro EU ausgeführt werden, einschließlich, aber nicht beschränkt auf SIMD8, SIMD16 und SIMD32. In mindestens einem Ausführungsbeispiel umfasst jede fusionierte Grafikausführungseinheit 3709A-3709N mindestens zwei Ausführungseinheiten. Beispielsweise umfasst in mindestens einem Ausführungsbeispiel die fusionierte Ausführungseinheit 3709A eine erste EU 3708A, eine zweite EU 3708B und eine Thread-Steuerlogik 3707A, die der ersten EU 3708A und der zweiten EU 3708B gemeinsam ist. In mindestens einem Ausführungsbeispiel steuert die Thread-Steuerlogik 3707A Threads, die auf der fusionierten Grafikausführungseinheit 3709A ausgeführt werden, so dass jede EU innerhalb der fusionierten Ausführungseinheiten 3709A-3709N unter Verwendung eines gemeinsamen Befehlszeigerregisters ausgeführt werden kann.
In mindestens einem Ausführungsbeispiel umfasst die Thread-Ausführungslogik 3700 einen oder mehrere interne Befehls-Caches (z. B. 3706), um Thread-Befehle für Ausführungseinheiten zu cachen. In mindestens einem Ausführungsbeispiel sind ein oder mehrere Daten-Caches (z.B. 3712) umfasst, um Thread-Daten während der Thread-Ausführung zu cachen. In mindestens einem Ausführungsbeispiel ist ein Sampler 3710 umfasst, um Textur-Sampling für 3D-Operationen und Medien-Sampling für Medien-Operationen bereitzustellen. In mindestens einem Ausführungsbeispiel umfasst der Sampler 3710 eine spezielle Funktionalität für Textur- oder Mediensampling, um Textur- oder Mediendaten während des Samplings zu verarbeiten, bevor die gesampelten Daten einer Ausführungseinheit bereitgestellt werden.
In mindestens einem Ausführungsbeispiel senden Grafik- und Medienpipelines während der Ausführung Thread-Initiierungsanforderungen an die Thread-Ausführungslogik 3700 über eine Thread-Spawning- und Versandlogik. In mindestens einem Ausführungsbeispiel wird, sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, die Pixelprozessorlogik (z. B. Pixel-Schattierer-Logik, Fragment-Schattierer-Logik usw.) innerhalb des Schattierungsprozessors 3702 aufgerufen, um weitere Ausführungsinformationen zu berechnen und zu bewirken, dass die Ergebnisse in Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In mindestens einem Ausführungsbeispiel berechnet ein Pixel-Schattierer oder Fragment-Schattierer die Werte verschiedener Scheitelpunktattribute, die über ein gerastertes Objekt interpoliert werden sollen. In mindestens einem Ausführungsbeispiel führt die Pixel-Schattierer-Logik innerhalb des Schattierungsprozessors 3702 dann ein von der Anwendungsprogrammierschnittstelle (API) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. In mindestens einem Ausführungsbeispiel gibt der Schattierungsprozessor 3702 zur Ausführung eines Schattierungsprogramms Threads über den Thread-Verteiler 3704 an eine Ausführungseinheit (z. B. 3708A) weiter. In mindestens einem Ausführungsbeispiel verwendet der Schattierungsprozessor 3702 die Textur-Sampling-Logik im Abtaster 3710, um auf Texturdaten in Texturkarten zuzugreifen, die im Speicher abgelegt sind. In mindestens einem Ausführungsbeispiel werden durch arithmetische Operationen an Texturdaten und Eingabegeometriedaten Pixelfarbdaten für jedes geometrische Fragment berechnet oder ein oder mehrere Pixel von der weiteren Verarbeitung ausgeschlossen.
In mindestens einem Ausführungsbeispiel stellt der Datenanschluss 3714 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 3700 bereit, um verarbeitete Daten zur weiteren Verarbeitung in einer Grafikprozessor-Ausgabepipeline an den Speicher auszugeben. In mindestens einem Ausführungsbeispiel umfasst der Datenanschluss 3714 einen oder mehrere Cache-Speicher (z. B. Daten-Cache 3712) oder ist mit diesen gekoppelt, um Daten für den Speicherzugriff über einen Datenanschluss zu cachen.
Wie in 37B beispielhaft gezeigt, kann eine Grafikausführungseinheit 3708 in mindestens einem Ausführungsbeispiel eine Befehlsausführungseinheit 3737, ein allgemeines Registerdatei-Array (GRF) 3724, ein architektonisches Registerdatei-Array (ARF) 3726, einen Thread-Arbiter 3722, eine Sendeeinheit 3730, eine Verzweigungseinheit 3732, einen Satz SIMD-Gleitkommaeinheiten (FPUs) 3734 und in mindestens einem Ausführungsbeispiel einen Satz dedizierter ganzzahliger SIMD-ALUs 3735 umfassen. In mindestens einem Ausführungsbeispiel umfassen GRF 3724 und ARF 3726 einen Satz allgemeiner Registerdateien und Architekturregisterdateien, die mit jedem simultanen Hardware-Thread assoziiert sind, der in der grafischen Ausführungseinheit 3708 aktiv sein kann. In mindestens einem Ausführungsbeispiel wird der Architekturzustand pro Thread in ARF 3726 verwaltet, während die während der Thread-Ausführung verwendeten Daten in GRF 3724 gespeichert werden. In mindestens einem Ausführungsbeispiel kann der Ausführungsstatus jedes Threads, einschließlich der Befehlszeiger für jeden Thread, in Thread-spezifischen Registern im ARF 3726 gespeichert werden.
In mindestens einem Ausführungsbeispiel hat die grafische Ausführungseinheit 3708 eine Architektur, die eine Kombination aus simultanem Multi-Threading (SMT) und feingranularem Interleaved Multi-Threading (IMT) ist. In mindestens einem Ausführungsbeispiel weist die Architektur eine modulare Konfiguration auf, die zur Design-Zeit basierend auf einer angestrebten Anzahl simultaner Threads und der Anzahl von Registern pro Ausführungseinheit fein abgestimmt werden kann, wobei die Ressourcen der Ausführungseinheit auf die Logik verteilt werden, die zur Ausführung mehrerer simultaner Threads verwendet wird.
In mindestens einem Ausführungsbeispiel kann die grafische Ausführungseinheit 3708 mehrere Befehle gemeinsam ausgeben, bei denen es sich um unterschiedliche Befehle handeln kann. In mindestens einem Ausführungsbeispiel kann der Thread Arbiter 3722 der grafischen Ausführungseinheit 3708 Befehle an eine der Sendeeinheiten 3730, Verzweigungseinheiten 3742 oder SIMD FPU(s) 3734 zur Ausführung weiterleiten. In mindestens einem Ausführungsbeispiel kann jeder Thread auf 128 allgemeine Register innerhalb des GRF 3724 zugreifen, wobei jedes Register 32 Byte speichern kann, die als SIMD-8-Element-Vektor von 32-Bit-Datenelementen zugänglich sind. In mindestens einem Ausführungsbeispiel hat jeder Thread der Ausführungseinheit Zugriff auf 4 KByte innerhalb des GRF 3724, obwohl Ausführungsbeispiele nicht so beschränkt sind und in anderen Ausführungsbeispielen mehr oder weniger Registerressourcen bereitgestellt werden können. In mindestens einem Ausführungsbeispiel können bis zu sieben Threads simultan ausgeführt werden, wobei die Anzahl der Threads pro Ausführungseinheit je nach Ausführungsbeispiel auch variieren kann. In mindestens einem Ausführungsbeispiel, in dem sieben Threads auf 4 KByte zugreifen können, kann der GRF 3724 insgesamt 28 KByte speichern. In mindestens einem Ausführungsbeispiel können flexible Adressierungsmodi erlauben, dass Register gemeinsam adressiert werden, um effektiv breitere Register zu bilden oder um geschichtete rechteckige Schritt-Datenstrukturen zu repräsentieren.
In mindestens einem Ausführungsbeispiel werden Speicheroperationen, Abtasteroperationen und andere Systemkommunikationen mit längerer Latenzzeit über „Sende“-Befehle abgewickelt, die von der nachrichtenübermittelnden Sendeeinheit 3730 ausgeführt werden. In mindestens einem Ausführungsbeispiel werden Verzweigungsbefehle an eine dedizierte Verzweigungseinheit 3732 weitergeleitet, um SIMD-Divergenz und eventuelle Konvergenz zu erleichtern.
In mindestens einem Ausführungsbeispiel umfasst die grafische Ausführungseinheit 3708 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 3734 zur Durchführung von Gleitkommaoperationen. In mindestens einem Ausführungsbeispiel unterstützen die FPU(s) 3734 auch Ganzzahlberechnungen. In mindestens einem Ausführungsbeispiel kann (können) die FPU(s) 3734 bis zu einer Anzahl von M 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen SIMD ausführen. In mindestens einem Ausführungsbeispiel stellt mindestens eine der FPU(s) eine erweiterte mathematische Funktionalität bereit, um transzendentale mathematische Funktionen mit hohem Durchsatz und 64-Bit-Gleitkommaoperationen mit doppelter Genauigkeit zu unterstützen. In mindestens einem Ausführungsbeispiel ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 3735 vorhanden, die speziell für die Durchführung von Operationen optimiert sein können, die mit maschinellen Lernberechnungen assoziiert sind.
In mindestens einem Ausführungsbeispiel können Arrays aus mehreren Instanzen der Grafikausführungseinheit 3708 in einer Gruppierung von Grafikunterkernen (z. B. einem Abschnitt) instanziiert werden. In mindestens einem Ausführungsbeispiel kann die Ausführungseinheit 3708 Anweisungen über eine Vielzahl von Ausführungskanälen ausführen. In mindestens einem Ausführungsbeispiel wird jeder Thread, der von der grafischen Ausführungseinheit 3708 ausgeführt wird, in einem anderen Kanal ausgeführt.
Die Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel können Teile oder die Gesamtheit der Inferenz- und/oder Trainingslogik 1315 in die Ausführungslogik 3700 integriert werden. Darüber hinaus können in mindestens einem Ausführungsbeispiel die hier beschriebenen Inferenzier- und/oder Trainingsvorgänge unter Verwendung einer anderen als der in 13A oder 13B gezeigten Logik durchgeführt werden. In mindestens einem Ausführungsbeispiel können Gewichtungsparameter in einem On-Chip- oder Off-Chip-Speicher und/oder Registern (dargestellt oder nicht dargestellt) gespeichert sein, die ALUs der Ausführungslogik 3700 konfigurieren, um einen oder mehrere hierin beschriebene maschinelle Lemalgorithmen, neuronale Netzwerkarchitekturen, Anwendungsfälle oder Trainingstechniken durchzuführen.
Die oben beschriebenen Techniken können zum Beispiel verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wird, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
[38 zeigt eine Parallelverarbeitungseinheit („PPU“) 3800 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel ist die PPU 3800 mit einem maschinenlesbaren Code konfiguriert, der, wenn er von der PPU 3800 ausgeführt wird, bewirkt, dass die PPU 3800 einige oder alle der in dieser Offenbarung beschriebenen Prozesse und Techniken ausführt. In mindestens einem Ausführungsbeispiel ist die PPU 3800 ein Multithreading-Prozessor, der auf einem oder mehreren Geräten mit integrierter Schaltung implementiert ist und der Multithreading als eine Technik zum Verbergen von Latenzzeiten nutzt, die dazu entworfen wurde, computerlesbare Befehle (auch als maschinenlesbare Befehle oder einfach Befehle bezeichnet) auf mehreren Threads parallel zu verarbeiten. In mindestens einem Ausführungsbeispiel bezieht sich ein Thread auf einen Ausführungsfaden und ist eine Instanziierung eines Befehlssatzes, der für die Ausführung durch die PPU 3800 konfiguriert ist. In mindestens einem Ausführungsbeispiel ist die PPU 3800 eine Grafikverarbeitungseinheit („GPU“), die so konfiguriert ist, dass sie eine Grafik-Rendering-Pipeline für die Verarbeitung dreidimensionaler („3D“) Grafikdaten implementiert, um zweidimensionale („2D“) Bilddaten für die Anzeige auf einem Gerät wie einer Flüssigkristallanzeige („LCD“) zu generieren. In mindestens einem Ausführungsbeispiel wird die PPU 3800 verwendet, um Berechnungen wie lineare Algebra-Operationen und Operationen des maschinellen Lernens durchzuführen. 38 zeigt einen beispielhaften Parallelprozessor, der nur zu beispielhaften Zwecken dient und als nicht begrenzendes Beispiel für Prozessorarchitekturen zu verstehen ist, die im Rahmen dieser Offenbarung in Betracht gezogen werden, und dass jeder geeignete Prozessor zur Ergänzung und/oder zum Ersatz desselben verwendet werden kann.
In mindestens einem Ausführungsbeispiel sind eine oder mehrere PPUs 3800 so konfiguriert, dass sie High Performance Computing („HPC“)-, Rechenzentrums- und Machine Learning-Anwendungen beschleunigen. In mindestens einem Ausführungsbeispiel ist die PPU 3800 so konfiguriert, dass sie Deep-Learning-Systeme und -Anwendungen beschleunigt, die mindestens die folgenden, nicht einschränkenden Beispiele umfassen: autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalyse, Molekularsimulationen, Arzneimittelentdeckung, Krankheitsdiagnose, Wettervorhersage, Big-Data-Analytik, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Online-Suchoptimierung und personalisierte Benutzerempfehlungen und mehr.
In mindestens einem Ausführungsbeispiel umfasst die PPU 3800 ohne Einschränkung eine Eingabe/Ausgabe-Einheit 3806, eine Front-End-Einheit 3810, eine Planer-Einheit 3812, eine Arbeitsverteilungseinheit 3814, einen Hub 3816, eine Crossbar („Xbar“) 3820, einen oder mehrere allgemeine Verarbeitungscluster („GPCs“) 3818 und eine oder mehrere Partitionseinheiten („Speicherpartitionseinheiten“) 3822. In mindestens einem Ausführungsbeispiel ist die PPU 3800 mit einem Host-Prozessor oder anderen PPUs 3800 über eine oder mehrere Hochgeschwindigkeits-GPU-Verbindungen („GPU-Interconnects“) 3808 verbunden. In mindestens einem Ausführungsbeispiel ist die PPU 3800 mit einem Host-Prozessor oder anderen peripheren Geräten über eine Zwischenverbindung 3802 verbunden. In mindestens einem Ausführungsbeispiel ist die PPU 3800 mit einem lokalen Speicher verbunden, der ein oder mehrere Speichergeräte („Speicher“) 3804 umfasst. In mindestens einem Ausführungsbeispiel umfassen die Speichergeräte 3804 ohne Einschränkung ein oder mehrere Dynamic Random Access Memory („DRAM“) Geräte. In mindestens einem Ausführungsbeispiel sind ein oder mehrere DRAM-Geräte als HBM-Subsysteme konfiguriert und/oder konfigurierbar, wobei mehrere DRAM-Dies in jedem Gerät gestapelt sind.
In mindestens einem Ausführungsbeispiel kann sich die Hochgeschwindigkeits-GPU-Verbindungseinheit 3808 auf eine drahtbasierte Multi-Lane-Kommunikationsverbindung beziehen, die von Systemen verwendet wird, die eine oder mehrere PPUs 3800 in Kombination mit einer oder mehreren Zentraleinheiten („CPUs“) umfassen und skalierbar sind, und die Cache-Kohärenz zwischen PPUs 3800 und CPUs sowie CPU-Mastering unterstützt. In mindestens einem Ausführungsbeispiel werden Daten und/oder Befehle durch die Hochgeschwindigkeits-GPU-Verbindungseinheit 3808 über den Hub 3816 zu/von anderen Einheiten der PPU 3800 übertragen, wie z. B. einer oder mehreren Copy-Engines, Video-Encodern, Video-Decodern, Energieverwaltungseinheiten und anderen Komponenten, die in 38 nicht explizit gezeigt werden können.
In mindestens einem Ausführungsbeispiel ist die E/A-Einheit 3806 so konfiguriert, dass sie Kommunikationen (z. B. Befehle, Daten) von einem (in 38 nicht dargestellten) Host-Prozessor über den Systembus 3802 sendet und empfängt. In mindestens einem Ausführungsbeispiel kommuniziert die E/A-Einheit 3806 mit dem Host-Prozessor direkt über den Systembus 3802 oder über ein oder mehrere zwischengeschaltete Geräte, wie z.B. eine Speicherbrücke. In mindestens einem Ausführungsbeispiel kann die E/A-Einheit 3806 mit einem oder mehreren anderen Prozessoren, z. B. einer oder mehreren PPUs 3800, über den Systembus 3802 kommunizieren. In mindestens einem Ausführungsbeispiel implementiert die E/A-Einheit 3806 eine Peripheral Component Interconnect Express („PCIe“)-Schnittstelle für die Kommunikation über einen PCIe-Bus. In mindestens einem Ausführungsbeispiel implementiert die E/A-Einheit 3806 Schnittstellen für die Kommunikation mit externen Geräten.
In mindestens einem Ausführungsbeispiel dekodiert die E/A-Einheit 3806 über den Systembus 3802 empfangene Pakete. In mindestens einem Ausführungsbeispiel repräsentieren mindestens einige Pakete Befehle, die so konfiguriert sind, dass sie die PPU 3800 veranlassen, verschiedene Operationen durchzuführen. In mindestens einem Ausführungsbeispiel überträgt die E/A-Einheit 3806 dekodierte Befehle an verschiedene andere Einheiten der PPU 3800, wie sie durch die Befehle spezifiziert sind. In mindestens einem Ausführungsbeispiel werden die Befehle an die Front-End-Einheit 3810 und/oder an den Hub 3816 oder andere Einheiten der PPU 3800, wie eine oder mehrere Copy-Engines, einen Video-Encoder, einen Video-Decoder, eine Energieverwaltungseinheit usw., übertragen, (in 38 nicht explizit gezeigt). In mindestens einem Ausführungsbeispiel ist die E/A-Einheit 3806 so konfiguriert, dass sie die Kommunikation zwischen und unter verschiedenen logischen Einheiten der PPU 3800 weiterleitet.
In mindestens einem Ausführungsbeispiel kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 3800 Arbeitslasten zur Verarbeitung bereitstellt. In mindestens einem Ausführungsbeispiel umfasst eine Arbeitslast Befehle und Daten, die von diesen Befehlen verarbeitet werden sollen. In mindestens einem Ausführungsbeispiel ist der Puffer ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 3800 zugreifen können (z. B. Lesen/Schreiben) - eine Host-Schnittstelleneinheit kann so konfiguriert sein, dass sie auf den Puffer in einem Systemspeicher zugreift, der mit dem Systembus 3802 verbunden ist, und zwar über Speicheranforderungen, die von der System-E/A-Einheit 3806 über den Systembus 3802 übertragen werden. In mindestens einem Ausführungsbeispiel schreibt der Hostprozessor einen Befehlsstrom in den Puffer und überträgt dann einen Zeiger auf den Beginn des Befehlsstroms an die PPU 3800, so dass die Front-End-Einheit 3810 Zeiger auf einen oder mehrere Befehlsströme empfängt und einen oder mehrere Befehlsströme verwaltet, indem sie Befehle aus den Befehlsströmen liest und Befehle an verschiedene Einheiten der PPU 3800 weiterleitet.
In mindestens einem Ausführungsbeispiel ist die Front-End-Einheit 3810 mit der Planer-Einheit 3812 gekoppelt, die verschiedene GPCs 3818 zur Verarbeitung von Aufgaben konfiguriert, die durch einen oder mehrere Befehlsströme definiert sind. In mindestens einem Ausführungsbeispiel ist die Planer-Einheit 3812 so konfiguriert, dass sie Zustandsinformationen in Bezug auf verschiedene, von der Planer-Einheit 3812 verwaltete Aufgaben verfolgt, wobei die Zustandsinformationen anzeigen können, welchem der GPCs 3818 eine Aufgabe zugewiesen ist, ob die Aufgabe aktiv oder inaktiv ist, welche Prioritätsstufe der Aufgabe zugeordnet ist und so weiter. In mindestens einem Ausführungsbeispiel verwaltet die Planer-Einheit 3812 die Ausführung einer Vielzahl von Aufgaben auf einem oder mehreren der GPCs 3818.
In mindestens einem Ausführungsbeispiel ist die Planer-Einheit 3812 mit der Arbeitsverteilungseinheit 3814 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den GPCs 3818 verteilt. In mindestens einem Ausführungsbeispiel verfolgt die Arbeitsverteilungseinheit 3814 eine Anzahl geplanter Aufgaben, die von der Planer-Einheit 3812 empfangen wurden, und die Arbeitsverteilungseinheit 3814 verwaltet einen Pool ausstehender Aufgaben und einen Pool aktiver Aufgaben für jeden der GPCs 3818. In mindestens einem Ausführungsbeispiel umfasst der Pool ausstehender Aufgaben eine Anzahl von Slots (z.B. 32 Slots), die Aufgaben enthalten, die zur Verarbeitung durch einen bestimmten GPC 3818 zugewiesen sind; der Pool aktiver Aufgaben kann eine Anzahl von Slots (z.B. 4 Slots) für Aufgaben umfassen, die aktiv von den GPCs 3818 verarbeitet werden, so dass, wenn einer der GPCs 3818 die Ausführung einer Aufgabe abschließt, diese Aufgabe aus dem Pool aktiver Aufgaben für den GPC 3818 entfernt wird und eine der anderen Aufgaben aus dem Pool ausstehender Aufgaben ausgewählt und zur Ausführung auf dem GPC 3818 geplant wird. In mindestens einem Ausführungsbeispiel wird, wenn eine aktive Aufgabe auf dem GPC 3818 inaktiv ist, beispielsweise während des Wartens auf die Auflösung einer Datenabhängigkeit, die aktive Aufgabe aus dem GPC 3818 entfernt und in den Pool aktiver Aufgaben zurückgeführt, während eine andere Aufgabe aus dem Pool ausstehender Aufgaben ausgewählt und für die Ausführung auf dem GPC 3818 geplant wird.
In mindestens einem Ausführungsbeispiel kommuniziert die Arbeitsverteilungseinheit 3814 mit einem oder mehreren GPCs 3818 über XBar 3820. In mindestens einem Ausführungsbeispiel ist XBar 3820 ein Verbindungsnetzwerk, das viele Einheiten der PPU 3800 mit anderen Einheiten der PPU 3800 koppelt und konfiguriert werden kann, um die Arbeitsverteilungseinheit 3814 mit einem bestimmten GPC 3818 zu koppeln. In mindestens einem Ausführungsbeispiel können auch eine oder mehrere andere Einheiten der PPU 3800 über den Hub 3816 mit der XBar 3820 verbunden sein.
In mindestens einem Ausführungsbeispiel werden Aufgaben von der Planer-Einheit 3812 verwaltet und von der Arbeitsverteilungseinheit 3814 an einen der GPCs 3818 weitergeleitet. GPC 3818 ist konfiguriert, um Aufgaben zu verarbeiten und Ergebnisse zu generieren. In mindestens einem Ausführungsbeispiel können die Ergebnisse von anderen Aufgaben innerhalb des GPC 3818 verwendet, über die XBar 3820 an einen anderen GPC 3818 weitergeleitet oder im Speicher 3804 abgelegt werden. In mindestens einem Ausführungsbeispiel können Ergebnisse über Partitionseinheiten 3822 in den Speicher 3804 geschrieben werden, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in/aus dem Speicher 3804 implementieren. In mindestens einem Ausführungsbeispiel können die Ergebnisse über eine Hochgeschwindigkeits-GPU-Verbindung 3808 an eine andere PPU 3804 oder CPU übertragen werden. In mindestens einem Ausführungsbeispiel umfasst die PPU 3800 ohne Einschränkung eine Anzahl U von Partitionseinheiten 3822, die der Anzahl von separaten und unterschiedlichen Speichergeräten 3804 entspricht, die mit der PPU 3800 gekoppelt sind. In mindestens einem Ausführungsbeispiel wird die Partitionseinheit 3822 hier in Verbindung mit 40 im Detail beschrieben.
In mindestens einem Ausführungsbeispiel führt ein Hostprozessor einen Treiberkernel aus, der eine Anwendungsprogrammierschnittstelle („API“) implementiert, die es einer oder mehreren auf dem Hostprozessor ausgeführten Anwendungen ermöglicht, Operationen zur Ausführung auf der PPU 3800 zu planen. In mindestens einem Ausführungsbeispiel werden mehrere Rechenanwendungen simultan von der PPU 3800 ausgeführt, und die PPU 3800 stellt Isolierung, Dienstgüte („QoS“) und unabhängige Adressräume für mehrere Rechenanwendungen bereit. In mindestens einem Ausführungsbeispiel generiert eine Anwendung Anweisungen (z. B. in Form von API-Aufrufen), die den Treiberkernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 3800 zu generieren, und der Treiberkernel gibt Aufgaben an einen oder mehrere Streams aus, die von der PPU 3800 verarbeitet werden. In mindestens einem Ausführungsbeispiel umfasst jede Aufgabe eine oder mehrere Gruppen von zusammenhängenden Threads, die als Warp bezeichnet werden können. In mindestens einem Ausführungsbeispiel umfasst ein Warp eine Vielzahl von zusammenhängenden Threads (z. B. 32 Threads), die parallel ausgeführt werden können. In mindestens einem Ausführungsbeispiel können sich zusammenarbeitende Threads auf eine Vielzahl von Threads beziehen, die Anweisungen zur Ausführung einer Aufgabe umfassen und Daten über gemeinsam genutzte Speicher austauschen. In mindestens einem Ausführungsbeispiel werden Threads und zusammenarbeitende Threads gemäß mindestens einem Ausführungsbeispiel in Verbindung mit 40 detaillierter beschrieben.
Inferenz- und/oder Trainingslogiken 1315 werden zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel wird der Deep-Learning-Anwendungsprozessor zum Trainieren eines maschinellen Lernmodells, wie z. B. eines neuronalen Netzwerks, verwendet, um Informationen, die der PPU 3800 bereitgestellt werden, vorherzusagen oder zu inferieren. In mindestens einem Ausführungsbeispiel wird der Deep Learning-Anwendungsprozessor 3800 verwendet, um Informationen basierend auf einem trainierten maschinellen Lernmodell (z. B. einem neuronalen Netzwerk), das von einem anderen Prozessor oder System oder von der PPU 3800 trainiert wurde, zu inferieren oder vorherzusagen. In mindestens einem Ausführungsbeispiel kann PPU 3800 verwendet werden, um einen oder mehrere hierin beschriebene Anwendungsfälle eines neuronalen Netzwerks durchzuführen.
Die oben beschriebenen Techniken können beispielsweise verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um das Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
[39 zeigt einen allgemeinen Verarbeitungscluster („GPC“) 3900 gemäß mindestens einem Ausführungsbeispiel. In mindestens einem Ausführungsbeispiel handelt es sich bei GPC 3900 um GPC 3818 aus 38. In mindestens einem Ausführungsbeispiel umfasst jeder GPC 3900 ohne Einschränkung eine Anzahl von Hardware-Einheiten zur Verarbeitung von Aufgaben, und jeder GPC 3900 umfasst ohne Einschränkung einen Pipeline-Manager 3902, eine Pre-Raster-Operations-Einheit („PROP“) 3904, eine Raster-Engine 3908, eine Arbeitsverteilungs-Crossbar („WDX“) 3916, eine Speicher-Management-Einheit („MMU“) 3918, einen oder mehrere Datenverarbeitungs-Cluster („DPCs“) 3906 und jede geeignete Kombination von Teilen.
In mindestens einem Ausführungsbeispiel wird der Betrieb des GPC 3900 durch den Pipeline-Manager 3902 gesteuert. In mindestens einem Ausführungsbeispiel verwaltet der Pipeline-Manager 3902 die Konfiguration eines oder mehrerer DPCs 3906 zur Verarbeitung von Aufgaben, die dem GPC 3900 zugewiesen sind. In mindestens einem Ausführungsbeispiel konfiguriert der Pipeline-Manager 3902 mindestens einen von einem oder mehreren DPCs 3906, um mindestens einen Teil einer Grafik-Rendering-Pipeline zu implementieren. In mindestens einem Ausführungsbeispiel ist der DPC 3906 so konfiguriert, dass er ein Schattierungsprogramm auf einem programmierbaren Streaming-Multiprozessor („SM“) 3914 ausführt. In mindestens einem Ausführungsbeispiel ist der Pipeline-Manager 3902 so konfiguriert, dass er von einer Arbeitsverteilungseinheit empfangene Pakete an geeignete logische Einheiten innerhalb des GPC 3900 weiterleitet, wobei einige Pakete an Hardwareeinheiten mit fester Funktionalität im PROP 3904 und/oder in der Rasterengine 3908 weitergeleitet werden können, während andere Pakete an DPCs 3906 zur Verarbeitung durch eine Primitiv-Engine 3912 oder SM 3914 weitergeleitet werden können. In mindestens einem Ausführungsbeispiel ist der Pipeline-Manager 3902 so konfiguriert, dass mindestens eine der DPCs 3906 ein Modell eines neuronalen Netzwerks und/oder eine Rechenpipeline implementiert.
In mindestens einem Ausführungsbeispiel ist die PROP-Einheit 3904 so konfiguriert, dass sie die von der Rasterengine 3908 und den DPCs 3906 generierten Daten an eine Raster Operations („ROP“)-Einheit in der Partitionseinheit 3822 weiterleitet, die oben in Verbindung mit 38 ausführlicher beschrieben ist. In mindestens einem Ausführungsbeispiel ist die PROP-Einheit 3904 so konfiguriert, dass sie Optimierungen für die Farbmischung durchführt, Pixeldaten organisiert, Adressübersetzungen vornimmt und vieles mehr. In mindestens einem Ausführungsbeispiel umfasst die Rasterengine 3908 ohne Einschränkung eine Anzahl von Hardware-Einheiten mit fester Funktion, die so konfiguriert sind, dass sie verschiedene Rasteroperationen durchführen, und die Rasterengine 3908 umfasst in mindestens einem Ausführungsbeispiel ohne Einschränkung eine Setup-Engine, eine Grobraster-Engine, eine Culling-Engine, eine Clipping-Engine, eine Feinraster-Engine, eine Tile-Coalescing-Engine und jede geeignete Kombination davon. In mindestens einem Ausführungsbeispiel empfängt die Setup-Engine transformierte Vertices und generiert Ebenengleichungen, die mit einer durch Vertices definierten geometrischen Primitive assoziiert sind; die Ebenengleichungen werden an eine grobe Rasterengine übertragen, um Abdeckungsinformationen (z. B. eine x-, y-Abdeckungsmaske für eine Kachel) für die Primitive zu generieren; die Ausgabe der groben Rasterengine wird an eine Ausblend-Engine übertragen, in der Fragmente, die mit der Primitive assoziiert sind und einen z-Test nicht bestehen, abgeschnitten werden, und an eine Abschneide-Engine übertragen, in der Fragmente, die außerhalb eines Sichtkegelstumpfes liegen, abgeschnitten werden. In mindestens einem Ausführungsbeispiel werden Fragmente, die das Abschneiden und Ausblenden überstehen, an eine feine Rasterengine weitergeleitet, um Attribute für Pixelfragmente basierend auf den von der Setup-Engine generierten Ebenengleichungen zu generieren. In mindestens einem Ausführungsbeispiel umfasst die Ausgabe der Rasterengine 3908 Fragmente, die von einer geeigneten Einheit, wie z. B. einer in DPC 3906 implementierten Fragment-Schattierung, verarbeitet werden.
In mindestens einem Ausführungsbeispiel umfasst jeder DPC 3906, der in GPC 3900 enthalten ist, ohne Einschränkung eine M-Pipe-Steuerung („MPC“) 3910, eine primitive Engine 3912, eine oder mehrere SMs 3914 und jede geeignete Kombination davon. In mindestens einem Ausführungsbeispiel steuert MPC 3910 den Betrieb von DPC 3906 und leitet die vom Pipeline-Manager 3902 empfangenen Pakete an die entsprechenden Einheiten in DPC 3906 weiter. In mindestens einem Ausführungsbeispiel werden mit einem Scheitelpunkt assoziierte Pakete an die primitive Engine 3912 weitergeleitet, die so konfiguriert ist, dass sie mit dem Scheitelpunkt assoziierte Scheitelpunktattribute aus dem Speicher holt; im Gegensatz dazu können mit einem Schattierungsprogramm assoziierte Pakete an SM 3914 übertragen werden.
In mindestens einem Ausführungsbeispiel umfasst SM 3914 ohne Einschränkung einen programmierbaren Streaming-Prozessor, der für die Verarbeitung von Aufgaben konfiguriert ist, die durch eine Anzahl von Threads repräsentiert werden. In mindestens einem Ausführungsbeispiel ist SM 3914 multi-threaded und so konfiguriert, dass er eine Vielzahl von Threads (z.B. 32 Threads) aus einer bestimmten Gruppe von Threads gleichzeitig ausführt und eine SIMD-Architektur („Single-Instruction, Multiple-Data“) implementiert, bei der jeder Thread in einer Gruppe von Threads (z.B. ein Warp) so konfiguriert ist, dass er einen anderen Datensatz basierend auf demselben Befehlssatz verarbeitet. In mindestens einem Ausführungsbeispiel führen alle Threads in einer Gruppe von Threads dieselben Befehle aus. In mindestens einem Ausführungsbeispiel implementiert SM 3914 eine Single-Instruction, Multiple Thread („SIMT“)-Architektur, wobei jeder Thread in einer Gruppe von Threads so konfiguriert ist, dass er einen anderen Datensatz basierend auf demselben Befehlssatz verarbeitet, wobei jedoch einzelne Threads in der Gruppe von Threads während der Ausführung divergieren dürfen. In mindestens einem Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden Warp beibehalten, was eine Gleichzeitigkeit zwischen Warps und eine serielle Ausführung innerhalb von Warps ermöglicht, wenn Threads innerhalb eines Warps divergieren. In einem anderen Ausführungsbeispiel werden ein Programmzähler, ein Aufrufstapel und ein Ausführungsstatus für jeden einzelnen Thread beibehalten, was eine gleiche Gleichzeitigkeit zwischen allen Threads innerhalb und zwischen Warps ermöglicht. In mindestens einem Ausführungsbeispiel wird der Ausführungsstatus für jeden einzelnen Thread beibehalten, und Threads, die dieselben Befehle ausführen, können zur Verbesserung der Effizienz zusammengeführt und parallel ausgeführt werden. Mindestens ein Ausführungsbeispiel von SM 3914 wird hier im Detail beschrieben.
In mindestens einem Ausführungsbeispiel stellt die MMU 3918 eine Schnittstelle zwischen dem GPC 3900 und der Speicherpartitionseinheit (z. B. der Partitionseinheit 3822 in 38) bereit, und die MMU 3918 übersetzt virtuelle Adressen in physikalische Adressen, sorgt für Speicherschutz und Arbitrierung von Speicheranforderungen. In mindestens einem Ausführungsbeispiel stellt MMU 3918 einen oder mehrere Übersetzungs-Lookaside-Puffer („TLBs“) bereit, um die Übersetzung von virtuellen Adressen in physische Adressen im Speicher durchzuführen.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel wird ein Deep-Learning-Anwendungsprozessor verwendet, um ein maschinelles Lernmodell, wie z. B. ein neuronales Netzwerk, zu trainieren, um Informationen, die dem GPC 3900 bereitgestellt werden, vorherzusagen oder zu inferieren. In mindestens einem Ausführungsbeispiel wird GPC 3900 verwendet, um Informationen basierend auf einem trainierten maschinellen Lernmodell (z. B. neuronales Netzwerk), das von einem anderen Prozessor oder System oder von GPC 3900 trainiert wurde, zu inferieren oder vorherzusagen. In mindestens einem Ausführungsbeispiel kann GPC 3900 verwendet werden, um einen oder mehrere hierin beschriebene Anwendungsfälle eines neuronalen Netzwerks durchzuführen.
Die oben beschriebenen Techniken können beispielsweise verwendet werden, um ein System für den Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um das Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
40 zeigt gemäß mindestens einem Ausführungsbeispiel eine Speicherpartitionseinheit 4000 einer Parallelverarbeitungseinheit („PPU“). In mindestens einem Ausführungsbeispiel umfasst die Speicherpartitionseinheit 4000 ohne Einschränkung eine Einheit 4002 für Rasteroperationen („ROP“), einen Level-1-Cache 4004 („L2“), eine Speicherschnittstelle 4006 und jede geeignete Kombination davon. Die Speicherschnittstelle 4006 ist mit dem Speicher gekoppelt. Die Speicherschnittstelle 4006 kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder Ähnliches für die Hochgeschwindigkeitsdatenübertragung implementieren. In mindestens einem Ausführungsbeispiel verfügt die PPU über U Speicherschnittstellen 4006, eine Speicherschnittstelle 4006 pro Paar Partitionseinheiten 4000, wobei jedes Paar Partitionseinheiten 4000 mit einem entsprechenden Speichergerät verbunden ist. In mindestens einem Ausführungsbeispiel kann die PPU beispielsweise mit bis zu Y Speichergeräten verbunden sein, wie z. B. Speicherstapeln mit hoher Bandbreite oder synchronem Dynamic Random Access Memory („GDDR5 SDRAM“) der Version 5 mit doppelter Datenrate.
In mindestens einem Ausführungsbeispiel implementiert die Speicherschnittstelle 4006 eine Speicherschnittstelle der zweiten Generation für Speicher mit hoher Bandbreite („HBM2“), und Y entspricht der Hälfte von U. In mindestens einem Ausführungsbeispiel befinden sich die HBM2-Speicherstapel in demselben Gehäuse wie die PPU, was im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen erhebliche Energie- und Flächeneinsparungen bereitstellt. In mindestens einem Ausführungsbeispiel umfasst jeder HBM2-Stapel ohne Einschränkung vier Speicherchips und Y ist gleich 4, wobei jeder HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit umfasst. In mindestens einem Ausführungsbeispiel unterstützt der Speicher den Single-Error Correcting Double-Error Detecting („SECDED“) Error Correction Code („ECC“) zum Schutz der Daten. ECC stellt eine höhere Zuverlässigkeit für Datenverarbeitungsanwendungen bereit, die empfindlich auf Datenverfälschung reagieren.
In mindestens einem Ausführungsbeispiel implementiert die PPU eine mehrstufige Speicherhierarchie. In mindestens einem Ausführungsbeispiel unterstützt die Speicherpartitionseinheit 4000 einen einheitlichen Speicher, um einen einzigen einheitlichen virtuellen Adressraum für die Zentraleinheit („CPU“) und den PPU-Speicher bereitzustellen, was die gemeinsame Nutzung von Daten zwischen virtuellen Speichersystemen ermöglicht. In mindestens einem Ausführungsbeispiel wird die Häufigkeit von Zugriffen einer PPU auf den Speicher anderer Prozessoren verfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU verschoben werden, die häufiger auf Seiten zugreift. In mindestens einem Ausführungsbeispiel unterstützt die Hochgeschwindigkeits-GPU-Verbindung 3808 Adressübersetzungsdienste, die es der PPU ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen, und die der PPU vollen Zugriff auf den CPU-Speicher bereitstellen.
In mindestens einem Ausführungsbeispiel übertragen Copy-Engines Daten zwischen mehreren PPUs oder zwischen PPUs und CPUs. In mindestens einem Ausführungsbeispiel können Copy-Engines Seitenfehler für Adressen generieren, die nicht in Seitentabellen zugeordnet sind, und die Speicherpartitionseinheit 4000 übernimmt dann die Generierung von Seitenfehlern und ordnet die Adressen der Seitentabelle zu, woraufhin die Copy-Engine die Übertragung durchführt. In mindestens einem Ausführungsbeispiel wird der Speicher für mehrere Copy-Engine-Operationen zwischen mehreren Prozessoren gepinnt (d. h. nicht auslagerbar), wodurch der verfügbare Speicher erheblich reduziert wird. In mindestens einem Ausführungsbeispiel können mit Hardware Page Faulting Adressen an Copy-Engines weitergegeben werden, ohne Rücksicht darauf, ob Speicherseiten vorhanden sind, und der Kopiervorgang ist transparent.
Gemäß mindestens einem Ausführungsbeispiel werden Daten aus dem Speicher 3804 von 38 oder einem anderen Systemspeicher von der Speicherpartitionseinheit 4000 geholt und im L2-Cache 4004 gespeichert, der sich auf dem Chip befindet und von verschiedenen GPCs gemeinsam genutzt wird. Jede Speicherpartitionseinheit 4000 umfasst in mindestens einem Ausführungsbeispiel ohne Einschränkung mindestens einen Teil des L2-Cache, der einem entsprechenden Speichergerät zugeordnet ist. In mindestens einem Ausführungsbeispiel sind Caches der unteren Ebene in verschiedenen Einheiten innerhalb der GPCs implementiert. In mindestens einem Ausführungsbeispiel kann jeder SM 3914 einen Level-1-Cache („L1“) implementieren, wobei der L1-Cache ein privater Speicher ist, der einem bestimmten SM 3914 zugeordnet ist, und Daten aus dem L2-Cache 4004 geholt und in jedem der LI-Caches zur Verarbeitung in den funktionalen Einheiten der SMs 3914 gespeichert werden. In mindestens einem Ausführungsbeispiel ist der L2-Cache 4004 mit der Speicherschnittstelle 4006 und der XBar 3820 gekoppelt.
Die ROP-Einheit 4002 führt in mindestens einem Ausführungsbeispiel Grafikrasteroperationen durch, die sich auf die Pixelfarbe beziehen, wie z. B. Farbkomprimierung, Pixelüberblendung und mehr. In mindestens einem Ausführungsbeispiel implementiert die ROP-Einheit 4002 eine Tiefenprüfung in Verbindung mit der Rasterengine 3908, wobei sie von der Culling-Engine der Rasterengine 3908 eine Tiefe für eine einem Pixelfragment assoziierte Sampling-Position empfängt. In mindestens einem Ausführungsbeispiel wird die Tiefe gegen eine entsprechende Tiefe in einem Tiefenpuffer für eine mit dem Fragment assoziierte Abtaststelle getestet. In mindestens einem Ausführungsbeispiel aktualisiert die ROP-Einheit 4002 den Tiefenpuffer und überträgt das Ergebnis des Tiefentests an die Rasterengine 3908, wenn das Fragment den Tiefentest für den Abtastort besteht. Es ist zu beachten, dass die Anzahl der Partitionseinheiten 4000 sich von der Anzahl der GPCs unterscheiden kann und daher kann jede ROP-Einheit 4002 in mindestens einem Ausführungsbeispiel mit jedem der GPCs gekoppelt sein. In mindestens einem Ausführungsbeispiel verfolgt die ROP-Einheit 4002 die von verschiedenen GPCs empfangenen Pakete und bestimmt, an welche ein von der ROP-Einheit 4002 generiertes Ergebnis über die XBar 3820 weitergeleitet wird.
41 zeigt gemäß mindestens einem Ausführungsbeispiel einen Streaming-Multiprozessor („SM“) 4100. In mindestens einem Ausführungsbeispiel handelt es sich bei SM 4100 um SM aus 39. In mindestens einem Ausführungsbeispiel umfasst SM 4100 ohne Einschränkung einen Befehls-Cache 4102; eine oder mehrere Planer-Einheiten 4104; eine Registerdatei 4108; einen oder mehrere Verarbeitungskeme („Kerne“) 4110; eine oder mehrere spezielle Funktionseinheiten („SFUs“) 4112; eine oder mehrere Lade-/Speicher-Einheiten („LSUs“) 4114; ein Verbindungsnetzwerk 4116; einen gemeinsam genutzten Speicher/Level-1-Cache 4118; und jede geeignete Kombination davon. In mindestens einem Ausführungsbeispiel verteilt eine Arbeitsverteilungseinheit Aufgaben zur Ausführung auf allgemeinen Verarbeitungsclustern („GPCs“) von Parallelverarbeitungseinheiten („PPUs“), und jede Aufgabe wird einem bestimmten Datenverarbeitungscluster („DPC“) innerhalb eines GPCs zugeordnet, und wenn die Aufgabe mit einem Schattierungsprogramm assoziiert ist, wird die Aufgabe einem der SMs 4100 zugeordnet. In mindestens einem Ausführungsbeispiel empfängt die Planer-Einheit 4104 Aufgaben von der Arbeitsverteilungseinheit und verwaltet die Befehlsplanung für einen oder mehrere Thread-Blöcke, die dem SM 4100 zugewiesen sind. In mindestens einem Ausführungsbeispiel plant die Planer-Einheit 4104 Thread-Blöcke für die Ausführung als Warps von parallelen Threads, wobei jedem Thread-Block mindestens ein Warp zugewiesen wird. In mindestens einem Ausführungsbeispiel führt jeder Warp Threads aus. In mindestens einem Ausführungsbeispiel verwaltet die Planer-Einheit 4104 eine Vielzahl verschiedener Thread-Blöcke, indem sie verschiedenen Thread-Blöcken Warps zuweist und dann während jedes Taktzyklus Befehle aus einer Vielzahl verschiedener Cooperative Groups an verschiedene Funktionseinheiten (z. B. Verarbeitungskerne 4110, SFUs 4112 und LSUs 4114) verteilt.
In mindestens einem Ausführungsbeispiel können sich Cooperative Groups auf ein Programmiermodell für die Organisation von Gruppen kommunizierender Threads beziehen, das es den Entwicklern ermöglicht, die Granularität auszudrücken, mit der Threads miteinander kommunizieren, und so reichhaltigere, effizientere parallele Dekompositionen zu erstellen. In mindestens einem Ausführungsbeispiel unterstützen kooperative Start-APIs die Synchronisierung zwischen Thread-Blöcken zur Ausführung paralleler Algorithmen. In mindestens einem Ausführungsbeispiel stellen Anwendungen konventioneller Programmiermodelle ein einziges, einfaches Konstrukt zur Synchronisierung kooperierender Threads bereit: eine Barriere über alle Threads eines Thread-Blocks (z. B. die Funktion syncthreads( )). In mindestens einem Ausführungsbeispiel können Programmierer jedoch Gruppen von Threads mit einer Granularität definieren, die kleiner ist als die des Thread-Blocks, und innerhalb der definierten Gruppen synchronisieren, um eine höhere Leistung, Design-Flexibilität und Software-Wiederverwendung in Form von gemeinsamen gruppenweiten Funktionsschnittstellen zu ermöglichen. In mindestens einem Ausführungsbeispiel können Programmierer mit Cooperative Groups explizit Gruppen von Threads mit Subblock- (d. h. so klein wie ein einzelner Thread) und Multiblock-Granularität definieren und kollektive Operationen wie Synchronisierung auf Threads in einer Cooperative Group durchführen. Das Programmiermodell unterstützt eine saubere Komposition über Software-Grenzen hinweg, so dass Bibliotheken und Dienstprogramme innerhalb ihres lokalen Kontexts sicher synchronisieren können, ohne Annahmen über Konvergenz treffen zu müssen. In mindestens einem Ausführungsbeispiel ermöglichen Cooperative Groups-Primitive neue Muster kooperativer Parallelität, einschließlich, ohne Einschränkung, Producer-Consumer-Parallelität, opportunistischer Parallelität und globaler Synchronisierung über ein gesamtes Gitter von Thread-Blöcken.
In mindestens einem Ausführungsbeispiel ist eine Verteilungseinheit 4106 so konfiguriert, dass sie Befehle an eine oder mehrere Funktionalitätseinheiten überträgt, und die Planer-Einheit 4104 umfasst ohne Einschränkung zwei Verteilungseinheiten 4106, die es ermöglichen, dass zwei verschiedene Befehle aus demselben Warp während jedes Taktzyklus verteilt werden. In mindestens einem Ausführungsbeispiel umfasst jede Planer-Einheit 4104 eine einzelne Verteilungseinheit 4106 oder zusätzliche Verteilungseinheiten 4106.
In mindestens einem Ausführungsbeispiel umfasst jedes SM 4100 in mindestens einem Ausführungsbeispiel ohne Einschränkung eine Registerdatei 4108, die einen Satz von Registern für funktionale Einheiten des SM 4100 bereitstellt. In mindestens einem Ausführungsbeispiel ist die Registerdatei 4108 zwischen den einzelnen funktionalen Einheiten aufgeteilt, so dass jeder funktionalen Einheit ein bestimmter Teil der Registerdatei 4108 zugeordnet ist. In mindestens einem Ausführungsbeispiel ist die Registerdatei 4108 zwischen verschiedenen Warps aufgeteilt, die von SM 4100 ausgeführt werden, und die Registerdatei 4108 stellt temporären Speicher für Operanden bereit, die mit Datenpfaden von funktionalen Einheiten verbunden sind. In mindestens einem Ausführungsbeispiel umfasst jedes SM 4100 ohne Einschränkung eine Vielzahl von L-Verarbeitungskernen 4110. In mindestens einem Ausführungsbeispiel umfasst SM 4100 ohne Einschränkung eine große Anzahl (z. B. 128 oder mehr) verschiedener Verarbeitungskerne 4110. In mindestens einem Ausführungsbeispiel umfasst jeder Verarbeitungskern 4110 in mindestens einem Ausführungsbeispiel ohne Einschränkung eine Vollpipeline-, einfachpräzise, doppeltpräzise und/oder gemischtpräzise Verarbeitungseinheit, die ohne Einschränkung eine arithmetische Gleitkomma-Logikeinheit und eine arithmetische Ganzzahl-Logikeinheit umfasst. In mindestens einem Ausführungsbeispiel implementieren Gleitkomma-Arithmetik-Logikeinheiten den Standard IEEE 754-2008 für Gleitkomma-Arithmetik. In mindestens einem Ausführungsbeispiel umfassen die Verarbeitungskeme 4110 ohne Einschränkung 64 Gleitkomma-Kerne mit einfacher Genauigkeit (32 Bit), 64 Ganzzahl-Kerne, 32 Gleitkomma-Kerne mit doppelter Genauigkeit (64 Bit) und 8 Tensor-Kerne.
Tensor-Kerne sind gemäß mindestens einem Ausführungsbeispiel zur Durchführung von Matrixoperationen konfiguriert. In mindestens einem Ausführungsbeispiel sind ein oder mehrere Tensor-Kerne in den Verarbeitungskemen 4110 umfasst. In mindestens einem Ausführungsbeispiel sind die Tensorkerne so konfiguriert, dass sie Deep Learning-Matrixarithmetik durchführen, wie z. B. Faltungsoperationen zum Trainieren und Inferenzieren von neuronalen Netzwerken. In mindestens einem Ausführungsbeispiel arbeitet jeder Tensorkern mit einer 4x4-Matrix und führt eine Matrixmultiplikations- und Akkumulationsoperation D = A X B + C durch, wobei A, B, C und D 4x4-Matrizen sind.
In mindestens einem Ausführungsbeispiel handelt es sich bei den Eingaben für die Matrixmultiplikation A und B um 16-Bit-Gleitkommamatrizen und bei den Akkumulationsmatrizen C und D um 16-Bit-Gleitkomma- oder 32-Bit-Gleitkommamatrizen. In mindestens einem Ausführungsbeispiel arbeiten Tensor-Kerne mit 16-Bit-Gleitkomma-Eingabedaten und 32-Bit-Gleitkomma-Akkumulation. In mindestens einem Ausführungsbeispiel verwendet die 16-Bit-Gleitkommamultiplikation 64 Operationen und ergibt ein Produkt mit voller Genauigkeit, das dann unter Verwendung von 32-Bit-Gleitkomma-Addition mit anderen Zwischenprodukten für eine 4x4x4-Matrixmultiplikation akkumuliert wird. Unter Verwendung von Tensor-Kernen werden in mindestens einem Ausführungsbeispiel viel größere zweidimensionale oder höherdimensionale Matrixoperationen durchgeführt, die aus diesen kleineren Elementen aufgebaut sind. In mindestens einem Ausführungsbeispiel stellt eine API, wie z. B. die CUDA 9 C++ API, spezialisierte Operationen zum Laden, Multiplizieren und Akkumulieren von Matrizen sowie zum Speichern von Matrizen zur Verfügung, um Tensor-Kerne in einem CUDA-C++-Programm effizient zu verwenden. In mindestens einem Ausführungsbeispiel geht die Warp-Level-Schnittstelle auf CUDA-Ebene von Matrizen der Größe 16x16 aus, die sich über alle 32 Threads des Warp erstrecken.
In mindestens einem Ausführungsbeispiel umfasst jeder SM 4100 ohne Einschränkung M SFUs 4112, die spezielle Funktionen ausführen (z. B. Attribut-Evaluierung, reziproke Quadratwurzel und dergleichen). In mindestens einem Ausführungsbeispiel umfassen die SFUs 4112 ohne Einschränkung eine Einheit zur Traversierung von Bäumen, die so konfiguriert ist, dass sie eine hierarchische Baumdatenstruktur durchläuft. In mindestens einem Ausführungsbeispiel umfassen die SFUs 4112 ohne Einschränkung eine Textureinheit, die so konfiguriert ist, dass sie Texturkarten-Filteroperationen durchführt. In mindestens einem Ausführungsbeispiel sind Textureinheiten so konfiguriert, dass sie Texturkarten (z. B. ein 2D-Array von Texeln) aus dem Speicher laden und Texturkarten samplen, um Sampling-Texturwerte zur Verwendung in von SM 4100 ausgeführten Schattierungsprogrammen zu erzeugen. In mindestens einem Ausführungsbeispiel werden Texturkarten im gemeinsam genutzten Speicher/L1-Cache 4118 gespeichert. In mindestens einem Ausführungsbeispiel implementieren Textureinheiten gemäß mindestens einem Ausführungsbeispiel Texturoperationen, wie z. B. Filteroperationen unter Verwendung von Mip-Maps (z. B. Texturkarten mit unterschiedlichen Details). In mindestens einem Ausführungsbeispiel umfasst jedes SM 4100, ohne Einschränkung, zwei Textureinheiten.
Jedes SM 4100 umfasst ohne Einschränkung N LSUs 4114, die in mindestens einem Ausführungsbeispiel Lade- und Speicheroperationen zwischen gemeinsam genutztem Speicher/L1-Cache 4118 und Registerdatei 4108 durchführen. Jedes SM 4100 umfasst ohne Einschränkung ein Verbindungsnetzwerk 4116, das in mindestens einem Ausführungsbeispiel jede der funktionalen Einheiten mit der Registerdatei 4108 und die LSU 4114 mit der Registerdatei 4108 und dem gemeinsam genutzten Speicher/L1-Cache 4118 verbindet. In mindestens einem Ausführungsbeispiel ist das Verbindungsnetzwerk 4116 eine Crossbar, die so konfiguriert werden kann, dass sie jede der funktionalen Einheiten mit jedem der Register in der Registerdatei 4108 verbindet und die LSUs 4114 mit der Registerdatei 4108 und den Speicherplätzen im gemeinsam genutzten Speicher/L1-Cache 4118 verbindet.
In mindestens einem Ausführungsbeispiel ist der gemeinsam genutzte Speicher/L1-Cache 4118 ein Array von On-Chip-Speicher, der in mindestens einem Ausführungsbeispiel die Datenspeicherung und Kommunikation zwischen SM 4100 und primitiver Engine und zwischen Threads in SM 4100 ermöglicht. In mindestens einem Ausführungsbeispiel umfasst der gemeinsam genutzte Speicher/L1-Cache 4118 ohne Einschränkung 128 KB Speicherkapazität und befindet sich auf dem Weg vom SM 4100 zur Partitionseinheit. In mindestens einem Ausführungsbeispiel wird der gemeinsam genutzte Speicher/L1-Cache 4118 in mindestens einem Ausführungsbeispiel zum Cachen von Lese- und Schreibvorgängen genutzt. In mindestens einem Ausführungsbeispiel sind einer oder mehrere der gemeinsam genutzten Speicher/L1-Cache 4118, L2-Cache und Arbeitsspeicher Zusatzspeicher (engl. Backing-Stores).
Die Kombination der Funktionalität von Datencache und gemeinsam genutztem Speicher in einem einzigen Speicherschritt stellt in mindestens einem Ausführungsbeispiel eine verbesserte Leistung für beide Arten von Speicherzugriffen bereit. In mindestens einem Ausführungsbeispiel wird die Kapazität von Programmen, die den gemeinsam genutzten Speicher nicht verwenden, als Cache genutzt oder kann von diesen genutzt werden, z. B. wenn der gemeinsam genutzte Speicher so konfiguriert ist, dass er die Hälfte der Kapazität nutzt, können Textur- und Lade-/Speicheroperationen die verbleibende Kapazität nutzen. Die Integration in den gemeinsam genutzten Speicher/L1-Cache 4118 ermöglicht es dem gemeinsam genutzten Speicher/L1-Cache 4118, gemäß mindestens einem Ausführungsbeispiel als durchsatzstarke Leitung für Streaming-Daten zu fungieren und gleichzeitig den Zugriff auf häufig wiederverwendete Daten mit hoher Bandbreite und geringer Latenz bereitzustellen. In mindestens einem Ausführungsbeispiel kann, wenn es für allgemeine parallele Berechnungen konfiguriert ist, eine einfachere Konfiguration im Vergleich zur Grafikverarbeitung verwendet werden. In mindestens einem Ausführungsbeispiel werden Grafikverarbeitungseinheiten mit festen Funktionen umgangen, wodurch ein wesentlich einfacheres Programmiermodell entsteht. In mindestens einem Ausführungsbeispiel ist in der Konfiguration für allgemeine parallele Berechnungen die Arbeitsverteilungseinheit Blöcken von Threads zugewiesen und diese direkt auf DPCs verteilt. In mindestens einem Ausführungsbeispiel führen Threads in einem Schritt dasselbe Programm aus, wobei eine eindeutige Thread-ID in der Berechnung genutzt wird, um sicherzustellen, dass jeder Thread eindeutige Ergebnisse generiert, unter Verwendung von SM 4100 zur Ausführung des Programms und zur Durchführung von Berechnungen, gemeinsam genutztem Speicher/L1-Cache 4118 zur Kommunikation zwischen Threads und LSU 4114 zum Lesen und Schreiben des globalen Speichers über Speicher/L1-Cache 4118 und Speicherpartitionseinheit. In mindestens einem Ausführungsbeispiel, wenn es für allgemeine parallele Berechnungen konfiguriert ist, schreibt SM 4100 Befehle, die die Planer-Einheit 4104 verwenden kann, um neue Arbeit auf DPCs zu starten.
In mindestens einem Ausführungsbeispiel ist die PPU in einem Desktop-Computer, einem Laptop-Computer, einem Tablet-Computer, Servern, Supercomputern, einem Smartphone (z. B. einem drahtlosen, handgehaltenen Gerät), einem persönlichen digitalen Assistenten („PDA“), einer Digitalkamera, einem Fahrzeug, einer am Kopf montierten Anzeige, einem handgehaltenen elektronischen Gerät usw. umfasst oder damit gekoppelt. In mindestens einem Ausführungsbeispiel ist das PPU auf einem einzigen Halbleitersubstrat untergebracht. In mindestens einem Ausführungsbeispiel ist die PPU in einem System-on-a-Chip („SoC“) zusammen mit einem oder mehreren anderen Geräten wie zusätzlichen PPUs, Speicher, einer CPU mit reduziertem Befehlssatz („RISC“), einer Speicherverwaltungseinheit („MMU“), einem Digital-Analog-Wandler („DAC“) und dergleichen umfasst.
In mindestens einem Ausführungsbeispiel kann die PPU eine Grafikkarte umfassen, die ein oder mehrere Speichergeräte enthält. Die Grafikkarte kann so konfiguriert sein, dass sie mit einem PCIe-Steckplatz auf einem Motherboard eines Desktop-Computers verbunden werden kann. In mindestens einem Ausführungsbeispiel kann die PPU eine integrierte Grafikverarbeitungseinheit („iGPU“) sein, die im Chipsatz der Hauptplatine umfasst ist.
Inferenz- und/oder Trainingslogik 1315 wird zum Inferenzieren und/oder Trainieren von Operationen verwendet, die mit einem oder mehreren Ausführungsbeispielen assoziiert sind. Details zur Inferenz- und/oder Trainingslogik 1315 werden hier in Verbindung mit 13A und/oder 13B bereitgestellt. In mindestens einem Ausführungsbeispiel wird ein Deep Learning-Anwendungsprozessor verwendet, um ein maschinelles Lernmodell, wie z. B. ein neuronales Netzwerk, zu trainieren, um Informationen, die dem SM 4100 bereitgestellt werden, vorherzusagen oder zu inferieren. In mindestens einem Ausführungsbeispiel wird SM 4100 verwendet, um Informationen basierend auf einem trainierten maschinellen Lernmodell (z. B. neuronales Netzwerk), das von einem anderen Prozessor oder System oder von SM 4100 trainiert wurde, zu inferieren oder vorherzusagen. In mindestens einem Ausführungsbeispiel kann SM 4100 verwendet werden, um einen oder mehrere hierin beschriebene Anwendungsfälle eines neuronalen Netzwerks durchzuführen.
Die oben beschriebenen Techniken können beispielsweise verwendet werden, um ein System zum Austausch von Objekten zwischen Mensch und Roboter zu implementieren. Einige Beispiele verwenden die Inferenz- und/oder Trainingslogik, um ein neuronales Netzwerk zu erstellen, das trainiert wurde, um ein Greifen eines Objekts zu generieren, das von einer menschlichen Hand gehalten wird, wie oben beschrieben.
In mindestens einem Ausführungsbeispiel kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche integrierte Schaltung oder einen Chip auf Halbleiterbasis beziehen. In mindestens einem Ausführungsbeispiel können Multi-Chip-Module mit erhöhter Konnektivität verwendet werden, die einen On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Zentraleinheit („CPU“) und einer Bus-Implementierung bieten. In mindestens einem Ausführungsbeispiel können verschiedene Module auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen je nach Wunsch des Benutzers angeordnet sein.
In mindestens einem Ausführungsbeispiel werden Computerprogramme in Form von maschinenlesbarem ausführbarem Code oder Computersteuerungslogik-Algorithmen im Hauptspeicher 1904 und/oder in einem sekundären Speicher gespeichert. Computerprogramme, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, ermöglichen es dem System 1900, verschiedene Funktionen gemäß mindestens einem Ausführungsbeispiel auszuführen. Speicher 1904, Speicher und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien. In mindestens einem Ausführungsbeispiel kann sich der sekundäre Speicher auf ein beliebiges geeignetes Speichergerät oder -system beziehen, wie etwa ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Compact-Disk-Laufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät, einen USB-Flash-Speicher usw. repräsentiert. In mindestens einem Ausführungsbeispiel werden die Architektur und/oder Funktionalität verschiedener vorhergehender Figuren im Zusammenhang mit der CPU 1902, dem Parallelverarbeitungssystem 1912, einer integrierten Schaltung, die mindestens einen Teil der Fähigkeiten sowohl der CPU 1902 als auch des Parallelverarbeitungssystems 1912 besitzt, einem Chipsatz (z.B. eine Gruppe integrierter Schaltungen, die so entworfen sind, dass sie als eine Einheit zur Ausführung verwandter Funktionen arbeiten und verkauft werden, usw.) und jeder geeigneten Kombination integrierter Schaltung(en) implementiert.
In mindestens einem Ausführungsbeispiel werden die Architektur und/oder Funktionalität verschiedener vorhergehender Figuren im Zusammenhang mit einem allgemeinen Computersystem, einem Leiterplattensystem, einem Spielkonsolensystem für Unterhaltungszwecke, einem anwendungsspezifischen System usw. umgesetzt. In mindestens einem Ausführungsbeispiel kann das Computersystem 1900 die Form eines Desktop-Computers, eines Laptops, eines Tablet-Computers, eines Servers, eines Supercomputers, eines Smartphones (z.B. eines drahtlosen Handgeräts), eines persönlichen digitalen Assistenten („PDA“), einer Digitalkamera, eines Fahrzeugs, einer auf dem Kopf montierten Anzeige, eines elektronischen Geräts in der Hand, eines Mobiltelefongeräts, eines Fernsehers, einer Workstation, von Spielkonsolen, eines eingebetteten Systems und/oder jeder anderen Art von Logik annehmen.
In mindestens einem Ausführungsbeispiel umfasst das Parallelverarbeitungssystem 1912 ohne Einschränkung eine Vielzahl von Parallelverarbeitungseinheiten („PPUs“) 1914 und assoziierte Speicher 1916. In mindestens einem Ausführungsbeispiel sind die PPUs 1914 mit einem Host-Prozessor oder anderen peripheren Geräten über eine Zwischenverbindung 1918 und einen Switch 1920 oder Multiplexer verbunden. In mindestens einem Ausführungsbeispiel verteilt das Parallelverarbeitungssystem 1912 Rechenaufgaben auf die PPUs 1914, die parallelisierbar sein können - zum Beispiel als Teil der Verteilung von Rechenaufgaben auf mehrere Thread-Blöcke der Grafikverarbeitungseinheit („GPU“). In mindestens einem Ausführungsbeispiel wird der Speicher gemeinsam genutzt und ist für einige oder alle PPUs 1914 zugänglich (z. B. für Lese- und/oder Schreibzugriffe), obwohl ein solcher gemeinsam genutzter Speicher Leistungseinbußen im Vergleich zur Verwendung von lokalem Speicher und Registern, die in einer PPU 1914 resident sind, nach sich ziehen kann. In mindestens einem Ausführungsbeispiel wird der Betrieb der PPUs 1914 unter Verwendung eines Befehls wie syncthreads() synchronisiert, wobei alle Threads in einem Schritt (z. B. über mehrere PPUs 1914 ausgeführt) einen bestimmten Punkt der Codeausführung erreichen müssen, bevor sie prozessiert werden.
Andere Variationen sind im Sinne der vorliegenden Offenbarung. Während die offenbaren Techniken für verschiedene Modifikationen und alternative Konstruktionen anfällig sind, sind bestimmte beispielhafte Ausführungsbeispiele davon in den Zeichnungen dargestellt und oben im Detail beschrieben worden. Es sollte jedoch verstanden werden, dass nicht beabsichtigt ist, die Offenbarung auf eine bestimmte Form oder bestimmte Formen zu beschränken, die offenbart wurden, sondern dass im Gegenteil beabsichtigt ist, alle Modifikationen, alternativen Konstruktionen und Äquivalente abzudecken, die in den Geist und Umfang der Offenbarung fallen, wie in den beigefügten Ansprüchen definiert.
Die Verwendung der Begriffe „ein“ und „der/di/das“ und ähnlicher Bezeichnungen im Zusammenhang mit der Beschreibung offenbarer Ausführungsbeispiele (insbesondere im Zusammenhang mit den folgenden Ansprüchen) ist so auszulegen, dass sie sowohl die Einzahl als auch die Mehrzahl umfasst, sofern hier nicht anders angezeigt oder durch den Kontext eindeutig widerlegt, und nicht als eine Definition eines Begriffs. Die Begriffe „umfassend“, „mit“, „einschließlich“ und „enthaltend“ sind als offene Begriffe zu verstehen (d.h. „einschließlich, aber nicht beschränkt auf‟), sofern nichts anderes angegeben ist. Der Begriff „verbunden“ ist, wenn er unverändert bleibt und sich auf physikalische Verbindungen bezieht, als teilweise oder ganz in einem Bauteil enthalten, an ihm befestigt oder mit ihm verbunden zu verstehen, auch wenn etwas dazwischen liegt. Die Aufzählung von Wertebereichen dient hier lediglich als kurzes Verfahren, um jeden separaten Wert, der in den Bereich fällt, einzeln zu bezeichnen, sofern hier nichts anderes angezeigt wird, und jeder separate Wert wird in die Beschreibung aufgenommen, als ob er hier einzeln aufgeführt wäre. Unter Verwendung des Begriffs „Menge“ (z. B. „eine Menge von Gegenständen“) oder „Teilmenge“ ist, sofern nicht anders angegeben oder durch den Kontext widerlegt, eine nicht leere Sammlung zu verstehen, die ein oder mehrere Elemente umfasst. Weiter, sofern nicht anders vermerkt oder durch den Kontext widerlegt, bezeichnet der Begriff „Teilmenge“ einer entsprechenden Menge nicht notwendigerweise eine echte Teilmenge der entsprechenden Menge, sondern Teilmenge und entsprechende Menge können gleich sein.
Konjunktivische Ausdrücke, wie z. B. Sätze der Form „mindestens eines von A, B und C“ oder „mindestens eines von A, B und C“, werden, sofern nicht ausdrücklich anders angegeben oder durch den Kontext eindeutig widerlegt, unter Verwendung des Kontexts allgemein so verstanden, dass ein Element, ein Begriff usw., entweder A oder B oder C oder eine beliebige nicht leere Teilmenge der Menge von A und B und C sein kann. Im beispielhaften Beispiel einer Menge mit drei Mitgliedern beziehen sich die konjunktiven Ausdrücke „mindestens eines von A, B und C“ und „mindestens eines von A, B und C“ auf eine der folgenden Mengen: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Diese konjunktivische Formulierung soll also nicht generell bedeuten, dass bei bestimmten Ausführungsbeispielen mindestens eines von A, mindestens eines von B und mindestens eines von C vorhanden sein muss. Sofern nicht anders vermerkt oder durch den Kontext widerlegt, zeigt der Begriff „Vielzahl“ einen Zustand der Mehrzahl an (z. B. „eine Vielzahl von Elementen“ zeigt mehrere Elemente an). Die Anzahl der Gegenstände in einer Vielzahl beträgt mindestens zwei, kann aber auch mehr sein, wenn dies entweder ausdrücklich oder durch den Kontext angezeigt wird. Weiter bedeutet „basierend auf‟, sofern nicht anders angegeben oder anderweitig aus dem Kontext klar, „zumindest teilweise basierend auf‟ und nicht „ausschließlich basierend auf‟.
Die Operationen der hierin beschriebenen Prozesse können in jeder geeigneten Reihenfolge durchgeführt werden, sofern dies nicht anders angezeigt wird oder sich aus dem Kontext eindeutig ergibt. In mindestens einem Ausführungsbeispiel wird ein Prozess wie die hier beschriebenen Prozesse (oder Variationen und/oder Kombinationen davon) unter der Steuerung eines oder mehrerer Computersysteme durchgeführt, die mit ausführbaren Anweisungen konfiguriert sind und als Code (z. B. ausführbare Anweisungen, ein oder mehrere Computerprogramme oder eine oder mehrere Anwendungen) implementiert sind, die gemeinsam auf einem oder mehreren Prozessoren, durch Hardware oder Kombinationen davon ausgeführt werden. In mindestens einem Ausführungsbeispiel ist der Code auf einem computerlesbaren Speichermedium gespeichert, zum Beispiel in Form eines Computerprogramms, das eine Vielzahl von Anweisungen umfasst, die von einem oder mehreren Prozessoren ausgeführt werden können. In mindestens einem Ausführungsbeispiel handelt es sich bei einem computerlesbaren Speichermedium um ein nichtflüchtiges computerlesbares Speichermedium, das transitorische Signale (z. B. eine sich ausbreitende transiente elektrische oder elektromagnetische Übertragung) ausschließt, aber eine nichtflüchtige Schaltungsanordnung zur Datenspeicherung (z. B. Puffer, Cache und Warteschlangen) innerhalb von Transceivem für transitorische Signale umfasst. In mindestens einem Ausführungsbeispiel ist Code (z. B. ausführbarer Code oder Quellcode) auf einem Satz von einem oder mehreren nichtflüchtigen computerlesbaren Speichermedien gespeichert, auf denen ausführbare Befehle (oder ein anderer Speicher zum Speichern ausführbarer Befehle) gespeichert sind, die bei Ausführung (d. h. als Ergebnis der Ausführung) durch einen oder mehrere Prozessoren eines Computersystems bewirken, dass das Computersystem hierin beschriebene Operationen durchführt. Ein Satz nichtflüchtiger, computerlesbarer Speichermedien umfasst in mindestens einem Ausführungsbeispiel mehrere nichtflüchtige, computerlesbare Speichermedien, wobei auf einem oder mehreren der einzelnen nichtflüchtigen Speichermedien der mehreren nichtflüchtigen, computerlesbaren Speichermedien der gesamte Code fehlt, während auf mehreren nichtflüchtigen, computerlesbaren Speichermedien gemeinsam der gesamte Code gespeichert ist. In mindestens einem Ausführungsbeispiel werden ausführbare Befehle so ausgeführt, dass verschiedene Befehle von verschiedenen Prozessoren ausgeführt werden - zum Beispiel speichert ein nichtflüchtiger computerlesbarer Speicher Befehle und eine zentrale Verarbeitungseinheit („CPU“) führt einige der Befehle aus, während eine Grafikverarbeitungseinheit („GPU“) andere Befehle ausführt. In mindestens einem Ausführungsbeispiel haben verschiedene Komponenten eines Computersystems separate Prozessoren, und verschiedene Prozessoren führen verschiedene Teilmengen von Befehlen aus.
Dementsprechend sind in mindestens einem Ausführungsbeispiel Computersysteme so konfiguriert, dass sie einen oder mehrere Dienste implementieren, die einzeln oder gemeinsam Operationen der hierin beschriebenen Prozesse ausführen, und solche Computersysteme sind mit anwendbarer Hardware und/oder Software konfiguriert, die die Durchführung von Operationen ermöglichen. Ferner ist ein Computersystem, das mindestens ein Ausführungsbeispiel der vorliegenden Offenbarung implementiert, ein einzelnes Gerät, und in einer weiteren Ausführungsform ist es ein verteiltes Computersystem, das mehrere Geräte umfasst, die unterschiedlich operieren, so dass das verteilte Computersystem die hierin beschriebenen Operationen durchführt und dass ein einzelnes Gerät nicht alle Operationen durchführt.
Die Verwendung von Ausführungsbeispielen oder exemplarischer Sprache (z.B. „wie“), die hier bereitgestellt werden, dient lediglich der besseren Veranschaulichung von Ausführungsbeispielen der Offenbarung und stellt keine Einschränkung des Umfangs der Offenbarung dar, sofern nichts anderes behauptet wird. Keine Formulierung in der Beschreibung sollte so ausgelegt werden, dass sie ein nicht beanspruchtes Element als wesentlich für die Praxis der Offenbarung anzeigt.
Alle Referenzen, einschließlich Veröffentlichungen, Patentanmeldungen und Patente, die hierin zitiert werden, werden hiermit durch Bezugnahme in demselben Umfang einbezogen, als ob jede Referenz einzeln und ausdrücklich als durch Bezugnahme einbezogen angezeigt und hier in ihrer Gesamtheit wiedergegeben würde.
In der Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ sowie ihre Ableitungen verwendet werden. Es sollte verstanden werden, dass diese Begriffe nicht als Synonyme füreinander angesehen werden können. Vielmehr kann in bestimmten Beispielen „verbunden“ oder „gekoppelt“ verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem oder indirektem physischen oder elektrischen Kontakt miteinander stehen. „Gekoppelt“ kann auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt zueinander stehen, aber dennoch miteinander kooperieren oder interagieren.
Sofern nicht ausdrücklich anders angegeben, kann davon ausgegangen werden, dass sich in der gesamten Beschreibung Begriffe wie „Verarbeiten“, „Berechnen“, „Bestimmen“ oder dergleichen auf Aktionen und/oder Prozesse eines Computers oder eines Rechensystems oder eines ähnlichen elektronischen Rechengeräts beziehen, die Daten, die als physikalische, z. B. elektronische, Größen in den Registern und/oder Speichern des Rechensystems repräsentiert werden, manipulieren und/oder in andere Daten umwandeln, die in ähnlicher Weise als physikalische Größen in den Speichern, Registern oder anderen Geräten zur Speicherung, Übertragung oder Anzeige von Informationen des Rechensystems repräsentiert werden.
In ähnlicher Weise kann sich der Begriff „Prozessor“ auf ein Gerät oder einen Teil eines Geräts beziehen, das elektronische Daten aus Registern und/oder Speichern verarbeitet und diese elektronischen Daten in andere elektronische Daten umwandelt, die in Registern und/oder Speichern gespeichert werden können. Als nicht einschränkende Beispiele kann der „Prozessor“ eine CPU oder eine GPU sein. Eine „Datenverarbeitungsplattform“ kann einen oder mehrere Prozessoren umfassen. Wie hier verwendet, kann der Begriff „Software“-Prozesse z. B. Software- und/oder Hardware-Einheiten umfassen, die im Laufe der Zeit Arbeit verrichten, wie z. B. Aufgaben, Threads und intelligente Agenten. Jeder Prozess kann sich auch auf mehrere Prozesse beziehen, um Anweisungen in Sequenz oder parallel, kontinuierlich oder intermittierend auszuführen. Die Begriffe „System“ und „Verfahren“ werden hier austauschbar verwendet, insofern als ein System ein oder mehrere Verfahren verkörpern kann und Verfahren als System betrachtet werden können.
Im vorliegenden Dokument kann auf das Erhalten, Erfassen, Empfangen oder Eingeben von analogen oder digitalen Daten in ein Teilsystem, ein Computersystem oder eine computerimplementierte Maschine Bezug genommen werden. Der Prozess des Erhalts, der Erfassung, des Empfangs oder der Eingabe analoger und digitaler Daten kann auf verschiedene Weise erfolgen, beispielsweise durch den Empfang von Daten als Parameter eines Funktionsaufrufs oder eines Aufrufs einer Anwendungsprogrammierschnittstelle. In einigen Implementierungen kann der Prozess des Erhaltens, Erfassens, Empfangens oder der Eingabe von analogen oder digitalen Daten durch die Übertragung von Daten über eine serielle oder parallele Schnittstelle erfolgen. In einer anderen Implementierung kann der Prozess des Erhaltens, Erfassens, Empfangens oder Eingebens analoger oder digitaler Daten durch die Übertragung von Daten über ein Computemetzwerk von der bereitstellenden zu der erwerbenden Einheit erfolgen. Es kann auch auf das Bereitstellen, Ausgeben, Übertragen, Senden oder Darstellen analoger oder digitaler Daten Bezug genommen werden. In verschiedenen Beispielen kann der Prozess des Bereitstellens, Ausgebens, Übertragens, Sendens oder Darstellens analoger oder digitaler Daten durch die Übertragung von Daten als Eingabe- oder Ausgabeparameter eines Funktionsaufrufs, eines Parameters einer Anwendungsprogrammierschnittstelle oder eines Interprozess-Kommunikationsmechanismus durchgeführt werden.
Obwohl die obige Diskussion Beispielimplementierungen der beschriebenen Techniken darlegt, können andere Architekturen verwendet werden, um die beschriebene Funktionalität zu implementieren, und sind dazu bestimmt, innerhalb des Umfangs dieser Offenbarung zu liegen. Darüber hinaus können verschiedene Funktionen und Verantwortlichkeiten je nach den Umständen auf unterschiedliche Weise verteilt und aufgeteilt werden, obwohl oben zu Diskussionszwecken spezifische Verteilungen von Verantwortlichkeiten definiert wurden.
Obwohl der Gegenstand in einer Sprache beschrieben wurde, die sich auf strukturelle Merkmale und/oder methodische Handlungen bezieht, ist es zu verstehen, dass der in den beigefügten Ansprüchen beanspruchte Gegenstand nicht notwendigerweise auf die beschriebenen spezifischen Merkmale oder Handlungen beschränkt ist. Vielmehr sind die spezifischen Merkmale und Handlungen als exemplarische Formen der Umsetzung der Ansprüche offenbart.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 3016201806 [0107]
JP 3016201609 [0107]

Claims

Prozessor, der einen oder mehrere Computer umfasst, die einen oder mehrere Prozessoren umfassen, zum: Erhalten einer Punktwolke, die eine Hand repräsentiert, die ein Objekt hält; Bestimmen, aus einem ersten Teil der Punktwolke, einer Objektpose; Bestimmen, aus einem zweiten Teil der Punktwolke, einer Handpose; Generieren eines Satzes von Greifposen, die es einem Roboter ermöglichen, das Objekt zu greifen; Auswählen, aus dem Satz von Greifposen, basierend zumindest teilweise auf der Handpose, einer Ziel-Greifpose, die nicht mit der Hand interferiert; und Veranlassen des Roboters, die Ziel-Greifpose auszuführen.
Prozessor nach Anspruch 1, wobei die Handpose eine Vielzahl von Segmenten und Gelenkwinkeln identifiziert.
Prozessor nach Anspruch 1 oder 2, wobei der eine oder die mehreren Prozessoren ausführen: Erhalten eines dreidimensionales Bildes von einer Tiefenkamera; und Erzeugen der Punktwolke aus dem dreidimensionalen Bild.
Prozessor nach einem der vorhergehenden Ansprüche, wobei: der Satz von Greifposen Posen für einen Robotergreifer des Roboters sind; und der Robotergreifer zwei gegenüberliegende Finger hat, die den Griff ausführen.
Prozessor nach einem der vorhergehenden Ansprüche, wobei die Objektpose drei Winkel umfasst, die eine Orientierung des Objekts anzeigen, und eine Information, die eine Position des Objekts identifiziert.
Prozessor nach einem der vorhergehenden Ansprüche, wobei der Roboter das Objekt aus der Hand nimmt.
System, umfassend: einen oder mehrere Prozessoren, die mit computerlesbaren Medien gekoppelt sind; wobei die computerlesbaren Medien ausführbare Befehle speichern, die als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren bewirken, dass das System folgende Schritte ausführt: Bestimmen, aus einem dreidimensionalen Bild eines Gliedes, das ein Objekt hält, einer Pose des Gliedes und einer Objektpose; Bestimmen eines Satzes von Greifposen, die es einem Robotergreifer ermöglichen, das Objekt zu greifen; Auswählen, aus dem Satz von Greifposen, einer Greifpose, die nicht mit dem Glied interferiert; und Ausführen der Greifpose.
System nach Anspruch 7, wobei das dreidimensionale Bild von einer Tiefenkamera, einem Radarbild, einem LIDAR-Bild oder einem dreidimensionalen medizinischen Bildgebungsgerät generiert wird.
System nach Anspruch 7 oder 8, wobei die ausführbaren Anweisungen als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren weiter bewirken, dass das System die folgenden Schritte ausführt: Generieren einer Punktwolke aus dem dreidimensionalen Bild; Identifizieren eines ersten Abschnitts der Punktwolke, der das Glied repräsentiert; und Identifizieren eines zweiten Abschnitts der Punktwolke, der das Objekt repräsentiert.
System nach einem der Ansprüche 7 bis 9, wobei die ausführbaren Anweisungen als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren weiter bewirken, dass das System ausführt: Bestimmen eines Typs einer Handpose aus dem dreidimensionalen Bild; und Bestimmen einer Greifpose, die zumindest teilweise auf dem Typ der Handpose basiert.
System nach einem der Ansprüche 7 bis 10, wobei die ausführbaren Anweisungen als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren weiter bewirken, dass das System ausführt: Generieren einer Punktwolke aus dem dreidimensionalen Bild; und Bereitstellen der Punktwolke an ein trainiertes Modell, das die Greifpose ausgibt.
System nach Anspruch 11, wobei das trainierte Modell durch Bereitstellen von Grundwahrheitsdaten trainiert wird, die Punktwolkeninformationen und entsprechende Greifposen umfassen.
System nach einem der Ansprüche 7 bis 12, wobei bestimmt wird, dass die Greifpose mit dem dem Glied interferiert, wenn vorhergesagt wird, dass der Robotergreifer das Glied während der Ausführung der Greifpose berührt.
Maschinenlesbares Medium, auf dem ein Satz von Befehlen gespeichert ist, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren dazu veranlassen, zumindest Folgendes auszuführen: Erhalten eines dreidimensionalen Bildes eines Gliedes, das ein Objekt hält; Generieren eines 3D-Modells aus dem dreidimensionalen Bild; Bereitstellen des 3D-Modells für ein trainiertes Netzwerk, wobei das trainierte Netzwerk eine Greifpose für einen Robotergreifer erzeugt, der in der Lage ist, das Glied zu greifen, ohne das Glied zu berühren; und Veranlassen, dass der Robotergreifer die Greifpose ausführt.
Maschinenlesbares Medium nach Anspruch 14, wobei das trainierte Netzwerk zumindest teilweise trainiert wird, indem einem Netzwerk Trainingsdaten bereitgestellt werden, die ein farbiges 3D-Modell eines Glieds, das ein Objekt hält, und einen vorgeschlagenen Griff für den Robotergreifer umfassen, so dass der Robotergreifer das Objekt von dem Glied aufnehmen kann, ohne das Glied zu berühren.
Maschinenlesbares Speichermedium nach Anspruch 15, wobei Trainingsdaten generiert werden durch zumindest: Generieren eines Datensatzes von menschlichen Objektübergaben; und Annotieren des Datensatzes mit Grundwahrheits-Posen der Hand und Objektposen der Grundwahrheit.
Maschinenlesbares Medium nach einem der Ansprüche 14 bis 16, wobei die Anweisungen weiter Anweisungen umfassen, die als ein Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren bewirken, dass der eine oder die mehreren Prozessoren Folgendes ausführen: Bestimmen einer Pose des Gliedes anhand des 3D-Modells; und Bestimmen, aus dem 3D-Modell, einer Objektpose.
Maschinenlesbares Speichermedium nach Anspruch 17, wobei: die Greifpose zumindest teilweise auf der Objektpose und der Pose des Glieds basiert; und die Greifpose als ein Greifen bestimmt wird, das erfolgreich das Objekt greift, während es das Glied nicht berührt.
Maschinenlesbares Speichermedium nach einem der Ansprüche 14 bis 18, wobei das Netzwerk unter Verwendung von Bildern des Gliedes, das verschiedene Objekttypen hält, trainiert wird.
Maschinenlesbares Medium nach einem der Ansprüche 14 bis 19, wobei die Anweisungen ferner Anweisungen umfassen, die als Ergebnis der Ausführung durch den einen oder die mehreren Prozessoren bewirken, dass der eine oder die mehreren Prozessoren die Greifpose als Ergebnis der Bestimmung bestimmen, dass die Pose des Glieds ein Posentyp ist, der dem Roboter das Objekt anbietet.
Prozessor, umfassend: eine oder mehrere arithmetische Logikeinheiten (ALUs), um ein oder mehrere neuronale Netzwerke zumindest teilweise zu trainieren, indem einem Netzwerk Trainingsdaten bereitgestellt werden, die ein 3D-Modell eines Glieds, das ein Objekt hält, und einen vorgeschlagenen Griff für den Robotergreifer umfassen, so dass der Robotergreifer das Objekt von dem Glied aufnehmen kann, ohne mit dem Glied zu interferieren.
Prozessor nach Anspruch 21, wobei Trainingsdaten generiert werden durch zumindest: Generieren eines Datensatzes von menschlichen Objektübergaben; und Annotieren des Datensatzes mit Grundwahrheits-Posen der Hand und Objektposen der Grundwahrheit.
Prozessor nach Anspruch 21 oder 22, wobei das Netzwerk ausführt: Bestimmen einer Pose des Gliedes aus dem 3D-Modell; und Bestimmen, aus dem 3D-Modell, einer Objektpose.
Prozessor nach einem der Ansprüche 21 bis 23, wobei das 3D-Modell aus einem dreidimensionalen Bild des Glieds, das das Objekt hält, generiert wird.
Prozessor nach einem der Ansprüche 21 bis 24, wobei das 3D-Modell eine Punktwolke ist.
Prozessor nach einem der Ansprüche 21 bis 25, wobei das Glied eine menschliche Hand, ein Robotergreifer oder eine Hand, ein Teil eines Tieres oder ein menschliches Bein oder ein Arm ist.