DE102020132088A1 - Berechnung effizienter kanalübergreifender operationen in parallelrechenmaschinen mit systolischen arrays - Google Patents

Berechnung effizienter kanalübergreifender operationen in parallelrechenmaschinen mit systolischen arrays Download PDF

Info

Publication number
DE102020132088A1
DE102020132088A1 DE102020132088.4A DE102020132088A DE102020132088A1 DE 102020132088 A1 DE102020132088 A1 DE 102020132088A1 DE 102020132088 A DE102020132088 A DE 102020132088A DE 102020132088 A1 DE102020132088 A1 DE 102020132088A1
Authority
DE
Germany
Prior art keywords
systolic array
operations
graphics
channel
circuit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020132088.4A
Other languages
English (en)
Inventor
Subramaniam Maiyuran
Jorge PARRA
Supratim Pal
Chandra Gurram
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/900,236 external-priority patent/US11182337B1/en
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102020132088A1 publication Critical patent/DE102020132088A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00General purpose image data processing
    • G06T1/20Processor architectures; Processor configuration, e.g. pipelining
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/76Architectures of general purpose stored program computers
    • G06F15/80Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8007Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors single instruction multiple data [SIMD] multiprocessors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/76Architectures of general purpose stored program computers
    • G06F15/80Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8046Systolic arrays
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/10Complex mathematical operations
    • G06F17/16Matrix or vector computation, e.g. matrix-matrix or matrix-vector multiplication, matrix factorization
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Image Generation (AREA)

Abstract

Es wird eine Vorrichtung zum Ermöglichen recheneffizienter kanalübergreifender Operationen in Parallelrechenmaschinen unter Verwendung systolischer Arrays offenbart. Die Vorrichtung umfasst mehrere Register und ein oder mehrere Verarbeitungselemente, die kommunikativ mit den mehreren Registern gekoppelt sind. Das eine oder die mehreren Verarbeitungselemente umfassen eine systolische Arrayschaltung zum Durchführen von kanalübergreifenden Operationen an Quelldaten, die von einem einzelnen Quellregister der mehreren Register empfangen werden, wobei die systolische Arrayschaltung modifiziert ist, Eingaben von dem einzelnen Quellregister zu empfangen und Elemente des einzelnen Quellregisters an mehrere Kanäle in der systolischen Arrayschaltung weiterzuleiten.

Description

  • QUERVERWEIS
  • Die vorliegende Anmeldung bezieht sich auf und beansprucht unter 35 U.S.C. 119 Nutzen und Priorität der indischen Patentanmeldung 202041018637 mit dem Titel COMPUTING EFFICIENT CROSS CHANNEL OPERATIONS IN PARALLEL COMPUTING MACHINES USING SYSTOLIC ARRAYS von Subramaniam Maiyuran et. al., eingereicht am 1. Mai 2020 (Attomey Docket Nr. AC8414-IN-Z), deren Inhalte hierin durch Bezugnahme mit aufgenommen werden.
  • GEBIET
  • Diese Offenbarung betrifft im Allgemeinen Datenverarbeitung und insbesondere Berechnung effizienter kanalübergreifender Operationen in Parallelrechenmaschinen mit systolischen Arrays.
  • HINTERGRUND DER OFFENBARUNG
  • Derzeitige parallele Grafikdatenverarbeitung umfasst Systeme und Verfahren, die entwickelt wurden, um spezifische Operationen an Grafikdaten durchzuführen, wie beispielsweise lineare Interpolation, Tesselierung, Rasterung, Texturabbildung, Tiefenprüfung usw. Traditionell nutzen Grafikprozessoren zum Verarbeiten von Grafikdaten Recheneinheiten mit fester Funktion. In letzter Zeit wurden Abschnitte von Grafikprozessoren jedoch programmierbar gemacht, was es solchen Prozessoren ermöglicht, eine größere Vielzahl von Operationen zum Verarbeiten von Vertex- und Fragmentdaten zu unterstützen.
  • Zur weiteren Erhöhung der Leistung implementieren Grafikprozessoren typischerweise Verarbeitungstechniken, wie etwa Pipelining, das parallel so viele Grafikdaten wie möglich in verschiedenen Teilen der Grafikpipeline zu verarbeiten versucht. Parallele Grafikprozessoren mit Single-Instruction-Multiple-Data-Architekur (SIMD) oder Single-Instruction-Multiple-Thread (SIMT)-Architektur sind dafür ausgelegt, die Menge der parallelen Verarbeitungen in der Grafikpipeline zu maximieren. In einer SIMD-Architektur versuchen Computer mit mehreren Verarbeitungselementen die gleiche Operation simultan an mehreren Datenpunkten durchzuführen. In einer SIMT-Architektur versuchen Gruppen paralleler Threads Programmanweisungen so oft wie möglich synchron zusammen auszuführen, um die Verarbeitungseffizienz zu erhöhen.
  • Figurenliste
  • Damit die Art und Weise, in der sich die vorstehend genannten Merkmale der vorliegenden Ausführungsformen im Detail verstehen lassen, kann eine konkretere Beschreibung der Ausführungsformen, die vorstehend kurz zusammengefasst wurden, unter Bezugnahme auf Ausführungsformen erfolgen, von denen einige in den beigefügten Zeichnungen veranschaulicht sind. Es ist jedoch zu beachten, dass die beigefügten Zeichnungen nur typische Ausführungsformen veranschaulichen und daher für den Umfang nicht als einschränkend zu betrachten sind.
    • 1 ist ein Blockdiagramm eines Verarbeitungssystems;
    • 2A-2D veranschaulichen Rechensysteme und Grafikprozessoren,
    • 3A-3C veranschaulichen Blockdiagramme zusätzlicher Prozessor- und Rechenbeschleunigerarchitekturen;
    • 4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors;
    • 5A-5B veranschaulichen Thread-Ausführungslogik, die ein Array von Verarbeitungselementen enthält, die in einem Grafikprozessorkern eingesetzt werden;
    • 6 veranschaulicht eine zusätzliche Ausführungseinheit;
    • 7 ist ein Blockdiagramm, das die Anweisungsformate eines Grafikprozessors veranschaulicht;
    • 8 ist ein Blockdiagramm einer zusätzlichen Grafikprozessorarchitektur;
    • 9A-9B veranschaulichen ein Befehlsformat und eine Befehlssequenz für einen Grafikprozessor;
    • 10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem;
    • 11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem veranschaulicht;
    • 11B veranschaulicht eine Querschnittsseitenansicht einer integrierten Package-Schaltungsbaugruppe;
    • 11C veranschaulicht eine Package-Baugruppe, die mehrere Einheiten von Hardware-Logik-Chiplets enthält, die mit einem Substrat (z.B. einem Basis-Die) verbunden sind;
    • 11D veranschaulicht eine Package-Baugruppe, die austauschbare Chiplets enthält;
    • 12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-a-Chip-Schaltung veranschaulicht;
    • 13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC veranschaulichen;
    • 14 ist ein Blockdiagramm, das ein systolisches Array gemäß Implementierungen der Offenbarung veranschaulicht;
    • 15 ist ein Blockdiagramm, das ein systolisches Array zum Berechnen von kanalübergreifenden Operationen in einer parallelen Rechenmaschine gemäß Implementierungen der Offenbarung veranschaulicht;
    • 16 ist ein Blockdiagramm, das ein anderes Beispiel für ein systolisches Array zum Berechnen von kanalübergreifenden Operationen in einer Parallelrechenmaschine gemäß Implementierungen der Offenbarung veranschaulicht;
    • 17 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zum Berechnen effizienter kanalübergreifender Operationen in Parallelrechenmaschinen unter Verwendung systolischer Arrays veranschaulicht;
    • 18 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens zum Modifizieren eines systolischen Arrays zum Berechnen effizienter kanalübergreifender Operationen in Parallelrechenmaschinen veranschaulicht.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Eine Grafikverarbeitungseinheit (Graphics Processing Unit; GPU) ist kommunikativ mit Host-/Prozessorkernen gekoppelt, um beispielsweise Grafikoperationen, Maschinenlemoperationen, Musteranalyseoperationen und/oder verschiedene Universal-GPU-Funktionen (General-Purpose-GPU; GPGPU) zu beschleunigen. Die GPU kann kommunikativ mit dem Host-Prozessor/-Kernen über einen Bus oder eine andere Verbindung verbunden sein (z.B. eine Hochgeschwindigkeitsverbindung, wie etwa PCIe oder NVLink). Alternativ kann die GPU auf dem gleichen Package oder Chip wie die Kerne integriert sein und über einen internen Prozessor-Bus/eine interne Verbindung (d.h. in dem Package oder Chip) kommunikativ mit den Kernen gekoppelt sein. Ungeachtet der Art und Weise, in der die GPU verbunden ist, können die Verarbeitungskerne Arbeit an die GPU in Form von Befehls-/Anweisungssequenzen, die in einem Arbeitsdeskriptor enthalten sind, zuweisen. Die GPU verwendet dann eine dedizierte Schaltungsanordnung/Logik zum effizienten Verarbeiten dieser Befehle/Anweisungen.
  • In der folgenden Beschreibung werden zahlreiche spezifische Details dargelegt, um ein genaueres Verständnis zu ermöglichen. Es wird Fachleuten jedoch offensichtlich sein, dass die hierin beschriebenen Ausführungsformen auch ohne ein oder mehrere dieser spezifischen Details praktiziert werden können. In anderen Fällen wurden wohlbekannte Merkmale nicht beschrieben, um eine Verundeutlichung der Details der vorliegenden Ausführungsformen zu vermeiden.
  • System-Übersicht
  • 1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. System 100 kann in einem Einzelprozessor-Desktop-System, einem Multiprozessor-Workstation-System oder einem Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einer integrierten System-on-a-Chip-Schaltung (SoC) zur Verwendung in mobilen, Handheld- oder eingebetteten Vorrichtungen integriert ist, wie etwa in Internet-der-Dinge-Vorrichtungen (Internet-of-Things; IoT) mit drahtgebundener oder drahtloser Konnektivität zu einem lokalen oder Wide Area Network.
  • In einer Ausführungsform kann System 100 enthalten, gekoppelt sein mit oder integriert sein in: eine serverbasierte Coming-Plattform; eine Spielkonsole, die ein Spiel und eine Medienkonsole umfasst; eine mobile Spielkonsole, eine Handheld-Spielkonsole oder eine Online-Spielkonsole. In manchen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder einer mobilen mit dem Internet verbundenen Vorrichtung, wie etwa ein Laptop mit niedriger interner Speicherkapazität. Verarbeitungssystem 100 kann auch umfassen, koppeln mit oder integriert sein in: einer tragbaren Vorrichtung, wie etwa eine tragbare Smartwatch-Vorrichtung; einer intelligenten Brille oder in intelligenter Kleidung, die mit Augmented-Reality (AR) oder Virtual-Reality (VR) Merkmalen ausgestattet ist, um visuelle, akustische oder taktile Ausgaben zur Ergänzung realer visueller, akustischer oder taktiler Erfahrungen bereitzustellen, oder anderweitig Text, Audio, Grafiken, Video, holografische Bilder oder Video oder taktiles Feedback bereitzustellen; einer anderen Augmented-Reality-Vorrichtung (AR); oder einer anderen Virtual-Reality-Vorrichtung (VR). In manchen Ausführungsformen enthält das Verarbeitungssystem 100 ein Fernsehgerät oder eine Set-Top-Box-Vorrichtung oder ist Teil davon. In einer Ausführungsform kann System 100 ein selbstfahrendes Fahrzeug umfassen, damit gekoppelt oder darin integriert sein, wie etwa einen Bus, Traktoranhänger, Auto, motor- oder elektrisch betriebenes Fahrrad, Flugzeug oder Glider (oder eine Kombination davon). Das selbstfahrende Fahrzeug kann System 100 verwenden, um die um das Fahrzeug erfasste Umgebung zu verarbeiten.
  • In manchen Ausführungsformen umfassen ein oder mehrere Prozessoren 102 einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, die, wenn sie ausgeführt werden, Operationen für System- oder Benutzersoftware durchführen. In manchen Ausführungsformen ist mindestens einer der einen oder mehrere Prozessorkerne 107 dafür ausgelegt, einen spezifischen Anweisungssatz 109 zu verarbeiten. In manchen Ausführungsformen kann Anweisungssatz 109 Complex Instruction Set Computing (CISC), Reduced Instruction Set Computing (RISC) oder Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Ein oder mehrere Prozessorkerne 107 können einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen zum Ermöglichen der Emulation anderer Anweisungssätze enthalten kann. Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen enthalten, wie etwa einen digitalen Signalprozessor (DSP).
  • In manchen Ausführungsformen enthält der Prozessor 102 Cache-Speicher 104. Je nach Architektur kann der Prozessor 102 über einen einzelnen internen Cache oder mehrere Ebenen interner Caches verfügen. In manchen Ausführungsformen wird der Cache-Speicher von verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In manchen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen Level-3 (L3) Cache oder einen Last Level Cache (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenztechniken gemeinsam genutzt werden kann. Zusätzlich kann in Prozessor 102 eine Registerdatei 106 enthalten sein und diese kann unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten enthalten (z.B. Integer-Register, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Manche Register können Universalregister sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
  • In manchen Ausführungsformen sind ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie etwa Adress-, Daten- oder Steuersignale, zwischen Prozessor 102 und anderen Komponenten in dem System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie etwa eine Version des Direct Medica Interface (DMI) Bus. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral Component Interconnect Busse (z.B. PCI, PCI-Express), Speicherbusse oder andere Arten von Schnittstellenbussen umfassen. In einer Ausführungsform enthalten der oder die Prozessor(en) 102 einen integrierten Speicher-Controller 116 und einen Plattform-Controller-Hub 130. Der Speicher-Controller 116 ermöglicht Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattform-Controller-Hub (PCH) 130 über einen lokalen I/O-Bus Verbindungen zu I/O-Vorrichtungen bereitstellt.
  • Die Speichervorrichtung 120 kann eine Direktzugriffsspeichervorrichtung (DRAM), eine statische Direktzugriffsspeichervorrichtung (SRAM), eine Flash-Speichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Speichervorrichtung sein, die eine geeignete Leistung aufweist, um als ein Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Speicher-Controller 116 koppelt außerdem mit einem optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In manchen Ausführungsformen können Grafiken, Medien und/oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, welcher ein Koprozessor ist, der konfiguriert werden kann, um einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen durchzuführen. In einer Ausführungsform ist der Beschleuniger 112 beispielsweise ein Matrixmultiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Raytracing-Beschleuniger, der zum Durchführen von Raytracing-Operationen in Zusammenarbeit mit dem Grafikprozessor 108 verwendet werden kann. In einer Ausführungsform kann anstatt von oder in Verbindung mit dem Beschleuniger 112 ein externer Beschleuniger 119 verwendet werden.
  • In manchen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem oder den Prozessor(en) 102 verbinden. Die Anzeigevorrichtung 111 kann eine oder mehrere interne Anzeigevorrichtung(en) sein, wie in einer mobilen elektronischen Vorrichtung oder einer Laptop-Vorrichtung, oder eine externe Anzeigevorrichtung, die über eine Anzeigeschnittstelle (z.B. DisplayPort usw.) verbunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf angebrachte Anzeige (Head Mounted Display; HMD) sein, wie etwa eine stereoskopische Anzeigevorrichtung zur Verwendung in Virtual-Reality-Anwendungen (VR) oder Augmented-Reality-Anwendungen (AR).
  • In manchen Ausführungsformen befähigt der Plattform-Controller-Hub 130 Peripheriegeräte mit Speichervorrichtung 120 und Prozessor 102 über einen Hochgeschwindigkeits-I/O-Bus zu verbinden. Die I/O-Peripheriegeräte umfassen, sind aber nicht beschränkt auf, einen Audio-Controller 146, einen Netzwerk-Controller 134, eine Firmware-Schnittstelle 128, einen drahtlosen Sendeempfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z.B. nichtflüchtiger Speicher, flüchtigen Speicher, Festplattenlaufwerk, Flash-Speicher, NAND, 3D NAND, 3D XPoint usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus, wie etwa einen Peripheral Component Interconnect Bus (z.B. PCI, PCI-Express), verbinden. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren umfassen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetzwerk-Sendeempfänger sein, wie etwa ein 3G, 4G, 5G oder Long-Term-Evolution (LTE) Sendeempfänger. Die Firmwareschnittstelle 128 ermöglicht Kommunikation mit System-Firmware und kann beispielsweise ein Unified Extensible Firmware Interface (UEFI) sein. Der Netzwerk-Controller 134 kann eine Netzwerkverbindung mit einem drahtgebundenem Netzwerk ermöglichen. In manchen Ausführungsformen koppelt ein Hochleistungs-Netzwerk-Controller (nicht gezeigt) mit dem Schnittstellenbus 110. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanal-High-Definition-Audio-Controller. In einer Ausführungsform enthält das System 100 einen optionalen Legacy-I/O-Controller 140 zum Koppeln von Legacy-Vorrichtungen (z.B. Personal System 2 (PS/2)) mit dem System. Der Plattform-Controller-Hub 130 kann auch mit einem oder mehreren Universal Serial Bus (USB) Controllern 142 verbinden, um Eingabevorrichtungen zu verbinden, wie etwa Tastatur und Maus 143 Kombinationen, eine Kamera 144 oder andere USB-Eingabevorrichtungen.
  • Es ist zu würdigen, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die anders konfiguriert sind, verwendet werden können. Eine Instanz des Speicher-Controllers 116 und des Plattform-Controller-Hubs 130 kann beispielsweise in einen diskreten externen Grafikprozessor integriert werden, wie etwa den externen Grafikprozessor 118. In einer Ausführungsform können der Plattform-Controller-Hub 130 und/oder Speicher-Controller 116 extern zu einem oder mehreren Prozessor(en) 102 sein. System 100 kann beispielsweise einen externen Speicher-Controller 116 und einen Plattform-Controller-Hub 130 umfassen, die als ein Speicher-Controller-Hub und Peripherie-Controller-Hub innerhalb eines System-Chipsatzes, der in Kommunikation mit dem oder den Prozessor(en) 102 steht, konfiguriert sein.
  • Es können beispielsweise Leiterplatten („Schlitten“), auf denen Komponenten, wie etwa CPUs, Speicher und andere Komponenten platziert sind, die für höhere thermische Leistung ausgelegt sind, verwendet werden. In manchen Beispielen befinden sich Verarbeitungskomponenten, wie etwa die Prozessoren, auf einer Oberseite eines Schlittens, während sich Nahspeicher, wie etwa DIMMs, auf einer Unterseite des Schlittens befinden. Infolge des verbesserten Luftstroms, der durch dieses Design bereitgestellt wird, können die Komponenten mit höheren Frequenzen und Leistungspegeln arbeiten als typische Systeme, wodurch die Leistung erhöht wird. Darüber hinaus sind die Schlitten konfiguriert, blind mit Strom- und Datenkommunikationskabeln in einem Rack verbunden zu werden, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, neuinstalliert und/oder ausgetauscht zu werden. Auf ähnliche Weise werden individuelle Komponenten, die sich auf den Schlitten befinden, wie etwa Prozessoren, Beschleuniger, Speicher und Datenspeicherlaufwerke, konfiguriert, aufgrund ihrer größeren Beabstandung voneinander einfacher aufgerüstet zu werden. In der veranschaulichenden Ausführungsform enthalten die Komponenten zusätzlich Hardware-Attestierungsmerkmale, um ihre Authentizität nachzuweisen.
  • Ein Rechenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) verwenden, die mehrere andere Netzwerkarchitekturen, einschließlich Ethernet und Omni-Path, unterstützt. Die Schlitten können über optische Fasern mit Schaltern gekoppelt werden, die höhere Bandbreite und niedrigere Latenz bereitstellen als typische Twisted-Pair-Verkabelungen (z.B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.). Aufgrund der hohen Bandbreite, Verbindungen mit niedriger Latenz und Netzwerkarchitektur kann das Rechenzentrum bei der Verwendung Ressourcen, wie etwa Speicher, Beschleuniger (z.B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neurale Netzwerk- und/oder künstliche Intelligenz Beschleuniger usw.) und Datenspeicherlaufwerke, die physisch disaggregiert sind, bündeln und ihnen Rechenressourcen (z.B. Prozessoren) nach Bedarf zuweisen, was es den Rechenressourcen ermöglicht, auf die gebündelten Ressourcen so zuzugreifen, als wären sie lokal.
  • Eine Stromversorgung oder -quelle kann Spannung und/oder Strom an das hierin beschriebene System 100 oder eine Komponente oder ein System zuführen. In einem Beispiel enthält die Stromversorgung einen AC-DC-Adapter (Wechselstrom zu Gleichstrom) zum Anschluss an eine Wandsteckdose. Solch ein Wechselstrom kann aus einer Quelle erneuerbarer Energie (z.B. Solarstrom) kommen. In einem Beispiel enthält die Stromquelle eine Gleichstromquelle, wie etwa einen externen Wechselstrom-Gleichstrom-Wandler. In einem Beispiel enthält die Stromquelle oder Stromversorgung Hardware für kabelloses Laden zum Laden über die Nähe zu einem Ladefeld. In einem Beispiel kann die Stromquelle eine interne Batterie, Wechselstromversorgung, bewegungsbasierte Stromquelle, Solarstromquelle oder Brennstoffzellenquelle enthalten.
  • 2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die von hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente in 2A-2D, die die gleichen Referenzzahlen (oder Bezeichnungen) aufweisen wie die Elemente einer anderen Figur hierin, können auf eine ähnliche Weise, wie an anderer Stelle hierin beschrieben, arbeiten oder funktionieren, sind aber nicht darauf beschränkt.
  • 2A ist ein Blockdiagramm einer Ausführungsform des Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einem integrierten Speicher-Controller 214 und einem integrierten Grafikprozessor 208. Prozessor 200 kann zusätzliche Kerne bis zu und einschließlich Kern 202N enthalten, was durch die mit gestrichelten Linien dargestellten Kästchen repräsentiert ist. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Cache-Einheiten 204A-204N. In manchen Ausführungsformen hat jeder Prozessorkern außerdem Zugriff auf eine oder mehrere gemeinsam genutzte Cache-Einheiten 206. Die internen Cache-Einheiten 204A-204N und gemeinsam genutzten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann mindestens eine Ebene von Anweisungs- und Datencache in jedem Prozessorkern und eine oder mehr Ebene(n) gemeinsam genutzten Mid-Level-Cache enthalten, wie etwa einen Ebene 2 (Level 2; L2), Ebene 3 (L3), Ebene 4 (L4), oder andere Cache-Ebenen, wobei die höchste Cache-Ebene vor externem Speicher als LLC klassifiziert ist. In manchen Ausführungsformen erhält Cache-Kohärenzlogik Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A-204N.
  • In manchen Ausführungsformen kann Prozessor 200 auch einen Satz von einer oder mehreren Bus-Controller-Einheit(en) 216 und einen Systemagentenkern 210 enthalten. Die eine oder mehreren Bus-Controller-Einheiten 216 verwalten einen Satz von Peripheriebussen, wie etwa einen oder mehrere PCI- oder PCI-Express-Busse. Systemagentenkern 210 stellt Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten bereit. In manchen Ausführungsformen enthält Systemagentenkern 210 einen oder mehrere integrierte Speicher-Controller 214 zum Verwalten des Zugriffs auf diverse externe Speichervorrichtungen (nicht gezeigt).
  • In manchen Ausführungsformen enthalten ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für simultanes Multithreading. In solchen Ausführungsformen enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben von Kernen 202A-202N während Multithreading-Verarbeitung. Systemagentenkern 210 kann zusätzlich eine Leistungssteuerungseinheit (Power Control Unit; PCU) enthalten, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 enthalten.
  • In manchen Ausführungsformen enthält Prozessor 200 zusätzlich Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen. In manchen Ausführungsformen koppelt der Grafikprozessor 208 mit dem Satz gemeinsam genutzter Cache-Einheiten 206 und dem Systemagentenkern 210, einschließlich des einen oder der mehreren integrierten Speicher-Controller 214. In manchen Ausführungsformen enthält Systemagentenkern 210 außerdem Anzeige-Controller 211 zum Treiben von Grafikprozessorausgaben an ein oder mehrere gekoppelte Anzeigen. In manchen Ausführungsformen kann Anzeige-Controller 211 auch ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Verbindung gekoppelt ist, oder er kann in den Grafikprozessor 208 integriert sein.
  • In manchen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch auch eine alternative Verbindungseinheit verwendet werden, wie etwa eine Punktzu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich im Fach bekannter Techniken. In manchen Ausführungsformen koppelt Grafikprozessor 208 mit der Ringverbindung 212 über eine I/O-Verbindung 213.
  • Die beispielhafte I/O-Verbindung 213 repräsentiert mindestens eine mehrerer verschiedener I/O-Verbindungen, einschließlich einer On-Package-I/O-Verbindung, die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebettetem Hochleistungsspeichermodul 218, wie etwa ein eDRAM-Modul, ermöglicht. In manchen Ausführungsformen kann jeder der Prozessorkerne 202A-202N und Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last Level Cache verwenden.
  • In manchen Ausführungsformen sind Prozessorkerne 202A-202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind Prozessorkerne 202A-202N heterogen in Hinblick auf Anweisungssatzarchitektur (Instruction Set Architecture; ISA), wobei ein oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Untersatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführen. In einer Ausführungsform sind Prozessorkerne 202A-202N in Bezug auf Mikroarchitektur heterogen, wobei ein oder mehrere Kerne eine relativ hohe Leistungsverbrauchskopplung mit einem oder mehreren Leistungskern(en) mit einem niedrigen Leistungsverbrauch aufweisen. In einer Ausführungsform sind Prozessorkerne 202A-202N in Bezug auf die Rechenfähigkeit heterogen. Zusätzlich kann Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung mit den veranschaulichten Komponenten, zusätzlich zu anderen Komponenten, implementiert sein.
  • 2B ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 219 gemäß manchen hierin beschriebenen Ausführungsformen. Elemente in 2B, die die gleichen Referenzzahlen (oder Bezeichnungen) aufweisen wie die Elemente einer anderen Figur hierin, arbeiten oder funktionieren auf eine ähnliche Weise, wie an anderer Stelle hierin beschrieben, sind aber nicht darauf beschränkt. Der Grafikprozessorkern 219, der bisweilen als Core-Slice bezeichnet wird, kann ein oder mehrere Grafikkern(e) in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 219 ist beispielhaft für einen Grafik-Core-Slice und ein Grafikprozessor, wie hierin beschrieben, kann mehrere Grafik-Core-Slices basierend auf Zielleistung und Leistungshüllen enthalten. Jeder Grafikprozessorkern 219 kann einen Festfunktionsblock 230 enthalten, der mit mehreren Sub-Kernen 221A-221F, die auch als Sub-Slices bezeichnet werden, die modulare Blöcke von Universal- und Festfunktionslogik enthalten, gekoppelt sein.
  • In manchen Ausführungsformen enthält der Festfunktionsblock 230 eine Geometrie-/Festfunktionspipeline 231, die von allen Sub-Kernen in dem Grafikprozessorkern 219 gemeinsam genutzt werden kann, beispielsweise bei Implementierungen mit niedrigerer Leistung und/oder mit einem Grafikprozessor mit niedrigerer Leistung. In verschiedenen Ausführungsformen enthält die Geometrie-/Festfunktionspipeline 231 eine 3D-Festfunktionspipeline (z.B. 3D-Pipeline 312, wie in 3A und 4 unten beschrieben), eine Video-Frontendeinheit, einen Thread-Spawner und Thread-Dispatcher und einen Unified-Return-Buffer-Manager, der Unified-Return-Buffer verwaltet (z.B. Unified-Return-Buffer 418 in 4, wie unten beschrieben).
  • In einer Ausführungsform enthält der Festfunktionsblock 230 außerdem eine Grafik-SoC-Schnittstelle 232, einen Grafik-Mikrocontroller 233 und eine Medienpipeline 234. Die Grafik-SoC-Schnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb einer integrierten System-on-a-Chip-Schaltung bereit. Der Grafikmikrocontroller 233 ist ein programmierbarer Sub-Prozessor, der dafür konfigurierbar ist, verschiedene Funktionen des Grafikprozessorkerns 219 zu verwalten, einschließlich Thread-Dispatch, Scheduling und Preemption. Die Medienpipeline 234 (z.B. Medienpipeline 316 in 3A und 4) enthält Logik, um das Dekodieren, Kodieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten, zu ermöglichen. Die Medienpipeline 234 implementiert Medienoperationen über Anforderungen, Logik in Sub-Kernen 221-221F zu berechnen oder zu samplen.
  • In einer Ausführungsform befähigt die SoC-Schnittstelle 232 den Grafikprozessorkern 219 mit Universalanwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten in einer SoC zu kommunizieren, einschließlich Speicherhierarchieelementen, wie etwa einem gemeinsamen Last-Level-Cache-Speicher, dem System-RAM und/oder in Chip oder in Package eingebettetem DRAM. Die SoC-Schnittstelle 232 kann auch Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoC ermöglichen, wie etwa Kamerabildgebungspipelines, und ermöglicht die Verwendung von und/oder implementiert globale Speicher-Atome, die gemeinsam von dem Grafikprozessorkern 219 und CPUs in dem SoC genutzt werden können. Die SoC-Schnittstelle 232 kann auch Leistungsverwaltungssteuerungen für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 219 und anderen Taktdomänen in dem SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 Empfang von Befehlspuffern von einem Befehls-Streamer und globalem Thread-Dispatcher, die dafür ausgelegt sind, Befehle und Anweisungen jeweils an einen oder mehrere Grafikkerne in einem Grafikprozessor bereitzustellen. Die Befehle und Anweisungen können an die Medien-Pipeline 234 versendet werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Festfunktions-Pipeline (z.B. Geometrie- und Festfunktions-Pipeline 231, Geometrie- und Festfunktions-Pipeline 237), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
  • Der Grafikmikrocontroller 233 kann dafür ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann Grafikmikrocontroller 233 Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafik-Engines in Ausführungseinheitarrays (Execution Unit; EU) 222A-222F, 224A-224F in den Sub-Kernen 221A-221F durchführen. In diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Grafikprozessorkern 219 enthält, Arbeitslasten eines von mehreren Grafikprozessor-Doorbells einreichen, was eine Planungsoperation an der entsprechenden Grafik-Engine aufruft. Planungsoperationen umfassen Bestimmen, welche Arbeitslast als nächstes auszuführen ist, Einreichen einer Arbeitslast an einen Befehls-Streamer, Vorziehen bestehender Arbeitslasten, die auf einer Engine laufen, Überwachen des Fortschritts einer Arbeitslast und Benachrichtigen von Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann Grafikmikrocontroller 233 auch stromsparende oder Ruhezustände für den Grafikprozessorkern 219 ermöglichen, dem Grafikprozessorkern 219 die Fähigkeit bereitstellen, Register in dem Grafikprozessorkern 219 bei Übergängen zu einem stromsparendem Zustand unabhängig von dem Betriebssystem und/oder von der Grafiktreibersoftware auf dem System zu speichern und wiederherzustellen.
  • Der Grafikprozessorkern 219 kann mehr oder weniger als die veranschaulichten Sub-Kerne 221A-221F, bis zu N modulare Sub-Kerne, aufweisen. Für jeden Satz der N Sub-Kerne kann der Grafikprozessorkern 219 auch gemeinsam genutzte Funktionslogik 235, gemeinsam genutzten und/oder Cache-Speicher 236, eine Geometrie-/Festfunktions-Pipeline 237 sowie eine zusätzliche Festfunktionslogik 238 enthalten, um diverse Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die gemeinsam genutzte Funktionslogik 235 kann Logikeinheiten enthalten, die der gemeinsam genutzten Funktionslogik 420 in 4 (z.B. Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik) zugeordnet ist, die gemeinsam von allen N Sub-Kernen in dem Grafikprozessorkern 219 genutzt werden können. Der gemeinsam genutzte und/oder Cache-Speicher 236 kann bzw. können ein Last-Level-Cache für den Satz von N Sub-Kernen 221A-221F in dem Grafikprozessorkern 219 sein und sie können auch als gemeinsamer Speicher dienen, auf den mehrere Sub-Kerne zugreifen können. Die Geometrie-/Festfunktions-Pipeline 237 kann anstatt der Geometrie-/festen Funktions-Pipeline 231 in dem festen Funktionsblock 230 enthalten sein und die gleichen oder ähnliche Logikeinheiten enthalten.
  • In einer Ausführungsform enthält der Grafikprozessorkern 219 zusätzliche Festfunktionslogik 238, die diverse Festfunktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 enthalten kann. In einer Ausführungsform enthält die zusätzliche Festfunktionslogik 238 eine zusätzliche Geometriepipeline zur Verwendung in der Nur-Positions-Schattierung. Bei Nur-Positions-Schattierung existieren zwei Geometrie-Pipelines in der Geometrie-/Festfunktions-Pipeline 238, 231 und eine Cull-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 238 enthalten sein kann. In einer Ausführungsform ist die Cull-Pipeline eine reduzierte Version der vollen Geometrie-Pipeline. Die vollständige Pipeline und die Cull-Pipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext hat. Nur-Positions-Schattierung kann lange Cull-Runs verworfener Dreiecke verstecken, was es in manchen Fällen ermöglicht, dass die Schattierung früher abgeschlossen wird. Zum Beispiel kann die Cull-Pipeline-Logik in einer Ausführungsform innerhalb der zusätzlichen Festfunktionslogik 238 Positions-Shader parallel mit der Hauptanwendung ausführen und erzeugt generell kritische Resultate schneller als die vollständige Pipeline, da die Cull-Pipeline nur die Positionsattribute der Vertices abruft und schattiert ohne Rasterung und Rendern der Pixel zu dem Frame-Buffer durchzuführen. Die Cull-Pipeline kann die erzeugten kritischen Resultate verwenden, um Sichtbarkeitsinformationen für alle Dreiecke zu berechnen, ungeachtet dessen, ob diese Dreiecke reduziert sind. Die vollständige Pipeline (die sich in diesem Fall als eine Replay-Pipeline bezeichnen lässt) kann die Sichtbarkeitsinformationen konsumieren, um die reduzierten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die letztlich an die Rasterungsphase weitergeben werden.
  • In einer Ausführungsform kann die zusätzliche Festfunktionslogik 238 auch, für Implementierungen, die Optimierungen für Maschinenlemtraining oder Inferenzierung umfassen, Maschinenlernbeschleunigungslogik enthalten, wie etwa Festfunktionsmatrixmultiplikationslogik.
  • In jedem Grafik-Sub-Kern 221A-221F ist ein Satz von Ausführungsressourcen enthalten, die zum Durchführen von Grafik-, Medien- und Rechenoperationen in Reaktion auf Anforderungen durch Grafik-Pipeline, Medien-Pipeline oder Shader-Programmen verwendet werden können. Die Grafik-Sub-Kerne 221A-221F enthalten mehrere EU-Arrays 222A-222F, 224A-224F, Thread-Dispatch und Inter-Thread-Kommunikations-Logik (TD/IC) 223A-223F, einen 3D-Sampler (z.B. Textur) 225A-225F, einen Medien-Sampler 206A-206F, einen Shader-Prozessor 227A-227F und gemeinsam genutzten lokalen Speicher (Shared Local Memory; SLM) 228A-228F. Die EU-Arrays 222A-222F, 224A-224F enthalten jeweils mehrere Ausführungseinheiten, die Universalgrafikverarbeitungseinheiten sind, die dazu in der Lage sind, Gleitkomma- und Ganzzahl-/Festkomma-Logikoperationen im Dienst einer Grafik-, Medien oder Rechenoperation, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen, durchzuführen. Die TD/IC-Logik 223A-223F führt lokale Thread-Dispatch- und Thread-Steueroperationen für die Ausführungseinheiten in einem Sub-Kern durch und ermöglicht Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Sub-Kerns ausgeführt werden. Der 3D-Sampler 225A-225F kann Textur- oder andere 3D-Grafikbezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Sample-Zustand und dem Texturformat, das einer gegebenen Textur zugeordnet ist, unterschiedlich lesen. Der Medien-Sampler 206A-206F kann ähnliche Lesevorgänge basierend auf dem Typ und Format, die Mediendaten zugewiesen sind, durchführen. In einer Ausführungsform kann jeder Grafik-Sub-Kern 221A-221F alternierend einen vereinigten 3D- und Medien-Sampler enthalten. Threads, die auf den Ausführungseinheiten in jedem der Sub-Kerne 221A-221F ausgeführt werden, können gemeinsamen lokalen Speicher 228A-228F in jedem Sub-Kern nutzen, um zu ermöglichen, dass Threads, die in einer Thread-Gruppe ausgeführt werden, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
  • 2C veranschaulicht eine Grafikverabeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen enthält, die in Mehrkerngruppen 240A-240N angeordnet sind. Obwohl nur die Details einer einzelnen Mehrkerngruppe 240A bereitgestellt werden, ist zu würdigen, dass die anderen Mehrkerngruppen 240B-240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
  • Wie veranschaulicht, kann eine Mehrkerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensor-Kernen 244 und einen Satz von Raytracing-Kernen 245 enthalten. Ein Scheduler/Dispatcher 241 plant und versendet die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 243, 244, 245. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 bei Ausführen der Grafik-Threads verwendet werden. Diese können beispielsweise Integer-Register zum Speichern von Integer-Werten, Gleitkommaregister zum Speichern von Gleitkommawerten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern gepackter Datenelemente (Integer- und/oder Gleitkommadatenelemente) und Kachel-Register zum Speichern von Tensor-/Matrixwerten enthalten. In einer Ausführungsform sind die Kachel-Register als kombinierte Sätze von Vektorregistern implementiert.
  • Eine oder mehrere kombinierte Level 1 (L1) Caches und gemeinsame Speichereinheiten 247 speichern Grafikdaten, wie etwa Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Bounding-Volume-Daten usw. lokal in jeder Mehrkerngruppe 240A. Zum Durchführen der Texturing-Operationen, wie etwa Textur-Mapping und Sampling, kann bzw. können ein oder mehrere Textur-Einheiten 247 verwendet werden. Ein Level 2 (L2) Cache 253, der von allen oder einer Teilmenge der Mehrkerngruppen 240A-240N gemeinsam genutzt wird, speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafik-Threads. Wie veranschaulicht, kann L2-Cache 253 von einer Mehrzahl von Mehrkerngruppen 240A-240N gemeinsam genutzt werden. Ein oder mehrere Speicher-Controller 248 koppeln die GPU 239 mit einem Speicher 249, der ein Systemspeicher (z.B. DRAM) und/oder ein dedizierter Grafikspeicher (z.B. GDDR6-Speicher) sein kann.
  • Eingabe-/Ausgabe-Schaltungsanordnung (I/O) 250 koppelt die GPU 239 mit einer oder mehreren I/O-Vorrichtungen 252, wie etwa Digitalsignalprozessoren (DSPs), Netzwerk-Controllern oder Benutzereingabegeräte. Zum Koppeln der I/O-Vorrichtungen 252 mit der GPU 239 und Speicher 249 kann eine On-Chip-Verbindung verwendet werden. Ein oder mehrere I/O-Speicherverwaltungseinheiten (I/O Memory Management Units; IOMMUs) 251 der I/O-Schaltungsanordnung 250 koppeln die I/O-Vorrichtungen 252 direkt mit dem Systemspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen zum Abbilden virtueller Adressen zu physischen Adressen im Systemspeicher 249. In dieser Ausführungsform können sich die I/O-Vorrichtungen 252, CPU(s) 246 und GPU(s) 239 den gleichen virtuellen Adressraum teilen.
  • In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen verwalten, um virtuelle Gast-/Grafikadressen zu physischen Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen zum Abbilden der physischen Gast-/Grafikadressen zu physischen System-/Host-Adressen (z.B. innerhalb des Systemspeichers 249). Die Basisadressen des ersten und des zweiten Satzes von Seitentabellen kann in Steuerregistern gespeichert werden und bei einem Kontextwechsel getauscht werden (z.B. so dass der neue Kontext mit Zugang zu dem relevanten Satz der Seitentabellen bereitgestellt wird). Obwohl in 2C nicht veranschaulicht, kann jeder der Kerne 243, 244, 245 und/oder Mehrkerngruppen 240A-240N Translation Lookaside Buffer (TLBs) enthalten, um virtuelle Gast- zu physischen Gast-Übersetzungen, physische Gast zu physischen Host-Übersetzungen und virtuelle Gast- zu physischen Host-Übersetzungen zwischenzuspeichern.
  • In einer Ausführungsform sind die CPUs 246, GPUs 239 und I/O-Vorrichtungen 252 auf einem einzelnen Halbleiterchip und/oder Chip-Package integriert. Der veranschaulichte Speicher 249 kann auf dem gleichen Chip integriert sein oder er kann mit den Speicher-Controllern 248 über eine Off-Chip-Schnittstelle gekoppelt sein. In einer Implementierung umfasst der Speicher 249 GDDR6-Speicher, der den gleichen virtuellen Adressraum teilt, wie andere physische Speicher auf Systemebene, obwohl das zugrundeliegende Prinzip der Erfindung nicht auf diese spezifische Implementierung beschränkt ist.
  • In einer Ausführungsform enthalten die Tensor-Kerne 244 eine Mehrzahl von Ausführungseinheiten, die spezifisch dafür entworfen sind, Matrixoperationen durchzuführen, welche die fundamentalen Rechenoperationen sind, die zum Durchführen von Deep Learning Operationen verwendet werden. Für das Training eines neuralen Netzwerks und Inferenzierung können beispielsweise simultane Matrixmultiplikationsoperationen verwendet werden. Die Tensor-Kerne 244 können Matrixverarbeitung unter Verwendung einer Vielzahl von Operandenpräzisionen durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z.B. 32 Bit), Gleitkomma mit halber Genauigkeit (z. B. 16 Bit), Ganzzahlwörter (16 Bit), Bytes (8 Bit) und Halbbytes (4 Bit). In einer Ausführungsform extrahiert eine Implementierung eines neuralen Netzwerks Merkmale jeder gerenderten Szene und kombiniert dabei potenziell Details aus mehreren Frames, um ein Endbild in hoher Qualität zu konstruieren.
  • In Deep-Learning-Implementierungen kann Parallelmatrixmultiplikationsarbeit für Ausführung auf den Tensor-Kernen 244 geplant werden. Das Training neuraler Netzwerke erfordert insbesondere eine erhebliche Anzahl von Matrixpunktproduktoperationen. Um eine Innenproduktformulierung einer N × N × N Matrix zu multiplizieren, können die Tensor-Kerne 244 mindestens N Punktproduktverarbeitungselemente enthalten. Bevor das Matrixmultiplizieren beginnt, wird eine ganze Matrix in Kachel-Register geladen und mindestens eine Spalte einer zweiten Matrix wird jeden Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Punktprodukte, die verarbeitet werden.
  • Matrixelemente können mit verschiedenen Präzisionen je nach der bestimmten Implementierung gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (z.B. INT8) und 4-Bit-Halbbytes (z.B. INT4). Für die Tensor-Kerne 244 können verschiedene Präzisionsmodi festgelegt werden, um sicherzustellen, dass die effizienteste Präzision für unterschiedliche Arbeitslasten verwendet wird (z.B. Inferenzierung von Arbeitslasten, die Quantisierung zu Bytes und Halbbytes tolerieren können).
  • In einer Ausführungsform beschleunigen die Raytracing-Kerne 245 Raytracing-Operationen für Echtzeit-Raytracing- und Nicht-Echtzeit-Raytracing-Implementierungen. Die Raytracing-Kerne 245 enthalten insbesondere eine Strahltraversierungs-/Überschneidungsschaltungsanordnung zum Durchführen von Strahltraversierung unter Verwendung von Bounding-Volume-Hierarchien (BVHs) und Identifizieren von Überschneidungen zwischen Strahlen und Primitiven, die in den BVH-Volumen eingeschlossen sind. Die Raytracing-Kerne 245 können außerdem eine Schaltungsanordnung zum Durchführen von Tiefentests und Culling enthalten (z.B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung). In einer Implementierung führen die Raytracing-Kerne 245 Traversierungs- und Überschneidungsoperationen in Zusammenarbeit mit den hierin beschriebenen Bildentrauschungstechniken durch, von denen zumindest ein Teil auf den Tensor-Kernen 244 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensor-Kerne 244 beispielsweise ein neurales Deep Learning Netzwerk, um Entrauschen von Frames durchzuführen, die von den Raytracing-Kernen 245 erzeugt wurden. Die CPU(s) 246, Grafikkerne 243 und/oder Raytracing-Kerne 245 können jedoch auch einen Teil oder alle der Entrausch- und/oder Deep-Learning-Algorithmen implementieren.
  • Darüber hinaus kann, wie vorstehend beschrieben, ein verteilter Ansatz zum Entrauschen eingesetzt werden, bei dem sich die GPU 239 in einer Rechenvorrichtung befindet, die mit anderen Rechenvorrichtungen über ein Netzwerk oder eine Hochgeschwindigkeitsverbindung gekoppelt ist. In dieser Ausführungsform teilen die miteinander verbundenen Rechenvorrichtung neurales Netzwerk Lern-/Trainingdaten, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, Entrauschen für verschiedene Arten von Bild-Frames und/oder unterschiedliche Grafikanwendungen durchzuführen.
  • In einer Ausführungsform verarbeiten die Raytracing-Kerne 245 alle BVH-Traversalen und Strahlprimitive-Überschneidungen, wodurch die Grafikkerne 243 nicht mit Tausenden von Anweisungen pro Strahl überlastet werden. In einer Ausführungsform enthält jeder Raytracing-Kern 245 einen ersten Satz spezialisierter Schaltungsanordnungen zum Durchführen von Bounding-Box-Tests (z.B. für Traversaloperationen) und einen zweiten Satz spezialisierter Schaltungsanordnung zum Durchführen von Strahl-Dreieck-Überschneidungstests (z.B. sich überschneidende Strahlen, die traversiert wurden). Somit kann die Mehrkerngruppe 240A in einer Ausführungsform einfach eine Strahlsonde starten und die Raytracing-Kerne 245 führen unabhängig Strahltraversierung und Überschneidung durch und geben Trefferdaten (z.B. ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 243, 244 werden freigegeben, um andere Grafik- und Rechenarbeit durchzuführen, während die Raytracing-Kerne 245 die Traversierungs- und Überschneidungsoperationen durchführen.
  • In einer Ausführungsform enthält jeder Raytracing-Kern 245 eine Traversierungseinheit zum Durchführen von BVH-Testoperationen und eine Überschneidungseinheit, die strahlprimitive Überschneidungstests durchführt. Die Überschneidungseinheit generiert eine „Treffer“, „kein Treffer“ oder „mehrere Treffer“ Reaktion, die sie an den entsprechenden Thread bereitstellt. Während der Traversal- und Überschneidungsoperationen werden die Ausführungsressourcen der anderen Kerne (z.B. Grafikkerne 243 und Tensor-Kerne 244) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
  • In einer bestimmten, unten beschriebenen Ausführungsform wird ein Hybrid-Rasterungs-/Raytracing-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 243 und Raytracing-Kernen 245 verteilt wird.
  • In einer Ausführungsform enthalten die Raytracing-Kerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstützung für einen Raytracing-Anweisungssatz, wie etwa Microsoft DirectX Ray Tracing (DXR), welches einen DispatchRays-Befehl enthält, sowie Strahlgenerierung, Closest-Hit, Any-Hit und Miss-Shader und Texturen für jedes Objekt. Eine andere Raytracing-Plattform, die von den Raytracing-Kernen 245, Grafikkernen 243 und Tensor-Kernen 244 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu beachten, dass die zugrundeliegenden Prinzipien der Erfindung nicht auf eine bestimmte Raytracing-ISA beschränkt sind.
  • Im Allgemeinen können die verschiedenen Kerne 245, 244, 243 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlerzeugung, Closest-Hit, Any-Hit, strahlprimitive Überschneidung, per-primitive und hierarchische Bounding-Box-Konstruktion, Miss, Visit und Ausnahmen enthält. Eine Ausführungsform umfasst insbesondere Raytracing-Anweisungen zum Durchführen der folgenden Funktionen:
  • Strahlerzeugung - Strahlerzeugungsanweisungen können für jeden Pixel, jedes Sample oder andere benutzerdefinierte Arbeitszuweisungen ausgeführt werden.
  • Closest Hit - Eine Closest-Hit-Anweisung kann ausgeführt werden, um den am nächsten gelegenen Überschneidungspunkt eines Strahls mit Primitiven in einer Szene zu lokalisieren.
  • Any Hit - Eine Any-Hit-Anweisung identifiziert mehrere Überschneidungen zwischen einem Strahl und Primitiven in einer Szene, um potenziell einen neuen am nächsten liegenden Überschneidungspunkt zu identifizieren.
  • Überschneidung - Eine Überschneidungsanweisung führt einen strahlprimitiven Überschneidungstest durch und gibt ein Ergebnis aus.
  • Per-Primitiv Bounding-Box-Konstruktion- Diese Anweisung errichtet eine Bounding-Box um eine gegebene Primitive oder Gruppe von Primitiven (z.B. beim Bauen einer neuen BVH oder anderen Beschleunigungsdatenstruktur).
  • Miss - Gibt an, dass ein Strahl die gesamte Geometrie in einer Szene oder einen bestimmten Bereich einer Szene verfehlt.
  • Visit - Gibt die Kindvolumen an, die ein Strahl durchläuft.
  • Ausnahmen - Beinhaltet verschiedene Arten von Ausnahmen-Handlern (z.B. für diverse Fehlerbedingungen aufgerufen).
  • 2D ist ein Blockdiagramm der Universalzweck-Grafikverarbeitungseinheit (GPGPU) 270, die gemäß hierin beschriebenen Ausführungsformen als ein Grafikprozessor und/oder Rechenbeschleuniger konfiguriert sein kann. Die GPGPU 270 kann mit Host-Prozessoren (z.B. einer oder mehreren CPU(s) 246) und Speicher 271, 272 über ein oder mehrere System(e) und/oder Speicherbusse verbinden. In einer Ausführungsform ist der Speicher 271 ein Systemspeicher, der mit der einen oder den mehreren CPU(s) 246 geteilt werden kann, während Speicher 272 ein Vorrichtungsspeicher ist, der der GPGPU 270 zugewiesen ist. In einer Ausführungsform können Komponenten in der GPGPU 270 und Speichervorrichtung 272 in Speicheradressen abgebildet werden, die der einen oder den mehreren CPU(s) 246 zugänglich sind. Zugriff auf Speicher 271 und 272 kann über einen Speicher-Controller 268 ermöglicht werden. In einer Ausführungsform enthält der Speicher-Controller 268 einen internen Controller für direkten Speicherzugriff (Direct Memory Access; DMA) 269 oder er kann Logik zum Durchführen von Operationen enthalten, die ansonsten von einem DMA-Controller durchgeführt werden würden.
  • Die GPGPU 270 enthält mehrere Cache-Speicher, einschließlich eines L2-Cache 253, L1-Cache 254, eines Anweisungs-Cache 255 und gemeinsam genutzten Speichers 256, von dem mindestens ein Teil ebenfalls als ein Cache-Speicher partitioniert sein kann. Die GPGPU 270 enthält außerdem mehrere Recheneinheiten 260A-260N. Jede Recheneinheit 260A-260N enthält einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264. Die Recheneinheiten 260A-260N können auch lokalen gemeinsam genutzten Speicher 265 und einen Programmzähler 266 enthalten. Die Recheneinheiten 260A-260N können mit einem Konstant-Cache 267 koppeln, der zum Speichern konstanter Daten verwendet werden kann. Das sind Daten, die sich während der Ausführung des Kernel oder Shader-Programms, die auf der GPGPU 270 ausgeführt werden, nicht ändern. In einer Ausführungsform ist der Konstant-Cache 267 ein Skalardaten-Cache und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
  • Im Betrieb können die eine oder mehreren CPU(s) 246 Befehle in Register oder Speicher in die GPGPU 270 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 257 können die Befehle aus Registern oder dem Speicher auslesen und bestimmen, wie diese Befehle in der GPGPU 270 verarbeitet werden. Dann kann ein Thread-Dispatcher 258 zum Versenden der Threads an die Recheneinheiten 260A-260N zur Durchführung dieser Befehle verwendet werden. Jede Recheneinheit 260A-260N kann Threads unabhängig von den anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A-260N unabhängig für bedingte Berechnung konfiguriert sein und kann die Ergebnisse der Berechnung bedingt an den Speicher ausgeben. Die Befehlsprozessoren 257 können die eine oder die mehreren CPU(s) 246 unterbrechen, wenn die übermittelten Befehle abgeschlossen sind.
  • 3A-3C veranschaulichen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die durch die hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente in 3A-3C, die die gleichen Referenzzahlen (oder die gleichen oder ähnliche Bezeichnungen) aufweisen wie die Elemente anderer Figuren hierin, können auf eine ähnliche Art und Weise arbeiten oder funktionieren, können die gleichen Komponenten umfassen und können mit anderen Entitäten verbunden sein, wie jene, die an anderer Stelle hierin beschrieben sind, sie sind insofern aber nicht eingeschränkt.
  • 3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverabeitungseinheit sein kann oder ein Grafikprozessor sein kann, der mit mehreren Verarbeitungskernen oder anderen Halbleitervorrichtungen integriert ist, wie etwa, aber nicht beschränkt auf Speichervorrichtungen oder Netzwerkschnittstellen. In manchen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete I/O-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in dem Prozessspeicher platziert sind. In manchen Ausführungsformen enthält Grafikprozessor 300 eine Speicherschnittstelle 314 für Zugriff auf den Speicher. Speicherschnittstelle 314 kann eine Schnittstelle mit lokalem Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder dem Systemspeicher bilden.
  • In manchen Ausführungsformen enthält Grafikprozessor 300 auch einen Anzeige-Controller 302 zum Steuern von Anzeigeausgabedaten an eine Anzeigevorrichtung 318. Anzeige-Controller 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Komposition mehrerer Videoschichten oder Benutzerschnittstellenelemente. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform ist die Anzeigevorrichtung 318 eine am Kopf angebrachte Anzeigevorrichtung (Head-Mounted Display), wie etwa eine Virtual-Reality-Anzeigevorrichtung (VR) oder eine Augmented-Reality-Anzeigevorrichtung (AR). In manchen Ausführungsformen enthält Grafikprozessor 300 eine Video-Codec-Engine 306 zum Kodieren, Dekodieren oder Transkodieren von Medien zu, von oder zwischen einem oder mehreren Medien-Kodierungsformaten, einschließlich, aber nicht beschränkt auf Moving Picture Experts Group (MPEG) Formate, wie etwa MPEG-2, Advanced Video Coding (AVC) Formate, wie etwa H.264/MPEG-4 AVC, H.265/HEVC, Alliance for Open Media (AOMedia) VP8, VP9 sowie die Society of Motion Picture & Television Engineers (SMPTE) 421M/VC-1 und Joint Photographic Experts Group (JPEG) Formate, wie etwa JPEG und Motion JPEG (MJPEG) Formate.
  • In manchen Ausführungsformen enthält Grafikprozessor 300 eine Block-Image-Transfer-Engine (BLIT) 304 zum Durchführen zweidimensionaler (2D) Rasterungsoperationen, einschließlich beispielsweise Bit-Boundary Block Transfers. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (Graphics Processing Engine; GPE) 310 durchgeführt. In manchen Ausführungsformen ist GPE 310 eine Rechen-Engine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
  • In manchen Ausführungsformen enthält GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie etwa Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf Grundlage von 3D-primitiven Formen (z.B. Rechteck, Dreieck usw.) wirken. Die 3D-Pipeline 312 enthält programmierbare und Festfunktionselemente, die innerhalb des Elements diverse Aufgaben durchführen und/oder Ausführungs-Threads zu einem 3D/Medien-Subsystem 315 spawnen. Während 3D-Pipeline 312 zum Durchführen von Medienoperationen verwendet werden kann, enthält eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die speziell zur Durchführung von Medienoperationen verwendet wird, wie etwa Videonachbearbeitung und Bildverbesserung.
  • In manchen Ausführungsformen enthält Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten zum Durchführen einer oder mehrerer spezialisierter Medienoperationen, wie etwa Videodekodierungsbeschleunigung, Videoentflechtung und Videokodierungsbeschleunigung anstatt von oder für Video-Codec-Engine 306. In manchen Ausführungsformen enthält Medien-Pipeline 316 zusätzlich eine Thread-Spawning-Einheit zum Spawnen von Threads zur Ausführung auf 3D-/Medien-Subsystem 315. Die gespawnten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten, die in 3D-/Medien-Subsystem 315 enthalten sind, durch.
  • In manchen Ausführungsformen enthält 3D-/Medien-Subsystem 315 Logik zum Ausführen von Threads, die von 3D-Pipeline 312 und Medien-Pipeline 316 gespawnt wurden. In einer Ausführungsform senden die Pipelines Thread-Ausführungs-Anforderungen an 3D-/Medien-Subsystem 315, die Thread-Dispatch-Logik zur Vermittlung und zum Versand der verschiedenen Anforderungen an verfügbare Thread-Ausführungsressourcen enthalten. Die Ausführungsressourcen enthalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. In manchen Ausführungsformen enthält 3D-/Medien-Subsystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und Daten. In manchen Ausführungsformen enthält das Subsystem außerdem gemeinsam genutzten Speicher, einschließlich Registern und adressierbarem Speicher, um Daten zwischen Threads zu teilen und um Ausgabedaten zu speichern.
  • 3B veranschaulicht einen Grafikprozessor 320 mit einer Kachelarchitektur gemäß hierin beschriebenen Ausführungsformen. In einer Ausführungsform enthält der Grafikprozessor 320 ein Grafikverarbeitungs-Engine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungs-Engine 310 der 3A in einer Grafik-Engine-Kachel 310A-310D.
  • Jede Grafik-Engine-Kachel 310A-310D kann über einen Satz von Kachelverbindungen 323A-323F verbunden werden. Jede Grafik-Engine-Kachel 310A-310D kann auch mit einem Speichermodul oder einer Speichervorrichtung 326A-326D über Speicherverbindungen 325A-325D verbunden werden. Die Speichervorrichtungen 326A-326D können jedwede Grafikspeichertechnologie verwenden. Die Speichervorrichtungen 326A-326D können beispielsweise ein GDDR-Speicher (Graphics Double Data Rate) sein. Die Speichervorrichtungen 326A-326D sind in einer Ausführungsform HBM-Module (High-Bandwith Memory), die mit ihrer jeweiligen Grafik-Engine-Kachel 310A-310D in dem Die sein können. In einer Ausführungsform sind die Speichervorrichtungen 326A-326D gestapelte Speichervorrichtungen, die auf ihrer jeweiligen Grafik-Engine-Kachel 310A-310D gestapelt sein können. In einer Ausführungsform befindet sich jede Grafik-Engine-Kachel 310A-310D und der zugeordnete Speicher 326A-326D auf separaten Chiplets, die mit einem Basis-Die oder Basissubstrat bondiert sind, wie in 11B-11D ausführlicher beschrieben.
  • Der Grafikprozessor 1620 kann mit einem NUMA-System (Non-Uniform Memory Access) konfiguriert sein, bei dem Speichervorrichtungen 326A-326D mit zugeordneten Grafik-Engine-Kacheln 310A-310D gekoppelt sind. Auf eine gegebene Speichervorrichtung kann durch andere Grafik-Engine-Kacheln als die Kachel, mit der sie direkt verbunden ist, zugegriffen werden. Die Latenz eines Zugriffs auf die Speichervorrichtungen 326A-326D kann jedoch am niedrigsten sein, wenn auf eine lokale Kachel zugegriffen wird. In einer Ausführungsform wird ein ccNUMA-System (Cache Coherent NUMA) befähigt, das die Kachelverbindungen 323A-323F verwendet, um Kommunikation zwischen Cache-Controllern in den Grafik-Engine-Kacheln 310A-310D zu ermöglichen, um ein konsistentes Speicher-Image zu halten, wenn mehr als ein Cache die gleiche Speicherposition speichert.
  • Das Grafik-Verarbeitungs-Engine-Cluster 322 kann mit einer On-Chip- oder On-Package-Fabric-Verbindung 324 verbinden. Die Fabric-Verbindung 324 kann Kommunikation zwischen Grafik-Engine-Kacheln 310A-310D und Komponenten, wie etwa dem Video-Codec 306 und einer oder mehreren Copy-Engines 304, ermöglichen. Die Copy-Engines 304 können verwendet werden, um Daten aus, in und zwischen den Speichervorrichtungen 326A-326D und einem Speicher extern von dem Grafikprozessor 320 (z.B. Systemspeicher) zu bewegen. Die Fabric-Verbindung 324 kann auch dazu verwendet werden, die Grafik-Engine-Kacheln 310A-310D zu verbinden. Der Grafikprozessor 320 kann optional einen Anzeige-Controller 302 enthalten, um eine Verbindung mit einer externen Anzeigevorrichtung 318 zu ermöglichen. Der Grafikprozess kann auch als ein Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können der Anzeige-Controller 302 und die Anzeigevorrichtung 318 weggelassen werden.
  • Der Grafikprozessor 320 kann über eine Host-Schnittstelle 328 mit einem Host-System verbinden. Die Host-Schnittstelle 328 kann Kommunikation zwischen dem Grafikprozessor 320, Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 328 kann beispielsweise ein PCI-Express-Bus oder eine andere Art von Host-System-Schnittstelle sein.
  • 3C veranschaulicht einen Rechenbeschleuniger 330 gemäß hierin beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architektonische Ähnlichkeiten mit dem Grafikprozessor 320 in 3B aufweisen und ist für Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz von Rechen-Engine-Kacheln 340A-340D enthalten, die Ausführungslogik enthalten, die für Parallel- oder vektorbasierte Universalrechenoperationen optimiert ist. In manchen Ausführungsformen enthalten die Rechen-Engine-Kacheln 340A-340D keine Festfunktionsgrafikverarbeitungslogik, obwohl in einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A-340D Logik zum Durchführen von Medienbeschleunigung enthalten können. Die Rechen-Engine-Kacheln 340A-340D können über Speicherverbindungen 325A-325D mit Speichern 326A-326D verbinden. Die Speicher 326A-326D und Speicherverbindungen 325A-325D können eine ähnliche Technologie sein, wie im Grafikprozessor 320, oder sie können unterschiedlich sein. Die Grafik-Rechen-Engine-Kacheln 340A-340D können auch über einen Satz von Kachelverbindungen 323A-323F miteinander verbunden sein und sie können mit und/oder durch eine Fabric-Verbindung 324 verbunden sein. In einer Ausführungsform enthält der Rechenbeschleuniger 330 einen großen L3-Cache 336, der als ein vorrichtungsweiter Cache konfiguriert sein kann. Der Rechenbeschleuniger 330 kann auch mit einem Host-Prozessor und Speicher über eine Host-Schnittstelle 328 auf eine ähnliche Weise verbunden sein, wie der Grafikprozessor 320 in 3B.
  • Grafikverarbeitungs-Engine
  • 4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß manchen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3A gezeigten GPE 310 und sie kann auch eine Grafik-Engine Kachel 310A-310D in 3B repräsentieren. Elemente in 4, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, arbeiten oder funktionieren auf eine ähnliche Weise, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt. Es sind beispielsweise die 3D-Pipeline 312 und Medien-Pipeline 316 in 3A veranschaulicht. Die Medien-Pipeline 316 ist in manchen Ausführungsformen der GPE 410 optional und sie muss nicht explizit in der GPE 410 enthalten sein. Zum Beispiel und in mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
  • In manchen Ausführungsformen koppelt GPE 410 mit oder enthält einen Befehls-Streamer 403, der einen Befehls-Stream an die 3D-Pipeline 312 und/oder Medien-Pipelines 316 bereitstellt. In manchen Ausführungsformen ist Befehls-Streamer 403 mit Speicher gekoppelt, welcher ein Systemspeicher oder ein oder mehrere interne Cache-Speicher und gemeinsam genutzter Cache-Speicher sein kann. In manchen Ausführungsformen empfängt Befehls-Streamer 403 Befehle von dem Speicher und sendet die Befehle an 3D-Pipeline 312 und/oder Medien-Pipeline 316. Die Befehle sind Direktiven, die von einem Ringpuffer abgerufen werden, der Befehle für die 3D-Pipeline 312 und Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batch-Befehls-Puffer enthalten, die Batches mit mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten, die im Speicher gespeichert sind, enthalten, wie etwa, aber nicht beschränkt auf Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Durchführung von Operationen über Logik in den jeweiligen Pipelines oder durch Versenden eines oder mehrerer Ausführungs-Threads an ein Grafikkern-Array 414. In einer Ausführungsform enthalten das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z.B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, die Universal- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Rechenoperationen sowie Festfunktionstexturverarbeitung und/oder Maschinenlern- und künstliche Intelligenz Beschleunigungslogik enthalten.
  • In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 Festfunktions- und programmierbare Logik enthalten, um ein oder mehrere Shader-Programme, wie etwa Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme, durch Verarbeiten der Anweisungen und Versenden von Ausführungs-Threads an das Grafikkern-Array 414 zu verarbeiten. Das Grafikkern-Array 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) in dem oder den Grafikkern(en) 415A-414B des Grafikkern-Array 414 enthalten Unterstützung für diverse 3D-API-Shader-Sprachen und können mehrere gleichzeitige Ausführungs-Threads, die mehreren Shadern zugeordnet sind, ausführen.
  • In manchen Ausführungsformen enthält das Grafikkern-Array 414 Ausführungslogik zum Durchführen von Medienfunktionen, wie etwa Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten Universallogik, die programmierbar ist, um parallele Universalrechenoperationen zusätzlich zu Grafikverarbeitungsoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel zu oder zusammen mit Universallogik in dem bzw. den Prozessorkern(en) 107 in 1 oder Kern 202A-202N in 2A durchführen.
  • Von Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, generierte Ausgabedaten können an einen Speicher in einem URB (Unified Return Buffer) 418 ausgegeben werden. Der URB 418 kann Daten für mehrere Threads speichern. In manchen Ausführungsformen kann der URB 418 zum Senden von Daten zwischen unterschiedlichen Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, verwendet werden. In manchen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisation von Threads auf dem Grafikkern-Array und Festfunktionslogik in der gemeinsam genutzten Funktionslogik 420 verwendet werden.
  • In manchen Ausführungsformen ist Grafikkern-Array 414 derart skalierbar, dass das Array eine variable Anzahl von Grafikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten basierend auf der Zielleistung und dem Leistungsniveau der GPE 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass Ausführungsressourcen nach Bedarf aktiviert oder deaktiviert werden können.
  • Das Grafik-Kern-Array 414 koppelt mit gemeinsamer Funktionslogik 420, die mehrere Ressourcen enthält, die zwischen den Grafikkernen in dem Grafikkern-Array geteilt werden. Die gemeinsamen Funktionen in der gemeinsamen Funktionslogik 420 sind Hardwarelogikeinheiten, die spezialisierte Zusatzfunktionalität an das Grafikkern-Array 414 bereitstellen. In verschiedenen Ausführungsformen enthält gemeinsame Funktionslogik 420 Sampler 421, Mathematik 422 und ITC (Inter-Thread Communication) 423 Logik, ist aber nicht darauf beschränkt. Zusätzlich implementieren manche Ausführungsformen einen oder mehrere Cache(s) 425 in der gemeinsamen Funktionslogik 420.
  • Eine gemeinsame Funktion wird mindestens in einem Fall implementiert, in dem der Bedarf an einer gegebenen spezialisierten Funktion unzureichend für Aufnahme in das Grafikkern-Array 414 ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsamen Funktionslogik 420 implementiert und von den Ausführungsressourcen in dem Grafikkern-Array 414 gemeinsam genutzt. Der genaue Satz von Funktionen, der von dem Grafikkern-Array 414 gemeinsam genutzt wird und in dem Grafikkern-Array 414 enthalten ist, variiert je nach Ausführungsform. In manchen Ausführungsformen können spezifische gemeinsam genutzte Funktionen in der gemeinsamen Funktionslogik 420, die intensiv von dem Grafikkern-Array 414 genutzt werden, in gemeinsame Funktionslogik 416 in dem Grafik-Core-Array 414 aufgenommen werden. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in dem Grafikkern-Array 414 manche oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente in der gemeinsam genutzten Funktionslogik 420 in der gemeinsam genutzten Funktionslogik 416 des Grafikkern-Array 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Logik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 in dem Grafikkern-Array 414 ausgeschlossen.
  • Ausführungseinheiten
  • 5A-5B veranschaulichen Thread-Ausführungslogik 500, die ein Array von Verarbeitungselementen enthält, die in einem Grafikprozessorkern gemäß hierin beschriebenen Ausführungsformen eingesetzt werden. Elemente in 5A-5B, die die gleichen Referenzzahlen (oder Bezeichnungen) aufweisen, wie die Elemente einer anderen Figur hierin, arbeiten oder funktionieren auf eine ähnliche Weise, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt. 5A-5B veranschaulichen einen Überblick über Thread-Ausführungslogik 500, die für Hardwarelogik repräsentativ sein kann, die mit jedem Sub-Kern 221A-221F in 2B veranschaulicht ist. 5A ist für eine Ausführungseinheit in einem Universalgrafikprozessor repräsentativ, während 5B für eine Ausführungseinheit repräsentativ ist, die in einem Computerbeschleuniger verwendet werden kann.
  • Wie in 5A veranschaulicht, enthält Thread-Ausführungslogik 500 in manchen Ausführungsformen einen Shader-Prozessor 502, einen Thread-Dispatcher 504, einen Anweisungs-Cache 506, ein skalierbares Ausführungseinheit-Array, das mehrere Ausführungseinheiten 508A-508N enthält, einen Sampler 510, gemeinsam genutzten lokalen Speicher 511, einen Daten-Cache 512 und einen Datenport 514. In einer Ausführungsform kann das skalierbare Ausführungseinheit-Array durch Aktivieren oder Deaktivieren von einer oder mehreren Ausführungseinheiten (z.B. beliebige der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) basierend auf den Rechenerfordernissen einer Arbeitslast skalieren. In einer Ausführungsform sind die enthaltenen Komponenten über ein Verbindungs-Fabric, das mit jeder der Komponenten verbunden ist, miteinander verbunden. In manchen Ausführungsformen enthält Thread-Ausführungslogik 500 eine oder mehrere Verbindungen mit einem Speicher, wie etwa Systemspeicher oder Cache-Speicher, durch einen Anweisungs-Cache 506, Datenport 514, Sampler 510 und/oder Ausführungseinheiten 508A-508N. In manchen Ausführungsformen ist jede Ausführungseinheit (z.B. 508A) eine eigenständige programmierbare Universalrecheneinheit, die dazu in der Lage ist, mehrere simultane Hardware-Threads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 508A-508N skalierbar, um eine beliebige Anzahl individueller Ausführungseinheiten zu enthalten.
  • In manchen Ausführungsformen werden die Ausführungseinheiten 508A-508N primär zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 502 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads, die den Shader-Programmen zugeordnet sind, über einen Thread-Dispatcher 504 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik zum Vermitteln von Thread-Initiierungsanforderungen von den Grafik- und Medien-Pipelines und zum Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A-508N. Eine Geometrie-Pipeline kann beispielsweise Vertex-, Tesselations- oder Geometrie-Shader an die Thread-Ausführungslogik zur Verarbeitung senden. In manchen Ausführungsformen kann Thread-Dispatcher 504 auch Laufzeit-Thread-Spawning-Anforderungen von den ausführenden Shader-Programmen verarbeiten.
  • In manchen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N einen Anweisungssatz, der derart native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen enthält, dass Shader-Programme aus Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z.B. Vertexprogramme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z.B. Pixel-Shader, Fragment-Shader) und Universalverarbeitung (z.B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 508A-508N ist zu SIMD-Ausführung (Multi-Issue Single Instruction Multiple Data) in der Lage und Multi-Thread-Operation ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread in jeder Ausführungseinheit verfügt über eine dedizierte Registerdatei mit hoher Bandbreite und zugeordnetem unabhängigem Thread-Status. Ausführung erfolgt mehrfach pro Takt an Pipelines, die Integer-, einfach und doppeltgenaue Gleitkommaoperationen, SIMD-Verzweigungsfähigkeit, logische Operationen, transzendentale Operationen und andere verschiedene Operationen ausführen können. Während des Wartens auf Daten aus dem Speicher oder einer der gemeinsam genutzten Funktionen veranlasst Abhängigkeitslogik in Ausführungseinheiten 508A-508N einen wartenden Thread zum Schlafen bis die angeforderten Daten zurückgeführt wurden. Während der wartende Thread schläft, können Hardwareressourcen der Verarbeitung anderer Threads gewidmet werden. Während einer Verzögerung in Verbindung mit einer Vertex-Shader-Operation kann eine Ausführungseinheit beispielsweise Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm durchführen, einschließlich eines anderen Vertex-Shaders. Verschiedene Ausführungsformen können Ausführung durch Verwendung von Single Instruction Multiple Thread (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD anwenden. Verweise auf einen SIMD-Kern oder -Betrieb können auch für SIMT oder für SIMD in Kombination mit SIMT gelten.
  • Jede Ausführungseinheit in Ausführungseinheiten 508A-508N arbeiten an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ bzw. die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Einheit der Ausführung für Datenelementezugriff, Maskierung und Flusssteuerung in Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl physischer arithmetischer Logikeinheiten (Arithmetic Logic Units; ALUs) oder Gleitkommaeinheiten (Floating Point Units; FPUs) für einen bestimmten Grafikprozessor sein. In manchen Ausführungsformen unterstützen Ausführungseinheiten 508A-508N Ganzzahl- und Gleitkomma-Datentypen.
  • Der Ausführungseinheitanweisungssatz enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Bei der Arbeit an einem 256-Bit breiten Vektor werden die 256 Bits des Vektors beispielsweise in einem Register gespeichert und die Ausführungseinheit arbeitet an dem Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente mit Quad-Wort (QW) Größe), acht separaten gepackten 32-Bit-Datenelementen (Datenelemente mit Doppel-Wort (DW) Größe), sechzehn separaten gepackten 16-Bit-Datenelementen (Datenelemente mit Wort (W) Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente mit Byte (B) Größe). Es sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
  • In einer Ausführungsform kann eine oder können mehrere Ausführungseinheiten in eine gemeinsame Ausführungseinheit 509A-509N mit Thread-Steuerlogik (507A-507N), die den kombinierten EUs gemeinsam ist, kombiniert werden. Mehrere EUs können in eine EU-Gruppe kombiniert werden. Jede EU in der kombinierten EU-Gruppe kann konfiguriert werden, einen separaten SIMD-Hardware-Thread auszuführen. Die Anzahl der EUs in einer kombinierten EU-Gruppe kann je nach Ausführungsform variieren. Zusätzlich können verschiedene SIMD-Breiten pro EU ausgeführt werden, einschließlich, aber nicht beschränkt auf SIMD8, SIMD16 und SIMD32. Jede kombinierte Grafikausführungseinheit 509A-509N enthält mindestens zwei Ausführungseinheiten. Kombinierte Ausführungseinheit 509A enthält beispielsweise eine erste EU 508A, zweite EU 508B und Thread-Steuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam sind. Die Thread-Steuerlogik 507A steuert Threads, die auf der kombinierten Grafikausführungseinheit 509A ausgeführt werden und ermöglicht jeder EU in den kombinierten Ausführungseinheiten 509A-509N unter Verwendung eines gemeinsamen Anweisungszeigerregisters auszuführen.
  • In der Thread-Ausführungslogik 500 sind ein oder mehrere interne Anweisungs-Caches (z.B. 506) enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In manchen Ausführungsformen sind ein oder mehrere Daten-Caches (z.B. 512) enthalten, um Thread-Daten während Thread-Ausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit verwaltete Daten in dem gemeinsam genutztem lokalen Speicher 511 speichern. In manchen Ausführungsformen ist ein Sampler 510 enthalten, um Textur-Sampling für 3D-Operationen und Medien-Sampling für Medienoperationen bereitzustellen. In manchen Ausführungsformen enthält Sampler 510 spezialisierte Textur- oder Medien-Sampling-Funktionalität, um Textur- oder Mediendaten während des Sampling-Prozesses vor Bereitstellen der gesampleten Daten an eine Ausführungseinheit zu verarbeiten.
  • Während der Ausführung senden die Grafik- und Medien-Pipelines über Thread-Spawning- und Dispatch-Logik Thread-Initiierungs-Anforderungen an Thread-Ausführungslogik 500. Nachdem eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten gerastert wurde, wird Pixelprozessorlogik (z.B. Pixel-Shader-Logik, Fragment-Shader-Logik usw.) in dem Shader-Prozessor 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu veranlassen, dass Ergebnisse zu Ausgabeflächen (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In manchen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt zu interpolieren sind. In manchen Ausführungsformen führt die Pixel-Prozessor-Logik in dem Shader-Prozessor 502 dann ein API (Application Programming Interface) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Zum Ausführen des Shader-Programms sendet der Shader-Prozessor 502 Threads über Thread-Dispatcher 504 an eine Ausführungseinheit (z.B. 508A). In manchen Ausführungsformen verwendet Shader-Prozessor 502 Textur-Sampling-Logik in dem Sampler 510, um auf Texturdaten in Textur-Maps, die im Speicher gespeichert sind, zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwirft einen oder mehrere Pixel aus der weiteren Verarbeitung.
  • In manchen Ausführungsformen stellt der Datenport 514 einen Speicherzugangsmechanismus für die Thread-Ausführungslogik 500 bereit, um verarbeitete Daten an den Speicher zur weiteren Verarbeitung in einer Grafikprozessorausgabe-Pipeline auszugeben. In manchen Ausführungsformen enthält der Datenport 514 oder koppelt mit einem oder mehreren Cache-Speichern (z.B. Daten-Cache 512), um Daten für Speicherzugriff über den Datenport zwischenzuspeichern.
  • In einer Ausführungsform kann die Ausführungslogik 500 auch einen Raytracer 505 enthalten, der Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Der Raytracer 505 kann einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen für Strahlerzeugung enthält. Der Raytracing-Anweisungssatz kann dem Raytracing-Anweisungssatz, der von den Raytracing-Kernen 245 in 2C unterstützt wird, ähnlich sein oder sich davon unterscheiden.
  • 5B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 508 gemäß Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, ein allgemeines Registerdatei-Array (General Register File; GRF) 524, ein architektonisches Registerdatei-Array (Architectural Register File; ARF) 526, einen Thread-Arbiter 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz von SIMD-Gleitkommaeinheiten (Floating Point Units; FPUs) 534 und in einer Ausführungsform einen Satz dedizierter Ganzzahl-SIMD-ALUs 535 umfassen. Das GRF 524 und ARF 526 enthalten den Satz allgemeiner Registerdateien und Architekturregisterdateien, die jedem simultanen Hardware-Thread zugewiesen sind, der in der Grafikausführungseinheit 508 aktiv sein kann. In einer Ausführungsform wird der architektonische per Thread Zustand in dem ARF 526 aufrechterhalten, während Daten, die während der Thread-Ausführung genutzt werden, in dem GRF 524 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, können in Thread-spezifischen Registern in dem ARF 526 gehalten werden.
  • In einer Ausführungsform verfügt die Grafikausführungseinheit 508 über eine Architektur, die eine Kombination aus simultanem Multi-Threading (SMT) und feinkörnigem Interleaved Multi-Threading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Entwurfszeitpunkt auf Grundlage einer Zielanzahl simultaner Threads und einer Anzahl von Registern pro Ausführungseinheit fein abgestimmt sein kann, wobei Ausführungseinheitressourcen über Logik verteilt sind, die zum Ausführen mehrerer simultaner Threads verwendet wird. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt und es können jedem Hardware-Thread mehrere logische Threads zugewiesen werden.
  • In einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Anweisungen mit ausgeben, die jeweils andere Anweisungen sein können. Der Thread-Arbiter 522 des Grafikausführungseinheit-Threads 508 kann die Anweisungen an eine von Sendeeinheit 530, Verzweigungseinheit 532 oder SIMD-FPU(s) 534 zur Ausführung versenden. Jeder Ausführungs-Thread kann auf 128 Universalregister in dem GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein SIMD 8-Element-Vektor von 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform verfügt jeder Ausführungseinheit-Thread über Zugang zu 4 Kbytes in dem GRF 524, obwohl Ausführungsformen nicht auf diese Weise eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardware-Threads partitioniert, die Rechenoperationen unabhängig durchführen können, obwohl die Anzahl der Threads pro Ausführungseinheit ebenfalls je nach Ausführungsform variieren kann. In einer Ausführungsform werden beispielsweise bis zu 16 Hardware-Threads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 Kbytes zugreifen können, kann der GRF 524 insgesamt 28 Kbytes speichern. Wenn 16 Threads auf 4 Kbytes zugreifen können, kann das GRF 524 insgesamt 64 Kbytes speichern. Flexible Adressierungsmodi können es zulassen, dass Register zusammen adressiert werden, um effektiv breitere Register zu bilden oder um geschichtete rechteckige Blockdatenstrukturen zu repräsentieren.
  • In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit höherer Latenz über „Sende“-Anweisungen versendet, die von der Message-Passing-Sendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 versendet, um SIMD-Divergenz und eventuelle Konvergenz zu ermöglichen.
  • In einer Ausführungsform enthält die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 zum Durchführen von Gleitkommaoperationen. In einer Ausführungsform unterstützen die FPU(s) 534 auch Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 534 bis zu einer M Anzahl von 32-Bit Gleitkomma- (oder Ganzzahl-) Operationen SIMD-ausführen oder bis zu 2M 16-Bit Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMD-ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) erweiterte mathematische Fähigkeit zur Unterstützung von transzendentalen mathematischen Funktionen mit hohem Durchsatz und 54-Bit Gleitkomma mit doppelter Präzision bereit. In manchen Ausführungsformen ist auch ein Satz von 8-Bit Ganzzahl-SIMD-ALUs 535 vorhanden und kann spezifisch optimiert sein, um Operationen durchzuführen, die Maschinenlernberechnungen zugeordnet sind.
  • In einer Ausführungsform können Arrays mehrerer Instanzen der Grafikausführungseinheit 508 in einer Grafik-Sub-Kern-Gruppierung (z.B. einem Sub-Slice) instanziiert werden. Zur Skalierbarkeit können Produktarchitekten die exakte Anzahl von Ausführungseinheiten pro Sub-Kern-Gruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über mehrere Ausführungskanäle ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 508 ausgeführt wird, auf einem anderen Kanal ausgeführt.
  • 6 veranschaulicht eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform. Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit beispielsweise zur Verwendung in einer Rechen-Engine-Kachel 340A-340D, wie in 3C gezeigt, sein, ist insofern aber nicht beschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafik-Engine-Kachel 310A-310D, wie in 3B gezeigt, verwendet werden. In einer Ausführungsform enthält die Ausführungseinheit 600 eine Thread-Steuereinheit 601, eine Thread-Zustandseinheit 602, eine Anweisungs-Abruf-/Vorabrufeinheit 603 und eine Anweisungsdekodiereinheit 604. Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die Register speichert, die an Hardware-Threads in der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 enthält zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608. In einer Ausführungsform können die Sendeeinheit 607 und Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 in 5B arbeiten.
  • Die Ausführungseinheit 600 enthält auch eine Recheneinheit 610, die mehrere unterschiedliche Arten funktionaler Einheiten umfasst. In einer Ausführungsform enthält die Recheneinheit 610 eine ALU-Einheit 611, die ein Array arithmetischer Logikeinheiten umfasst. Die ALU-Einheit 611 kann dafür ausgelegt sein, 64-Bit, 32-Bit und 16-Bit Ganzzahl- und Gleitkommaoperationen durchzuführen. Ganzzahl- und Gleitkommaoperationen können gleichzeitig durchgeführt werden. Die Recheneinheit 610 kann auch ein systolisches Array 612 und eine Mathematikeinheit 613 enthalten. Das systolische Array 612 enthält ein W breites und D tiefes Netzwerk von Datenverarbeitungseinheiten, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf eine systolische Weise durchzuführen. In einer Ausführungsform kann das systolische Array 612 dafür ausgelegt sein, Matrixoperationen durchzuführen, wie etwa Matrixpunktproduktoperationen. In einer Ausführungsform unterstützt das systolische Array 612 16-Bit Gleitkommaoperationen sowie 8-Bit und 4-Bit-Ganzzahloperationen. In einer Ausführungsform kann das systolische Array 612 dafür ausgelegt sein, Maschinenlernoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das bfloat 16-Bit Gleitkommaformat konfiguriert sein. In einer Ausführungsform kann eine Mathematikeinheit 613 enthalten sein, um eine spezifische Untergruppe mathematischer Operationen auf eine effizientere und stromsparendere Weise als die ALU-Einheit 611 durchzuführen. Die Mathematikeinheit 613 kann eine Variante von Mathematiklogik enthalten, die sich in gemeinsam genutzter Funktionslogik einer Grafikverarbeitungs-Engine findet, die von anderen Ausführungsformen bereitgestellt wird (z.B. Mathematiklogik 422 der gemeinsam genutzten Funktionslogik 420 in 4). In einer Ausführungsform kann die Mathematikeinheit 613 dafür ausgelegt sein, 32-Bit und 64-Bit Gleitkommaoperationen durchzuführen.
  • Die Thread-Steuereinheit 601 enthält Logik zum Steuern der Ausführung von Threads in der Ausführungseinheit. Die Thread-Steuereinheit 601 kann Thread-Arbitrierungslogik zum Starten, Stoppen und zur vorzeitigen Ausführung von Threads in der Ausführungseinheit 600 enthalten. Die Thread-Zustandslogik 602 kann zum Speichern des Thread-Zustands für Threads, die einer Ausführung auf der Ausführungseinheit 600 zugewiesen sind, verwendet werden. Speichern des Thread-Zustands in der Ausführungseinheit 600 ermöglicht die schnelle vorzeitige Ausführung von Threads, wenn diese Threads blockiert werden oder untätig sind. Die Anweisungs-Abruf-/Vorabrufeinheit 603 kann Anweisungen aus einem Anweisungs-Cache einer Ausführungslogik höherer Ebene (z.B. Anweisungs-Cache 506, wie in 5A) abrufen. Die Anweisungs-Abruf-/Vorabrufeinheit 603 kann auch, basierend auf einer Analyse der Threads, die aktuell ausgeführt werden, Vorabrufanforderungen für Anweisungen ausgeben, die in den Anweisungs-Cache zu laden sind. Die Anweisungsdekodiereinheit 604 kann zum Dekodieren von Anweisungen, die von den Recheneinheiten auszuführen sind, verwendet werden. In einer Ausführungsform kann die Anweisungsdekodiereinheit 604 als ein Sekundärdekoder zum Dekodieren komplexer Anweisungen in einzelne Mikrooperationen verwendet werden.
  • Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die von Hardware-Threads genutzt werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Register in der Registerdatei 606 lassen sich über die Logik, die zum Ausführen mehrerer simultaner Threads in der Recheneinheit 610 der Ausführungseinheit 600 verwendet wird, verteilen. Die Anzahl logischer Threads, die von der Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Anzahl von Hardware-Threads beschränkt und es können jedem Hardware-Thread mehrere logische Threads zugewiesen werden. Die Größe der Registerdatei 606 kann je nach Ausführungsform basierend auf der Anzahl unterstützter Hardware-Threads variieren. In einer Ausführungsform kann Registerumbenennung verwendet werden, um Register dynamisch an Hardware-Threads zuzuweisen.
  • 7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat 700 gemäß manchen Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die mit durchgezogenen Linien gezeigten Kästchen veranschaulichen die Komponenten, die im Allgemeinen in einer Ausführungseinheitanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Untergruppe der Anweisungen enthalten sind. In manchen Ausführungsformen besteht das beschriebene und veranschaulichte Anweisungsformat 700 insofern aus Makroanweisungen, als dass sie Anweisungen sind, die an die Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die aus Anweisungsdekodierung resultieren, nachdem die Anweisung verarbeitet wurde.
  • In manchen Ausführungsformen unterstützen die Grafikprozessorausführungseinheiten nativ Anweisungen in einem 128-Bit Anweisungsformat 710. Ein kompaktes 64-Bit Anweisungsformat 730 ist für manche Anweisungen basierend auf der gewählten Anweisung, Anweisungsoptionen und Anzahl von Operanden verfügbar. Das native 128-Bit Anweisungsformat 710 stellt Zugang zu allen Anweisungsoptionen bereit, während manche Optionen und Operationen in dem 64-Bit Format 730 eingeschränkt sind. Die in dem 64-Bit Format 730 verfügbaren nativen Anweisungen variieren je nach Ausführungsform. In manchen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 verdichtet. Die Ausführungseinheithardware referenziert einen Satz von Verdichtungstabellen basierend auf den Indexwerten und verwendet die Ausgaben der Verdichtungstabelle zum Rekonstruieren einer nativen Anweisung in dem 128-Bit Anweisungsformat 710. Es können auch andere Größen und Formate von Anweisungen verwendet werden
  • Für jedes Format definiert Anweisungs-Opcode 712 die Operation, die die Ausführungseinheit durchzuführen hat. Die Ausführungseinheiten führen jede Anweisung parallel in den mehreren Datenelementen jedes Operanden aus. In Reaktion auf eine Addieranweisung führt die Ausführungseinheit beispielsweise eine simultane Addieroperation für jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung an allen Datenkanälen der Operanden durch. In manchen Ausführungsformen ermöglicht Anweisungssteuerungsfeld 714 Steuerung bestimmter Ausführungsoptionen, wie etwa Kanalauswahl (z.B. Prädikation) und Datenkanalreihenfolge (z.B. Swizzle). Für Anweisungen in dem 128-Bit Anweisungsformat 710 begrenzt ein exec-size-Feld 716 die Anzahl von Datenkanälen, die parallel ausgeführt werden. In manchen Ausführungsformen steht das exec-size-Feld 716 zur Verwendung in dem kompakten 64-Bit Anweisungsformat 730 nicht zur Verfügung.
  • Manche Ausführungseinheitanweisungen verfügen über bis zu drei Operanden, einschließlich zwei Quelloperanden, src0 720, src1 722, und ein Ziel 718. In manchen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können über einen dritten Quelloperanden (z.B. SRC2 724) verfügen, wobei der Anweisungs-Opcode 712 die Anzahl der Quelloperanden bestimmt. Ein letzter Quelloperand einer Anweisung kann ein unmittelbarer (z.B. hartkodierter) Wert sein, der mit der Anweisung übermittelt wird.
  • In manchen Ausführungsformen enthält das 128-Bit Anweisungsformat 710 ein Zugriffs-/Adressierungsmodusfeld 726, das beispielsweise spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
  • In manchen Ausführungsformen enthält das 128-Bit Anweisungsformat 710 ein Zugriffs-/Adressierungsmodusfeld 726, das einen Adressierungsmodus und/oder einen Zugriffsmodus für die Anweisung enthält. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Manche Ausführungsformen unterstützen Zugriffsmodi, die einen ausgerichteten 16-Byte Zugriffsmodus und einen ausgerichteten 1-Byte Zugriffsmodus enthalten, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einem ersten Modus kann die Anweisung beispielsweise Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus kann die Anweisung ausgerichtete 16-Byte Adressierung für alle Quell- und Zieloperanden enthalten.
  • In einer Ausführungsform bestimmt der Adressierungsmodusteil des Zugriffs-/Adressierungsmodusfelds 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung die Registeradresse von einem oder mehreren Operanden direkt bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
  • In manchen Ausführungsformen werden Anweisungen basierend auf Opcode 712 Bit-Feldern gruppiert, um Opcode-Dekodierung 740 zu vereinfachen. Für einen 8-Bit Opcode erlauben Bits 4, 5 und 6 der Ausführungseinheit, die Art des Opcodes zu bestimmen. Die gezeigte genaue Opcode-Gruppierung ist lediglich ein Beispiel. In manchen Ausführungsformen enthält eine Move- und Logik-Opcode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z.B. Move (mov), Compare (cmp)). In manchen Ausführungsformen teilt die Move-und-Logik-Gruppe 742 die fünf höchstwertigsten Bits (Most Significant Bits; MSB), wobei Move-Anweisungen (mov) die Form 0000xxxxb und Logikanweisungen die Form 0001xxxxb haben. Eine Flusssteuerungsanweisungsgruppe 744 (z.B. Call, Jump (jmp)) enthält Anweisungen in der Form 0010xxxxb (z.B. 0x20). Eine Gruppe diverser Anweisungen 746 enthält einen Mix von Anweisungen, einschließlich Synchronisationsanweisungen (z.B. Wait, Send) in der Form 0011xxxxb (z.B. 0x30). Eine Gruppe paralleler mathematischer Anweisungen 748 enthält komponentenweise arithmetische Anweisungen (z.B. Add, Multiply (mul)) in der Form 0100xxxxb (z.B. 0x40). Die parallele mathematische Gruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle aus. Die Gruppe Vektor-Mathematik 750 enthält arithmetische Anweisungen (z.B. dp4) in der Form 0101xxxxb (z.B. 0x50). Die Gruppe Vektor-Mathematik führt Arithmetik durch, wie etwa Punktproduktberechnungen an Vektoroperanden. Die veranschaulichte Opcode-Dekodierung 740 kann in einer Ausführungsform zum Bestimmen verwendet werden, welcher Teil einer Ausführungseinheit zum Ausführen einer dekodierten Anweisung verwendet wird. Manche Anweisungen können beispielsweise als systolische Anweisungen designiert sein, die von einem systolischen Array durchgeführt werden. Andere Anweisungen, wie etwa Raytracing-Anweisungen (nicht gezeigt), können zu einem Raytracing-Kern oder an Raytracing-Logik in einem Slice oder einer Partition der Ausführungslogik weitergeleitet werden.
  • Grafik-Pipeline
  • 8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente in 8, die die gleichen Referenzzahlen (oder Bezeichnungen), wie die Elemente einer anderen Figur hierin aufweisen, arbeiten oder funktionieren auf eine ähnliche Weise, wie an anderer Stelle hierin beschrieben, sie sind aber nicht darauf beschränkt.
  • In manchen Ausführungsformen enthält Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, Thread-Ausführungslogik 850 und eine Render-Ausgabe-Pipeline 870. In manchen Ausführungsformen ist Grafikprozessor 800 ein Grafikprozessor in einem Mehrkern-Verarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle gesteuert, die an Grafikprozessor 800 über eine Ringverbindung 802 ausgegeben werden. In manchen Ausführungsformen koppelt Ringverbindung 802 Grafikprozessor 800 mit anderen Verarbeitungskomponenten, wie etwa anderen Grafikprozessoren oder Universalprozessoren. Befehle von Ringverbindung 802 werden von einem Befehls-Streamer 803 interpretiert, der Anweisungen an individuelle Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 zuführt.
  • In manchen Ausführungsformen leitet Befehls-Streamer 803 den Betrieb eines Vertex-Fetchers 805 an, der Vertexdaten aus Speicher liest und Vertexverarbeitungsbefehle, die von Befehls-Streamer 803 bereitgestellt werden, ausführt. In manchen Ausführungsformen stellt Vertex-Fetcher 805 Vertexdaten an einen Vertex-Shader 807 bereit, der Koordinatenraumtransformation und Beleuchtungsoperationen an jedem Vertex durchführt. In manchen Ausführungsformen führen Vertex-Fetcher 805 und Vertex-Shader 807 Vertexverarbeitungsanweisungen durch Versenden von Ausführungs-Threads an Ausführungseinheiten 852A-852B über einen Thread-Dispatcher 831 aus.
  • In manchen Ausführungsformen sind Ausführungseinheiten 852A-852B ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In manchen Ausführungsformen verfügen Ausführungseinheiten 852A-852B über einen verbundenen L1-Cache 851, der für jedes Array spezifisch ist oder von den Arrays gemeinsam genutzt wird. Der Cache kann als ein Daten-Cache, ein Anweisungs-Cache oder ein Einzel-Cache, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu halten, konfiguriert sein.
  • In manchen Ausführungsformen enthält Geometrie-Pipeline 820 Tesselierungskomponenten zur Durchführung von hardwarebeschleunigter Tesselierung von 3D-Objekten. In manchen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselierungsoperationen. Ein programmierbarer Domain-Shader 817 stellt Backend-Auswertung der Tesselierungsausgabe bereit. Ein Tesselator 813 arbeitet unter Anleitung des Hull-Shaders 811 und enthält Speziallogik zum Generieren eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe in Geometrie-Pipeline 820 bereitgestellt wird. In manchen Ausführungsformen können, wenn keine Tesselierung verwendet wird, Tesselierungskomponenten (z.B. Hull-Shader 811, Tesselator 813 und Domain-Shader 817) umgangen werden. Die Tesselierungskomponenten können auf Grundlage von Daten arbeiten, die von dem Vertex-Shader 807 empfangen wurden.
  • In manchen Ausführungsformen können vollständige geometrische Objekte von einem Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an Ausführungseinheiten 852A-852B gesendet werden, oder sie können direkt zu dem Clipper 829 fortfahren. In manchen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten anstatt von Vertices oder Flecken von Vertices, wie in den vorherigen Stufen der Grafikpipeline. Wenn die Tesselierung deaktiviert ist, empfängt der Geometrie-Shader 819 Eingaben von dem Vertex-Shader 807. In manchen Ausführungsformen ist Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, Geometrie-Tesselierung durchzuführen, wenn die Tesselierungseinheiten deaktiviert sind.
  • Vor Rasterung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In manchen Ausführungsformen sendet eine Rasterungs- und Tiefentestkomponente 873 in der Rendering-Ausgabe-Pipeline 870 Pixel-Shader zum Wandeln der geometrischen Objekte in per-Pixel-Repräsentationen. In manchen Ausführungsformen ist Pixel-Shader-Logik in Thread-Ausführungs-Logik 850 enthalten. In manchen Ausführungsformen kann eine Anweisung die Rasterungs- und Tiefentestkomponente 873 umgehen und über eine Stream-out-Einheit 823 auf ungerasterte Vertexdaten zugreifen.
  • Der Grafikprozessor 800 verfügt über einen Verbindungs-Bus, eine Verbindungs-Fabric oder irgendeinen anderen Verbindungsmechanismus, der es erlaubt, Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors weiterzugeben. In manchen Ausführungsformen verbinden Ausführungseinheiten 852A-852B und zugeordnete Logikeinheiten (z.B. L1-Cache 851, Sampler 854, Textur-Cache 858 usw.) über einen Datenport 856, um Zugriff auf und Kommunikation mit Rendering-Ausgabe-Pipeline-Komponenten des Prozessors durchzuführen. In manchen Ausführungsformen verfügen Sampler 854, Caches 851, 858 und Ausführungseinheiten 852A-852B jeweils über separate Speicherzugriffspfade. In einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache konfiguriert sein.
  • In manchen Ausführungsformen enthält Rendering-Ausgabe-Pipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die Vertex-basierte Objekte in eine zugeordnete pixelbasierte Repräsentation wandelt. In manchen Ausführungsformen enthält die Rasterungslogik eine Fenster-/Maskierereinheit zum Durchführen von Festfunktions-Dreieck- und Linienrasterung. In manchen Ausführungsformen stehen auch ein zugeordneter Rendering-Cache 878 und Tiefen-Cache 879 zur Verfügung. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl in manchen Fällen Pixeloperationen, die 2D-Operationen (z.B. Bit-Block-Bildtransfers mit Überblendung) zugeordnet sind, von der 2D-Engine 841 durchgeführt oder zum Anzeigezeitpunkt durch die Anzeigesteuerung 843 unter Verwendung von Overlay-Anzeigeebenen ersetzt wird. In manchen Ausführungsformen steht allen Grafikkomponenten ein gemeinsam genutzter L3-Cache 875 zur Verfügung, der die gemeinsame Nutzung von Daten ohne die Verwendung des Hauptsystemspeichers erlaubt.
  • In manchen Ausführungsformen enthält Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834. In manchen Ausführungsformen empfängt Video-Frontend 834 Pipeline-Befehle von dem Befehls-Streamer 803. In manchen Ausführungsformen enthält Medien-Pipeline 830 einen separaten Befehls-Streamer. In manchen Ausführungsformen verarbeitet Video-Frontend 834 Medienbefehle vor Senden des Befehls an die Medien-Engine 837. In manchen Ausführungsformen enthält Medien-Engine 837 Thread-Spawning-Funktionalität zum Spawnen von Threads zum Versand an Thread-Ausführungslogik 850 über Thread-Dispatcher 831.
  • In manchen Ausführungsformen enthält Grafikprozessor 800 eine Anzeige-Engine 840. In manchen Ausführungsformen ist Anzeige-Engine 840 extern zu Prozessor 800 und koppelt mit dem Grafikprozessor über die Ringverbindung 802 oder einen anderen Verbindungs-Bus oder ein anderes Verbindungs-Fabric. In manchen Ausführungsformen enthält Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In manchen Ausführungsformen enthält Anzeige-Engine 840 Speziallogik, die dazu in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In manchen Ausführungsformen koppelt Anzeigesteuerung 843 mit einer Anzeigevorrichtung (nicht gezeigt), die eine systemintegrierte Anzeigevorrichtung sein kann, wie in einem Laptop-Computer, oder eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungskonnektor verbunden ist.
  • In manchen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierungsschnittstellen durchzuführen und sind nicht für irgendeine Anwendungsprogrammierschnittstelle (API) spezifisch. In manchen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die von dem Grafikprozessor verarbeitet werden können. In manchen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos Group, bereitgestellt. In manchen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek der Microsoft Corporation bereitgestellt werden. In manchen Ausführungsformen kann eine Kombination aus diesen Bibliotheken unterstützt werden. Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt, wenn ein Mapping aus der Pipeline der zukünftigen API zu der Pipeline des Grafikprozessors erfolgen kann.
  • Grafik-Pipeline-Programmierung
  • 9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 gemäß mancher Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die in 9A gezeigten Kästchen mit durchgezogenen Linien veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind, oder die nur in einer Untergruppe der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessorbefehlsformat 900 in 9A enthält Datenfelder zum Identifizieren eines Client 902, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. In manchen Befehlen sind auch ein Sub-Opcode 905 und eine Befehlsgröße 908 enthalten.
  • In manchen Ausführungsformen spezifiziert Client 902 die Client-Einheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In manchen Ausführungsformen untersucht ein Grafikprozessorbefehl-Parser das Client-Feld jedes Befehls, um das weitere Verarbeiten des Befehls zu bedingen und leitet die Befehlsdaten an die entsprechende Client-Einheit weiter. In manchen Ausführungsformen enthalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendering-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit hat eine entsprechende Verarbeitungs-Pipeline, die die Befehle verarbeitet. Nachdem der Befehl von der Client-Einheit empfangen wurde, liest die Client-Einheit den Opcode 904 und, sofern vorhanden, Sub-Opcode 905, um die durchzuführende Operation zu bestimmen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen in Datenfeld 906 durch. Für manche Befehle wird eine explizite Befehlsgröße 908 erwartet, um die Größe des Befehls zu spezifizieren. In manchen Ausführungsformen bestimmt der Befehls-Parser automatisch die Größe zumindest eines Teils des Befehls auf Grundlage des Befehl-Opcodes. In manchen Ausführungsformen sind Befehle über Vielfache eines Doppelworts ausgerichtet. Es können auch andere Befehlsformate verwendet werden.
  • Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessorbefehlssequenz 910. In manchen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors darstellt, eine Version der gezeigten Befehlssequenz zum Einrichten, Ausführen und Beenden eines Satzes von Grafikoperationen. Eine beispielhafte Befehlssequenz wird ausschließlich zu Beispielzwecken gezeigt und beschrieben, da Ausführungsformen nicht auf diese konkreten Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als ein Befehlsstapel in einer Befehlssequenz ausgegeben werden, so dass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
  • In manchen Ausführungsformen kann die Grafikprozessorbefehlssequenz 910 mit einem Pipeline-Flush-Befehl 912 beginnen, um zu veranlassen, dass eine aktive Grafik-Pipeline die aktuell für die Pipeline ausstehenden Befehle abschließt. In manchen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Der Pipeline-Flush wird durchgeführt, um die aktive Grafik-Pipeline zu veranlassen, jedwede ausstehenden Befehle abzuschließen. In Reaktion auf einen Pipeline-Flush pausiert der Befehls-Parser für den Grafikprozessor das Befehlsverarbeiten bis die aktiv ziehenden Engines ausstehende Operationen beendet haben und die relevanten Lese-Caches ungültig gemacht wurden. Optional können Daten, die in dem Rendering-Cache als „dirty“ markiert sind, in einen Speicher gespült werden. In manchen Ausführungsformen kann Pipeline-Flush-Befehl 912 zur Pipeline-Synchronisation oder vor Platzieren des Grafikprozessor in einen Stromsparmodus verwendet werden.
  • In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erforderlich macht, dass der Grafikprozessor explizit zwischen Pipelines schaltet. In manchen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts vor Ausgabe von Pipeline-Befehlen erforderlich, sofern der Kontext nicht Ausgabe von Befehlen für beide Pipelines umfasst. In manchen Ausführungsformen ist ein Pipeline-Flush-Befehl 912 unmittelbar vor einem Pipeline-Wechsel über den Pipeline-Auswahlbefehl 913 erforderlich.
  • In manchen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird zum Programmieren der 3D-Pipeline 922 und der Medien-Pipeline 924 verwendet. In manchen Ausführungsformen konfiguriert Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cache-Speichern in der aktiven Pipeline vor Verarbeiten eines Befehlstapels verwendet.
  • In manchen Ausführungsformen werden Retum-Buffer-Zustandsbefehle 916 zum Konfigurieren eines Satzes von Return-Puffern für die jeweiligen Pipelines zum Schreiben von Daten verwendet. Manche Pipeline-Operationen erfordern die Zuweisung, Auswahl oder Konfiguration von einem oder mehreren Return-Puffern, in die die Operationen Zwischendaten während der Verarbeitung schreiben. In manchen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Return-Puffer zum Speichern von Ausgabedaten und zum Durchführen von Threadübergreifender Kommunikation. In manchen Ausführungsformen umfasst der Return-Buffer-Zustand 916 Auswählen der Größe und Anzahl von Return-Puffern zur Verwendung für einen Satz von Pipeline-Operationen.
  • Die übrigen Befehle in der Befehlssequenz unterscheiden sich auf Grundlage der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz der 3D-Pipeline 922, beginnend mit dem 3D-Pipeline-Zustand 930, oder der Medien-Pipeline 924, beginnend mit dem Medien-Pipeline-Zustand 940, individuell angepasst.
  • Die Befehle zum Konfigurieren des 3D-Pipeline-Zustands 930 enthalten 3D-Zustandseinstellungsbefehle für den Vertex-Pufferzustand, Vertex-Elementzustand, Konstantfarbenzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitivenbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Grundlage des konkreten 3D-API in Verwendung bestimmt. In manchen Ausführungsformen sind 3D-Pipeline-Zustand 930 Befehle auch dazu in der Lage, bestimmte Pipeline-Elemente zu deaktivieren oder zu umgehen, wenn diese Elemente nicht genutzt werden.
  • In manchen Ausführungsformen wird der 3D-Primitiv 932 Befehl zur Übermittlung von durch die 3D-Pipeline zu verarbeitenden 3D-Primitive verwendet. Befehle und zugeordnete Parameter, die über den 3D-Primitiv 932 Befehl an den Grafikprozessor übergeben werden, werden an die Vertex-Abruffunktion der Grafikpipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die 3D-Primitv 932 Befehlsdaten zum Generieren von Vertexdatenstrukturen. Die Vertexdatenstrukturen werden in einem oder mehreren Return-Puffern gespeichert. In manchen Ausführungsformen wird der 3D-Primitiv 932 Befehl zum Durchführen von Vertexoperationen an 3D-Primitiven über Vertex-Shader verwendet. Zum Verarbeiten von Vertex-Shadern versendet 3D-Pipeline 922 Shader-Ausführungs-Threads an Grafikprozessorausführungseinheiten.
  • In manchen Ausführungsformen wird 3D-Pipeline 922 über einen Ausführung 934 Befehl oder Ereignis ausgelöst. In manchen Ausführungsformen löst ein Registerschreibvorgang Befehlsausführung aus. In manchen Ausführungsformen wird Ausführung über einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird Befehlsausführung unter Verwendung eines Pipeline-Synchronisationsbefehls zum Auslagern der Befehlssequenz durch die Grafik-Pipeline ausgelöst. Die 3D-Pipeline führt Geometrieverarbeitung für die 3D-Primitiven durch. Nachdem die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixel-Engine koloriert die resultierenden Pixel. Für diese Operationen können auch zusätzliche Befehle zum Steuern von Pixel-Shading und Pixel-Backend-Operationen enthalten sein.
  • In manchen Ausführungsformen folgt die Grafikprozessorbefehlssequenz 910 bei Durchführung von Medienoperationen dem Pfad der Medien-Pipeline 924. Im Allgemeinen hängt die spezifische Verwendung und Art und Weise der Programmierung für die Medien-Pipeline 924 von den Medien oder durchzuführenden Rechenoperationen ab. Spezifische Mediendekodieroperationen können während der Mediendekodierung zu der Medien-Pipeline ausgelagert werden. In manchen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und Mediendekodierung kann insgesamt oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medien-Pipeline auch Elemente für Operationen einer Universalgrafikprozessoreinheit (General-Purpose Graphics Processor Unit; GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von Berechnungs-Shader-Programmen durchgeführt werden, die nicht explizit auf das Rendern von Grafik-Primitiven bezogen sind.
  • In manchen Ausführungsformen ist Medien-Pipeline 924 auf eine ähnliche Weise konfiguriert wie die 3D-Pipeline 922. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird vor den Medien-Objektbefehlen 942 an eine Befehlswarteschlange gesendet oder darin platziert. In manchen Ausführungsformen enthalten Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Diese enthalten Daten zum Konfigurieren der Videodekodier- und Videokodierlogik in der Medien-Pipeline, wie etwa Kodier- und Dekodierformat. In manchen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung von einem oder mehreren Zeigern zu „indirekten“ Zustandselementen, die einen Stapel von Zustandseinstellungen enthalten.
  • In manchen Ausführungsformen führen Medienobjektbefehle 942 Zeiger an Medienobjekte zum Verarbeiten durch die Medien-Pipeline zu. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In manchen Ausführungsformen müssen alle Medien-Pipeline-Zustände vor Ausgabe eines Medienobjektbefehls 942 gültig sein. Nachdem der Pipeline-Zustand konfiguriert ist und Medienobjektbefehle 942 in der Warteschlange stehen, wird die Medien-Pipeline 924 über einen Ausführbefehl 944 oder ein äquivalentes Ausführereignis (z.B. Registerschreibvorgang) ausgelöst. Die Ausgabe aus der Medien-Pipeline 924 kann dann durch Operationen, die von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellt werden, nachbearbeitet werden. In manchen Ausführungsformen sind GPGPU-Operationen konfiguriert und werden auf eine ähnliche Weise ausgeführt, wie Medienoperationen.
  • Grafik-Software-Architektur
  • 10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß manchen Ausführungsformen. In manchen Ausführungsformen enthält Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In manchen Ausführungsformen enthält Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkern(e) 1034. Die Grafikanwendung 1010 und Betriebssystem 1020 führen jeweils in dem Systemspeicher 1050 des Datenverarbeitungssystems aus.
  • In manchen Ausführungsformen enthält 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programm(e), die Shader-Anweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer Shader-Sprache hoher Ebene sein, wie etwa die High-Level Shader Language (HLSL) von Direct3D, die OpenGL Shader Language (GLSL) usw. Die Anwendung enthält auch ausführbare Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Universalprozessorkern 1034 geeignet ist. Die Anwendung enthält außerdem Grafikobjekte 1016, die durch Vertexdaten definiert sind.
  • In manchen Ausführungsformen ist Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source UNIX-ähnliches Betriebssystem unter Verwendung des Linux-Kernels. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie etwa die Direct3D API, die OpenGL API oder die Vulkan API. Wenn die Direct3D API verwendet wird, nutzt das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024 zum Kompilieren von Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene. Die Kompilierung kann eine Just-in-Time (JIT) Kompilierung sein oder die Anwendung kann Shader-Vorkompilierung durchführen. In manchen Ausführungsformen werden Shader hoher Ebene während der Kompilierung der 3D-Grafikanwendung 1010 in Shader niedriger Ebene kompiliert. In manchen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie etwa als eine Version der Standard Portable Intermediate Representation (SPIR), die von der Vulkan-API genutzt wird.
  • In manchen Ausführungsformen enthält Benutzermodusgrafiktreiber 1026 einen Backend-Shader-Compiler 1027 zum Wandeln der Shader-Anweisungen 1012 in eine hardwarespezifische Repräsentation. Wenn die OpenGL-API verwendet wird, werden Shader-Anweisungen 1012 in der GLSL-Sprache hoher Ebene zu einem Benutzermodusgrafiktreiber 1026 zur Kompilierung übergeben. In manchen Ausführungsformen verwendet Benutzermodusgrafiktreiber 1026 Betriebssystem-Kernel-Modusfunktionen 1028, um mit einem Kernel-Modusgrafiktreiber 1029 zu kommunizieren. In manchen Ausführungsformen kommuniziert Kernel-Modusgrafiktreiber 1029 mit Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
  • IP-Kern-Implementierungen
  • Ein oder mehrere Aspekte mindestens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbarem Medium gespeichert ist, das Logik in einer integrierten Schaltung, wie einem Prozessor, repräsentiert und/oder definiert. Das maschinenlesbare Medium kann beispielsweise Anweisungen enthalten, die verschiedene Logik in dem Prozessor repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zum Durchführen der hierin beschriebenen Techniken herzustellen. Solche Repräsentationen, die als „IP-Kerne“ (IP-Cores) bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbarem, maschinenlesbarem Medium als ein Hardwaremodell, das die Struktur der integrierten Schaltung beschreibt, gespeichert werden können. Das Hardwaremodell kann an verschiedene Kunden oder Fertigungseinrichtungen geliefert werden, die das Hardwaremodell auf Fertigungsmaschinen laden, die die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart gefertigt werden, dass die Schaltung Operationen durchführt, die hierin in Verbindung mit jedweden der Ausführungsformen beschrieben sind.
  • 11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das zur Herstellung einer integrierten Schaltung zur Durchführung von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kern-Entwicklungssystem 1100 kann zum Generieren modularer, wiederverwendbarer Designs verwendet werden, die in ein größeres Design integriert oder zum Konstruieren einer gesamten integrierten Schaltung (z.B. einer integrierten SOC-Schaltung) verwendet werden können. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer Programmiersprache hoher Ebene (z.B. C/C++) generieren. Die Softwaresimulation 1110 kann für den Entwurf, das Testen und Verifizieren des Verhaltens des IP-Kerns unter Verwendung eines Simulationsmodells 1112 eingesetzt werden. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsimulationen enthalten. Ein Design auf Register-Transfer-Ebene (RTL) 1115 kann dann aus dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss digitaler Daten zwischen Hardwareregistern modelliert, einschließlich der dazugehörigen Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs tieferer Ebene auf der Logikebene oder Transistorebene erstellt, entworfen oder synthetisiert werden. Somit können die konkreten Details des anfänglichen Designs und der Simulation variieren.
  • Das RTL-Design 1115 oder ein Äquivalent können durch die Designeinrichtung in ein Hardwaremodell 1120, das in einer Hardwarebeschreibungssprache (Hardware Description Language; HDL) oder eine andere Repräsentation physischer Designdaten weiter synthetisiert werden. Die HDL kann weiterhin simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann für Auslieferung an eine Dritt-Fertigungseinrichtung 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (z.B. Festplatte, Flash-Speicher oder jedwedes nichtflüchtige Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design (z.B. über das Internet) über eine drahtgebundene Verbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden. Die Fertigungseinrichtung 1165 kann dann eine integrierte Schaltung fertigen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die gefertigte integrierte Schaltung kann dafür ausgelegt sein, Operationen in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
  • 11B veranschaulicht eine Querschnittsseitenansicht einer Package-Baugruppe einer integrierten Schaltung 1170 gemäß manchen hierin beschriebenen Ausführungsformen. Die Package-Baugruppe einer integrierten Schaltung 1170 veranschaulicht eine Implementierung einer oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie hierin beschrieben. Die Package-Baugruppe 1170 enthält mehrere Einheiten von Hardware-Logik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Festfunktionalitätslogikhardware implementiert sein und sie kann einen oder mehrere Teile eines Prozessorkerns/Prozessorkerne, Grafikprozessor(en) oder anderer hierin beschriebener Beschleunigervorrichtungen enthalten. Jede Einheit der Logik 1172, 1174 kann in einem Halbleiter-Die implementiert und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 verbunden sein. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 weiterzuleiten und kann Verbindungen, wie etwa Höcker oder Säulen enthalten, ist aber nicht darauf beschränkt. In manchen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale, wie beispielsweise Eingabe-/Ausgabesignale (I/O) und/oder Strom- oder Massesignale, die dem Betrieb der Logik 1172, 1174 zugeordnet sind, weiterzuleiten. In manchen Ausführungsformen ist das Substrat 1180 ein Substrat auf Basis von Epoxidlaminat. Das Substrat 1180 kann in anderen Ausführungsformen auch andere geeignete Arten von Substraten enthalten. Die Package-Baugruppe 1170 kann über eine Package-Verbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Package-Verbindung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa eine Hauptplatine, andere Chipsätze oder ein Mehrchipmodul zu leiten.
  • In manchen Ausführungsformen sind die Einheiten der Logik 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die dafür ausgelegt ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
  • Obwohl zwei Einheiten von Logik 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies enthalten. Der eine oder die mehreren Dies können durch Null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen werden kann, wenn die Logik auf einem einzelnen Die enthalten ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten, Dies und Brücken in anderen möglichen Konfigurationen, einschließlich dreidimensionalen Konfigurationen, miteinander verbunden werden.
  • 11C veranschaulicht eine Package-Baugruppe 1190, die mehrere Einheiten von Hardware-Logik-Chiplets enthält, die mit einem Substrat 1180 (z.B. einem Basis-Die) verbunden sind. Ein(e) Grafikverarbeitungseinheit, Parallelprozessor und/oder Rechenbeschleuniger, wie hierin beschrieben, kann bzw. können aus diversen Siliziumchiplets zusammengesetzt sein, die separat hergestellt wurden. In diesem Zusammenhang ist ein Chiplet zumindest teilweise eine gepackte integrierte Schaltung, die unterschiedliche Logikeinheiten enthält, die mit anderen Chiplets in ein größeres Package gepackt werden können. Ein vielfältiger Satz von Chiplets mit unterschiedlicher IP-Kern-Logik kann in eine einzelne Vorrichtung gepackt werden. Zusätzlich können die Chiplets in einen Basis-Die oder ein Basis-Chiplet unter Verwendung aktiver Interposertechnologie integriert werden. Die hierin beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den unterschiedlichen Formen von IP innerhalb der GPU. IP-Kerne können unter Verwendung unterschiedlicher Prozesstechnologien hergestellt und während der Fertigung zusammengesetzt werden, was die Komplexität des Konvergierens mehrerer IPs, insbesondere auf einem großen SoC mit mehreren Arten von IPs, in dem gleichen Fertigungsprozess vermeidet. Ermöglichung der Verwendung mehrerer Prozesstechnologien verbessert die Markteinführungszeit und bietet eine kosteneffektive Möglichkeit, mehrere Produkt-SKUs zu erstellen. Außerdem lassen sich die disaggregierten IPs besser unabhängig mit Strom versorgen. Komponenten, die bei einer gegebenen Arbeitslast nicht in Verwendung sind, können ausgeschaltet werden, was den Gesamtstromverbrauch reduziert.
  • Die Hardwarelogikchiplets können Spezial-Hardwarelogikchiplets 1172, Logik- oder I/O-Chiplets 1174 und/oder Speicherchiplets 1175 enthalten. Die Hardwarelogikchiplets 1172 und Logik- oder I/O-Chiplets 1174 können zumindest teilweise in konfigurierbarer Logik oder Festfunktionalitätslogikhardware implementiert sein und sie können einen oder mehrere Teile eines von Prozessorkern/Prozessorkernen, Grafikprozessor(en) oder anderer hierin beschriebener Beschleunigervorrichtungen enthalten. Die Speicherchiplets 1175 können DRAM-Speicher (z.B. GDDR, HBM) oder Cache-Speicher (SRAM) sein.
  • Jedes Chiplet kann als separater Halbleiter-Die gefertigt und mit dem Substrat 1180 über eine Verbindungsstruktur 1173 gekoppelt werden. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, um elektrische Signale zwischen den verschiedenen Chiplets und Logik in dem Substrat 1180 zu leiten. Die Verbindungsstruktur 1173 kann Verbindungen enthalten, wie etwa, aber nicht beschränkt auf Höcker oder Säulen. In manchen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale, wie beispielsweise Eingabe-/Ausgabesignale (I/O) und/oder Strom- oder Massesignale, die dem Betrieb der Logik, I/O und Speicherchiplets zugeordnet sind, weiterzuleiten.
  • In manchen Ausführungsformen ist das Substrat 1180 ein Substrat auf Basis von Epoxidlaminat. Das Substrat 1180 kann in anderen Ausführungsformen auch andere geeignete Arten von Substraten enthalten. Die Package-Baugruppe 1190 kann über eine Package-Verbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Package-Verbindung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen, wie etwa eine Hauptplatine, andere Chipsätze oder ein Mehrchipmodul zu leiten.
  • In manchen Ausführungsformen können eine Logik oder ein I/O-Chiplet 1174 und ein Speicherchiplet 1175 elektrisch über eine Brücke 1187 gekoppelt werden, die dafür ausgelegt ist, elektrische Signale zwischen der Logik oder dem I/O-Chiplet 1174 und einem Speicherchiplet 1175 zu leiten. Die Brücke 1187 kann eine dichte Verbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Brücke 1187 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik oder dem I/O-Chiplet 1174 und einem Speicherchiplet 1175 bereitzustellen. Die Brücke 1187 kann auch als eine Siliziumbrücke oder eine Verbindungsbrücke bezeichnet werden. Die Brücke 1187 ist in manchen Ausführungsformen beispielsweise eine Embedded Multidie Interconnect Bridge (EMIB). In manchen Ausführungsformen kann die Brücke 1187 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
  • Das Substrat 1180 kann Hardwarekomponenten für I/O 1191, Cache-Speicher 1192 und andere Hardwarelogik 1193 enthalten. In dem Substrat 1180 kann ein Fabric 1185 eingebettet sein, um Kommunikation zwischen den verschiedenen Logikchiplets und der Logik 1191, 1193 in dem Substrat 1180 zu ermöglichen. In einer Ausführungsform können die I/O 1191, Fabric 1185, Cache, Brücke und andere Hardwarelogik 1193 in einen Basis-Die integriert sein, der auf dem Substrat 1180 geschichtet ist. Das Fabric 1185 kann eine Netzwerk-auf-Chip-Verbindung oder eine andere Form von paketvermitteltem Fabric sein, das Datenpakete zwischen Komponenten der Package-Baugruppe vermittelt.
  • In verschiedenen Ausführungsformen kann eine Package-Baugruppe 1190 eine kleinere oder größere Anzahl an Komponenten und Chiplets enthalten, die untereinander durch ein Fabric 1185 oder eine oder mehrere Brücken 1187 verbunden sind. Die Chiplets in der Package-Baugruppe 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können die Brückenstrukturen 1187 genutzt werden, um eine Punkt-zu-Punkt-Verbindung zwischen, beispielsweise, Logik oder I/O-Chiplets und Speicherchiplets zu ermöglichen. Das Fabric 1185 kann zum Verbinden der verschiedenen Logik- und/oder I/O-Chiplets (z.B. Chiplets 1172, 1174, 1191, 1193) mit anderer Logik und/oder I/O-Chiplets verwendet werden. In einer Ausführungsform kann der Cache-Speicher 1192 in dem Substrat als ein globaler Cache für die Package-Baugruppe 1190, Teil eines verteilten globalen Cache oder als ein dedizierter Cache für das Fabric 1185 dienen.
  • 11D veranschaulicht eine Package-Baugruppe 1194, die gemäß einer Ausführungsform austauschbare Chiplets 1195 enthält. Die austauschbaren Chiplets 1195 können in standardisierte Steckplätze auf einem oder mehreren Basischiplets 1196, 1198 montiert werden. Die Basischiplets 1196, 1198 können über eine Brückenverbindung 1197 gekoppelt werden, die den anderen hierin beschriebenen Brückenverbindungen ähnlich sein kann, und sie kann beispielsweise eine EMIB sein. Speicherchiplets können auch mit Logik- oder I/O-Chiplets über eine Brückenverbindung verbunden werden. I/O- und Logikchiplets können über ein Verbindungs-Fabric kommunizieren. Die Basischiplets können jeweils einen oder mehrere Steckplätze in einem standardisierten Format für eines von Logik oder I/O oder Speicher/Cache unterstützen.
  • In einer Ausführungsform können SRAM und Stromversorgungsschaltungen in einem oder mehreren der Basischiplets 1196, 1198, die unter Verwendung einer anderen Prozesstechnologie im Vergleich zu den austauschbaren Chiplets 1195, die auf den Basischiplets gestapelt werden, gefertigt werden, hergestellt werden. Die Basischiplets 1196, 1198 können unter Verwendung einer größeren Prozesstechnologie gefertigt werden, während die austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Ein oder mehrere der austauschbaren Chiplets 1195 können Speicherchiplets (z.B. DRAM) sein. Für die Package-Baugruppe 1194 können basierend auf der Leistung und/oder der für das Produkt, das die Package-Baugruppe 1194 nutzt, vorgesehene Performance unterschiedliche Speicherdichten ausgewählt werden. Zusätzlich können Logikchiplets mit einer unterschiedlichen Anzahl von Typen funktionaler Einheiten zum Zeitpunkt der Montage basierend auf der Leistung und/oder für das Produkt vorgesehenen Performance ausgewählt werden. Darüber hinaus können Chiplets, die IP-Logik-Kerne unterschiedlicher Typen enthalten, in die austauschbaren Chiplet-Steckplätze eingesetzt werden, was Hybridprozessordesigns ermöglicht, die unterschiedliche Technologie-IP-Blöcke mischen und anpassen können.
  • Beispielhafte integrierte System-auf-Chip-Schaltung
  • 12-13 veranschaulichen beispielhafte integrierte Schaltungen und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden können, gemäß verschiedener hierin beschriebener Ausführungsformen. Zusätzlich zu dem, was veranschaulicht ist, können auch andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Universalprozessorkerne.
  • 12 ist ein Blockdiagramm, das eine beispielhafte integrierte System-on-Chip-Schaltung 1200 veranschaulicht, die unter Verwendung von einem oder mehreren IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z.B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, die alle ein modularer IP-Kern aus den gleichen oder mehreren unterschiedlichen Designeinrichtungen sein können. Integrierte Schaltung 1200 enthält Peripherie- oder Bus-Logik, einschließlich eines USB-Controllers 1225, UART-Controllers 1230, einen SPI/SDIO-Controller 1235 und einen I2S/I2C-Controller 1240. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 enthalten, die mit einem oder mehreren von einem High-Definition Multimedia Interface (HDMI) Controller 1250 und einer Mobile Industry Processor Interface (MIPI) Anzeigeschnittstelle 1255 gekoppelt ist. Speicher kann durch ein Flash-Speicher-Subsystem 1260 bereitgestellt werden, einschließlich eines Flash-Speichers und eines Flash-Speicher-Controllers. Die Speicherschnittstelle kann über einen Speicher-Controller 1265 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt werden. Manche integrierte Schaltungen enthalten zusätzlich eine eingebettete Sicherheits-Engine 1270.
  • 13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung in einem SoC veranschaulichen, gemäß hierin beschriebener Ausführungsformen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten System-on-Chip-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten System-on-Chip-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen gefertigt werden kann, gemäß einer Ausführungsform. Grafikprozessor 1310 in 13A ist ein Beispiel für einen Grafikprozessorkern mit niedrigem Stromverbrauch. Grafikprozessor 1340 in 13B ist ein Beispiel für einen Grafikprozessorkern mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 in 12 sein.
  • Wie in 13A gezeigt, enthält Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Grafikprozessor 1310 kann verschiedene Shader-Programme über separate Logik derart ausführen, dass der Vertexprozessor 1305 optimiert wird, Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragment- (z.B. Pixel-) Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Primitive und Vertexdaten. Der bzw. die Fragmentprozessor(en) 1315A-1315N verwenden die Primitiven und Vertexdaten, die von dem Vertexprozessor 1305 erzeugt wurden, um einen Framebuffer zu produzieren, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist bzw. sind der bzw. die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragment-Shader-Programme, wie in der OpenGL API bereitgestellt, auszuführen, die verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm, wie durch die Direct 3D API bereitgestellt, durchzuführen.
  • Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Speicherverwaltungseinheiten (Memory Management Units; MMUs) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B ermöglichen virtuell-zu-physisches Adressmapping für den Grafikprozessor 1310, einschließlich des Vertexprozessors 1305 und/oder Fragmentprozessor(en) 1315A-1315N, die Vertex- oder Bild-/Texturdaten, die in dem Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild-/Texturdaten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind, referenzieren können. In einer Ausführungsform kann bzw. können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs in dem System synchronisiert werden, einschließlich einer oder mehreren MMUs, die dem einen oder den mehreren Anwendungsprozessor(en) 1205, Bildprozessor 1215 und/oder Videoprozessor 1220 in 12 derart zugeordnet sind, dass jeder Prozessor 1205-1220 an einem gemeinsamem oder einheitlichem virtuellen Speichersystem partizipieren kann. Die eine oder die mehreren Schaltungsverbindung(en) 1330A-1330B befähigen gemäß Ausführungsformen Grafikprozessor 1310 eine Schnittstelle mit anderen IP-Kernen in dem SoC, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, zu bilden.
  • Wie in 13B gezeigt, enthält Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B des Grafikprozessors 1310 in 13A. Grafikprozessor 1340 enthält einen oder mehrere Shader-Kern(e) 1355A-1355N (z.B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), der bzw. die eine einheitliche Shader-Kern-Architektur ermöglichen, in der ein einzelner Kern oder Typ oder Kern alle Arten programmierbarer Shade-Codes ausführen kann, einschließlich Shader-Programm-Code zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Anzahl der vorhandenen Shader-Kerne kann bei verschiedenen Ausführungsformen und Implementierungen variieren. Zusätzlich enthält Grafikprozessor 1340 einen Inter-Kern-Taskmanager 1345, der als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N wirkt und eine Kacheleinheit 1358 zum Beschleunigen von Kacheloperationen für kachelbasiertes Rendering, bei dem Renderingoperationen für eine Szene in Bildraum unterteilt werden, beispielsweise um lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder um Verwendung interner Caches zu optimieren.
  • In manchen Ausführungsformen repräsentiert eine Verarbeitungsressource ein Verarbeitungselement (z.B. GPGPU-Kern, Raytracing-Kern, Tensor-Kern, Ausführungsressource, Ausführungseinheit (EU), Stream-Prozessor, Streaming-Multiprozessor (SM), Grafik-Multiprozessor), das einem Grafikprozessor oder einer Grafikprozessorstruktur (z.B. Parallelverarbeitungseinheit, Grafikverarbeitungs-Engine, Mehrkerngruppe, Recheneinheit, Recheneinheit eines nächsten Grafikkerns) in einer GPU, wie hierin beschrieben, zugeordnet ist. Die Verarbeitungsressource kann beispielsweise einer der GPGPU-Kerne oder Tensor-/Raytracing-Kerne des Grafik-Multiprozessors sein; ein Raytracing-Kern, Tensor-Kern oder GPGPU-Kern des Grafik-Multiprozessors; Ausführungsressourcen des Grafik-Multiprozessors; einer der GFX-Kerne, Tensor-Kerne oder Raytracing-Kerne einer Mehrkerngruppe; eine der Vektorlogikeinheiten oder Skalarlogikeinheiten einer Recheneinheit; Ausführungseinheit mit EU-Array oder EU-Array; eine Ausführungseinheit der Ausführungslogik; und/oder Ausführungseinheit. Die Verarbeitungsressource kann auch eine Ausführungsressource beispielsweise in einer Grafikverarbeitungs-Engine, einem Verarbeitungs-Cluster, GPGPU, GPGPU, Grafikverarbeitungs-Engine, Grafikverarbeitungs-Engine-Cluster und/oder Grafikverarbeitungs-Engine sein. Die Verarbeitungsressource kann auch eine Verarbeitungsressource in einem Grafikprozessor und/oder ein Grafikprozessor sein.
  • Parallelrechnen ist eine Art von Berechnung, bei der viele Berechnungen oder die Ausführung von Prozessen gleichzeitig durchgeführt werden. Parallelrechnen kann vielerlei Formen haben, einschließlich, aber nicht beschränkt auf SIMD oder SIMT. SIMD beschreibt Computer mit mehreren Verarbeitungselementen, die die gleiche Operation gleichzeitig an mehreren Datenpunkten durchführen. In einem Beispiel beziehen sich die vorstehend diskutierten 5A-5B auf SIMD und seine Implementierung in einem Universalprozessor in Bezug auf EUs, FPUs und ALUs. In einer gewöhnlichen SIMD-Maschine werden Daten in Register gepackt, die jeweils ein Array von Kanälen enthalten. Anweisungen arbeiten an den Daten, die in Kanal n eines Registers gefunden werden, mit den Daten, die in dem gleichen Kanal eines anderen Registers gefunden wurden. SIMD-Maschinen sind in Bereichen vorteilhaft, in denen eine einzelne Anweisungssequenz zeitgleich auf hohe Datenmengen angewendet werden kann. In einer Ausführungsform kann beispielsweise ein Grafikprozessor (z.B. GPGPU, GPU usw.) verwendet werden, um SIMD-Vektoroperationen unter Verwendung von Berechnungs-Shader-Programmen durchzuführen.
  • Verschiedene Ausführungsformen können auch Verwendung von Single Instruction Multiple Thread (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD für Ausführung anwenden. Verweise auf einen SIMD-Kern oder -Betrieb können auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten. Die folgende Beschreibung wird in Bezug auf SIMD-Maschinen diskutiert. Die Implementierungen der Offenbarung sind jedoch nicht ausschließlich auf eine Anwendung in dem SIMD-Kontext beschränkt und können auch für andere Parallelrechenparadigmen gelten, wie etwa SIMT zum Beispiel. Zur Vereinfachung der Diskussion und Erläuterung konzentriert sich die folgende Beschreibung im Allgemeinen auf eine SIMD-Implementierung. Implementierungen der Offenbarung können jedoch in ähnlicher Weise für SIMT-Maschinen ohne Modifikationen an den beschriebenen Techniken und Methoden gelten. In Bezug auf SIMT-Maschinen kann ähnlichen Mustern, wie nachfolgend diskutiert, gefolgt werden, um Anweisungen an das systolische Array bereitzustellen und um die Anweisungen auf der SIMT-Maschine auszuführen. Andere Arten von Parallelrechenmaschinen können ebenfalls Implementierungen der Offenbarung nutzen.
  • Herkömmlich werden Operationen zwischen den Kanälen eines gleichen Registers in einer SIMD-Maschine normal emuliert und somit nicht in Hardware implementiert. Solche kanalübergreifenden Operationen können, neben anderen Beispielen, Berechnen des Mindestwerts oder des Maximalwerts in einer Sequenz von Kanälen umfassen. Es können hierin auch andere arithmetische und/oder logische Operationen unter Verwendung von kanalübergreifenden Abhängigkeiten als kanalübergreifende Operationen in Erwägung gezogen werden. Kanalübergreifende Operationen werden beispielsweise häufig in modernen Raytracing-Arbeitslasten verwendet. Solche kanalübergreifenden Operationen sind typischerweise nicht in Hardware implementiert, da sie das oben erwähnte Modell oft brechen, wodurch ihre Implementierung in Hardwareressourcen kostspielig wird. Auf ähnliche Weise werden solche kanalübergreifenden Operationen herkömmlich nicht in Hardware implementiert, da sie gegenüber der emulierten Alternative keine signifikanten Leistungsverbesserungen bereitstellen.
  • Konventionelle Systeme verfügen über implementierte kanalübergreifende Operationen in Parallelrechenmaschinen, wie etwa SIMD-Maschinen oder SIMT-Maschinen, durch Emulieren des Verhaltens der Anweisungen mit einer Kombination von Hardware- und Softwareimplementierungen. Für konventionelle Ansätze implementiert Hardware eine Anweisung, die an einer Teilmenge von Kanälen mit einer anderen Teilmenge von Kanälen des gleichen Registers arbeitet. Diese Anweisung wird üblicherweise verwendet, um an den Daten mehrere Durchgänge durchzuführen, wodurch die Anzahl der Kanäle, an denen gearbeitet wird, bei jedem Durchgang reduziert wird. Das Resultat wird in einem einzelnen Kanal erhalten, der an alle Kanäle gesendet wird. Dieser Prozess lässt sich anhand des Algorithmus veranschaulichen, der zum Finden des Maximalwerts eines Satzes von Kanälen in einem Register verwendet wird. Nehmen wir ein Register mit acht Kanälen und einer Anweisung, die die oberen vier Kanäle eines Registers mit den vier unteren Kanälen des gleichen Registers vergleicht. Ein erster Durchlauf dieser Operation resultiert in vier Elementen, von denen die Hälfte in den oberen Kanälen des Registers gespeichert werden können, und die andere Hälfte in den unteren Kanälen des gleichen Registers. Eine zweite Operation resultiert in zwei Ergebnissen, die ebenfalls auf die oben beschriebene Weise gespeichert werden können. Ein abschließender Durchlauf kann das gewünschte Resultat bringen, das an alle Kanäle gesendet werden kann.
  • Emulieren von Operationen zwischen den Kanälen des gleichen Registers konsumiert üblicherweise eine größere Anzahl von Zyklen als Implementieren der Anweisung in Hardware. Dies liegt nicht allein an der iterativen Natur des Prozesses, sondern auch an den Abhängigkeiten, die bei diesem Prozess für das Resultat jedes Schritts bestehen. Obwohl Emulieren von Operationen eine größere Anzahl von Zyklen konsumiert, sind herkömmliche Systeme immer noch von der Emulation von Anweisungen abhängig, da die Effizienzen von Multi-Thread-Maschinen die Ineffizienzen dieser größeren Anzahl von Zyklen häufig ausgleicht. Multi-Thread-Maschinen versenden beispielsweise Anweisungen aus anderen Threads während der Zeit, die diese Abhängigkeiten zu ihrer Auflösung in Anspruch nehmen, was es im Durchschnitt möglich macht, eine effizientere Gesamtausführung aller Threads, die beim Emulieren von Operationen in die Maschine gesendet werden, zu erreichen.
  • Ein anderer herkömmlicher Ansatz zum Implementieren von kanalübergreifenden Operationen in SIMD-Maschinen ist eine hardwarebasierte Implementierung. Eine hardwarebasierte Implementierung kann die gleiche Operation zwischen allen Kanälen des Registers implementieren. Da dies normalerweise das Design der Ausführungseinheiten in einer SIMD-Maschine ist, wird zu diesem Zweck Spezialhardware erstellt.
  • Implementierungen der Offenbarung vermeiden die Erstellung spezieller Hardware für kanalübergreifende Operationen, indem sie ein systolisches Array verwenden. Ein systolisches Array ist ein homogenes Netzwerk eng gekoppelter Datenverarbeitungseinheiten (Data Processing Units; DPUs), die als Zellen oder Knoten bezeichnet werden, wobei jeder Knoten unabhängig ein Teilresultat als eine Funktion der Daten berechnet, die von seinen vorgelagerten Nachbarn empfangen wurden, das Resultat in sich selber speichert und es nachgelagert weitergibt. In einem Beispiel kann ein systolisches Array für massive Multiplikations-Akkumulations-Operationen verwendet werden. In manchen Ausführungsformen enthält ein systolisches Array ein W breites und D tiefes Netzwerk von DPUs, die zum Durchführen von Vektor- oder anderen Datenparalleloperationen auf eine systolische Weise verwendet werden können. Das systolische Array kann dafür ausgelegt sein, Matrixoperationen durchzuführen, wie etwa Matrixpunktproduktoperationen. Das systolische Array kann 16-Bit Gleitkommaoperationen sowie 8-Bit und 4-Bit-Ganzzahloperationen unterstützen. In einer Ausführungsform kann das systolische Array dafür ausgelegt sein, Maschinenlernoperationen zu beschleunigen. In solchen Ausführungsformen kann das systolische Array mit Unterstützung für das bfloat 16-Bit Gleitkommaformat konfiguriert sein.
  • Implementierungen der Offenbarung stellen eine Technik bereit, die die Vorteile systolischer Arrays nutzt, um effizient Operationen zwischen Kanälen (d.h. kanalübergreifende Operationen) zu implementieren. Somit ermöglichen Implementierungen im Vergleich zu konventionellen Lösungen (z.B. Emulation, eine Hardwareimplementierung usw.), die ausschließlich für die Ausführung dieser Operationen entwickelt wurden, eine reduzierte Anzahl von Hardwareressourcen. Implementierungen der kanalübergreifenden Operationen nutzen den Vorteil der Merkmale des systolischen Arrays, wie etwa eine Broadcasting-Funktion des systolischen Array und die Pipeline-Implementierung des systolischen Arrays. Implementierungen der Offenbarung können ein Element über Kanäle des systolischen Arrays senden/verbreiten und dann die Hardware des systolischen Arrays erweitern, um die kanalübergreifenden Operationen zu implementieren. Implementierungen der Offenbarung verbessern somit die Leistung der Verarbeitungsressourcen des Prozessors (z.B. CPU, GPU, GPGPU usw.) in Hinblick auf Beschleunigung der Ausführungsgeschwindigkeit in den bestehenden Verarbeitungsressourcen ohne Einbringen zusätzlicher kostspieliger Hardware.
  • 14 veranschaulicht ein systolische Array 1400 gemäß Implementierungen der Offenbarung. Das in 14 veranschaulichte systolische Array 1400 kann das gleiche sein wie systolisches Array 612, das in Bezug auf 6 hierin beschrieben wurde. In einer Implementierung ist systolisches Array 1400 ein konventionelles systolisches Array, das eine Multiplikations-Akkumulations-Operation implementiert. Das systolische Array kann ein homogenes Netzwerk eng gekoppelter Datenverarbeitungseinheiten (DPUs) 1405 enthalten, die Zellen oder Knoten genannt werden. Obwohl Referenznummer 1405 auf nur zwei DPUS in systolischem Array 1400 verweist, versteht es sich, dass sich Referenznummer 1405 auf alle anderen Blöcke in systolischem Array 1400 erstreckt. Jeder Knoten bzw. DPU 1405 in systolischem Array 1400 berechnet unabhängig ein Teilergebnis als eine Funktion der Daten, die von seinen vorgelagerten Nachbarn empfangen wurden, speichert das Ergebnis in sich selber (z.B. rslt0.0, rslt0.1, ..., rslt6.0, rslt6.1...) und gibt das Ergebnis nachgelagert an andere DPUs 1405 in dem systolischen Array 1400 weiter. In einem Beispiel kann das konventionelle systolische Array 1400 eine Matrixmultiplikationsoperation implementieren, indem sie die Daten auf den Kanälen der mehreren Register (src1 1430a-1430h) gegen Elemente eines einzelnen Registers (src2 1410) multipliziert und addiert. Zum Implementieren einer Additions-Akkumulations-Anweisung empfängt das konventionelle systolische Array drei Eingaberegister (z.B. src0 1420, src2 1410 und src1 1430a-1430h) in jedem Zyklus. In jeder Stufe 1407a-h der Pipeline des systolischen Array 1400 werden die Elemente eines Kanals von src2 1410 an alle die Kanäle der Pipeline gesendet, die ein src1 Register 1430a-1430h enthalten, und die Multiplikations-Additions-Operation wird kanalweise unter Verwendung der Kanäle des scr0 Registers 1420 durchgeführt.
  • In Bezug auf Implementierungen der Offenbarung nutzen Ausführungsformen zum Implementieren von kanalübergreifenden Operationen, wie etwa min, max, are_equal und anderer kanalübergreifender Operationen, eine Broadcasting-Funktion des systolischen Arrays und die Pipeline-Implementierung des systolischen Array. Implementierungen der Offenbarung können ein Element über die Kanäle des systolischen Arrays versenden/verbreiten und dann die Hardware des systolischen Arrays erweitern, um die kanalübergreifenden Operationen zu implementieren, wie unten in Bezug auf das in 15 und 16 veranschaulichte beispielhafte systolische Array ausführlicher diskutiert.
  • 15 veranschaulicht ein systolisches Array 1500 zum Berechnen von kanalübergreifenden Operationen in Parallelrechenmaschinen gemäß Implementierungen der Offenbarung. Das in 15 veranschaulichte systolische Array 1500 kann das gleiche sein wie systolisches Array 612, das in Bezug auf 6 hierin beschrieben wurde. Das systolische Array in 15 ist als eine max-Operation durchführend veranschaulicht, gemäß Implementierungen der Offenbarung. Eine min-Operation, die von dem systolischen Array durchgeführt wird, würde dem gleichen entsprechen, wobei die Operation „>=‟ durch „<=“ ersetzt wäre. Es ist zu beachten, dass das Ergebnis dieser max- (oder min-) Operation als Ausgabe an alle Kanäle des Zielregisters gesendet wird.
  • In einer Ausführungsform ist das systolische Array 1500 in 15 dafür ausgelegt, eine max-Operation durchzuführen. Für min- und max-Operationen werden Kanäle 0 und 1 des systolischen Arrays 1500 verwendet. Alle anderen Kanäle des systolischen Arrays 1500 sind deaktiviert, um Stromverbrauch zu reduzieren. In einem Beispiel kann ein Kanal durch Power-Gating deaktiviert werden, um Strom vollständig aus dem Kanal zu entfernen.
  • In Bezug auf systolisches Array 1500 wird für die Anweisungen ein einzelnes Quellregister (src0 1510) verwendet und es wird als eine Eingabe in ein systolisches Array 1500 eingespeist. In einer Ausführungsform kann die Eingabe die gleiche Eingabe sein, wie die, die in 14 als „src2“ gekennzeichnet ist. In der ersten Stufe des systolischen Array 1500 werden src0.0 und src0.1 in die Schaltungsanordnung (z.B. DPU 1505), die die Berechnungen für Kanal 0 durchführt, eingegeben. Src0.8 und src0.9 werden in die Schaltungsanordnung eingegeben, die die Berechnungen für Kanal 1 durchführt. Src0.2 wird in die Schaltungsanordnung eingegeben, die die Berechnungen für Kanal 0 in der nächsten Stufe des systolischen Arrays durchführt, und src0.10 in die Schaltungsanordnung, die die Berechnungen für Kanal 1 durchführt. Der gleiche letztgenannte Verlauf wird bei den nächsten Quellen verfolgt.
  • Jede Stufe 1507a-1507h des systolischen Arrays 1500 führt einen Vergleich (min oder max) mit der Ausgabe des Vergleichs durch, der von seiner Vorgängerstufe 1507a-1507h berechnet wurde. Für die erste Stufe 1507a wird der Vergleich aber zu src0.0 oder src0.8 vorgenommen. Weiterhin wird für die letzte Stufe die Berechnung der Ausgaben der vorherigen zwei Kanäle durchgeführt. Diese letzte Stufe 1507h liefert eine einzelne Ausgabe für die gesamte Berechnung. Diese einzelne Ausgabe wird dann von dem systolischen Array 1500 an alle Kanäle eines Zielregisters 1540 gesendet.
  • 16 veranschaulicht ein anderes Beispiel für ein systolisches Array 1600 zum Berechnen von kanalübergreifenden Operationen in einer Parallelrechenmaschine gemäß Implementierungen der Offenbarung. Das in 16 veranschaulichte systolische Array 1600 kann das gleiche sein wie systolisches Array 612, das in Bezug auf 6 hierin beschrieben wurde. Systolisches Array 1600 kann eine ähnliche Architektur enthalten, wie systolisches Array 1500, das in Bezug auf 15 beschrieben wurde. In Bezug auf systolisches Array 1600 kann bei manchen kanalübergreifenden Operationen in einer Parallelrechenmaschine (wie etwa einer SIMD-Maschine oder einer SIMT-Maschine), anstatt des Findens eines Wertes einer Operation unter Kanälen (wie durch systolisches Array 1500 in 15 gezeigt), die Arbeitslast der kanalübergreifenden Operationen den Index eines Kanals bestimmen.
  • Systolisches Array 1600 in 16 zeigt diese Indexwertbestimmung für eine max-Operation. Um dies zu erreichen, kann die Pipeline des in 16 gezeigten systolischen Arrays 1600 den Index des Gewinners der Teilberechnung an jeder DPU 1605 der Stufen 1607a-1607h des systolischen Arrays 1600 verbreiten. Im Vergleich zu systolischem Array 1500 in 15 kann systolisches Array 1600 modifiziert sein, um einen Indexwert eines Kanals anstatt des Werts an sich zu verbreiten. In manchen Implementierungen sind die DPUs 1605 des systolischen Arrays 1600 derart konfiguriert, dass, wenn beim Berechnen von max (oder min) zwei Elemente gleich sind, der Index des niedrigeren einen behalten wird. Ein Einzelausgabeindexwert kann von dem systolischen Array 1600 an alle Kanäle eines Zielregisters 1640 gesendet werden.
  • 17 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 1700 zum Berechnen effizienter kanalübergreifender Operationen in parallelen Rechenmaschinen unter Verwendung systolischer Arrays veranschaulicht. Verfahren 1700 kann von Verarbeitungslogik durchgeführt werden, die Hardware (z.B. Schaltungsanordnungen, dedizierte Logik, programmierbare Logik usw.), Software (wie etwa Anweisungen, die auf einer Verarbeitungsvorrichtung laufen) oder eine Kombination davon enthalten. Der Prozess des Verfahrens 1700 wird der Kürze und Klarheit der Präsentation halber in linearen Sequenzen veranschaulicht. Es ist jedoch angedacht, dass jedwede Anzahl davon parallel, asynchron oder in anderen Reihenfolgen durchgeführt wird. Weiterhin werden, aus Gründen der Kürze, Klarheit und des besseren Verständnisses, viele der Komponenten und Prozesse, die in Bezug auf 1-16 beschrieben wurden, nachfolgend nicht wiederholt oder diskutiert. In einer Implementierung kann ein systolisches Array, wie etwa systolisches Array 1500 in 15 oder systolisches Array 1600 in 16, Verfahren 1700 durchführen.
  • Verfahren 1700 beginnt am Verarbeitungsblock 1710, wo das systolische Array Quelldaten von einem einzelnen Quellregister empfängt. In einer Implementierung wurde das systolische Array modifiziert, um kanalübergreifende Operationen durchzuführen. Am Block 1720 führt das systolische Array Operationen an den Quelldaten auf einer Teilmenge von Kanälen der systolische Arrayhardwareschaltung durch. In einer Ausführungsform sind die Operationen kanalübergreifende Operationen und können max-Operationen, min-Operationen oder areequal-Operationen umfassen. In manchen Ausführungsformen werden die Operationen auf einer Teilmenge von Kanälen des systolischen Arrays durchgeführt und die übrigen Kanäle des systolischen Arrays werden deaktiviert.
  • Im Block 1730 reicht das systolische Array Ergebnisse der Operationen an nachfolgende Stufen des systolischen Arrays weiter. Die nachfolgenden Stufen des systolischen Arrays können unterschiedliche Quelldaten von dem einzelnen Quellregister empfangen. Die nachfolgenden Stufen des systolischen Arrays können beispielsweise Daten von einem Satz unterschiedlicher Kanäle des einzelnen Quellregisters empfangen, als von Kanälen, die Daten an vorherige Stufen des systolischen Arrays bereitgestellt haben. Die nachfolgenden Stufen des systolischen Arrays können an den Eingabedaten, die an den nachfolgenden Stufen empfangen werden, Operationen durchführen, die den im Block 1720 durchgeführten Operationen ähnlich sind. Schließlich sendet das systolische Array im Block 1740 ein Ergebnis einer letzten Stufe des systolischen Arrays an jeden Kanal eines Zielregisters.
  • 18 ist ein Flussdiagramm, das eine Ausführungsform eines Verfahrens 1800 zum Modifizieren eines systolischen Arrays zum Berechnen effizienter kanalübergreifender Operationen in parallelen Rechenmaschinen veranschaulicht. Verfahren 1800 kann von Verarbeitungslogik durchgeführt werden, die Hardware (z.B. Schaltungsanordnungen, dedizierte Logik, programmierbare Logik usw.), Software (wie etwa Anweisungen, die auf einer Verarbeitungsvorrichtung laufen) oder eine Kombination davon enthalten. Der Prozess des Verfahrens 1800 wird der Kürze und Klarheit der Präsentation halber in linearen Sequenzen veranschaulicht. Es ist jedoch angedacht, dass jedwede Anzahl davon parallel, asynchron oder in anderen Reihenfolgen durchgeführt wird. Weiterhin werden, aus Gründen der Kürze, Klarheit und des besseren Verständnisses, viele der Komponenten und Prozesse, die in Bezug auf 1-17 beschrieben wurden, nachfolgend nicht wiederholt oder diskutiert. In einer Implementierung kann ein systolisches Array, wie etwa systolisches Array 1500 in 15 oder systolisches Array 1600 in 16, Verfahren 1800 durchführen.
  • Verfahren 1800 beginnt an Verarbeitungsblock 1810, wo Eingangskanäle von Knoten einer systolische Arrayhardwareschaltung modifiziert sind, um Eingaben von unterschiedlichen Elementen eines einzelnen Quellregisters in verschiedenen Stufen der systolischen Arrayhardwareschaltung zu empfangen. Am Verarbeitungsblock 1820 sind Logikschaltungsanordnungen der Knoten der Kanäle der systolischen Arrayhardwareschaltung modifiziert, um bestimmte kanalübergreifende Operationen durchzuführen. In einer Ausführungsform können die kanalübergreifenden Operationen Maximumoperationen, Minimumoperationen und areequal-Operationen umfassen, um einige Beispiele zu nennen. Es können auch andere arithmetische und/oder logische Operationen unter Nutzung von kanalübergreifenden Abhängigkeiten implementiert werden.
  • Am Verarbeitungsblock 1830 werden Kanäle der systolischen Arrayhardwareschaltung, die nicht zum Berechnen von kanalübergreifenden Operationen verwendet werden, deaktiviert. In einer Implementierung werden Knoten der Kanäle, die nicht genutzt werden, durch Power-Gating der Knoten deaktiviert. Schließlich ist die systolische Arrayhardwareschaltung in Verarbeitungsblock 1840 modifiziert, um ein Ergebnis einer abschließenden Stufe der systolischen Arrayhardwareschaltung an jeden Kanal eines Zielregisters zu senden.
  • Die folgenden Beispiele beziehen sich auf weitere Ausführungsformen. Beispiel 1 ist eine Vorrichtung zum Berechnen von kanalübergreifenden Operationen in Parallelrechenmaschinen, die eine systolische Arrayschaltung verwenden. Die Vorrichtung des Beispiels 1 enthält mehrere Register und ein oder mehrere Verarbeitungselemente, die kommunikativ mit den mehreren Registern gekoppelt sind. Das eine oder die mehreren Verarbeitungselemente des Beispiels 1 umfassen eine systolische Arrayschaltung zum Durchführen von kanalübergreifenden Operationen an Quelldaten, die von einem einzelnen Quellregister der mehreren Register empfangen werden, wobei die systolische Arrayschaltung modifiziert ist, Eingaben von dem einzelnen Quellregister zu empfangen und Elemente des einzelnen Quellregisters an mehrere Kanäle in der systolischen Arrayschaltung weiterzuleiten.
  • In Beispiel 2 kann der Gegenstand des Beispiels 1 optional umfassen, dass die systolische Arrayschaltung modifiziert ist, einen Ergebniswert aus einer letzten Zeile der systolischen Arrayschaltung an alle Elemente eines Zielregisters der mehreren Register zu senden. In Beispiel 3 kann der Gegenstand eines der Beispiele 1-2 optional umfassen, dass das eine oder die mehreren Verarbeitungselemente in einer Grafikverarbeitungseinheit (GPU) umfasst sind. In Beispiel 4 kann der Gegenstand eines der Beispiele 1-3 optional umfassen, dass die systolische Arrayschaltung für die kanalübergreifenden Operationen durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayschaltung, um die kanalübergreifenden Operationen an den Quelldaten durchzuführen, und Modifizieren des Routings der DPUs der systolischen Arrayschaltung, Eingaben von unterschiedlichen Kanälen des einzelnen Quellregisters an unterschiedlichen Stufen der systolischen Arrayschaltung zu empfangen, modifiziert ist.
  • In Beispiel 5 kann der Gegenstand eines der Beispiele 1-4 optional umfassen, dass die unterschiedlichen Stufen der systolischen Arrayschaltung jeweils ein anderes Element des einzelnen Quellregisters, an dem die kanalübergreifenden Operationen durchzuführen sind, empfängt. In Beispiel 6 kann der Gegenstand eines der Beispiele 1-5 optional umfassen, dass eine Teilmenge von Kanälen der systolischen Arrayschaltung die kanalübergreifenden Operationen durchführt, und wobei andere Kanäle der systolischen Arrayschaltung, die nicht in der Teilmenge der Kanäle umfasst sind, deaktiviert werden.
  • In Beispiel 7 kann der Gegenstand eines der Beispiele 1-6 optional umfassen, dass die kanalübergreifenden Operationen mindestens eines von einer Maximumoperation, einer Minimumoperation oder einer areequal-Operation umfassen. In Beispiel 8 kann der Gegenstand eines der Beispiele 1-7 optional umfassen, dass ein erster Kanal einer letzten Stufe der systolischen Arrayschaltung modifiziert ist, um Eingaben von mehr als einem Kanal einer vorherigen Stufe der systolischen Arrayschaltung zu empfangen.
  • In Beispiel 9 kann der Gegenstand eines der Beispiele 1-8 optional umfassen, dass die Vorrichtung eine SIMD-Maschine (Single Instruction Multiple Data) umfasst. In Beispiel 10 kann der Gegenstand eines der Beispiele 1-9 optional umfassen, dass die Vorrichtung eine SIMT-Maschine (Single Instruction Multiple Thread) umfasst.
  • Beispiel 11 ist ein computergeneriertes Verfahren zum Ermöglichen von kanalübergreifenden Rechenoperationen in einer Parallelrechenmaschine unter Verwendung einer systolischen Arrayhardwareschaltung, umfassend: Empfangen, an der systolischen Arrayhardwareschaltung, die für kanalübergreifende Operationen modifiziert ist, von Quelldaten von einem einzelnen Quellregister; Durchführen der kanalübergreifenden Operationen an den Quelldaten in einer Teilmenge von Kanälen der systolischen Arrayhardwareschaltung; Weitergeben von Ergebnissen der kanalübergreifenden Operationen an nachfolgende Stufen der systolischen Arrayhardwareschaltung; und Senden eines Ergebnisses einer letzten Stufe der systolischen Arrayhardwareschaltung an jeden Kanal eines Zielregisters.
  • In Beispiel 12 kann der Gegenstand des Beispiels 11 optional umfassend, dass die systolische Arrayschaltung modifiziert ist, einen Ergebniswert aus einer letzten Zeile der systolischen Arrayschaltung an alle Elemente eines Zielregisters der mehreren Register zu senden. In Beispiel 13 kann der Gegenstand eines der Beispiele 11-12 optional umfassen, dass das eine oder die mehreren Verarbeitungselemente in einer Grafikverarbeitungseinheit (GPU) umfasst sind. In Beispiel 14 kann der Gegenstand eines der Beispiele 11-13 optional umfassen, dass die systolische Arrayschaltung für die kanalübergreifenden Operationen durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayschaltung, um die kanalübergreifenden Operationen an den Quelldaten durchzuführen, und Modifizieren des Routings der DPUs der systolischen Arrayschaltung, Eingaben von unterschiedlichen Kanälen des einzelnen Quellregisters in unterschiedlichen Stufen der systolischen Arrayschaltung zu empfangen, modifiziert ist.
  • In Beispiel 15 kann der Gegenstand eines der Beispiele 11-14 optional umfassen, dass die unterschiedlichen Stufen der systolischen Arrayschaltung jeweils ein anderes Element des einzelnen Quellregisters, an dem die kanalübergreifenden Operationen durchzuführen sind, empfängt. In Beispiel 16 kann der Gegenstand eines der Beispiele 11-15 optional umfassen, dass eine Teilmenge der Kanäle der systolischen Arrayschaltung die kanalübergreifenden Operationen durchführt, und wobei andere Kanäle der systolischen Arrayschaltung, die nicht in der Teilmenge von Kanälen umfasst sind, deaktiviert werden.
  • In Beispiel 17 kann der Gegenstand eines der Beispiele 11-16 optional umfassen, dass die kanalübergreifenden Operationen mindestens eines von einer Maximumoperation, einer Minimumoperation oder einer areequal-Operation umfassen. In Beispiel 18 kann der Gegenstand eines der Beispiele 11-17 optional umfassen, dass ein erster Kanal einer letzten Stufe der systolischen Arrayschaltung modifiziert ist, um Eingaben von mehr als einem Kanal einer vorherigen Stufe der systolischen Arrayschaltung zu empfangen.
  • In Beispiel 19 kann der Gegenstand eines der Beispiele 11-18 optional umfassen, dass die Parallelrechenmaschine eine SIMD-Maschine (Single Instruction Multiple Data) umfasst. In Beispiel 20 kann der Gegenstand eines der Beispiele 11-19 optional umfassen, dass die Parallelrechenmaschine eine SIMT-Maschine (Single Instruction Multiple Thread) umfasst.
  • Beispiel 21 ist ein nichtflüchtiges computerlesbares Medium zum Ermöglichen der Berechnung von kanalübergreifenden Operationen in einer Parallelrechenmaschine unter Verwendung einer systolischen Arrayhardwareschaltung. In Beispiel 21 kann das nichtflüchtige computerlesbare Medium über Anweisungen verfügen, die darauf gespeichert sind, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, die Prozessoren veranlassen, an einer systolischen Arrayhardwareschaltung, die für kanalübergreifende Operationen modifiziert ist, Quelldaten von einem einzelnen Quellregister zu empfangen; die kanalübergreifenden Operationen an den Quelldaten in einer Teilmenge von Kanälen der systolischen Arrayhardwareschaltung durchzuführen; Ergebnisse der kanalübergreifenden Operationen an nachfolgende Stufen der systolischen Arrayhardwareschaltung weiterzugeben; und ein Ergebnis einer letzten Stufe der systolischen Arrayhardwareschaltung an jeden Kanal eines Zielregisters zu senden.
  • In Beispiel 22 kann der Gegenstand des Beispiels 21 optional umfassen, dass die systolische Arrayschaltung modifiziert ist, einen Ergebniswert aus einer letzten Zeile der systolischen Arrayschaltung an alle Elemente eines Zielregisters der mehreren Register zu senden. In Beispiel 23 kann der Gegenstand eines der Beispiele 21-22 optional umfassen, dass das eine oder die mehreren Verarbeitungselemente in einer Grafikverarbeitungseinheit (GPU) umfasst sind. In Beispiel 24 kann der Gegenstand eines der Beispiele 21-23 optional umfassen, dass die systolische Arrayschaltung für die kanalübergreifenden Operationen durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayschaltung, um die kanalübergreifenden Operationen an den Quelldaten durchzuführen, und Modifizieren des Routings der DPUs der systolischen Arrayschaltung, Eingaben von unterschiedlichen Kanälen des einzelnen Quellregisters in unterschiedlichen Stufen der systolischen Arrayschaltung zu empfangen, modifiziert ist.
  • In Beispiel 25 kann der Gegenstand eines der Beispiele 21-24 optional umfassen, dass die unterschiedlichen Stufen der systolischen Arrayschaltung jeweils ein anderes Element des einzelnen Quellregisters, an dem die kanalübergreifenden Operationen durchzuführen sind, empfängt. In Beispiel 26 kann der Gegenstand eines der Beispiele 21-25 optional umfassen, dass eine Teilmenge von Kanälen der systolischen Arrayschaltung die kanalübergreifenden Operationen durchführt, und wobei andere Kanäle der systolischen Arrayschaltung, die nicht in der Teilmenge der Kanäle umfasst sind, deaktiviert werden.
  • In Beispiel 27 kann der Gegenstand eines der Beispiele 21-26 optional umfassen, dass die kanalübergreifenden Operationen mindestens eines von einer Maximumoperation, einer Minimumoperation oder einer areequal-Operation umfassen. In Beispiel 28 kann der Gegenstand eines der Beispiele 21-27 optional umfassen, dass ein erster Kanal einer letzten Stufe der systolischen Arrayschaltung modifiziert ist, um Eingaben von mehr als einem Kanal einer vorherigen Stufe der systolischen Arrayschaltung zu empfangen.
  • In Beispiel 29 kann der Gegenstand eines der Beispiele 21-28 optional umfassen, dass die Parallelrechenmaschine eine SIMD-Maschine (Single Instruction Multiple Data) umfasst. In Beispiel 30 kann der Gegenstand eines der Beispiele 21-29 optional umfassen, dass die Parallelrechenmaschine eine SIMT-Maschine (Single Instruction Multiple Thread) umfasst.
  • Beispiel 31 ist ein System zum Ermöglichen von kanalübergreifenden Rechenoperationen in Parallelrechenmaschinen unter Verwendung einer systolischen Arrayhardwareschaltung. In Beispiel 31 umfasst das System einen Speicher und einen oder mehrere Prozessoren der mehreren GPUs. Der eine oder die mehreren Prozessoren des Beispiels 31 sind kommunikativ mit dem Speicher gekoppelt und umfassen eine systolische Arrayschaltung zum Durchführen von kanalübergreifenden Operationen an Quelldaten, die von einem einzelnen Quellregister der mehreren Register empfangen werden, wobei die systolische Arrayschaltung modifiziert ist, Eingaben von dem einzelnen Quellregister zu empfangen und Elemente des einzelnen Quellregisters an mehrere Kanäle in der systolischen Arrayschaltung weiterzuleiten.
  • In Beispiel 32 kann der Gegenstand des Beispiels 31 optional umfassen, dass die systolische Arrayschaltung modifiziert ist, einen Ergebniswert aus einer letzten Zeile der systolischen Arrayschaltung an alle Elemente eines Zielregisters der mehreren Register zu senden. In Beispiel 33 kann der Gegenstand eines der Beispiele 31-32 optional umfassen, dass das eine oder die mehreren Verarbeitungselemente in einer Grafikverarbeitungseinheit (GPU) umfasst sind. In Beispiel 34 kann der Gegenstand eines der Beispiele 31-33 optional umfassen, dass die systolische Arrayschaltung für die kanalübergreifenden Operationen durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayschaltung, um die kanalübergreifenden Operationen an den Quelldaten durchzuführen, und Modifizieren des Routings der DPUs der systolischen Arrayschaltung, Eingaben von unterschiedlichen Kanälen des einzelnen Quellregisters in unterschiedlichen Stufen der systolischen Arrayschaltung zu empfangen, modifiziert ist.
  • In Beispiel 35 kann der Gegenstand eines der Beispiele 31-34 optional umfassen, dass die unterschiedlichen Stufen der systolischen Arrayschaltung jeweils ein anderes Element des einzelnen Quellregisters, an dem die kanalübergreifenden Operationen durchzuführen sind, empfängt. In Beispiel 36 kann der Gegenstand eines der Beispiele 31-35 optional umfassen, dass eine Teilmenge von Kanälen der systolischen Arrayschaltung die kanalübergreifenden Operationen durchführt, und wobei andere Kanäle der systolischen Arrayschaltung, die nicht in der Teilmenge der Kanäle umfasst sind, deaktiviert werden.
  • In Beispiel 37 kann der Gegenstand eines der Beispiele 31-36 optional umfassen, dass die kanalübergreifenden Operationen mindestens eines von einer Maximumoperation, einer Minimumoperation oder einer areequal-Operation umfassen. In Beispiel 38 kann der Gegenstand eines der Beispiele 31-37 optional umfassen, dass ein erster Kanal einer letzten Stufe der systolischen Arrayschaltung modifiziert ist, um Eingaben von mehr als einem Kanal einer vorherigen Stufe der systolischen Arrayschaltung zu empfangen.
  • In Beispiel 39 kann der Gegenstand eines der Beispiele 31-38 optional umfassen, dass die Parallelrechenmaschine eine SIMD-Maschine (Single Instruction Multiple Data) umfasst. In Beispiel 40 kann der Gegenstand eines der Beispiele 31-39 optional umfassen, dass die Parallelrechenmaschine eine SIMT-Maschine (Single Instruction Multiple Thread) umfasst.
  • Beispiel 41 ist eine Vorrichtung zum Ermöglichen von kanalübergreifenden Rechenoperationen in Parallelrechenmaschinen unter Verwendung einer systolischen Arrayhardwareschaltung, umfassend: Mittel zum Empfangen, an der systolischen Arrayhardwareschaltung, die für kanalübergreifende Operationen modifiziert ist, von Quelldaten von einem einzelnen Quellregister; Mittel zum Durchführen der kanalübergreifenden Operationen an den Quelldaten in einer Teilmenge von Kanälen der systolischen Arrayhardwareschaltung; Mittel zum Weitergeben von Ergebnissen der kanalübergreifenden Operationen an nachfolgende Stufen der systolischen Arrayhardwareschaltung; und Mittel zum Senden eines Ergebnisses einer letzten Stufe der systolischen Arrayhardwareschaltung an jeden Kanal eines Zielregisters. In Beispiel 42 kann der Gegenstand des Beispiels 41 optional umfassen, dass die Vorrichtung ferner dafür ausgelegt ist, das Verfahren nach einem der Beispiele 12 bis 20 durchzuführen.
  • Beispiel 43 ist mindestens ein maschinenlesbares Medium, eine Vielzahl von Anweisungen umfassend, die, in Reaktion auf ihre Ausführung auf einer Rechenvorrichtung, die Rechenvorrichtung veranlassen, ein Verfahren nach einem der Beispiele 11-20 auszuführen. Beispiel 44 ist eine Vorrichtung zum Berechnen von kanalübergreifenden Operationen in Parallelrechenmaschinen unter Verwendung einer systolischen Arrayhardwareschaltung, die dafür ausgelegt ist, das Verfahren nach einem der Beispiele 11-20 durchzuführen. Beispiel 45 ist eine Vorrichtung zum Berechnen von kanalübergreifenden Operationen in Parallelrechenmaschinen unter Verwendung einer systolischen Arrayhardwareschaltung, die Mittel zum Durchführen des Verfahrens nach einem der Ansprüche 11-20 umfasst. Spezifische Aspekte in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden.
  • Die vorstehende Beschreibung und Zeichnungen sind in einem veranschaulichenden und nicht in einem einschränkenden Sinne aufzufassen. Fachleute werden verstehen, dass verschiedene Modifikationen und Veränderungen an den hierin beschriebenen Ausführungsformen vorgenommen werden können, ohne dass vom breiteren Geist und Umfang der in den beigefügten Ansprüchen dargelegten Merkmale abgewichen werden würde.
  • 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 202041018637 [0001]

Claims (20)

  1. Vorrichtung, umfassend: mehrere Register; und ein oder mehrere Verarbeitungselemente, die kommunikativ mit den mehreren Registern gekoppelt sind, wobei das eine oder die mehreren Verarbeitungselemente umfassen: eine systolische Arrayschaltung zum Durchführen von kanalübergreifenden Operationen an Quelldaten, die von einem einzelnen Quellregister der mehreren Register empfangen werden, wobei die systolische Arrayschaltung modifiziert ist, Eingaben von dem einzelnen Quellregister zu empfangen und Elemente des einzelnen Quellregisters an mehrere Kanäle in der systolischen Arrayschaltung weiterzuleiten.
  2. Vorrichtung nach Anspruch 1, wobei die systolische Arrayschaltung modifiziert ist, einen Ergebniswert aus einer letzten Zeile der systolischen Arrayschaltung an alle Elemente eines Zielregisters der mehreren Register zu senden.
  3. Vorrichtung nach einem der Ansprüche 1 oder 2, wobei das eine oder die mehreren Verarbeitungselemente in einer Grafikverarbeitungseinheit (GPU) umfasst sind.
  4. Vorrichtung nach einem der Ansprüche 1 bis 3, wobei die systolische Arrayschaltung für die kanalübergreifenden Operationen durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayschaltung, um die kanalübergreifenden Operationen an den Quelldaten durchzuführen, und Modifizieren des Routings der DPUs der systolischen Arrayschaltung, um Eingaben von unterschiedlichen Kanälen des einzelnen Quellregisters in unterschiedlichen Stufen der systolischen Arrayschaltung zu empfangen, modifiziert ist.
  5. Vorrichtung nach Anspruch 4, wobei die unterschiedlichen Stufen der systolischen Arrayschaltung jeweils ein anderes Element des einzelnen Quellregisters, an dem die kanalübergreifenden Operationen durchzuführen sind, empfangen.
  6. Vorrichtung nach einem der Ansprüche 1 bis 5, wobei eine Teilmenge von Kanälen der systolischen Arrayschaltung die kanalübergreifenden Operationen durchführt, und wobei andere Kanäle der systolischen Arrayschaltung, die nicht in der Teilmenge der Kanäle umfasst sind, deaktiviert werden.
  7. Vorrichtung nach einem der Ansprüche 1 bis 6, wobei die kanalübergreifenden Operationen mindestens eines von einer Maximumoperation, einer Minimumoperation oder einer areequal-Operation umfassen.
  8. Vorrichtung nach einem der Ansprüche 1 bis 7, wobei ein erster Kanal einer letzten Stufe der systolischen Arrayschaltung modifiziert ist, um Eingaben von mehr als einem Kanal einer vorherigen Stufe der systolischen Arrayschaltung zu empfangen.
  9. Vorrichtung nach einem der Ansprüche 1 bis 8, wobei die Vorrichtung eine SIMD-Maschine (Single Instruction Multiple Data) ist.
  10. Vorrichtung nach einem der Ansprüche 1 bis 9, wobei die Vorrichtung eine SIMT-Maschine (Single Instruction Multiple Thread) ist.
  11. Verfahren, umfassend: Empfangen, an der systolischen Arrayhardwareschaltung, die für kanalübergreifende Operationen modifiziert ist, von Quelldaten von einem einzelnen Quellregister; Durchführen der kanalübergreifenden Operationen an den Quelldaten in einer Teilmenge von Kanälen der systolischen Arrayhardwareschaltung; Weitergabe der Ergebnisse der kanalübergreifenden Operationen an nachfolgende Stufen der systolischen Arrayhardwareschaltung; und Senden eines Ergebnisses einer letzten Stufe der systolischen Arrayhardwareschaltung an jeden Kanal eines Zielregisters.
  12. Verfahren nach Anspruch 11, wobei die nachfolgenden Stufen jeweils ein anderes Element des einzelnen Quellregisters, an dem Operationen durchzuführen sind, empfangen.
  13. Verfahren nach einem der Ansprüche 11 oder 12, wobei andere Kanäle der systolischen Arrayhardwareschaltung, die nicht in der Teilmenge von Kanälen umfasst sind, deaktiviert werden.
  14. Verfahren nach einem der Ansprüche 11 bis 13, wobei die systolische Arrayhardwareschaltung Teil einer Grafikverarbeitungseinheit (GPU) ist.
  15. Verfahren nach einem der Ansprüche 11 bis 14, wobei ein erster Kanal einer letzten Stufe der systolischen Arrayschaltung modifiziert ist, um Eingaben von mehr als einem Kanal einer vorherigen Stufe der systolischen Arrayschaltung zu empfangen.
  16. Verfahren nach einem der Ansprüche 11 bis 15, wobei die systolische Arrayhardwareschaltung für die kanalübergreifenden Operationen durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayhardwareschaltung, um die kanalübergreifenden Operationen an den Quelldaten durchzuführen, und Modifizieren des Routings der DPUs der systolischen Arrayhardwareschaltung, um Eingaben von unterschiedlichen Kanälen des einzelnen Quellregisters in unterschiedlichen Stufen der systolischen Arrayhardwareschaltung zu empfangen, modifiziert ist.
  17. Nichtflüchtiges computerlesbares Medium bzw. nichtflüchtige computerlesbare Medien mit darauf gespeicherten Anweisungen, die, wenn sie von einem oder mehreren Prozessoren ausgeführt werden, die Prozessoren zu Folgendem veranlassen: Empfangen, an einer systolischen Arrayhardwareschaltung, die für kanalübergreifende Operationen modifiziert ist, von Quelldaten von einem einzelnen Quellregister; Durchführen der kanalübergreifenden Operationen an den Quelldaten in einer Teilmenge von Kanälen der systolischen Arrayhardwareschaltung; Weitergabe der Ergebnisse der kanalübergreifenden Operationen an nachfolgende Stufen der systolischen Arrayhardwareschaltung; und Senden eines Ergebnisses einer letzten Stufe der systolischen Arrayhardwareschaltung an jeden Kanal eines Zielregisters.
  18. Nichtflüchtiges computerlesbares Medium nach Anspruch 17, wobei die nachfolgenden Stufen jeweils ein anderes Element des einzelnen Quellregisters, an dem Operationen durchzuführen sind, empfangen.
  19. Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 17 oder 18, wobei andere Kanäle der systolischen Arrayhardwareschaltung, die nicht in der Teilmenge von Kanälen umfasst sind, deaktiviert werden.
  20. Nichtflüchtiges computerlesbares Medium nach einem der Ansprüche 17 bis 19, wobei die systolische Arrayhardwareschaltung durch Modifizieren von Datenverarbeitungseinheiten (DPUs) der systolischen Arrayhardwareschaltung zum Durchführen der kanalübergreifenden Operationen an den Quelldaten und Modifizieren von Routing DPUs der systolischen Arrayhardwareschaltung zum Empfangen von Eingaben von unterschiedlichen Kanälen einzelner Quellregister an unterschiedlichen Stufen der systolischen Arrayhardwareschaltung für die kanalübergreifenden Operationen modifiziert ist.
DE102020132088.4A 2020-05-01 2020-12-03 Berechnung effizienter kanalübergreifender operationen in parallelrechenmaschinen mit systolischen arrays Pending DE102020132088A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
IN202041018637 2020-05-01
IN202041018637 2020-05-01
US16/900,236 2020-06-12
US16/900,236 US11182337B1 (en) 2020-05-01 2020-06-12 Computing efficient cross channel operations in parallel computing machines using systolic arrays

Publications (1)

Publication Number Publication Date
DE102020132088A1 true DE102020132088A1 (de) 2021-11-04

Family

ID=78238023

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020132088.4A Pending DE102020132088A1 (de) 2020-05-01 2020-12-03 Berechnung effizienter kanalübergreifender operationen in parallelrechenmaschinen mit systolischen arrays

Country Status (3)

Country Link
US (2) US11669490B2 (de)
CN (1) CN113590198A (de)
DE (1) DE102020132088A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11669490B2 (en) 2020-05-01 2023-06-06 Intel Corporation Computing efficient cross channel operations in parallel computing machines using systolic arrays

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117033270B (zh) * 2023-10-08 2024-01-26 腾讯科技(深圳)有限公司 一种芯片、设备以及数据处理方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200018637A1 (en) 2018-07-12 2020-01-16 Airbus Helicopters Method of analyzing a vibratory signal derived from rotation of at least one moving part belonging to a rotary mechanism

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3533800C1 (de) 1985-09-21 1987-02-05 Hans-Werner Lang Verfahren zum Betreiben eines hochintegrierten Wellenfront-Feldrechners sowie entsprechender Wellenfront-Feldrechner
EP0428770B1 (de) 1989-11-21 1995-02-01 Deutsche ITT Industries GmbH Datengesteuerter Arrayprozessor
US5168499A (en) * 1990-05-02 1992-12-01 California Institute Of Technology Fault detection and bypass in a sequence information signal processor
US6088783A (en) 1996-02-16 2000-07-11 Morton; Steven G DPS having a plurality of like processors controlled in parallel by an instruction word, and a control processor also controlled by the instruction word
US7418536B2 (en) 2001-07-30 2008-08-26 Cisco Technology, Inc. Processor having systolic array pipeline for processing data packets
US7113505B2 (en) 2001-12-17 2006-09-26 Agere Systems Inc. Mesh architecture for synchronous cross-connects
US7120658B2 (en) 2002-05-14 2006-10-10 Nash James G Digital systolic array architecture and method for computing the discrete Fourier transform
TWI259659B (en) * 2005-05-13 2006-08-01 Ind Tech Res Inst Pipelined datapath with dynamically reconfigurable pipeline stages
US7478299B2 (en) * 2006-08-14 2009-01-13 International Business Machines Corporation Processor fault isolation
US8001361B2 (en) 2006-12-13 2011-08-16 International Business Machines Corporation Structure for a single shared instruction predecoder for supporting multiple processors
US9053681B2 (en) 2010-07-07 2015-06-09 Fotonation Limited Real-time video frame pre-processing hardware
US9626165B1 (en) 2013-09-12 2017-04-18 Altera Corporation Method and apparatus for generating systolic arrays on a target device using a high-level synthesis language
US9720646B2 (en) 2015-11-12 2017-08-01 Arm Limited Redundant representation of numeric value using overlap bits
US10241972B2 (en) 2017-03-16 2019-03-26 International Business Machines Corporation Matrix multiplication on a systolic array
US10838910B2 (en) 2017-04-27 2020-11-17 Falcon Computing Systems and methods for systolic array design from a high-level program
US20190114548A1 (en) * 2017-10-17 2019-04-18 Xilinx, Inc. Static block scheduling in massively parallel software defined hardware systems
US11042370B2 (en) * 2018-04-19 2021-06-22 Intel Corporation Instruction and logic for systolic dot product with accumulate
DE102020132088A1 (de) 2020-05-01 2021-11-04 Intel Corporation Berechnung effizienter kanalübergreifender operationen in parallelrechenmaschinen mit systolischen arrays

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200018637A1 (en) 2018-07-12 2020-01-16 Airbus Helicopters Method of analyzing a vibratory signal derived from rotation of at least one moving part belonging to a rotary mechanism

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11669490B2 (en) 2020-05-01 2023-06-06 Intel Corporation Computing efficient cross channel operations in parallel computing machines using systolic arrays

Also Published As

Publication number Publication date
CN113590198A (zh) 2021-11-02
US11669490B2 (en) 2023-06-06
US20230367740A1 (en) 2023-11-16
US20220058158A1 (en) 2022-02-24

Similar Documents

Publication Publication Date Title
DE112020000874T5 (de) Systeme und Methoden zum Aktualisieren von speicherseitigen Caches in einer Multi-GPU-Konfiguration
DE102020115026A1 (de) Systeme und Verfahren zur Tonabbildung von Bildern mit hohem Dynamikumfang für auf tiefem Lernen basierende Verarbeitung von hoher Qualität
DE112020000464T5 (de) Mehrfachkachel-grafikprozessor-rendering
DE102020121814A1 (de) Vorrichtung und Verfahren zum Verwenden von Dreieckspaaren und gemeinsam genutzten Transformationsschaltungen zum Verbessern der Strahlverfolgungsleistung
DE112018005527T5 (de) Automatisches aufwecken von leistungsdomänen fürgrafikkonfigurationsanforderungen
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE102020115680A1 (de) LESEZUSAMMENFüGUNG UND M ULTICAST-RÜCKFÜHRUNG FÜR EINEN GETEILTEN LOKALEN SPEICHER
DE102020131704A1 (de) Multikachelspeicherverwaltungsmechanismus
DE112018007634T5 (de) Vorrichtung und verfahren für eine virtualisierte anzeige
DE102020124872A1 (de) Verwendung von innere-abdeckung-informationen durch eine konservative-rasterung-pipeline zum aktivieren von earlyz für eine konservative rasterung
DE102020130865A1 (de) Anweisungen und logik für vektor-multiplikation-addition mit zero-skipping
DE102020126177A1 (de) Verfahren und vorrichtung zum planen der threadreihenfolge, um den cache-wirkungsgrad zu verbessern
DE102020130880A1 (de) Mechanismus zur partitionierung eines geteilten lokalen speichers
DE102019117545A1 (de) Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors
DE102020130184A1 (de) Optimierungsmechanismus mit spärlich besetzten matrizen
DE102020129432A1 (de) System und Verfahren zum Anpassen eines ausführbaren Objekts an eine Verarbeitungseinheit
DE102020105902A1 (de) Hardware-indexzuordnungsmechanismus
DE102020134334A1 (de) Vorrichtung und verfahren zur quantisierten konvergenten richtungsbasierten strahlsortierung
DE102019106701A1 (de) Einrichtung und Verfahren zum virtualisierten Planen von mehreren doppelten Grafik-Engines
DE102020131293A1 (de) Einrichtung und verfahren zur multi-adapter-kodierung
DE102020129625A1 (de) Seitentabellen-mapping-mechanismus
DE112018003999T5 (de) Verfahren und Vorrichtung für effiziente Verarbeitung von abgeleiteten einheitlichen Werten in einem Grafikprozessor
DE102020113789A1 (de) Asynchroner ausführungsmechanismus
DE102020113400A1 (de) Registerteilungsmechanismus

Legal Events

Date Code Title Description
R081 Change of applicant/patentee

Owner name: INTEL CORPORATION, SANTA CLARA, US

Free format text: FORMER OWNER: INTEL CORPORATION, SANTA CLARA, CALIF., US