DE102020133275A1 - Compiler-unterstützte registerdatei-schreibverringerung - Google Patents

Compiler-unterstützte registerdatei-schreibverringerung Download PDF

Info

Publication number
DE102020133275A1
DE102020133275A1 DE102020133275.0A DE102020133275A DE102020133275A1 DE 102020133275 A1 DE102020133275 A1 DE 102020133275A1 DE 102020133275 A DE102020133275 A DE 102020133275A DE 102020133275 A1 DE102020133275 A1 DE 102020133275A1
Authority
DE
Germany
Prior art keywords
execution
register
instructions
graphics
instruction
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
DE102020133275.0A
Other languages
English (en)
Inventor
Chandra S. Gurram
Gang Y. Chen
Subramaniam Maiyuran
Supratim Pal
Ashutosh Garg
Jorge E. Parra
Darin M. STARKEY
Guei-Yuan Lueh
Wei-Yu Chen
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
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102020133275A1 publication Critical patent/DE102020133275A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/20—Processor architectures; Processor configuration, e.g. pipelining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/30101—Special purpose registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/78—Architectures of general purpose stored program computers comprising a single central processing unit
    • G06F15/7839—Architectures of general purpose stored program computers comprising a single central processing unit with memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/45—Exploiting coarse grain parallelism in compilation, i.e. parallelism between groups of instructions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30032—Movement instructions, e.g. MOVE, SHIFT, ROTATE, SHUFFLE
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098—Register arrangements
    • G06F9/3012—Organisation of register space, e.g. banked or distributed register file
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30185—Instruction operation extension or modification according to one or more bits in the instruction, e.g. prefix, sub-opcode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877—Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/60—Memory management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Image Generation (AREA)
  • Executing Machine-Instructions (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Hier beschriebene Beispiele betreffen eine Software- und Hardwareoptimierung, wodurch Szenarien behandelt werden, bei denen ein Schreibvorgang in ein Register weniger als das gesamte Register betrifft. Ein Compiler erkennt Befehle, die Teilschreibvorgänge in dasselbe Register vornehmen, gruppiert diese Befehle und stellt Hardware Hinweise über das teilweise Schreiben bereit. Die Ausführungseinheit kombiniert die Ausgangsdaten für gruppierte Befehle und aktualisiert das Zielregister als Einzelschreibvorgang an Stelle mehrerer getrennter Teilschreibvorgänge.

Description

  • STAND DER TECHNIK
  • Die Erzeugung, Verarbeitung und Anzeige digitaler Bilder wird weitverbreitet von Computersystemen und von von Computern ausgeführten Anwendungen ausgeführt und eingesetzt. Beispielsweise erzeugen Smartphones, Smarthomes, Sicherheitssysteme, selbstfahrende Fahrzeuge und Computerspielanwendungen digitale Bilder oder verwenden Bildverarbeitung. In einigen Fällen werden zweidimensionale (2D-) oder dreidimensionale (3D-) Bilder von einem Computersystem erzeugt und angezeigt.
  • Grafikverarbeitungseinheiten werden üblicherweise für die Bilderzeugung und Maschinenlern- und Künstliche-Intelligenz-Anwendungen verwendet. Registerdateien in der Art allgemeiner Registerdateien (GRF), spezieller Registerdateien (SRF) und von Akkumulatorregistern (ACR) werden zum Speichern bei der Berechnung durch Ausführungseinheiten (EU) einer Grafikverarbeitungseinheit (GPU) verwendeter Daten verwendet. Teilaktualisierungen einer Registerdatei verschwenden verfügbare Bandbreite. Sie können ferner Lese-Modifizier-Schreiboperationen herbeiführen, die Registerbandbreite und Strom verbrauchen.
  • Figurenliste
  • Es zeigen:
    • 1 ein Blockdiagramm eines Verarbeitungssystems gemäß einer Au sführungsform,
    • die 2A - 2D Rechensysteme und Grafikprozessoren, die von hier beschriebenen Ausführungsformen bereitgestellt werden,
    • die 3A - 3C Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die von hier beschriebenen Ausführungsformen bereitgestellt werden,
    • 4 ein Blockdiagramm einer Grafikverarbeitungs-Engine eines Grafikprozessors gemäß einigen Ausführungsformen,
    • die 5A - 5B eine Thread-Ausführungslogik mit einem Array von Verarbeitungselementen, die in einem Grafikprozessorkern verwendet werden, gemäß hier beschriebenen Ausführungsformen,
    • 6 eine zusätzliche Ausführungseinheit gemäß einer Ausführungsform,
    • 7 ein Blockdiagramm von Grafikprozessor-Befehlsformaten gemäß einigen Ausführungsformen,
    • 8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors,
    • 9A ein Blockdiagramm eines Grafikprozessor-Befehlsformats gemäß einigen Ausführungsformen,
    • 9B ein Blockdiagramm einer Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform,
    • 10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einigen Ausführungsformen,
    • 11A ist ein Blockdiagramm eines IP-Kernentwicklungssystems, das für die Herstellung einer integrierten Schaltung zur Ausführung von Operationen gemäß einer Ausführungsform verwendet werden kann,
    • 11B eine seitliche Schnittansicht einer Integrierte-Schaltung-Baugruppenanordnung gemäß einigen hier beschriebenen Ausführungsformen,
    • 11C eine Baugruppenanordnung, die mehrere Einheiten mit einem Substrat verbundener Hardwarelogik-Chiplets aufweist,
    • 11D eine Baugruppenanordnung, die austauschbare Chiplets aufweist, gemäß einer Ausführungsform,
    • die 12, 13A und 13B beispielhafte integrierte Schaltungen und zugeordnete Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden können, gemäß verschiedenen hier beschriebenen Ausführungsformen,
    • 14 ein beispielhaftes System,
    • 15 eine bildliche Darstellung einer Datenverschiebung,
    • 16 ein Beispiel einer von einer Ausführungseinheit (EU) verwendeten vereinfachten Mikroarchitektur,
    • 17 eine beispielhafte Darstellung der Verwendung eines Puffers,
    • 18 eine Datenverschiebung für eine Gepackte-Bytes-Wandlung,
    • 19 eine beispielhafte Implementation eines Puffers,
    • 20 einen beispielhaften Prozess und
    • 21 einen beispielhaften Prozess.
  • DETAILLIERTE BESCHREIBUNG
  • In der folgenden Beschreibung werden für die Zwecke der Erklärung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der Ausführungsformen der nachstehend beschriebenen Erfindung bereitzustellen. Fachleute werden jedoch verstehen, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten verwirklicht werden können. In anderen Fällen sind wohlbekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um das Unklarmachen der zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
  • Systemüberblick
  • 1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. Das System 100 kann in einem Einzelprozessor-Desktopsystem, einem Mehrprozessor-Workstationsystem oder einem Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 verwendet werden. Gemäß einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in eine integrierte System-on-a-Chip(SoC)-Schaltung zur Verwendung in mobilen, handgehaltenen oder eingebetteten Vorrichtungen beispielsweise innerhalb von Internet-of-Things(IoT)-Vorrichtungen mit einer drahtgebundenen oder drahtlosen Verbindbarkeit mit einem lokalen oder Weitbereichsnetz aufgenommen ist.
  • Gemäß einer Ausführungsform kann das System 100 Folgendes aufweisen, damit koppeln oder darin integriert sein: eine serverbasierte Spielplattform, eine Spielkonsole, einschließlich einer Spiel- und Medienkonsole, eine mobile Spielkonsole, eine handgehaltene Spielkonsole oder eine Online-Spielkonsole. Gemäß einigen Ausführungsformen ist das System 100 Teil eines Mobiltelefons, eines Smartphones, einer Tablet-Rechenvorrichtung oder einer mobilen mit dem Internet verbundenen Vorrichtung in der Art eines Laptops mit einer geringen inneren Speicherkapazität. Das Verarbeitungssystem 100 kann auch Folgendes aufweisen, damit gekoppelt sein oder darin integriert sein: eine tragbare Vorrichtung in der Art einer tragbaren Smartwatch-Vorrichtung, einer Smart-Brille oder eines Kleidungsstücks, das zusätzliche Augmented-Reality(AR)- oder Virtual-Reality(VR)-Merkmale aufweist, um visuelle, auditive oder taktile Ausgaben zur Ergänzung visueller, auditiver oder taktiler Erfahrungen der realen Welt bereitzustellen oder auf andere Weise Text, Audio, Grafiken, Video, holographische Bilder oder Video oder eine taktile Rückmeldung bereitzustellen, eine andere Augmented-Reality(AR)-Vorrichtung oder eine andere Virtual-Reality(VR)-Vorrichtung. Gemäß einigen Ausführungsformen weist das Verarbeitungssystem 100 ein Fernsehgerät oder eine Settop-Box-Vorrichtung auf oder ist Teil davon. Gemäß einer Ausführungsform kann das System 100 ein selbstfahrendes Fahrzeug in der Art eines Busses, eines Sattelschleppers, eines Personenkraftfahrzeugs, eines Flugzeugs oder Gleiters mit Motorantrieb oder mit elektrischem Leistungszyklus (oder eine Kombination davon) aufweisen, damit koppeln oder darin integriert sein. Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die um das Fahrzeug erfasste Umgebung zu verarbeiten.
  • Gemäß einigen Ausführungsformen weisen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zur Verarbeitung von Befehlen auf, die, wenn sie ausgeführt werden, Operationen für System- oder Benutzersoftware ausführen. Gemäß einigen Ausführungsformen ist wenigstens einer von dem einen oder den mehreren Prozessorkernen 107 dafür ausgelegt, einen spezifischen Befehlssatz 109 zu verarbeiten. Gemäß einigen Ausführungsformen kann der Befehlssatz 109 eine Berechnung mit einem komplexen Befehlssatz (CISC), eine Berechnung mit einem reduzierten Befehlssatz (RISC) oder eine Berechnung durch ein sehr langes Befehlswort (VLIW) erleichtern. Ein oder mehrere Prozessorkerne 107 können einen anderen Befehlssatz 109 verarbeiten, der Befehle zur Erleichterung der Emulation anderer Befehlssätze aufweisen kann. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen in der Art eines digitalen Signalprozessors (DSP) aufweisen.
  • Gemäß einigen Ausführungsformen weist der Prozessor 102 einen Cache-Speicher 104 auf. Abhängig von der Architektur kann der Prozessor 102 einen einzigen internen Cache oder mehrere Ebenen eines internen Caches aufweisen. Gemäß einigen Ausführungsformen wird der Cache-Speicher zwischen verschiedenen Komponenten des Prozessors 102 geteilt. Gemäß einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (beispielsweise einen Level-3(L3)-Cache oder Last-Level-Cache (LLC)) (nicht dargestellt), die unter Verwendung bekannter Cache-Kohärenztechniken zwischen Prozessorkernen 107 geteilt werden können. Eine Registerdatei 106 kann zusätzlich in den Prozessor 102 aufgenommen sein und verschiedene Registertypen zum Speichern verschiedener Datentypen aufweisen (beispielsweise Ganzzahlregister, Gleitkommaregister, Statusregister und ein Befehlszeigerregister). Einige Register können Register für allgemeine Zwecke sein, während andere Register für den Entwurf des Prozessors 102 spezifisch sein können.
  • Gemäß einigen Ausführungsformen sind ein oder mehrere Prozessoren 102 mit einem oder mehreren Schnittstellenbussen 110 gekoppelt, um Kommunikationssignale in der Art von Adress-, Daten- oder Steuersignalen zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Der Schnittstellenbus 110 kann gemäß einer Ausführungsform ein Prozessorbus in der Art einer Version des Direct-Media-Interface(DMI)-Busses sein. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheriekomponentenverbindungsbusse (beispielsweise PCI, PCI-Express), Speicherbusse oder andere Typen von Schnittstellenbussen einschließen. Gemäß einer Ausführungsform weisen der eine oder die mehreren Prozessoren 102 eine integrierte Speichersteuereinrichtung 116 und einen Plattformsteuereinrichtungs-Hub 130 auf. Die Speichersteuereinrichtung 116 erleichtert die Kommunikation zwischen einer Speichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuereinrichtungs-Hub (PCH) 130 Verbindungen zu E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
  • Die Speichervorrichtung 120 kann eine Dynamischer-Direktzugriffsspeicher-(DRAM)-Vorrichtung, eine Statischer-Direktzugriffsspeicher(SRAM)-Vorrichtung, eine Flash-Speichervorrichtung, eine Phasenänderungs-Speichervorrichtung oder eine andere Speichervorrichtung mit einer geeigneten Funktionsweise, um als Prozessspeicher zu dienen, sein. Gemäß einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 wirken, um Daten 122 und Befehle 121 zu speichern, die zu verwenden sind, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Die Speichersteuereinrichtung 116 koppelt auch mit einem optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen auszuführen. Gemäß einigen Ausführungsformen können Grafik-, Medien- und/oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, der ein Coprozessor ist, welcher dafür ausgelegt sein kann, einen spezialisierten Satz von Grafik-, Medien- oder Rechenoperationen auszuführen. Beispielsweise ist der Beschleuniger 112 gemäß einer Ausführungsform ein Matrixmultiplikationsbeschleuniger, der verwendet wird, um Maschinenlern- oder Rechenoperationen zu optimieren. Gemäß einer Ausführungsform ist der Beschleuniger 112 ein Raytracing-Beschleuniger, der verwendet werden kann, um Raytracing-Operationen in Zusammenarbeit mit dem Grafikprozessor 108 auszuführen. Gemäß einer Ausführungsform kann an Stelle des Beschleunigers 112 oder in Zusammenarbeit mit diesem ein externer Beschleuniger 119 verwendet werden.
  • Gemäß einigen Ausführungsformen kann eine Anzeigevorrichtung 111 mit dem einen oder den mehreren Prozessoren 102 verbinden. Die Anzeigevorrichtung 111 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie bei einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder eine externe Anzeigevorrichtung, die über eine Anzeigeschnittstelle (beispielsweise DisplayPort, embedded DisplayPort, MIPI, HDMI usw.) angebracht ist, sein. Gemäß einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf angebrachte Anzeige (HMD) in der Art einer stereoskopischen Anzeigevorrichtung zur Verwendung bei Virtual-Reality(VR)-Anwendungen oder Augmented-Reality(AR)-Anwendungen sein.
  • Gemäß einigen Ausführungsformen ermöglicht der Plattformsteuereinrichtungs-Hub 130 Peripheriegeräten, sich über einen schnellen E/A-Bus mit der Speichervorrichtung 120 und dem Prozessor 102 zu verbinden. Die E/A-Peripheriegeräte umfassen eine Audiosteuereinrichtung 146, eine Netzsteuereinrichtung 134, eine Firmwareschnittstelle 128, einen Drahtlostransceiver 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (beispielsweise einen nichtflüchtigen Speicher, einen flüchtigen Speicher, ein Festplattenlaufwerk, einen Flash-Speicher, NAND, 3D-NAND, 3D-XPoint usw.), sind jedoch nicht darauf beschränkt. Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (beispielsweise SATA) oder über einen Peripheriebus in der Art eines Peripheriekomponentenverbindungsbusses (beispielsweise PCI, PCI-Express) verbinden. Die Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdrucksensoren einschließen. Der Drahtlostransceiver 126 kann ein WiFi-Transceiver, ein Bluetooth-Transceiver oder ein Mobilnetz-Transceiver in der Art eines 3G-, 4G-, 5G- oder Long-Term-Evolution(LTE)-Transceivers sein. Die Firmware-Schnittstelle 128 ermöglicht eine Kommunikation mit System-Firmware und kann beispielsweise eine einheitliche erweiterbare Firmware-Schnittstelle (UEFI) sein. Die Netzsteuereinrichtung 134 kann eine Netzverbindung mit einem festverdrahteten Netz ermöglichen. Gemäß einigen Ausführungsformen koppelt eine Hochleistungs-Netzsteuereinrichtung (nicht dargestellt) mit dem Schnittstellenbus 110. Die Audiosteuereinrichtung 146 ist gemäß einer Ausführungsform eine Mehrkanal-High-Definition-Audiosteuereinrichtung. Gemäß einer Ausführungsform weist das System 100 eine optionale Legacy-E/A-Steuereinrichtung 140 zur Kopplung von Legacy-(beispielsweise Personal System 2 (PS/2))-Vorrichtungen mit dem System auf. Der Plattformsteuereinrichtungs-Hub 130 kann auch mit einer oder mehreren Universeller-Serieller-Bus(USB)-Steuereinrichtungen 142 zur Verbindung mit Eingabevorrichtungen in der Art von Tastatur-und-Maus-Kombinationen 143, einer Kamera 144 oder anderer USB-Eingabevorrichtungen verbinden.
  • Es sei bemerkt, dass das dargestellte System 100 als beispielhaft und nicht als einschränkend anzusehen ist und dass auch andere Typen von Datenverarbeitungssystemen, die anders ausgelegt sind, verwendet werden können. Beispielsweise kann eine Instanz der Speichersteuereinrichtung 116 und des Plattformsteuereinrichtungs-Hubs 130 in einen diskreten externen Grafikprozessor in der Art des externen Grafikprozessors 118 integriert sein. Gemäß einer Ausführungsform können sich der Plattformsteuereinrichtungs-Hub 130 und/oder die Speichersteuereinrichtung 116 außerhalb des einen oder der mehreren Prozessoren 102 befinden. Beispielsweise kann das System 100 eine externe Speichersteuereinrichtung 116 und einen Plattformsteuereinrichtungs-Hub 130 aufweisen, die als Speichersteuereinrichtungs-Hub und Peripheriesteuereinrichtungs-Hub innerhalb eines System-Chipsatzes, der in Kommunikation mit dem einen oder den mehreren Prozessoren 102 steht, ausgelegt sein können.
  • Beispielsweise können Leiterplatten („Sleds“) verwendet werden, auf denen Komponenten in der Art von CPUs, Speicher und andere Komponenten angeordnet sind, welche für eine erhöhte thermische Leistungsfähigkeit ausgelegt sind. Bei einigen Beispielen befinden sich Verarbeitungskomponenten in der Art der Prozessoren auf der Oberseite eines Sleds, während sich nahe gelegener Speicher in der Art von DIMM-Modulen an der Unterseite des Sleds befindet. Infolge der durch diesen Entwurf bereitgestellten verbesserten Luftströmung können die Komponenten mit höheren Frequenzen und Leistungsniveaus arbeiten als bei typischen Systemen, wodurch die Leistungsfähigkeit erhöht wird. Ferner sind die Sleds dafür ausgelegt, blind mit Strom- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, aufgerüstet, neu installiert und/oder ersetzt zu werden. Ähnlich sind einzelne Komponenten, die sich auf den Sleds befinden, wie Prozessoren, Beschleuniger, Speicher und Datenspeichervorrichtungen, dafür ausgelegt, infolge ihres erhöhten Abstands voneinander leicht aufgerüstet zu werden. Gemäß der der Erläuterung dienenden Ausführungsform weisen die Komponenten zusätzlich Hardwareattestierungsmerkmale zum Beweisen ihrer Authentizität auf.
  • Ein Rechenzentrum kann eine Einzelnetzarchitektur („Fabric“) verwenden, die mehrere andere Netzarchitekturen einschließlich Ethernet und Omni-Path einschließt. Die Sleds können über optische Fasern, die eine höhere Bandbreite und niedrigere Latenz bereitstellen als typische Twisted-Pair-Kabel (beispielsweise Kategorie 5, Kategorie 5e, Kategorie 6 usw.), mit Switches gekoppelt sein. Infolge der Zwischenverbindungen mit hoher Bandbreite und niedriger Latenz und der Netzarchitektur kann das Rechenzentrum bei der Verwendung Ressourcen in der Art von Speicher, Beschleunigern (beispielsweise GPUs, Grafikbeschleunigern, FPGAs, ASICs, neuronale Netze und/oder Beschleuniger für künstliche Intelligenz usw.) und Datenspeicher-Laufwerken, die physisch nicht aggregiert sind, poolen und sie Rechenressourcen (beispielsweise Prozessoren) nach Bedarf bereitstellen, wodurch es den Rechenressourcen ermöglicht wird, auf die gepoolten Ressourcen zuzugreifen, als ob sie lokal wären.
  • Eine Stromversorgung oder -quelle kann dem System 100 oder einer hier beschriebenen Komponente oder einem hier beschriebenen System Spannung und/oder Strom bereitstellen. Bei einem Beispiel weist die Stromversorgung einen AC-zu-DC(Wechselstromzu-Gleichstrom)-Adapter zum Einstecken in eine Wandsteckdose auf. Dieser Wechselstrom kann von einer Stromquelle auf der Grundlage erneuerbarer Energie (beispielsweise Solarenergie) stammen. Bei einem Beispiel weist die Stromquelle eine Gleichstromquelle in der Art eines externen AC-zu-DC-Wandlers auf. Bei einem Beispiel weist die Stromquelle oder die Stromversorgung Drahtlosladehardware zum Laden durch die Nähe zu einem ladenden Feld auf. Bei einem Beispiel kann die Stromquelle eine innere Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Stromversorgung, eine Solarstromversorgung oder eine Brennstoffzellenquelle aufweisen.
  • Die 2A - 2D zeigen Rechensysteme und Grafikprozessoren, die durch hier beschriebene Ausführungsformen bereitgestellt werden. Die Elemente aus den 2A - 2D, welche die gleichen Bezugszahlen (oder Namen) aufweisen wie die Elemente einer anderen hier angeführten Figur, können ähnlich zu den hier beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
  • 2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A - 202N, einer integrierten Speichersteuereinrichtung 214 und einem integrierten Grafikprozessor 208. Der Prozessor 200 kann zusätzliche Kerne bis zum zusätzlichen Kern 202N und einschließlich diesem aufweisen, wie durch die in gestrichelten Linien angegebenen Kästchen repräsentiert ist. Jeder der Prozessorkerne 202A - 202N weist eine oder mehrere interne Cache-Einheiten 204A - 204N auf. Gemäß einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere geteilte gecachte Einheiten 206. Die internen Cache-Einheiten 204A - 204N und die geteilten Cache-Einheiten 206 repräsentieren eine Cache-Speicherhierarchie innerhalb des Prozessors 200. Die Cache-Speicherhierarchie kann wenigstens eine Ebene eines Befehls- und Daten-Caches innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen eines geteilten Caches mittlerer Ebene in der Art eines Level-2(L2)-, Level-3(L3)-, Level-4(L4)-Caches oder einer anderen Cache-Ebene aufweisen, wobei die höchste Cache-Ebene vor dem externen Speicher als LLC klassifiziert wird. Gemäß einigen Ausführungsformen hält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cache-Einheiten 206 und 204A - 204N aufrecht.
  • Gemäß einigen Ausführungsformen kann der Prozessor 200 auch einen Satz aus einer oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 aufweisen. Die eine oder die mehreren Bussteuereinheiten 216 verwalten einen Satz von Peripheriebussen in der Art eines oder mehrerer PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 stellt den verschiedenen Prozessorkomponenten eine Verwaltungsfunktionalität bereit. Gemäß einigen Ausführungsformen weist der Systemagentenkern 210 eine oder mehrere integrierte Speichersteuereinrichtungen 214 zur Behandlung des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht dargestellt) auf.
  • Gemäß einigen Ausführungsformen weisen einer oder mehrere der Prozessorkerne 202A - 202N eine Unterstützung für ein gleichzeitiges Multi-Threading auf. Gemäß einer solchen Ausführungsform weist der Systemagentenkern 210 Komponenten zur Koordination und für den Betrieb der Kerne 202A - 202N während der Multi-Thread-Verarbeitung auf. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) aufweisen, die Logik und Komponenten zum Regeln des Leistungszustands der Prozessorkerne 202A - 202N und des Grafikprozessors 208 aufweist.
  • Gemäß einigen Ausführungsformen weist der Prozessor 200 zusätzlich einen Grafikprozessor 208 zur Ausführung von Grafikverarbeitungsoperationen auf. Gemäß einigen Ausführungsformen koppelt der Grafikprozessor 208 mit dem Satz geteilter Cache-Einheiten 206 und dem Systemagentenkern 210, einschließlich der einen oder der mehreren integrierten Speichersteuereinrichtungen 214. Gemäß einigen Ausführungsformen weist der Systemagentenkern 210 auch eine Anzeigesteuereinrichtung 211 zur Steuerung der Grafikprozessorausgabe an eine oder mehrere angeschlossene Anzeigen auf. Gemäß einigen Ausführungsformen kann die Anzeigesteuereinrichtung 211 auch ein getrenntes Modul sein, das über wenigstens eine Zwischenverbindung mit dem Grafikprozessor gekoppelt ist, oder in den Grafikprozessor 208 integriert sein.
  • Gemäß einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 zur Verbindung der internen Komponenten des Prozessors 200 verwendet. Es kann jedoch auch eine alternative Verbindungseinheit verwendet werden, wie eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich auf dem Fachgebiet wohlbekannter Techniken. Gemäß einigen Ausführungsformen koppelt der Grafikprozessor 208 über eine E/A-Strecke 213 mit der Ringzwischenverbindung 212.
  • Die beispielhafte E/A-Strecke 213 repräsentiert wenigstens eine von mehreren Ausführungen von E/A-Verbindungen, einschließlich einer Baugruppen-E/A-Verbindung, welche die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218 in der Art eines eDRAM-Moduls erleichtert. Gemäß einigen Ausführungsformen können die jeweiligen Prozessorkerne 202A - 202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als geteilten Last-Level-Cache verwenden.
  • Gemäß einigen Ausführungsformen sind die Prozessorkerne 202A - 202N homogene Kerne, welche die gleiche Befehlssatzarchitektur ausführen. Gemäß einer anderen Ausführungsform sind die Prozessorkerne 202A - 202N in Bezug auf die Befehlssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A - 202N einen ersten Befehlssatz ausführen, während wenigstens einer der anderen Kerne eine Teilmenge des ersten Befehlssatzes oder einen anderen Befehlssatz ausführt. Gemäß einer Ausführungsform sind die Prozessorkerne 202A - 202N in Bezug auf die Mikroarchitektur heterogen, wobei einer oder mehrere der Kerne mit einem höheren Stromverbrauch mit einem oder mehreren Leistungskernen mit einem geringeren Stromverbrauch koppeln. Gemäß einigen Ausführungsformen sind die Prozessorkerne 202A - 202N in Bezug auf die Rechenfähigkeit heterogen. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als integrierte SoC-Schaltung mit den dargestellten Komponenten zusätzlich zu anderen Komponenten implementiert werden.
  • 2B ist ein Blockdiagramm einer Hardwarelogik eines Grafikprozessorkerns 219 gemäß einigen hier beschriebenen Ausführungsformen. Elemente aus 2B, welche die gleichen Bezugszahlen (oder Namen) aufweisen wie die Elemente einer anderen hier angeführten Figur, können ähnlich zu den hier beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Der Grafikprozessorkern 219, der manchmal als Kern-Slice bezeichnet wird, kann durch einen oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors gegeben sein. Der Grafikprozessorkern 219 dient als Beispiel eines Grafikkern-Slices, und ein hier beschriebener Grafikprozessor kann auf der Grundlage von Ziel-Stromverbrauchs- und Leistungsfähigkeitsrichtlinien mehrere Grafikkern-Slices aufweisen. Jeder Grafikprozessorkern 219 kann einen Festfunktionsblock 230 aufweisen, der mit mehreren auch als Unter-Slices, die modulare Blöcke von Logik für allgemeine Zwecke und Festfunktionslogik aufweisen, bezeichneten Unterkernen 221A - 221F gekoppelt ist.
  • Gemäß einigen Ausführungsformen weist der Festfunktionsblock 230 eine Geometrie/Festfunktions-Pipeline 231 auf, die beispielsweise bei Grafikprozessorimplementationen mit einer geringeren Leistungsfähigkeit und/oder einem geringeren Stromverbrauch von allen Unterkernen im Grafikprozessorkern 219 geteilt werden kann. Gemäß verschiedenen Ausführungsformen weist die Geometrie/Festfunktions-Pipeline 231 eine 3D-Festfunktions-Pipeline (beispielsweise 3D-Pipeline 312, wie in 3 und 4, wie nachstehend beschrieben), eine Video-Frontend-Einheit, einen Thread-Spawner und einen Thread-Abfertiger und einen Unified-Return-Buffer-Manager, der Unified Return Buffers (beispielsweise den Unified Return Buffer 418 in 4, wie nachstehend beschrieben) behandelt, auf.
  • Gemäß einer Ausführungsform weist der Festfunktionsblock 230 auch eine Grafik-SoC-Schnittstelle 232, eine Grafikmikrosteuereinrichtung 233 und eine Medien-Pipeline 234 auf. Die Grafik-SoC-Schnittstelle 232 stellt eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb einer System-on-a-Chipintegrierten-Schaltung bereit. Die Grafikmikrosteuereinrichtung 233 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 219, einschließlich Thread-Abfertigung, -Planung und -Unterbrechung, zu behandeln. Die Medien-Pipeline 234 (beispielsweise die Medien-Pipeline 316 aus 3 und 4) weist Logik zur Vereinfachung der Decodierung, Codierung, Vorverarbeitung und/oder Nachverarbeitung von Multimediadaten, einschließlich Bild- und Videodaten, auf. Die Medien-Pipeline 234 implementiert Medienoperationen durch Anfragen an Rechen- oder Abtastlogik innerhalb der Unterkeme 221 - 221F.
  • Gemäß einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 dem Grafikprozessorkern 219, mit Anwendungsprozessorkernen (beispielsweise CPUs) für allgemeine Zwecke und/oder anderen Komponenten innerhalb eines SoCs zu kommunizieren, einschließlich Speicherhierarchieelementen in der Art eines geteilten Last-Level-Cache-Speichers, des System-RAMs und/oder eines eingebetteten On-Chip- oder On-Package-DRAMs. Die SoC-Schnittstelle 232 kann auch eine Kommunikation mit Festfunktionsvorrichtungen innerhalb des SoCs in der Art von Kamerabilderzeugungs-Pipelines ermöglichen, und sie ermöglicht die Verwendung von globalen atomaren Speichereinheiten, die zwischen dem Grafikprozessorkern 219 und CPUs innerhalb des SoCs geteilt werden können, und/oder implementiert diese. Die SoC-Schnittstelle 232 kann auch Stromverwaltungssteuerungen für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einer Takt-Domäne des Grafikkerns 219 und anderen Takt-Domänen innerhalb des SoCs ermöglichen. Gemäß einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 den Empfang von Befehlspuffern von einem Befehls-Streamer und einem globalen Thread-Abfertiger, die dafür ausgelegt sind, Befehle und Anweisungen jedem von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors bereitzustellen. Die Befehle und Anweisungen können zur Medien-Pipeline 234, wenn Medienoperationen auszuführen sind, oder zu einer Geometrie- und Festfunktions-Pipeline (beispielsweise Geometrie- und Festfunktions-Pipeline 231, Geometrie- und Festfunktions-Pipeline 237), wenn Grafikverarbeitungsoperationen auszuführen sind, übermittelt werden.
  • Die Grafikmikrosteuereinrichtung 233 kann dafür ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 auszuführen. Gemäß einer Ausführungsform kann die Grafikmikrosteuereinrichtung 233 eine Grafik- und/oder Rechenarbeitslastplanung auf den verschiedenen parallelen Grafik-Engines innerhalb der Ausführungseinheits(EU)-Arrays 222A - 222F, 224A - 224F innerhalb der Unterkerne 221A - 221F ausführen. Bei diesem Planungsmodell kann Host-Software, die auf einem CPU-Kern eines den Grafikprozessorkern 219 aufweisenden SoCs ausgeführt wird, Arbeitslasten bei einem von mehreren Grafikprozessor-Benachrichtigungssignalen, wodurch eine Planungsoperation an der geeigneten Grafik-Engine herbeigeführt wird, zuweisen. Planungsoperationen umfassen das Bestimmen, welche Arbeitslast als nächstes auszuführen ist, das Übermitteln einer Arbeitslast zu einem Befehls-Streamer, das Unterbrechen existierender Arbeitslasten, die auf einer Maschine laufen, das Überwachen des Fortschritts einer Arbeitslast und das Benachrichtigen von Host-Software, wenn eine Arbeitslast abgeschlossen wurde. Gemäß einer Ausführungsform kann die Grafikmikrosteuereinrichtung 233 auch Zustände mit geringer Leistungsaufnahme oder Bereitschaftszustände für den Grafikprozessorkern 219 erleichtern, wodurch der Grafikprozessorkern 219 mit der Fähigkeit versehen wird, Register innerhalb des Grafikprozessorkerns 219 über Zustandsübergänge mit geringer Leistungsaufnahme unabhängig vom Betriebssystem und/oder von Grafiktreibersoftware am System einzusparen und wiederherzustellen.
  • Der Grafikprozessorkern 219 kann eine größere oder kleinere Anzahl als die dargestellten Unterkeme 221A - 221F und bis zu N modulare Unterkeme aufweisen. Für jeden Satz von N Unterkernen kann der Grafikprozessorkern 219 auch eine Geteilte-Funktionen-Logik 235, einen geteilten und/oder Cache-Speicher 236, eine Geometrie/Festfunktions-Pipeline 237 sowie eine zusätzliche Festfunktionslogik 238 zur Beschleunigung verschiedener Grafik- und Rechenverarbeitungsoperationen aufweisen. Die Geteilte-Funktionen-Logik 235 kann Logikeinheiten in Zusammenhang mit der Geteilte-Funktionen-Logik 420 aus 4 (beispielsweise eine Sampler-, Mathematik- und/oder Inter-Thread-Kommunikationslogik) aufweisen, die von den jeweiligen N Unterkernen innerhalb des Grafikprozessorkerns 219 geteilt werden können. Der geteilte und/oder Cache-Speicher 236 kann ein Last-Level-Cache für den Satz von N Unterkernen 221A - 221F innerhalb des Grafikprozessorkerns 219 sein und auch als geteilter Speicher, der von mehreren Unterkernen zugänglich ist, dienen. Die Geometrie/Festfunktions-Pipeline 237 kann an Stelle der Geometrie/Festfunktions-Pipeline 231 innerhalb des Festfunktionsblocks 230 aufgenommen sein und die gleichen oder ähnliche Logikeinheiten aufweisen.
  • Gemäß einer Ausführungsform weist der Grafikprozessorkern 219 eine zusätzliche Festfunktionslogik 238 auf, die verschiedene Festfunktions-Beschleunigungslogiken zur Verwendung durch den Grafikprozessorkern 219 aufweisen kann. Gemäß einer Ausführungsform weist die zusätzliche Festfunktionslogik 238 eine zusätzliche Geometrie-Pipeline zur Verwendung beim Nur-Positions-Shading auf. Beim Nur-Positions-Shading existieren zwei Geometrie-Pipelines, nämlich die Vollständige-Geometrie-Pipeline innerhalb der Geometrie/Festfunktions-Pipeline 238, 231 und eine Aussortier-Pipeline, die eine zusätzliche Geometrie-Pipeline ist, die in der zusätzlichen Festfunktionslogik 238 enthalten sein kann. Gemäß einer Ausführungsform ist die Aussortier-Pipeline eine herunterskalierte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die Aussortier-Pipeline können verschiedene Instanzen derselben Anwendung ausführen, wobei jede Instanz einen getrennten Kontext aufweist. Ein Nur-Positions-Shading kann lange Aussortierläufe verworfener Dreiecke verbergen, wodurch das Shading in manchen Fällen früher abgeschlossen werden kann. Beispielsweise und gemäß einer Ausführungsform kann die Aussortier-Pipeline-Logik innerhalb der zusätzlichen Festfunktionslogik 238 Positions-Shader parallel mit der Hauptanwendung ausführen und erzeugt im Allgemeinen kritische Ergebnisse schneller als die vollständige Pipeline, weil die Aussortier-Pipeline nur die Positionsattribute der Vertices abruft und shadet, ohne eine Rasterung und ein Rendern der Pixel in den Framebuffer auszuführen. Die Aussortier-Pipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke ohne Berücksichtigung, ob diese Dreiecke aussortiert wurden, zu berechnen. Die vollständige Pipeline (die in diesem Fall als Replay-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen für das Überspringen der aussortierten Dreiecke verwenden, um nur die sichtbaren Dreiecke zu shaden, die schließlich an die Rasterungsphase übergeben werden.
  • Gemäß einer Ausführungsform kann die zusätzliche Festfunktionslogik 238 auch eine Maschinenlern-Beschleunigungslogik in der Art einer Festfunktions-Matrixmultiplikationslogik für Implementationen einschließlich Optimierungen für das Training und das Inferencing beim Maschinenlernen aufweisen.
  • Innerhalb jedes Grafikunterkerns 221A - 221F befindet sich ein Satz von Ausführungsressourcen, die zur Ausführung von Grafik-, Medien- und Rechenoperationen ansprechend auf Anforderungen durch Grafik-Pipeline, Medien-Pipeline oder Shader-Programme verwendet werden können. Die Grafikunterkerne 221A - 221F weisen mehrere EU-Arrays 222A - 222F, 224A - 224F, eine Thread-Abfertigungs- und Inter-Thread-Kommunikations(TD/IC)-Logik 223A - 223F, einen 3D(beispielsweise Textur)-Sampler 225A - 225F, einen Medien-Sampler 206A - 206F, einen Shader-Prozessor 227A - 227F und einen geteilten lokalen Speicher (SLM) 228A - 228F auf. Die EU-Arrays 222A - 222F, 224A - 224F weisen jeweils mehrere Ausführungseinheiten auf, wobei es sich um Grafikverarbeitungseinheiten für allgemeine Zwecke handelt, die in der Lage sind, Gleitkomma- und Ganzzahl/Festpunkt-Logikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen, auszuführen. Die TD/IC-Logik 223A - 223F führt lokale Thread-Abfertigungs- und Thread-Steueroperationen für die Ausführungseinheiten innerhalb eines Unterkerns aus und erleichtert die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Unterkerns ausgeführt werden. Der 3D-Sampler 225A - 225F kann Textur- oder andere sich auf 3D-Grafiken beziehende Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten auf verschiedene Arten auf der Grundlage eines konfigurierten Abtastzustands und des Texturformats in Zusammenhang mit einer gegebenen Textur lesen. Der Medien-Sampler 206A - 206F kann ähnliche Leseoperationen auf der Grundlage des Typs und des Formats in Zusammenhang mit Mediendaten ausführen. Gemäß einer Ausführungsform kann jeder Grafikunterkern 221A - 221F alternativ einen vereinheitlichten 3D- und Medien-Sampler aufweisen. Threads, die auf den Ausführungseinheiten innerhalb jedes der Unterkerne 221A - 221F ausgeführt werden, können den geteilten lokalen Speicher 228A - 228F innerhalb jedes Unterkerns verwenden, um zu ermöglichen, dass Threads, die innerhalb einer Threads-Gruppe ausgeführt werden, unter Verwendung eines gewöhnlichen Pools eines On-Chip-Speichers ausgeführt werden.
  • 2C zeigt eine Grafikverarbeitungseinheit (GPU) 239, die dedizierte Sätze in Mehrkerngruppen 240A - 240N angeordneter Grafikverarbeitungsressourcen aufweist. Wenngleich nur die Einzelheiten einer einzigen Mehrkerngruppe 240A bereitgestellt werden, ist zu verstehen, dass die anderen Mehrkerngruppen 240B - 240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen versehen sein können.
  • Wie dargestellt, kann eine Mehrkerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensorkernen 244 und einen Satz von Raytracing-Kernen 245 aufweisen. Ein Planer/Abfertiger 241 plant die Grafik-Threads zur Ausführung auf den verschiedenen Kernen 243, 244, 245 und fertigt diese ab. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 verwendet werden, wenn sie die Grafik-Threads ausführen. Diese können beispielsweise Natürliche-Zahlen-Register zum Speichern von Werten natürlicher Zahlen, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern paketierter Datenelemente (Datenelemente natürlicher Zahlen und/oder Gleitkommawerte) und Kachelregister zum Speichern von Tensor-/Matrixwerten einschließen. Gemäß einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
  • Ein oder mehrere kombinierte Level-1(L1)-Caches und geteilte Speichereinheiten 247 speichern Grafikdaten in der Art von Texturdaten, Vertexdaten, Pixeldaten, Ray-Daten, Begrenzungsvolumendaten usw. lokal innerhalb jeder Mehrkerngruppe 240A. Eine oder mehrere Textureinheiten 247 können auch verwendet werden, um Texturierungsoperationen auszuführen, wie eine Texturabbildung und ein Textur-Sampling. Ein Level-2(L2)-Cache 253, der von allen Mehrkerngruppen 240A - 240N oder einer Teilmenge davon geteilt verwendet wird, speichert Grafikdaten und/oder Befehle für mehrere gleichzeitige Grafik-Threads. Wie dargestellt, kann der L2-Cache 253 von mehreren Mehrkerngruppen 240A - 240N geteilt verwendet werden. Eine oder mehrere Speichersteuereinrichtungen 248 koppeln die GPU 239 mit einem Speicher 249, wobei es sich um einen Systemspeicher (beispielsweise DRAM) und/oder einen dedizierten Grafikspeicher (beispielsweise GDDR6-Speicher) handeln kann.
  • Die Ein-/Ausgabe(E/A)-Schaltungsanordnung 250 koppelt die GPU 239 mit einer oder mehreren E/A-Vorrichtungen 252 in der Art digitaler Signalprozessoren (DSP), Netzsteuereinrichtungen oder Benutzereingabevorrichtungen. Eine On-Chip-Zwischenverbindung kann verwendet werden, um die E/A-Vorrichtungen 252 mit der GPU 239 und dem Speicher 249 zu koppeln. Eine oder mehrere E/A-Speicherverwaltungseinheiten (IOMMUs) 251 der E/A-Schaltungsanordnung 250 koppeln die E/A-Vorrichtungen 252 direkt mit dem Systemspeicher 249. Gemäß einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen zur Abbildung virtueller Adressen auf physische Adressen im Systemspeicher 249. Gemäß dieser Ausführungsform können sich die E/A-Vorrichtungen 252, die eine oder die mehreren CPU 246 und die eine oder die mehreren GPU 239 den gleichen virtuellen Adressraum teilen.
  • Gemäß einer Implementation unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen zum Abbilden virtueller Gast-/Grafikadressen auf physische Gast-/Grafikadressen und einen zweiten Satz von Seitentabellen zum Abbilden der physischen Gast-/Grafikadressen auf physische System-/Host-Adressen (beispielsweise innerhalb des Systemspeichers 249) verwalten. Die Basisadressen sowohl des ersten als auch des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert werden und bei einem Kontextwechsel ausgetauscht werden (so dass beispielsweise der neue Kontext mit Zugriff auf den relevanten Satz von Seitentabellen versehen wird). Wenngleich dies in 2C nicht dargestellt ist, kann jeder der Kerne 243, 244, 245 und/oder der Mehrkerngruppen 240A - 240N Translation-Lookaside-Buffer (TLBs) zum Cachen von Gast-virtuell-zu-Gast-physisch-Übersetzungen, von Gast-physisch-zu-Host-physisch-Übersetzungen und von Gast-virtuell-zu-Host-physisch-Übersetzungen aufweisen.
  • Gemäß einer Ausführungsform sind die CPUs 246, GPUs 239 und E/A-Vorrichtungen 252 auf einem einzigen Halbleiterchip und/oder Halbleitergehäuse integriert. Der dargestellte Speicher 249 kann auf demselben Chip integriert sein oder über eine Off-Chip-Schnittstelle mit den Speichersteuereinrichtungen 248 gekoppelt sein. Gemäß einer Implementation umfasst der Speicher 249 GDDR6-Speicher, der sich mit anderen Speichern auf der Ebene des physischen Systems den gleichen virtuellen Adressraum teilt, wenngleich die der Erfindung zugrunde liegenden Prinzipien nicht auf diese spezifische Implementation beschränkt sind.
  • Gemäß einer Ausführungsform weisen die Tensorkerne 244 mehrere Ausführungseinheiten auf, die spezifisch dafür ausgelegt sind, Matrixoperationen auszuführen, welche die grundlegende Rechenoperation sind, die für die Ausführung von Deep-Learning-Operationen verwendet wird. Beispielsweise können gleichzeitige Matrixmultiplikationsoperationen für das Training und Inferencing neuronaler Netze verwendet werden. Die Tensorkerne 244 können eine Matrixverarbeitung unter Verwendung einer Vielzahl von Operandengenauigkeiten, einschließlich Gleitkomma mit einfacher Genauigkeit (beispielsweise 32 Bits), Gleitkomma mit halber Genauigkeit (beispielsweise 16 Bits), Ganzzahlwörter (16 Bits), Bytes (8 Bits) und Halb-Bytes (4 Bits), ausführen. Gemäß einer Ausführungsform extrahiert eine Implementation eines neuronalen Netzes Merkmale jeder gerenderten Szene, wobei möglicherweise Einzelheiten von mehreren Frames kombiniert werden, um ein endgültiges Bild hoher Qualität zu bilden.
  • Bei Deep-Learning-Implementationen können parallele Matrixmultiplikationsoperationen für die Ausführung auf den Tensorkernen 244 geplant werden. Das Training neuronaler Netze erfordert insbesondere eine erhebliche Anzahl von Matrix-Skalarproduktoperationen. Zur Verarbeitung einer Skalarproduktformulierung einer N x N x N-Matrixmultiplikation können die Tensorkerne 244 wenigstens N Skalarprodukt-Verarbeitungselemente aufweisen. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und wird wenigstens eine Spalte einer zweiten Matrix in jedem Zyklus für N Zyklen geladen. In jedem Zyklus werden N Skalarprodukte verarbeitet.
  • Matrixelemente können abhängig von der bestimmten Implementation bei unterschiedlichen Genauigkeiten gespeichert werden, einschließlich 16-Bit-Wörtern, 8-Bit-Bytes (beispielsweise INT8) und 4-Bit-Halb-Bytes (beispielsweise INT4). Unterschiedliche Genauigkeitsmodi können für die Tensorkerne 244 spezifiziert werden, um zu gewährleisten, dass die wirksamste Genauigkeit für unterschiedliche Arbeitslasten verwendet wird (beispielsweise in der Art von Inferencing-Arbeitslasten, die eine Quantisierung zu Bytes und Halb-Bytes tolerieren können).
  • Gemäß einer Ausführungsform beschleunigen die Raytracing-Kerne 245 Raytracing-Operationen sowohl für Echtzeit-Raytracing- als auch für Nicht-Echtzeit-Raytracing-Implementationen. Insbesondere weisen die Raytracing-Kerne 245 eine Strahlenverlaufs-/Schnittschaltungsanordnung zur Ausführung einer Strahlenverlaufsuntersuchung unter Verwendung von Begrenzungsvolumenhierarchien (BVHs) und zur Identifikation von Schnittpunkten zwischen Strahlen und in die BVH-Volumina eingeschlossenen Grundformen auf. Die Raytracing-Kerne 245 können auch eine Schaltungsanordnung zur Ausführung eines Tiefentestens und einer Aussonderung (beispielsweise unter Verwendung einer Z-Buffer oder ähnlichen Anordnung) aufweisen. Gemäß einer Implementation führen die Raytracing-Kerne 245 zusammen mit den hier beschriebenen Bild-Rauschunterdrückungstechniken Verlaufs- und Schnittoperationen aus, wobei zumindest ein Teil davon auf den Tensorkernen 244 ausgeführt werden kann. Beispielsweise implementieren die Tensorkerne 244 gemäß einer Ausführungsform ein neuronales Deep-Learning-Netz zur Ausführung einer Rauschunterdrückung an von den Raytracing-Kernen 245 erzeugten Frames. Die CPU(s) 246, die Grafikkerne 243 und/oder die Raytracing-Kerne 245 können jedoch auch alle Rauschunterdrückungs- und/oder Deep-Learning-Algorithmen oder einen Teil davon implementieren.
  • Zusätzlich kann, wie vorstehend beschrieben, ein verteilter Ansatz zur Rauschunterdrückung verwendet werden, wobei sich die GPU 239 in einer Rechenvorrichtung befindet, die über ein Netz oder eine schnelle Zwischenverbindung mit anderen Rechenvorrichtungen gekoppelt ist. Gemäß dieser Ausführungsform teilen sich die miteinander verbundenen Rechenvorrichtungen Daten für das Lernen/das Training eines neuronalen Netzes, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, eine Rauschunterdrückung für verschiedene Typen von Bild-Frames und/oder verschiedene Grafikanwendungen auszuführen.
  • Gemäß einer Ausführungsform verarbeiten die Raytracing-Kerne 245 alle BVH-Verläufe und Strahl-Grundform-Schnitte, wodurch verhindert wird, dass die Grafikkerne 243 mit tausenden von Befehlen pro Strahl überlastet werden. Gemäß einer Ausführungsform weist jeder Raytracing-Kern 245 einen ersten Satz spezialisierter Schaltungsanordnungen zur Ausführung von Begrenzungskästchentests (beispielsweise für Verlaufsoperationen) und einen zweiten Satz spezialisierter Schaltungsanordnungen zur Ausführung der Strahl-Dreieck-Schnitttests (beispielsweise einander schneidende Strahlen, deren Verlauf verfolgt wurde) auf. Dementsprechend kann die Mehrkerngruppe 240A gemäß einer Ausführungsform einfach eine Strahlsonde absenden und führen die Raytracing-Kerne 245 unabhängig Strahlverlaufs- und Schnittuntersuchungen aus und geben Trefferdaten (beispielsweise ein Treffer, kein Treffer, mehrere Treffer usw.) an den Thread-Kontext zurück. Die anderen Kerne 243, 244 werden freigegeben, um andere Grafik- oder Rechenoperationen auszuführen, während die Raytracing-Kerne 245 die Verlaufs- und Schnittoperationen ausführen.
  • Gemäß einer Ausführungsform weist jeder Raytracing-Kern 245 eine Verlaufseinheit zur Ausführung von BVH-Testoperationen und eine Schnitteinheit, die Strahl-Grundform-Schnitttests ausführt, auf. Die Schnitteinheit erzeugt eine „Treffer“-, „Kein-Treffer“- oder „Mehrere-Treffer“-Antwort, welche sie dem geeigneten Thread bereitstellt. Während der Verlaufs- und Schnittoperationen werden die Ausführungsressourcen der anderen Kerne (beispielsweise Grafikkerne 243 und Tensorkerne 244) freigegeben, um andere Formen von Grafikoperationen auszuführen.
  • Gemäß einer bestimmten nachstehend beschriebenen Ausführungsform wird ein hybrider Rasterungs-/Raytracing-Ansatz verwendet, bei dem Arbeit zwischen den Grafikkernen 243 und den Raytracing-Kernen 245 verteilt wird.
  • Gemäß einer Ausführungsform weisen die Raytracing-Kerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstützung für einen Raytracing-Befehlssatz in der Art von DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl aufweist, sowie Strahlerzeugungs-, Nächstgelegener-Treffer-, Irgendein-Treffer- und Kein-Treffer-Shader auf, welche die Zuweisung eindeutiger Shader-Sätze und Texturen für jedes Objekt ermöglichen. Eine andere Raytracing-Plattform, die von den Raytracing-Kernen 245, den Grafikkernen 243 und den Tensorkernen 244 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch zu verstehen, dass die der Erfindung zugrunde liegenden Prinzipien nicht auf eine bestimmte Raytracing-ISA beschränkt sind.
  • Die verschiedenen Kerne 245, 244, 243 können im Allgemeinen einen Raytracing-Befehlssatz unterstützen, der Befehle/Funktionen zur Strahlerzeugung, für nächstgelegener Treffer, irgendein Treffer, Strahl-Grundform-Schnitt, Pro-Grundform- und hierarchische Begrenzungskästchenbildung, kein Treffer, Besuch und Ausnahmen aufweist. Insbesondere weist eine Ausführungsform Raytracing-Befehle für die Ausführung der folgenden Funktionen auf:
    • Strahlerzeugung - Strahlerzeugungsbefehle können für jedes Pixel, jedes Sample oder eine andere Zuweisung benutzerdefinierter Arbeit ausgeführt werden.
    • Nächstgelegener Treffer - ein Nächstgelegener-Treffer-Befehl kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Grundformen innerhalb einer Szene zu lokalisieren.
    • Irgendein Treffer - ein Irgendein-Treffer-Befehl identifiziert mehrere Schnittpunkte zwischen einem Strahl und Grundformen innerhalb einer Szene, um möglicherweise einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
    • Schnitt - ein Schnittbefehl führt einen Strahl-Grundform-Schnitttest aus und gibt ein Ergebnis aus.
    • Pro-Grundform-Begrenzungskästchenbildung - dieser Befehl bildet ein Begrenzungskästchen um eine gegebene Grundform oder Gruppe von Grundformen (beispielsweise wenn eine neue BVH oder eine andere Beschleunigungsdatenstruktur gebildet wird).
    • Kein Treffer - gibt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder ein spezifiziertes Gebiet einer Szene verfehlt.
    • Besuch - gibt die nachgeordneten Volumina an, die ein Strahl durchquert.
    • Ausnahmen - gibt verschiedene Typen von Ausnahme-Handlern an (beispielsweise für verschiedene Fehlerbedingungen aufgerufen).
  • 2D ist ein Blockdiagramm einer Grafikverarbeitungseinheit (GPGPU) 270 für allgemeine Zwecke, die als Grafikprozessor und/oder Rechenbeschleuniger ausgelegt sein kann, gemäß hier beschriebenen Ausführungsformen. Die GPGPU 270 kann sich über ein oder mehrere System- und/oder Speicherbusse mit Host-Prozessoren (beispielsweise einer oder mehreren CPU(s) 246) und Speicher 271, 272 verbinden. Gemäß einer Ausführungsform ist der Speicher 271 ein Systemspeicher, der von der einen oder den mehreren CPU(s) 246 geteilt verwendet werden kann, während der Speicher 272 ein Vorrichtungsspeicher ist, welcher der GPGPU 270 dediziert zugewiesen ist. Gemäß einer Ausführungsform können Komponenten innerhalb der GPGPU 270 und des Vorrichtungsspeichers 272 in Speicheradressen abgebildet werden, worauf die eine oder die mehreren CPU(s) 246 zugreifen können. Der Zugriff auf Speicher 271 und 272 kann durch eine Speichersteuereinrichtung 268 erleichtert werden. Gemäß einer Ausführungsform weist die Speichersteuereinrichtung 268 eine interne Direktspeicherzugriffs(DMA)-Steuereinrichtung 269 auf oder kann Logik zur Ausführung von Operationen aufweisen, die andernfalls durch eine DMA-Steuereinrichtung ausgeführt werden würden.
  • Die GPGPU 270 weist mehrere Cache-Speicher, einschließlich eines L2-Caches 253, eines L1-Caches 254, eines Befehls-Caches 255 und eines geteilten Speichers 256 auf, wobei zumindest ein Teil davon auch als Cache-Speicher partitioniert sein kann. Die GPGPU 270 weist auch mehrere Recheneinheiten 260A - 260N auf. Jede Recheneinheit 260A - 260N weist einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264 auf. Die Recheneinheiten 260A - 260N können auch einen lokalen geteilten Speicher 265 und einen Programmzähler 266 aufweisen. Die Recheneinheiten 260A - 260N können mit einem Konstanten-Cache 267 koppeln, der verwendet werden kann, um konstante Daten zu speichern, wobei es sich um Daten handelt, die sich während der Ausführung des Kernel- oder Shader-Programms auf der GPGPU 270 nicht ändern. Gemäß einer Ausführungsform ist der Konstanten-Cache 267 ein Skalardaten-Cache und können gecachte Daten direkt in die Skalarregister 262 abgerufen werden.
  • Während des Betriebs können die eine oder die mehreren CPU(s) 246 Befehle in Register oder Speicher in der GPGPU 270 schreiben, die in einen zugänglichen Adressraum abgebildet wurde. Die Befehlsprozessoren 257 können die Befehle aus Registern oder Speicher lesen und feststellen, wie diese Befehle innerhalb der GPGPU 270 verarbeitet werden. Ein Thread-Abfertiger 258 kann dann verwendet werden, um Threads an die Recheneinheiten 260A - 260N zu übergeben, um diese Befehle auszuführen. 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 eine bedingte Berechnung ausgelegt werden und 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 übergebenen Befehle abgeschlossen sind.
  • Die 3A - 3C zeigen Blockdiagramme zusätzlicher Grafikprozessor- und Rechenbeschleunigerarchitekturen, die durch hier beschriebene Ausführungsformen bereitgestellt werden, Die Elemente aus den 3A - 3C, welche die gleichen Bezugszahlen (oder Namen) aufweisen wie die Elemente einer anderen hier angeführten Figur, können ähnlich zu den hier beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
  • 3A ist ein Blockdiagramm eines Grafikprozessors 300, wobei es sich um eine diskrete Grafikverarbeitungseinheit oder einen mit mehreren Verarbeitungskernen oder anderen Halbleitervorrichtungen in der Art von Speichervorrichtungen oder Netzschnittstellen, jedoch ohne Einschränkung darauf, integrierten Grafikprozessor handeln kann. Gemäß einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorspeicher gegebenen Befehlen. Gemäß einigen Ausführungsformen weist der Grafikprozessor 300 eine Speicherschnittstelle 314 zum Zugriff auf den Speicher auf. Die Speicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Speicher, zu einem oder mehreren internen Caches, zu einem oder mehreren geteilten externen Caches und/oder zum Systemspeicher sein.
  • Gemäß einigen Ausführungsformen weist der Grafikprozessor 300 auch eine Anzeigesteuereinrichtung 302 zur Steuerung der Anzeige an eine Anzeigevorrichtung 318 ausgegebener Daten auf. Die Anzeigesteuereinrichtung 302 weist Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und Zusammensetzung mehrerer Videoschichten oder Benutzerschnittstellenelemente auf. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. Gemäß einer Ausführungsform ist die Anzeigeorrichtung 318 eine am Kopf angebrachte Anzeigevorrichtung in der Art einer Virtual-Reality(VR)-Anzeigevorrichtung oder einer Augmented-Reality(AR)-Anzeigevorrichtung. Gemäß einigen Ausführungsformen weist der Grafikprozessor 300 eine Videocodec-Engine 306 zur Codierung, Decodierung oder Transcodierung von Medien zu, von oder zwischen einem oder mehreren Mediencodierformaten auf, welche Moving-Picture-Experts-Group(MPEG)-Formate in der Art von MPEG-2, Advanced-Video-Coding(AVC)-Formate in der Art von 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 in der Art von JPEG und Motion-JPEG(MJPEG)-Formate einschließen, jedoch nicht darauf beschränkt sind.
  • Gemäß einigen Ausführungsformen weist der Grafikprozessor 300 eine Blockbildübertragungs(BLIT)-Engine 304 zur Ausführung zweidimensionaler (2D-) Rasterungsoperationen, einschließlich beispielsweise von Bitgrenzen-Blockübertragungen, auf. Gemäß einer Ausführungsform werden jedoch 2D-Grafikoperationen unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungs-Engine (GPE) 310 ausgeführt. Gemäß einigen Ausführungsformen ist die GPE 310 eine Rechen-Engine zur Ausführung von Grafikoperationen unter Einschluss dreidimensionaler (3D-) Grafikoperationen und Medienoperationen.
  • Gemäß einigen Ausführungsformen weist die GPE 310 eine 3D-Pipeline 312 zur Ausführung von 3D-Operationen in der Art eines Renderns dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf 3D-Grundformen (beispielsweise Rechteck, Dreieck usw.) wirken, auf. Die 3D-Pipeline 312 weist programmierbare und Festfunktionselemente auf, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Ausführungs-Threads an einem 3D-/Medienuntersystem 315 hervorbringen. Wenngleich die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen auszuführen, weist eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316 auf, die spezifisch für die Ausführung von Medienoperationen in der Art einer Videonachbearbeitung und einer Bildverbesserung verwendet wird.
  • Gemäß einigen Ausführungsformen weist die Medien-Pipeline 316 Festfunktions- oder programmierbare Logikeinheiten zur Ausführung einer oder mehrerer spezialisierter Medienoperationen in der Art einer Videodecodierbeschleunigung, eines Video-Deinterlacings und einer Videocodierbeschleunigung an Stelle der Videocodec-Engine 306 oder für diese auf. Gemäß einigen Ausführungsformen weist die Medien-Pipeline 316 zusätzlich eine Thread-Hervorbringungseinheit zur Hervorbringung von Threads zur Ausführung auf dem 3D-/Medienuntersystem 315 auf. Die hervorgebrachten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren im 3D-/Medienuntersystem 315 enthaltenen Grafikausführungseinheiten aus.
  • Gemäß einigen Ausführungsformen weist das 3D-/Medienuntersystem 315 Logik zur Ausführung von der 3D-Pipeline 312 und der Medien-Pipeline 316 hervorgebrachter Threads auf. Gemäß einer Ausführungsform senden die Pipelines Thread-Ausführungsanforderungen zum 3D-/Medienuntersystem 315, das eine Thread-Abfertigungslogik zur Arbitrierung und Abfertigung der verschiedenen Anforderungen von verfügbaren Thread-Ausführungsressourcen aufweist. Die Ausführungsressourcen weisen ein Array von Grafikausführungseinheiten zur Verarbeitung der 3D- und Medien-Threads auf. Gemäß einigen Ausführungsformen weist das 3D-/Medienuntersystem 315 einen oder mehrere interne Caches für Thread-Befehle und Daten auf. Gemäß einigen Ausführungsformen weist das Untersystem auch einen geteilten Speicher, einschließlich Registern und eines adressierbaren Speichers, auf, um Daten zwischen Threads zu teilen und ausgegebene Daten zu speichern.
  • 3B zeigt einen Grafikprozessor 320 mit einer gekachelten Architektur gemäß hier beschriebenen Ausführungsformen. Gemäß einer Ausführungsform weist der Grafikprozessor 320 einen Grafikverarbeitungs-Engine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungs-Engine 310 aus 3A innerhalb einer Grafik-Engine-Kachel 310A - 310D auf. Die jeweiligen Grafik-Engine-Kacheln 310A - 310D können durch einen Satz von Kachelzwischenverbindungen 323A - 323F miteinander verbunden sein. Jede Grafik-Engine-Kachel 310A - 310D kann auch über Speicherzwischenverbindungen 325A - 325D mit einem Speichermodul oder einer Speichervorrichtung 326A - 326D verbunden sein. Die Speichervorrichtungen 326A - 326D können eine beliebige Grafikspeichertechnologie verwenden. Beispielsweise können die Speichervorrichtungen 326A - 326D ein Grafikspeicher mit doppelter Datenrate (GDDR-Speicher) sein. Die Speichervorrichtungen 326A - 326D sind gemäß einer Ausführungsform Hohe-Bandbreite-Speicher(HBM)-Module, die sich auf einem Die mit ihrer jeweiligen Grafik-Engine-Kachel 310A - 310D befinden können. Gemäß einer Ausführungsform sind die Speichervorrichtungen 326A - 326D gestapelte Speichervorrichtungen, die auf ihrer jeweiligen Grafik-Engine-Kachel 310A - 310D gestapelt sein können. Gemäß einer Ausführungsform befinden sich jede Grafik-Engine-Kachel 310A - 310D und ihr zugeordneter Speicher 326A - 326D auf getrennten Chiplets, die an einen Basis-Die oder ein Basissubstrat gebondet sind, wie in weiteren Einzelheiten in den 11B - 11D beschrieben wird.
  • Der Grafikverarbeitungs-Engine-Cluster 322 kann sich mit einer On-Chip- oder On-Package-Fabric-Zwischenverbindung 324 verbinden. Die Fabric-Zwischenverbindung 324 kann eine Kommunikation zwischen Grafik-Engine-Kacheln 310A - 310D und Komponenten in der Art des Videocodecs 306 und einer oder mehrerer Kopier-Engines 304 ermöglichen. Die Kopier-Engines 304 können verwendet werden, um Daten aus, in und zwischen den Speichervorrichtungen 326A - 326D und Speicher außerhalb des Grafikprozessors 320 (beispielsweise Systemspeicher) zu verschieben. Die Fabric-Zwischenverbindung 324 kann auch verwendet werden, um die Grafik-Engine-Kacheln 310A - 310D zu verbinden. Der Grafikprozessor 320 kann optional eine Anzeigesteuereinrichtung 302 aufweisen, um eine Verbindung mit einer externen Anzeigevorrichtung 318 zu ermöglichen. Der Grafikprozessor kann auch als Grafik- oder Rechenbeschleuniger ausgelegt sein. In der Beschleunigerkonfiguration können die Anzeigesteuereinrichtung 302 und die Anzeigevorrichtung 318 fortgelassen sein.
  • Der Grafikprozessor 320 kann sich über eine Host-Schnittstelle 328 mit einem Host-System verbinden. Die Host-Schnittstelle 328 kann eine Kommunikation zwischen dem Grafikprozessor 320, dem Systemspeicher und/oder anderen Systemkomponenten ermöglichen. Die Host-Schnittstelle 328 kann beispielsweise ein PCI-Expressbus oder ein anderer Typ einer Host-System-Schnittstelle sein.
  • 3C zeigt einen Rechenbeschleuniger 330 gemäß hier beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann Architekturähnlichkeiten mit dem Grafikprozessor 320 aus 3B aufweisen und ist für die Rechenbeschleunigung optimiert. Ein Rechen-Engine-Cluster 332 kann einen Satz von Rechen-Engine-Kacheln 340A - 340D aufweisen, die eine Ausführungslogik aufweisen, die für parallele oder vektorbasierte Rechenoperationen für allgemeine Zwecke optimiert ist. Gemäß einigen Ausführungsformen weisen die Rechen-Engine-Kacheln 340A - 340D keine Festfunktions-Grafikverarbeitungslogik auf, wenngleich gemäß einer Ausführungsform eine oder mehrere der Rechen-Engine-Kacheln 340A - 340D Logik zur Ausführung einer Medienbeschleunigung aufweisen können. Die Rechen-Engine-Kacheln 340A - 340D können sich über Speicherzwischenverbindungen 325A - 325D mit Speicher 326A - 326D verbinden. Der Speicher 326A - 326D und die Speicherzwischenverbindungen 325A - 325D können eine ähnliche Technologie wie im Grafikprozessor 320 sein oder davon verschieden sein. Die Grafikrechen-Engine-Kacheln 340A - 340D können auch über einen Satz von Kachelzwischenverbindungen 323A - 323F miteinander verbunden sein und durch eine Fabric-Zwischenverbindung 324 angeschlossen und/oder miteinander verbunden sein. Gemäß einer Ausführungsform weist der Rechenbeschleuniger 330 einen großen L3-Cache 336 auf, der als ein vorrichtungsweiter Cache ausgelegt sein kann. Der Rechenbeschleuniger 330 kann sich auch ähnlich wie der Grafikprozessor 320 aus 3B über eine Host-Schnittstelle 328 mit einem Host-Prozessor und Speicher verbinden.
  • Grafikverarbeitungs-Engine
  • 4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors gemäß einigen Ausführungsformen. Gemäß einer Ausführungsform ist die Grafikverarbeitungs-Engine (GPE) 410 eine Version der in 3A dargestellten GPE 310 und kann auch eine Grafik-Engine-Kachel 310A - 310D aus 3B repräsentieren. Elemente aus 4, welche die gleichen Bezugszahlen (oder Namen) aufweisen wie die Elemente einer anderen hier angeführten Figur, können ähnlich zu den hier beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Beispielsweise sind die 3D-Pipeline 312 und die Medien-Pipeline 316 aus 3A dargestellt. Die Medien-Pipeline 316 ist bei einigen Ausführungsformen der GPE 410 optional und kann in der GPE 410 nicht explizit enthalten sein. Beispielsweise und gemäß zumindest einer Ausführungsform ist ein getrennter Medien- und/oder Bildprozessor mit der GPE 410 gekoppelt.
  • Gemäß einigen Ausführungsformen koppelt die GPE 410 mit einem Befehls-Streamer 403 oder weist diesen auf, welcher der 3D-Pipeline 312 und/oder der Medien-Pipeline 316 einen Befehlsstrom bereitstellt. Gemäß einigen Ausführungsformen ist der Befehls-Streamer 403 mit einem Speicher gekoppelt, wobei es sich um den Systemspeicher oder einen oder mehrere interne Cache-Speicher und geteilte Cache-Speicher handeln kann. Gemäß einigen Ausführungsformen empfängt der Befehls-Streamer 403 Befehle vom Speicher und sendet die Befehle zur 3D-Pipeline 312 und/oder zur Medien-Pipeline 316. Die Befehle sind von einem Ringbuffer, der Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert, abgerufene Leitlinien. Gemäß einer Ausführungsform kann der Ringbuffer zusätzlich Stapelbefehlspuffer aufweisen, welche Stapel mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Bezüge auf im Speicher gespeicherte Daten aufweisen, einschließlich Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316, jedoch ohne Einschränkung darauf. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch Ausführen von Operationen über Logik innerhalb der jeweiligen Pipelines oder durch Übergeben eines oder mehrerer Ausführungs-Threads an ein Grafikkern-Array 414. Gemäß einer Ausführungsform weist das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (beispielsweise Grafikkern(e) 415A, Grafikkern(e) 415B) auf, wobei jeder Block einen oder mehrere Grafikkerne aufweist. Jeder Grafikkern weist einen Satz von Grafikausführungsressourcen auf, welcher eine Ausführungslogik für allgemeine Zwecke und eine graphikspezifische Ausführungslogik zur Ausführung von Grafik- und Rechenoperationen sowie eine Festfunktions-Texturverarbeitungs- und/oder Rechen-Engine-Kachelnlern- und Künstliche-Intelligenz-Beschleunigungs-Logik aufweist.
  • Gemäß verschiedenen Ausführungsformen kann die 3D-Pipeline 312 eine Festfunktions- und programmierbare Logik zur Verarbeitung eines oder mehrerer Shader-Programme in der Art von Vertex-Shadern, Geometrie-Shadern, Pixel-Shadern, Fragment-Shadern, Rechen-Shadern oder anderen Shader-Programmen durch Verarbeiten der Befehle und Übergeben von Ausführungs-Threads an das Grafikkern-Array 414 aufweisen. Das Grafikkern-Array 414 stellt einen vereinheitlichten Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader -Programme bereit. Eine Mehrzweck-Ausführungslogik (beispielsweise Ausführungseinheiten) innerhalb des einen oder der mehreren Grafikkerne 415A - 414B des Grafikkern-Arrays 414 weist eine Unterstützung für verschiedene 3D-API-Shader-Sprachen auf und kann mehrere gleichzeitige Ausführungs-Threads in Zusammenhang mit mehreren Shadern ausführen.
  • Gemäß einigen Ausführungsformen weist das Grafikkern-Array 414 eine Ausführungslogik zur Ausführung von Medienfunktionen in der Art einer Video- und/oder Bildverarbeitung auf. Gemäß einer Ausführungsform weisen die Ausführungseinheiten eine Logik für allgemeine Zwecke auf, die programmierbar ist, um parallele Rechenoperationen für allgemeine Zwecke zusätzlich zu Grafikverarbeitungsoperationen auszuführen. Die Logik für allgemeine Zwecke kann Verarbeitungsoperationen parallel oder in Zusammenhang mit der Logik für allgemeine Zwecke innerhalb des einen oder der mehreren Prozessorkerne 107 aus 1 oder der Kerne 202A - 202N wie in 2A ausführen.
  • Von Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, erzeugte Daten können an einen Speicher in einem Unified Return Buffer (URB) 418 ausgegeben werden. Der URB 418 kann Daten für mehrere Threads speichern. Gemäß einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen verschiedenen Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, zu übertragen. Gemäß einigen Ausführungsformen kann der URB 418 zusätzlich für die Synchronisation zwischen Threads auf dem Grafikkern-Array und Festfunktionslogik innerhalb der Geteilte-Funktionen-Logik 420 verwendet werden.
  • Gemäß einigen Ausführungsformen ist das Grafikkern-Array 414 skalierbar, so dass es eine veränderliche Anzahl von Grafikkernen aufweist, die jeweils eine veränderliche Anzahl von Ausführungseinheiten auf der Grundlage des Zielstromverbrauchs- und Leistungsfähigkeitsniveaus der GPE 410 aufweisen. Gemäß einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, so dass sie nach Bedarf aktiviert oder deaktiviert werden können.
  • Das Grafikkern-Array 414 koppelt mit der Geteilte-Funktionen-Logik 420, die mehrere Ressourcen aufweist, die zwischen den Grafikkernen im Grafikkern-Array geteilt werden. Die geteilten Funktionen innerhalb der Geteilte-Funktionen-Logik 420 sind Hardwarelogikeinheiten, die dem Grafikkern-Array 414 eine spezialisierte ergänzende Funktionalität bereitstellen. Gemäß verschiedenen Ausführungsformen weist die Geteilte-Funktionen-Logik 420 eine Sampler-Logik 421, eine Mathematik-Logik 422 und eine Inter-Thread-Kommunikations(ITC)-Logik 423 auf, ist jedoch nicht darauf beschränkt. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Caches 425 innerhalb der Geteilte-Funktionen-Logik 420.
  • Eine geteilte Funktion wird zumindest in einem Fall implementiert, in dem kein ausreichender Bedarf zur Aufnahme einer gegebenen spezialisierten Funktion in das Grafikkern-Array 414 besteht. Stattdessen wird eine einzelne Instanz dieser spezialisierten Funktion als autonome Entität in der Geteilte-Funktionen-Logik 420 implementiert und zwischen den Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 geteilt. Der genaue Satz von Funktionen, die zwischen dem Grafikkern-Array 414 geteilt werden und innerhalb des Grafikkern-Arrays 414 enthalten sind, ändert sich zwischen Ausführungsformen. Gemäß einigen Ausführungsformen können spezifische geteilte Funktionen innerhalb der Geteilte-Funktionen-Logik 420, die extensiv vom Grafikkern-Array 414 verwendet werden, in die Geteilte-Funktionen-Logik 416 innerhalb des Grafikkern-Arrays 414 aufgenommen werden. Gemäß verschiedenen Ausführungsformen kann die Geteilte-Funktionen-Logik 416 innerhalb des Grafikkern-Arrays 414 einige Logik oder die gesamte Logik innerhalb der Geteilte-Funktionen-Logik 420 aufweisen. Gemäß einer Ausführungsform können alle Logikelemente innerhalb der Geteilte-Funktionen-Logik 420 innerhalb der Geteilte-Funktionen-Logik 416 des Grafikkern-Arrays 414 dupliziert werden. Gemäß einer Ausführungsform wird die Geteilte-Funktionen-Logik 420 zugunsten der Geteilte-Funktionen-Logik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
  • Ausführungseinhei ten
  • Die 5A - 5B zeigen eine Thread-Ausführungslogik 500, die ein Array in einem Grafikprozessorkern verwendeter Verarbeitungselemente gemäß hier beschriebenen Ausführungsformen aufweist. Elemente aus den 5A - 5B, welche die gleichen Bezugszahlen (oder Namen) aufweisen wie die Elemente einer anderen hier angeführten Figur, können ähnlich zu den hier beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt. Die 5A - 5B zeigen einen Überblick über die Thread-Ausführungslogik 500, die für die in 2B mit jedem Unterkern 221A - 221F dargestellte Hardwarelogik repräsentativ sein kann. 5A repräsentiert eine Ausführungseinheit innerhalb eines Grafikprozessors für allgemeine Zwecke, während 5B eine Ausführungseinheit repräsentiert, die innerhalb eines Rechenbeschleunigers verwendet werden kann.
  • Wie in 5A dargestellt ist, weist die Thread-Ausführungslogik 500 gemäß einigen Ausführungsformen einen Shader-Prozessor 502, einen Thread-Abfertiger 504, einen Befehls-Cache 506, ein skalierbares Ausführungseinheits-Array einschließlich mehrerer Ausführungseinheiten 508A - 508N, einen Sampler 510, einen geteilten lokalen Speicher 511, einen Daten-Cache 512 und einen Daten-Port 514 auf. Gemäß einer Ausführungsform kann das skalierbare Ausführungseinheits-Array durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (beispielsweise jeglicher der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) auf der Grundlage der Rechenanforderungen einer Arbeitslast dynamisch skalieren. Gemäß einer Ausführungsform sind die enthaltenen Komponenten durch ein Verbindungsnetz, das die jeweiligen Komponenten verknüpft, verbunden. Gemäß einigen Ausführungsformen weist die Thread-Ausführungslogik 500 eine oder mehrere Verbindungen zum Speicher in der Art des Systemspeichers oder Cache-Speichers durch einen oder mehrere vom Befehls-Cache 506, Daten-Port 514, Sampler 510 und von den Ausführungseinheiten 508A - 508N auf. Gemäß einigen Ausführungsformen ist jede Ausführungseinheit (beispielsweise 508A) eine autonome programmierbare Recheneinheit für allgemeine Zwecke, die in der Lage ist, mehrere gleichzeitige Hardware-Threads auszuführen, während mehrere Datenelemente für jeden Thread parallel verarbeitet werden. Gemäß verschiedenen Ausführungsformen ist das Array der Ausführungseinheiten 508A - 508N skalierbar, so dass es jede beliebige Anzahl einzelner Ausführungseinheiten aufweist.
  • Gemäß einigen Ausführungsformen werden die Ausführungseinheiten 508A - 508N in erster Linie zur Ausführung von Shader-Programmen verwendet. Ein Shader-Prozessor 502 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads in Zusammenhang mit den Shader-Programmen über einen Thread-Abfertiger 504 abfertigen. Gemäß einer Ausführungsform weist der Thread-Abfertiger Logik zum Arbitrieren von Thread-Einleitungsanforderungen von den Grafik- und Medien-Pipelines und zum Instanziieren der angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A - 508N auf. Beispielsweise kann eine Geometrie-Pipeline Vertex, Tesselation- oder Geometrie-Shader an die Thread-Ausführungslogik für die Verarbeitung übergeben. Gemäß einigen Ausführungsformen kann der Thread-Abfertiger 504 auch Laufzeit-Thread-Hervorbringungsanforderungen von den ausführenden Shader-Programmen verarbeiten.
  • Gemäß einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A - 508N einen Befehlssatz, der eine native Unterstützung für viele Standard-3D-Grafik-Shader-Befehle aufweist, so dass Shader-Programme aus Grafikbibliotheken (beispielsweise Direct 3D und OpenGL) mit minimaler Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen eine Vertex- und Geometrieverarbeitung (beispielsweise Vertex-Programme, Geometrieprogramme, Vertex-Shader), eine Pixelverarbeitung (beispielsweise Pixel-Shader, Fragment-Shader) und eine Verarbeitung für allgemeine Zwecke (beispielsweise Rechen- und Medien-Shader). Jede der Ausführungseinheiten 508A - 508N ist zu einer Mehrere-Probleme-einzelner-Befehl-mehrere-Daten(SIMD)-Ausführung in der Lage, und eine Mehr-Thread-Operation ermöglicht angesichts von Speicherzugriffen mit höherer Latenz eine wirksame Ausführungsumgebung. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei hoher Bandbreite und einen zugeordneten unabhängigen Thread-Zustand auf. Die Ausführung erfolgt Mehrere-Probleme-pro-Takt auf Pipelines, die zu Ganzzahl-, Einfache-Genauigkeit- und Doppelte-Genauigkeit-Gleitkommaoperationen in der Lage sind, eine SIMD-Zweig-Fähigkeit aufweisen, und zu logischen Operationen, transzendenten Operationen und anderen verschiedenen Operationen in der Lage sind. Während auf Daten vom Speicher oder eine der geteilten Funktionen gewartet wird, veranlasst die Abhängigkeitslogik innerhalb der Ausführungseinheiten 508A - 508N einen wartenden Thread, zu schlafen, bis die angeforderten Daten zurückgegeben wurden. Während der wartende Thread schläft, können Hardware-Ressourcen der Verarbeitung anderer Threads zugewiesen werden. Beispielsweise kann eine Ausführungseinheit während einer Verzögerung in Zusammenhang mit einer Vertex-Shader-Operation Operationen für ein Pixel-Shader-, Fragment-Shader- oder Shader-Programm eines anderen Typs, einschließlich eines anderen Vertex-Shaders, ausführen. Verschiedene Ausführungsformen können dafür geeignet sein, eine Ausführung unter Verwendung eines Einzelner-Befehl-mehrere-Threads (SIMT) als Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD zu verwenden. Ein Bezug auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
  • Jede der Ausführungseinheiten 508A - 508N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für den Befehl. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, die Maskierung und die Flusssteuerung innerhalb von Befehlen. Die Anzahl der Kanäle kann von der Anzahl der physischen Rechenlogikeinheiten (ALU) oder Gleitkommaeinheiten (FPU) für einen bestimmten Grafikprozessor unabhängig sein. Gemäß einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A - 508N ganzzahlige und Gleitkomma-Datentypen.
  • Der Ausführungseinheits-Befehlssatz weist SIMD-Befehle auf. Die verschiedenen Datenelemente können als ein paketierter Datentyp in einem Register gespeichert werden, und die Ausführungseinheit verarbeitet die verschiedenen Elemente auf der Grundlage der Datengröße der Elemente. Wenn auf einem 256-Bit-breiten Vektor gearbeitet wird, werden beispielsweise die 256 Bits des Vektors in einem Register gespeichert und arbeitet die Ausführungseinheit an dem Vektor als vier getrennte 54-Bit-paketierte Datenelemente (Quad-Wort(QW)-Größen-Datenelemente), acht getrennte 32-Bit-paketierte Datenelemente (Doppelwort(DW)-Größen-Datenelemente), sechzehn getrennte 16-Bit-paketierte Datenelemente (Wort(W)-Größen-Datenelemente) oder zweiunddreißig getrennte 8-Bit-Datenelemente (Byte(B)-Größen-Datenelemente). Es sind jedoch auch andere Vektorbreiten und Registergrößen möglich.
  • Gemäß einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer vereinigten Ausführungseinheit 509A - 509N mit einer den vereinigten EU gemeinsamen Thread-Steuerlogik (507A - 507N) kombiniert werden. Mehrere EU können zu einer EU-Gruppe vereinigt werden. Jede EU in der vereinigten EU-Gruppe kann dafür ausgelegt sein, einen getrennten SIMD-Hardware-Thread auszuführen. Die Anzahl der EU in einer vereinigten EU-Gruppe kann von Ausführungsformen abhängen. Zusätzlich können verschiedene SIMD-Breiten pro EU ausgeführt werden, einschließlich SIMD8, SIMD16 und SIMD32, jedoch ohne Einschränkung darauf. Jede vereinigte Grafikausführungseinheit 509A - 509N weist wenigstens zwei Ausführungseinheiten auf. Beispielsweise weist die vereinigte Ausführungseinheit 509A eine erste EU 508A, eine zweite EU 508B und eine Thread-Steuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam ist, auf. Die Thread-Steuerlogik 507A steuert Threads, die auf der vereinigten Grafikausführungseinheit 509A ausgeführt werden, wodurch es jeder EU innerhalb der vereinigten Ausführungseinheiten 509A - 509N ermöglicht wird, unter Verwendung eines gemeinsamen Befehlszeigerregisters zu arbeiten.
  • Ein oder mehrere interne Befehls-Caches (beispielsweise 506) sind in der Thread-Ausführungslogik 500 enthalten, um Thread-Befehle für die Ausführungseinheiten zu cachen. Gemäß einigen Ausführungsformen sind ein oder mehrere Daten-Caches (beispielsweise 512) aufgenommen, um Thread-Daten während der Thread-Ausführung zu cachen. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit gemanagte Daten im geteilten lokalen Speicher 511 speichern. Gemäß einigen Ausführungsformen ist ein Sampler 510 aufgenommen, um eine Texturabtastung für 3D-Operationen und eine Medienabtastung für Medienoperationen bereitzustellen. Gemäß einigen Ausführungsformen weist der Sampler 510 eine spezialisierte Textur- oder Medienabtastfunktionalität zur Verarbeitung von Textur- oder Mediendaten während des Abtastprozesses, bevor die abgetasteten Daten einer Ausführungseinheit bereitgestellt werden, auf.
  • Während der Ausführung senden die Grafik- und Medien-Pipelines Thread-Initialisierungsanforderungen über die Thread-Hervorbringungs- und -Abfertigungslogik zur Thread-Ausführungslogik 500. Sobald eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten gerastert wurde, wird die Pixelprozessorlogik (beispielsweise Pixel-Shader-Logik, Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 502 aufgerufen, um ferner Ausgangsinformationen zu berechnen und zu bewirken, dass Ergebnisse in Ausgabeflächen geschrieben werden (beispielsweise Farbbuffer, Tiefenbuffer, Stencil-Buffer usw.). Gemäß einigen Ausführungsformen berechnet ein Pixel-Shader oder Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über das gerasterte Objekt zu interpolieren sind. Gemäß einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 502 dann ein Anwendungsprogrammierschnittstellen(API)-zugeführte-Pixel- oder Fragment-Shader-Programm aus. Zur Ausführung des Shader-Programms übergibt der Shader-Prozessor 502 Threads über den Thread-Abfertiger 504 an eine Ausführungseinheit (beispielsweise 508A). Gemäß einigen Ausführungsformen verwendet der Shader-Prozessor 502 eine Texturabtastlogik im Sampler 510 zum Zugriff auf Texturdaten in Texturkarten, die im Speicher gespeichert sind. Rechenoperationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder schließen ein oder mehrere Pixel von der Weiterverarbeitung aus.
  • Gemäß einigen Ausführungsformen stellt der Daten-Port 514 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 500 zur Ausgabe verarbeiteter Daten an den Speicher zur Weiterverarbeitung auf einer Grafikprozessor-Ausgabe-Pipeline bereit. Gemäß einigen Ausführungsformen weist der Daten-Port 514 einen oder mehrere Cache-Speicher (beispielsweise Daten-Cache 512) auf oder koppelt damit, um Daten für den Speicherzugriff über den Daten-Port zu cachen.
  • Gemäß einer Ausführungsform kann die Ausführungslogik 500 auch ein Raytracer 505 aufweisen, der eine Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Der Raytracer 505 kann einen Raytracing-Befehlssatz unterstützen, der Befehle/Funktionen zur Strahlerzeugung aufweist. Der Raytracing-Befehlssatz kann dem Raytracing-Befehlssatz, der von den Raytracing-Kernen 245 in 2C unterstützt wird, ähneln oder davon verschieden sein.
  • 5B zeigt beispielhafte interne Einzelheiten einer Ausführungseinheit 508 gemäß Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Befehlsabrufeinheit 537, ein allgemeines Registerdatei-Array (GRF) 524, ein Architekturregisterdatei-Array (ARF) 526, einen Thread-Arbiter 522, eine Sendeeinheit 530, eine Zweigeinheit 532, einen Satz von SIMD-Gleitkommaeinheiten (FPU) 534 und gemäß einer Ausführungsform einen Satz dedizierter Ganzzahl-SIMD-ALU 535 aufweisen. Die GRF 524 und ARF 526 weisen den Satz allgemeiner Registerdateien und Architekturregisterdateien in Zusammenhang mit jedem gleichzeitigen Hardware-Thread, der in der Grafikausführungseinheit 508 aktiv sein kann, auf. Gemäß einer Ausführungsform wird der Pro-Thread-Architekturzustand in der ARF 526 aufrechterhalten, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 524 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Befehlszeiger für jeden Thread, können in Thread-spezifischen Registern in der ARF 526 gehalten werden.
  • Gemäß einer Ausführungsform weist die Grafikausführungseinheit 508 eine Architektur auf, die eine Kombination eines gleichzeitigen Mehr-Threadings (SMT) und eines feinkörnigen verschachtelten Mehr-Threadings (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zur Entwurfszeit auf der Grundlage einer Zielanzahl gleichzeitiger Threads und der Anzahl der Register pro Ausführungseinheit fein abgestimmt werden kann, wobei Ausführungseinheitsressourcen über die für die Ausführung mehrerer gleichzeitiger Threads verwendete Logik verteilt werden. Die Anzahl der Logik-Threads, die von der Grafikausführungseinheit 508 ausgeführt werden können, ist nicht auf die Anzahl der Hardware-Threads beschränkt, und es können jedem Hardware-Thread mehrere Logik-Threads zugewiesen werden.
  • Gemäß einer Ausführungsform kann die Grafikausführungseinheit 508 mehrere Befehle gemeinsam ausgeben, die jeweils voneinander verschieden sein können. Der Thread-Arbiter 522 des Grafikausführungseinheits-Threads 508 kann die Befehle zur Ausführung auf eine von der Sendeeinheit 530, der Zweigeinheit 532 oder der einen oder der mehreren SIMD FPU 534 geben. Jeder Befehls-Thread kann auf 128 Register für allgemeine Zwecke innerhalb der GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als SIMD-8-Elementvektor von 32-Bit-Datenelementen zugänglich sind. Gemäß einer Ausführungsform hat jeder Ausführungseinheits-Thread Zugriff auf 4 kBytes innerhalb der GRF 524, wenngleich Ausführungsformen nicht darauf beschränkt sind und gemäß anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. Gemäß einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardware-Threads unterteilt, die unabhängig Rechenoperationen ausführen können, wenngleich die Anzahl der Threads pro Ausführungseinheit gemäß Ausführungsformen auch variieren kann. Beispielsweise werden gemäß einer Ausführungsform bis zu 16 Hardware-Threads unterstützt. Gemäß einer Ausführungsform, bei der sieben Threads auf 4 kBytes zugreifen können, kann die 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 ermöglichen, dass Register gemeinsam adressiert werden, um breitere Register wirksam zu bilden oder ausgreifende rechteckige Blockdatenstrukturen zu repräsentieren.
  • Gemäß einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Befehle übermittelt, die von der Nachrichtenübermittlungs-Sendeeinheit 530 ausgeführt werden. Gemäß einer Ausführungsform werden Zweigbefehle an eine dedizierte Zweigeinheit 532 übermittelt, um die SIMD-Divergenz und schließliche Konvergenz zu erleichtern.
  • Gemäß einer Ausführungsform weist die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534 zur Ausführung von Gleitkommaoperationen auf. Gemäß einer Ausführungsform unterstützen die FPU(s) 534 auch eine Ganzzahlberechnung. Gemäß einer Ausführungsform können die eine oder die mehreren FPU 534 bis zu einer Anzahl von M 32-Bit-Gleitkomma(oder Ganzzahl)-Operationen SIMDausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkommaoperationen SIMDausführen. Gemäß einer Ausführungsform stellt wenigstens eine der FPU(s) eine erweiterte mathematische Fähigkeit zur Unterstützung transzendenter mathematischer Funktionen hohen Durchsatzes und 54-Bit-Gleitkommaoperationen mit doppelter Genauigkeit bereit. Gemäß einigen Ausführungsformen ist auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 535 vorhanden und kann spezifisch optimiert werden, um Operationen in Zusammenhang mit Rechen-Engine-Kachelnlernberechnungen auszuführen.
  • Gemäß einer Ausführungsform können Arrays mehrerer Instanzen der Grafikausführungseinheit 508 in einer Grafikunterkerngruppe (beispielsweise einem Unter-Slice) instanziiert werden. Im Interesse der Skalierbarkeit können Produktarchitekten die genaue Anzahl der Ausführungseinheiten pro Unterkerngruppe wählen. Gemäß einer Ausführungsform kann die Ausführungseinheit 508 Befehle über mehrere Ausführungskanäle ausführen. Gemäß einer weiteren Ausführungsform wird jeder auf der Grafikausführungseinheit 508 ausgeführte Thread auf einem anderen Kanal ausgeführt.
  • 6 eine zusätzliche Ausführungseinheit 600 gemäß einer Ausführungsform, Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit zur Verwendung beispielsweise in einer Rechen-Engine-Kachel 340A - 340D wie in 3C sein, ist jedoch nicht darauf beschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafik-Engine-Kachel 310A - 310D wie in 3B verwendet werden. Gemäß einer Ausführungsform weist die Ausführungseinheit 600 eine Thread-Steuereinheit 601, eine Thread-Zustandseinheit 602, eine Befehls-Abruf-/Vorabrufeinheit 603 und eine Befehlsdecodiereinheit 604 auf. Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die Register speichert, die Hardware-Threads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 weist zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608 auf. Gemäß einer Ausführungsform können die Sendeeinheit 607 und die Verzweigungseinheit 608 gleichzeitig als Sendeeinheit 530 und als Verzweigungseinheit 532 der Grafikausführungseinheit 508 aus 5B wirken.
  • Die Ausführungseinheit 600 weist auch eine Recheneinheit 610 auf, die mehrere verschiedene Typen funktioneller Einheiten aufweist. Gemäß einer Ausführungsform weist die Recheneinheit 610 eine ALU-Einheit 611 auf, die ein Array von Rechenlogikeinheiten aufweist. Die ALU-Einheit 611 kann dafür ausgelegt sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkommaoperationen auszuführen. Ganzzahl- und Gleitkommaoperationen können gleichzeitig ausgeführt werden. Die Recheneinheit 610 kann auch ein systolisches Array 612 und eine Mathematikeinheit 613 aufweisen. Das systolische Array 612 weist ein W-breites und D-tiefes Netz von Datenverarbeitungseinheiten auf, die verwendet werden können, um in systolischer Weise vektor- oder andere datenparallele Operationen auszuführen. Gemäß einer Ausführungsform kann das systolische Array 612 dafür ausgelegt sein, Matrixoperationen in der Art von Matrix-Skalarproduktoperationen auszuführen. Gemäß einer Ausführungsform unterstützt das systolische Array 612 16-Bit-Gleitkommaoperationen sowie 8-Bit- und 4-Bit-Ganzzahloperationen. Gemäß einer Ausführungsform kann das systolische Array 612 dafür ausgelegt sein, Maschinenlernoperationen zu beschleunigen. Gemäß solchen Ausführungsformen kann das systolische Array 612 mit Unterstützung für das bfloat-16-Bit-Gleitkommaformat ausgelegt sein. Gemäß einer Ausführungsform kann eine Mathematikeinheit 613 zur effizienten und weniger Energie als die ALU-Einheit 611 verbrauchenden Ausführung einer spezifischen Teilmenge mathematischer Operationen aufgenommen sein. Die Mathematikeinheit 613 kann eine Variante einer Mathematiklogik aufweisen, die in der Geteilte-Funktionen-Logik einer Grafikverarbeitungs-Engine vorgefunden werden kann, die von anderen Ausführungsformen bereitgestellt wird (beispielsweise Mathematiklogik 422 der Geteilte-Funktionen-Logik 420 aus 4). Gemäß einer Ausführungsform kann die Mathematikeinheit 613 dafür ausgelegt sein, 32-Bit- und 64-Bit-Gleitkommaoperationen auszuführen.
  • Die Thread-Steuereinheit 601 weist Logik zur Steuerung der Ausführung von Threads innerhalb der Ausführungseinheit auf. Die Thread-Steuereinheit 601 kann eine Thread-Arbitrierungslogik zum Einleiten, Unterbrechen und Präemptieren der Ausführung von Threads innerhalb der Ausführungseinheit 600 aufweisen. Die Thread-Zustandseinheit 602 kann verwendet werden, um den Thread-Zustand für Threads zu speichern, die für die Ausführung auf der Ausführungseinheit 600 zugewiesen werden. Das Speichern des Thread-Zustands innerhalb der Ausführungseinheit 600 ermöglicht die schnelle Präemption von Threads, wenn diese Threads blockiert oder inaktiv werden. Die Befehls-Abruf-/Vorabrufeinheit 603 kann Befehle von einem Befehls-Cache der Ausführungslogik höherer Ebene (beispielsweise Befehls-Cache 506 wie in 5A) abrufen. Die Befehls-Abruf-/Vorabrufeinheit 603 kann auch auf der Grundlage einer Analyse gegenwärtig ausgeführter Threads Vorabrufsanforderungen für in den Befehls-Cache zu ladende Befehle ausgeben. Die Befehlsdecodiereinheit 604 kann verwendet werden, um von den Recheneinheiten auszuführende Befehle zu decodieren. Gemäß einer Ausführungsform kann die Befehlsdecodiereinheit 604 als Sekundärdecodierer zur Decodierung komplexer Befehle zu Mikrooperationsbestandteilen verwendet werden.
  • Die Ausführungseinheit 600 weist zusätzlich eine Registerdatei 606 auf, die von Hardware-Threads verwendet werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Register in der Registerdatei 606 können über die für die Ausführung mehrerer gleichzeitiger Threads innerhalb der Recheneinheit 610 der Ausführungseinheit 600 verwendete Logik unterteilt werden. Die Anzahl der Logik-Threads, die von der Grafikausführungseinheit 600 ausgeführt werden können, ist nicht auf die Anzahl der Hardware-Threads beschränkt, und es können jedem Hardware-Thread mehrere Logik-Threads zugewiesen werden. Die Größe der Registerdatei 606 kann auf der Grundlage der Anzahl der unterstützten Hardware-Threads zwischen Ausführungsformen variieren. Gemäß einer Ausführungsform kann eine Registerumbenennung zur dynamischen Zuordnung von Registern zu Hardware-Threads verwendet werden.
  • 7 ist ein Blockdiagramm, das Grafikprozessor-Befehlsformate 700 gemäß einigen Ausführungsformen zeigt. Gemäß einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Befehlssatz mit Befehlen in mehreren Formaten. Die durch durchgezogene Linien angegebenen Kästchen zeigen die Komponenten, die im Allgemeinen in einem Ausführungseinheitsbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder die nur in einer Teilmenge der Befehle enthalten sind. Gemäß einigen Ausführungsformen besteht das beschriebene und dargestellte Befehlsformat 700 aus Makrobefehlen, und zwar in der Hinsicht, dass es sich dabei um Befehle handelt, die der Ausführungseinheit zugeführt werden, im Gegensatz zu Mikrooperationen, die sich aus einer Befehlsdecodierung ergeben, sobald der Befehl verarbeitet wird.
  • Gemäß einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Befehle in einem 128-Bit-Befehlsformat 710. Ein kompaktiertes 64-Bit-Befehlsformat 730 ist für einige Befehle auf der Grundlage des ausgewählten Befehls, Befehlsoptionen und der Anzahl der Operanden verfügbar. Das native 128-Bit-Befehlsformat 710 stellt Zugriff auf alle Befehlsoptionen bereit, während einige Optionen und Operationen auf das 64-Bit-Format 730 beschränkt sind. Die im 64-Bit-Format 730 verfügbaren nativen Befehle hängen von der Ausführungsform ab. Gemäß einigen Ausführungsformen wird der Befehl teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 kompaktiert. Die Ausführungseinheitshardware referenziert einen Satz von Kompaktierungstabellen auf der Grundlage der Indexwerte und verwendet die Kompaktierungstabellenausgaben zur Rekonstruktion eines nativen Befehls im 128-Bit-Befehlsformat 710. Es können auch andere Befehlsgrößen und -formate verwendet werden.
  • Für jedes Format definiert ein Befehlsoperationscode 712 die Operation, welche die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jeden Befehl parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit ansprechend auf einen Addierbefehl eine gleichzeitige Addieroperation über jeden Farbkanal, der ein Texturelement oder Bildelement repräsentiert, aus. Standardmäßig führt die Ausführungseinheit jeden Befehl über alle Datenkanäle der Operanden aus. Gemäß einigen Ausführungsformen ermöglicht ein Befehlssteuerfeld 714 eine Steuerung bestimmter Ausführungsoptionen in der Art der Kanalauswahl (beispielsweise Prädikation) und der Datenkanalreihenfolge (beispielsweise Vermischung). Für Befehle im 128-Bit-Befehlsformat 710 begrenzt ein Ausführungsgrößenfeld 716 die Anzahl der Datenkanäle, die parallel ausgeführt werden. Gemäß einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 für eine Verwendung im kompakten 64-Bit-Befehlsformat 730 nicht zur Verfügung.
  • Einige Ausführungseinheitsbefehle haben bis zu drei Operanden, einschließlich zweier Quelloperanden src0 720, src1 722 und ein Ziel 718. Gemäß einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelzielbefehle, worin eines der Ziele implizit ist. Datenmanipulationsbefehle können einen dritten Quelloperanden (beispielsweise SRC2 724) aufweisen, wobei der Befehlsoperationscode 712 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand eines Befehls kann ein mit dem Befehl übergebener unmittelbarer (beispielsweise hart codierter) Wert sein.
  • Gemäß einigen Ausführungsformen weist das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das beispielsweise spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits im Befehl bereitgestellt.
  • Gemäß einigen Ausführungsformen weist das 128-Bit-Befehlsformat 710 ein Zugriffs-/Adressmodusfeld 726 auf, das einen Adressmodus und/oder einen Zugriffsmodus für den Befehl spezifiziert. Gemäß einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für den Befehl zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi unter Einschluss eines 16-Byte-ausgerichteten Zugriffsmodus und eines 1-Byte-ausgerichteten Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung des Befehlsoperanden festlegt. Beispielsweise kann der Befehl in einem ersten Modus eine Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden, und in einem zweiten Modus eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
  • Gemäß einer Ausführungsform legt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726 fest, ob der Befehl eine direkte oder indirekte Adressierung verwenden soll. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen Bits im Befehl direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden auf der Grundlage eines Adressregisterwerts und eines unmittelbaren Adressfelds im Befehl berechnet werden.
  • Gemäß einigen Ausführungsformen werden Befehle auf der Grundlage von Operationscode-712-Bit-Arrays gruppiert, um die Operationscodedecodierung 740 zu vereinfachen. Für einen 8-Bit-Operationscode ermöglichen es die Bits 4, 5 und 6, dass die Ausführungseinheit den Typ des Operationscodes bestimmt. Die dargestellte genaue Operationscodegruppierung dient lediglich als Beispiel. Gemäß einigen Ausführungsformen weist eine Verschiebungs- und Logikoperationscodegruppe 742 Datenverschiebungs- und Logikbefehle (beispielsweise Verschieben (mov), Vergleichen (cmp)) auf. Gemäß einigen Ausführungsformen teilt sich die Verschiebungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB), wobei Verschiebungs(mov)-Befehle in der Form 0000xxxxb vorliegen und Logikbefehle in der Form 0001xxxxb vorliegen. Eine Ablaufsteuerungs-Befehlsgruppe 744 (beispielsweise Aufrufen, Springen (jmp)) weist Befehle in der Form 0010xxxxb (beispielsweise 0x20) auf. Eine vermischte Befehlsgruppe 746 weist eine Mischung von Befehlen unter Einschluss von Synchronisationsbefehlen (beispielsweise Warten, Senden) in der Form 0011xxxxb (beispielsweise 0x30) auf. Eine parallele mathematische Befehlsgruppe 748 weist komponentenweise Rechenbefehle (beispielsweise Addieren, Multiplizieren (mul)) in der Form 0100xxxxb (beispielsweise 0x40) auf. Die parallele mathematische Gruppe 748 führt die Rechenoperationen parallel über Datenkanäle aus. Die Vektormathematikgruppe 750 weist Rechenbefehle (beispielsweise dp4) in der Form 0101xxxxb (beispielsweise 0x50) auf. Die Vektormathematikgruppe führt Berechnungen in der Art von Skalarproduktberechnungen an Vektoroperanden aus. Die dargestellte Operationscodedecodierung 740 kann gemäß einer Ausführungsform verwendet werden, um festzustellen, welcher Teil einer Ausführungseinheit verwendet wird, um einen decodierten Befehl auszuführen. Beispielsweise können einige Befehle als systolische Befehle zugewiesen werden, die von einem systolischen Array ausgeführt werden. Andere Befehle in der Art von Raytracing-Befehlen (nicht dargestellt) können zu einem Raytracing-Kern oder einer Raytracing-Logik innerhalb eines Slices oder einer Partition der Ausführungslogik geleitet werden.
  • Grafik-Pipeline
  • 8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente aus 8, welche die gleichen Bezugszahlen (oder Namen) aufweisen wie die Elemente einer anderen hier angeführten Figur, können ähnlich zu den hier beschriebenen arbeiten oder funktionieren, sind jedoch nicht darauf beschränkt.
  • Gemäß einigen Ausführungsformen weist der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeige-Engine 840, eine Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870 auf. Gemäß einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Verarbeitungskerne für allgemeine Zwecke aufweist. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht dargestellt) oder durch Befehle, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden, gesteuert. Gemäß einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungskomponenten in der Art anderer Grafikprozessoren oder Prozessoren für allgemeine Zwecke. Befehle von der Ringverbindung 802 werden durch einen Befehls-Streamer 803 interpretiert, der Befehle einzelnen Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 zuführt.
  • Gemäß einigen Ausführungsformen leitet der Befehls-Streamer 803 den Betrieb eines Vertex-Abrufers 805, der Vertex-Daten aus dem Speicher liest und vom Befehls-Streamer 803 bereitgestellte Vertex-Verarbeitungsbefehle ausführt. Gemäß einigen Ausführungsformen stellt der Vertex-Abrufer 805 einem Vertex-Shader 807, der an jedem Vertex eine Koordinatenraumtransformation und Lichtoperationen ausführt, Vertex-Daten bereit. Gemäß einigen Ausführungsformen führen der Vertex-Abrufer 805 und der Vertex-Shader 807 Vertex-Verarbeitungsbefehle durch Übergeben von Ausführungs-Threads an Ausführungseinheiten 852A - 852B über einen Thread-Abfertiger 831 aus.
  • Gemäß einigen Ausführungsformen sind die Ausführungseinheiten 852A - 852B ein Array von Vektorprozessoren mit einem Befehlssatz zur Ausführung von Grafik- und Medienoperationen. Gemäß einigen Ausführungsformen weisen die Ausführungseinheiten 852A - 852B einen angegliederten L1-Cache 851 auf, der für jedes Array spezifisch ist oder zwischen den Arrays geteilt wird. Der Cache kann als Daten-Cache, Befehls-Cache oder einzelner Cache ausgelegt sein, der unterteilt ist, um Daten und Befehle in verschiedenen Partitionen aufzunehmen.
  • Gemäß einigen Ausführungsformen weist die Geometrie-Pipeline 820 Tesselationskomponenten zur Ausführung einer hardwarebeschleunigten Tesselation von 3D-Objekten auf. Gemäß einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tesselationsoperationen. Ein programmierbarer Domain-Shader 817 stellt eine Backend-Beurteilung der Tesselationsausgabe bereit. Ein Tesselator 813 arbeitet auf Anweisung des Hull-Shaders 811 und enthält Logik für spezielle Zwecke zur Erzeugung eines Satzes detaillierter geometrischer Objekte auf der Grundlage eines groben geometrischen Modells, das der Geometrie-Pipeline 820 als Eingabe bereitgestellt wird. Gemäß einigen Ausführungsformen können Tesselationskomponenten (beispielsweise Hull-Shader 811, Tesselator 813 und Domain-Shader 817) umgangen werden, wenn die Tesselation nicht verwendet wird.
  • Gemäß einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrie-Shader 819 über einen oder mehrere Threads verarbeitet werden, die an Ausführungseinheiten 852A - 852B übergeben werden, oder sie können direkt zum Clipper 829 weitergeleitet werden. Gemäß einigen Ausführungsformen bearbeitet der Geometrie-Shader ganze geometrische Objekte statt Vertices oder Abschnitte von Vertices wie in vorhergehenden Stufen der Grafik-Pipeline. Falls die Tesselation deaktiviert wird, empfängt der Geometrie-Shader 819 eine Eingabe vom Vertex-Shader 807. Gemäß einigen Ausführungsformen ist der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmierbar, um eine Geometrie-Tesselation auszuführen, falls die Tesselationseinheiten deaktiviert werden.
  • Vor der Rasterung bearbeitet ein Clipper 829 Vertex-Daten. Der Clipper 829 kann ein Festfunktions-Clipper oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. Gemäß einigen Ausführungsformen veranlasst eine Rasterungs- und Tiefentestkomponente 873 in der Renderausgabe-Pipepline 870 Pixel-Shader, die geometrischen Objekte in Pro-Pixel-Repräsentationen umzuwandeln. Gemäß einigen Ausführungsformen ist die Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. Gemäß einigen Ausführungsformen kann eine Anwendung die Rasterungs- und Tiefentestkomponente 873 umgehen und auf nicht gerasterte Vertex-Daten über eine Stromausgabeeinheit 823 zugreifen.
  • Der Grafikerzeuger 800 hat einen Verbindungsbus, ein Verbindungsnetz oder einen anderen Verbindungsmechanismus, der es ermöglicht, Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors zu übertragen. Gemäß einigen Ausführungsformen verbinden sich die Ausführungseinheiten 852A - 852B und zugeordnete Logikeinheiten (beispielsweise L1-Cache 851, Sampler 854, Textur-Cache 858 usw.) über einen Daten-Port 856 zur Ausführung eines Speicherzugriffs und einer Kommunikation mit Renderausgabe-Pipeline-Komponenten des Prozessors. Gemäß einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A - 852B jeweils getrennte Speicherzugriffswege auf. Gemäß einer Ausführungsform kann der Textur-Cache 858 auch als ein Sampler-Cache ausgelegt sein.
  • Gemäß einigen Ausführungsformen enthält die Renderausgabe-Pipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die Vertex-basierte Objekte in eine zugeordnete pixelbasierte Repräsentation umwandelt. Gemäß einigen Ausführungsformen weist die Rasterungslogik eine Fenster-/Maskierungseinheit zur Ausführung einer Festfunktions-Dreiecks- und Linienrasterung auf. Ein zugeordneter Render-Cache 878 und Tiefen-Cache 879 sind gemäß einigen Ausführungsformen auch verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten aus, wenngleich in einigen Fällen Pixeloperationen in Zusammenhang mit 2D-Operationen (beispielsweise Bitblockbildübertragungen mit Überblenden) von der 2D-Engine 841 ausgeführt werden oder zur Anzeigezeit durch Überlagerungsanzeigeebenen von der Anzeigesteuereinrichtung 843 ersetzt werden. Gemäß einigen Ausführungsformen ist ein geteilter L3-Cache 875 für alle Grafikkomponenten verfügbar, wodurch das Teilen von Daten ohne die Verwendung von Hauptsystemspeicher ermöglicht wird.
  • Gemäß einigen Ausführungsformen weist die Grafikprozessor-Medien-Pipeline 830 eine Medien-Engine 837 und ein Video-Frontend 834 auf. Gemäß einigen Ausführungsformen empfängt das Video-Frontend 834 Pipeline-Befehle vom Befehls-Streamer 803. Gemäß einigen Ausführungsformen weist die Medien-Pipeline 830 einen getrennten Befehls-Streamer auf. Gemäß einigen Ausführungsformen verarbeitet das Video-Frontend 834 Medienbefehle, bevor sie zur Medien-Engine 837 gesendet werden. Gemäß einigen Ausführungsformen weist die Medien-Engine 837 eine Thread-Hervorbringungsfunktionalität zur Hervorbringung von Threads auf, um sie über den Thread-Abfertiger 831 zur Thread-Ausführungslogik 850 zu übermitteln.
  • Gemäß einigen Ausführungsformen weist der Grafikprozessor 800 eine Anzeige-Engine 840 auf. Gemäß einigen Ausführungsformen befindet sich die Anzeige-Engine 840 außerhalb des Prozessors 800 und koppelt über die Ringverbindung 802 oder einen anderen Verbindungsbus oder ein anderes Verbindungsnetz mit dem Grafikprozessor. Gemäß einigen Ausführungsformen weist die Anzeige-Engine 840 eine 2D-Engine 841 und eine Anzeigesteuereinrichtung 843 auf. Gemäß einigen Ausführungsformen enthält die Anzeige-Engine 840 Logik für spezielle Zwecke, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. Gemäß einigen Ausführungsformen ist die Anzeigesteuereinrichtung 843 mit einer Anzeigevorrichtung (nicht dargestellt) verbunden, wobei es sich um eine systemintegrierte Anzeigevorrichtung handeln kann, wie bei einem Laptopcomputer, oder um eine externe Anzeigevorrichtung, die über einen Anzeigevorrichtungsverbinder angeschlossen ist.
  • Gemäß einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 konfigurierbar, um Operationen auf der Grundlage mehrerer Grafik- und Medienprogrammierschnittstellen auszuführen, und für keine Anwendungsprogrammierschnittstelle (API) spezifisch. Gemäß einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. Gemäß einigen Ausführungsformen wird Unterstützung für die Open-Graphics-Library(OpenGL)-, Open-Computing-Language(OpenCL)- und/oder die Vulkan-Graphics-and-Compute-API, die alle von Khronos Group sind, bereitgestellt. Gemäß einigen Ausführungsformen kann Unterstützung auch für die Direct3D-Bibliothek von Microsoft Corporation bereitgestellt werden. Gemäß einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Eine Unterstützung kann auch für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, falls eine Abbildung von der Pipeline der künftigen API auf die Pipeline des Grafikprozessors vorgenommen werden kann.
  • Grafik-PipelineProgrammierung
  • 9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 gemäß einigen Ausführungsformen zeigt. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform zeigt. Die in durchgezogenen Linien dargestellten Kästchen in 9A zeigen die Komponenten, die allgemein in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten aufweisen, die optional sind oder nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 aus 9A weist Daten-Arrays zur Identifikation eines Clients 902, eines Befehlsoperationscodes (opcodes) 904 und Daten 906 für den Befehl auf. Ein Sub-Operationscode 905 und eine Befehlsgröße 908 sind auch in einigen Befehlen enthalten.
  • Gemäß einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit der Grafikvorrichtung, welche die Befehlsdaten verarbeitet. Gemäß einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Client-Array jedes Befehls zur Bestimmung der Weiterverarbeitung des Befehls und zum Weiterleiten der Befehlsdaten zur geeigneten Client-Einheit. Gemäß einigen Ausführungsformen weisen die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Render-Einheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit auf. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, welche die Befehle verarbeitet. Sobald der Befehl von der Client-Einheit empfangen wird, liest die Client-Einheit den Operationscode 904 und, falls vorhanden, den Sub-Operationscode 905, um die auszuführende Operation festzulegen. Die Client-Einheit führt den Befehl unter Verwendung von Informationen im Daten-Array 906 aus. Für einige Befehle wird eine explizite Befehlsgröße 908 zur Spezifikation der Größe des Befehls erwartet. Gemäß einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe wenigstens einiger der Befehle auf der Grundlage des Befehls-Operationscodes. Gemäß einigen Ausführungsformen werden Befehle durch Mehrfache eines Doppelworts ausgerichtet. Es können auch andere Befehlsformate verwendet werden.
  • Das Flussdiagramm in 9B zeigt eine beispielhafte Grafikprozessor-Befehlssequenz 910. Gemäß einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems gemäß einer Ausführungsform eines Grafikprozessors eine Version der Befehlssequenz, die wie dargestellt einen Satz von Grafikoperationen einrichtet, ausführt und beendet. Eine Musterbefehlssequenz wird nur als Beispiel dargestellt und beschrieben, weil Ausführungsformen nicht auf diese spezifischen Befehle oder diese Befehlssequenz beschränkt sind. Überdies können die Befehle als Befehlsstapel in einer Befehlssequenz erteilt werden, so dass der Grafikprozessor die Befehlssequenz zumindest teilweise gleichzeitig verarbeitet.
  • Gemäß einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipeline-Räumungsbefehl 912 beginnen, um zu bewirken, dass jede aktive Grafik-Pipeline die gegenwärtig anhängigen Befehle für die Pipeline beendet. Gemäß einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipeline-Räumung wird ausgeführt, um zu bewirken, dass die aktive Grafik-Pipeline jegliche anhängigen Befehle abschließt. Ansprechend auf eine Pipeline-Räumung pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungs-Engines anhängige Operationen abgeschlossen haben und die relevanten Lese-Caches ungültig gemacht wurden. Optional können jegliche Daten im Render-Cache, die als „schmutzig“ markiert sind, in den Speicher geräumt werden. Gemäß einigen Ausführungsformen kann der Pipeline-Räumungsbefehl 912 für die Pipeline-Synchronisation verwendet werden oder verwendet werden, bevor der Grafikprozessor in einen Zustand mit geringer Leistungsaufnahme versetzt wird.
  • Gemäß einigen Ausführungsformen wird ein Pipeline-Wählbefehl 913 verwendet, wenn es eine Befehlssequenz erforderlich macht, dass der Grafikprozessor explizit zwischen Pipelines schaltet. Gemäß einigen Ausführungsformen ist ein Pipeline-Wählbefehl 913 nur einmal innerhalb eines Ausführungszusammenhangs erforderlich, bevor Pipeline-Befehle erteilt werden, es sei denn, dass der Zusammenhang Befehle für beide Pipelines ausgeben soll. Gemäß einigen Ausführungsformen ist ein Pipeline-Räumungsbefehl 912 unmittelbar vor einem Pipeline-Schalten über den Pipeline-Wählbefehl 913 erforderlich.
  • Gemäß einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medien-Pipeline 924 zu programmieren. Gemäß einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. Gemäß einer Ausführungsform wird der Pipeline-Steuerbefehl 914 für die Pipeline-Synchronisation und für das Löschen von Daten aus einem oder mehreren Cache-Speichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Befehlsstapels verwendet.
  • Gemäß einigen Ausführungsformen werden Return-Puffer-Zustandsbefehle 916 verwendet, um einen Satz von Return-Puffern für die jeweiligen Pipelines für das Schreiben von Daten zu konfigurieren. Einige Pipeline-Operationen erfordern das Zuweisen, die Auswahl oder die Konfiguration eines oder mehrerer Return-Buffer, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. Gemäß einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Return-Buffer zum Speichern von ausgegebenen Daten und zur Ausführung einer Kommunikation zwischen Threads. Gemäß einigen Ausführungsformen umfasst der Return-Buffer-Zustand 916 das Auswählen der Größe und der Anzahl der Return-Buffer zur Verwendung für einen Satz von Pipeline-Operationen.
  • Die restlichen Befehle in der Befehlssequenz unterscheiden sich auf der Grundlage der aktiven Pipeline für Operationen. Auf der Grundlage einer Pipeline-Bestimmung 920 wird die Befehlssequenz für die 3D-Pipeline 922 beginnend mit dem 3D-Pipeline-Zustand 930 oder die Medien-Pipeline 924 beginnend mit dem Medien-Pipeline-Zustand 940 eingerichtet.
  • Die Befehle zur Konfiguration des 3D-Pipeline-Zustands 930 umfassen 3D-Zustandsfestlegungsbefehle für den Vertex-Puffer-Zustand, den Vertex-Elementzustand, den Konstante-Farbe-Zustand, den Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Grundformbefehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf der Grundlage der bestimmten gerade verwendeten 3D-API festgelegt. Gemäß einigen Ausführungsformen sind 3D-Pipeline-Zustands-930-Befehle auch in der Lage, selektiv bestimmte Pipeline-Elemente zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
  • Gemäß einigen Ausführungsformen wird der 3D-Grundform-932-Befehl verwendet, um 3D-Grundformen zuzuweisen, die von der 3D-Pipeline zu verarbeiten sind. Befehle und zugeordnete Parameter, die durch den 3D-Grundform-932-Befehl an den Grafikprozessor übergeben werden, werden zur Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die 3D-Grundform-932-Befehlsdaten für die Erzeugung von Vertex-Datenstrukturen. Die Vertex-Datenstrukturen werden in einem oder mehreren Return-Buffern gespeichert. Gemäß einigen Ausführungsformen wird der 3D-Grundform-932-Befehl zur Ausführung von Vertex-Operationen an 3D-Grundformen über Vertex-Shader verwendet. Zur Verarbeitung von Vertex-Shadern übergibt die 3D-Pipeline 922 Shader-Ausführungs-Threads an die Grafikprozessor-Ausführungseinheiten.
  • Gemäß einigen Ausführungsformen wird die 3D-Pipeline 922 durch einen Ausführungsbefehl oder ein Ausführungsereignis 934 ausgelöst. Gemäß einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. Gemäß einigen Ausführungsformen wird die Ausführung durch einen „Go“- oder „Kick“-Befehl in der Befehlssequenz ausgelöst. Gemäß einer Ausführungsform wird die Befehlsausführung durch die Verwendung eines Pipeline-Synchronisationsbefehls zum Räumen der Befehlssequenz durch die Grafik-Pipeline ausgelöst. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Grundformen aus. Sobald die Operationen abgeschlossen sind, werden die sich ergebenden geometrischen Objekte gerastert und färbt die Pixel-Engine die sich ergebenden Pixel. Zusätzliche Befehle zur Steuerung des Pixel-Shadings und Pixel-Backend-Operationen können für diese Operationen auch aufgenommen werden.
  • Gemäß einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Weg der Medien-Pipeline 924, wenn Medienoperationen ausgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und die spezifische Art der Programmierung für die Medien-Pipeline 924 von den auszuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung an die Medien-Pipeline ausgelagert werden. Gemäß einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und kann eine Mediendecodierung ganz oder teilweise unter Verwendung von Ressourcen ausgeführt werden, die von einem oder mehreren Verarbeitungskernen für allgemeine Zwecke bereitgestellt werden. Gemäß einer Ausführungsform weist die Medien-Pipeline auch Elemente für Operationen einer Grafikprozessoreinheit für allgemeine Zwecke (GPGPU) auf, wobei der Grafikprozessor zur Ausführung von SIMD-Vektoroperationen unter Verwendung von Rechen-Shader-Programmen verwendet wird, die sich nicht explizit auf das Rendern von Grafikgrundformen beziehen.
  • Gemäß einigen Ausführungsformen ist die Medien-Pipeline 924 ähnlich ausgelegt wie die 3D-Pipeline 922. Ein Satz von Befehlen zur Konfiguration des Medien-Pipeline-Zustands 940 wird vor den Medienobjektbefehlen 942 zur Befehlswarteschlange übermittelt oder in diese gegeben. Gemäß einigen Ausführungsformen weisen Befehle für den Medien-Pipeline-Zustand 940 Daten zur Konfiguration der Medien-Pipeline-Elemente, die für die Verarbeitung der Medienobj ekte verwendet werden, auf. Dies umfasst Daten zur Konfiguration der Videodecodier- und Videocodierlogik innerhalb der Medien-Pipeline in der Art eines Codier- oder Decodierformats. Gemäß einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung eines oder mehrerer Zeiger auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
  • Gemäß einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte umfassen Speicherpuffer, die zu verarbeitende Videodaten enthalten. Gemäß einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände vor der Erteilung eines Medienobjektbefehls 942 gültig sein. Sobald der Pipeline-Zustand konfiguriert wurde und Medienobjektbefehle 942 in eine Warteschlange eingereiht wurden, wird die Medien-Pipeline 924 durch einen Ausführungsbefehl 944 oder ein gleichwertiges Ausführungsereignis (beispielsweise Registerschreiben) ausgelöst. Die Ausgabe von der Medien-Pipeline kann dann durch von der 3D-Pipeline 922 oder der Medien-Pipeline 924 bereitgestellte Operationen nachbearbeitet werden. Gemäß einigen Ausführungsformen werden GPGPU-Operationen in ähnlicher Weise wie Medienoperationen konfiguriert und ausgeführt.
  • Grafiksoftwarearchitektur
  • 10 zeigt eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einigen Ausführungsformen. Gemäß einigen Ausführungsformen weist die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und wenigstens einen Prozessor 1030 auf. Gemäß einigen Ausführungsformen weist der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Prozessorkerne 1034 für allgemeine Zwecke auf. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
  • Gemäß einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Befehle 1012 aufweisen. Die Shader-Sprachbefehle können in einer Shader-Sprache hoher Ebene in der Art der High-Level Shader Language (HLSL) von Direct3D, der OpenGL Shader Language (GLSL) usw. vorliegen. Die Anwendung weist auch ausführbare Befehle 1014 in einer für die Ausführung durch den Prozessorkern 1034 für allgemeine Zwecke geeigneten Maschinensprache auf. Die Anwendung weist auch durch Vertex-Daten definierte Grafikobjekte 1016 auf.
  • Gemäß einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft®-Windows®-Betriebssystem von Microsoft Corporation, ein proprietäres UNIX-artiges Betriebssystem oder ein Open-Source-UNIX-artiges Betriebssystem unter Verwendung einer Variante des Linux-Kerns. Das Betriebssystem 1020 kann eine Grafik-API 1022 in der Art der Direct3D-API, der OpenGL-API oder der Vulkan-API unterstützen. Wenn die Direct3D-API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shader-Compiler 1024 zur Kompilierung jeglicher Shader-Befehle 1012 in HLSL in eine Shader-Sprache niedrigerer Ebene. Die Kompilierung kann eine Just-in-time(JIT)-Kompilerung sein, oder die Anwendung kann eine Shader-Vorkompilierung ausführen. Gemäß einigen Ausführungsformen werden Shader hoher Ebene während der Kompilierung der 3D-Grafikanwendung 1010 in Shader niedrigerer Ebene kompiliert. Gemäß einigen Ausführungsformen werden die Shader-Befehle 1012 in einer Zwischenform bereitgestellt, wie einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
  • Gemäß einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Backend-Shader-Compiler 1027 zum Umwandeln der Shader-Befehle 1012 in eine hardwarespezifische Repräsentation. Wenn die OpenGL-API verwendet wird, werden Shader-Befehle 1012 in der GLSL-Sprache hoher Ebene zur Kompilierung an den Benutzermodus-Grafiktreiber 1026 übergeben. Gemäß einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystemkernmodusfunktionen 1028 zur Kommunikation mit einem Kernmodus-Grafiktreiber 1029. Gemäß einigen Ausführungsformen kommuniziert der Kernmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032 zur Übermittlung von Befehlen und Anweisungen.
  • IP-Kernimplementationen
  • Ein oder mehrere Aspekte wenigstens einer Ausführungsform können durch repräsentativen Code implementiert werden, der auf einem maschinenlesbaren Medium gespeichert ist, wodurch Logik innerhalb einer integrierten Schaltung in der Art eines Prozessors repräsentiert und/oder definiert wird. Beispielsweise kann das maschinenlesbare Medium Befehle aufweisen, die verschiedene Logiken innerhalb des Prozessors repräsentieren. Wenn sie von einer Maschine gelesen werden, können die Befehle die Maschine veranlassen, die Logik zur Ausführung der hier beschriebenen Techniken zu bilden. Solche Repräsentationen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem physischen, maschinenlesbaren Medium als Hardwaremodell, das die Struktur der integrierten Schaltung beschreibt, gespeichert werden können. Das Hardwaremodell kann verschiedenen Kunden oder Herstellungseinrichtungen zugeführt werden, welche das Hardwaremodell auf Herstellungsmaschinen laden, welche die integrierte Schaltung herstellen. Die integrierte Schaltung kann so hergestellt werden, dass sie in Zusammenhang mit jeglichen der hier beschriebenen Ausführungsformen beschriebene Operationen ausführt.
  • 11A ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 zeigt, das für die Herstellung einer integrierten Schaltung zur Ausführung von Operationen gemäß einer Ausführungsform verwendet werden kann. Das IP-Kernentwicklungssystem 1100 kann für die Erzeugung modularer wiederverwendbarer Entwürfe verwendet werden, die in einen größeren Entwurf aufgenommen oder zur Bildung einer gesamten integrierten Schaltung (beispielsweise einer SoC-integrierten-Schaltung) verwendet werden können. Eine Entwurfseinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kernentwurfs in einer Programmiersprache hoher Ebene (beispielsweise C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu entwickeln, zu testen und zu überprüfen. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Zeitsimulationen aufweisen. Ein Register-übertragungsebenen(RTL)-Entwurf 1115 kann dann vom Simulationsmodell 1112 erzeugt oder synthetisiert werden. Der RTL-Entwurf 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, welche den Fluss von Digitalsignalen zwischen Hardwareregistern, einschließlich der zugeordneten Logik, die unter Verwendung der modellierten Digitalsignale ausgeführt wird, modelliert. Zusätzlich zu einem RTL-Entwurf 1115 können auch Entwürfe niedrigerer Ebene auf der Logikebene oder der Transistorebene erzeugt, entworfen oder synthetisiert werden. Demgemäß können die bestimmten Einzelheiten des anfänglichen Entwurfs und der Simulation variieren.
  • Der RTL-Entwurf 1115 oder eine Entsprechung kann ferner durch die Entwurfseinrichtung zu einem Hardwaremodell 1120, das in einer Hardwarebeschreibungssprache (HDL) vorliegen kann, oder zu einer anderen Repräsentation physischer Entwurfsdaten synthetisiert werden. Die HDL kann ferner simuliert oder getestet werden, um den IP-Kernentwurf zu überprüfen. Der IP-Kernentwurf kann zur Auslieferung an eine Herstellungseinrichtung 1165 einer dritten Partei unter Verwendung eines nicht flüchtigen Speichers 1140 (beispielsweise Festplatte, Flash-Speicher oder irgendein nichtflüchtiges Speichermedium) gespeichert werden. Alternativ kann der IP-Kernentwurf (beispielsweise über das Internet) über eine Drahtverbindung 1150 oder eine drahtlose Verbindung 1160 übertragen werden. Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kernentwurf beruht. Die hergestellte integrierte Schaltung kann dafür ausgelegt werden, Operationen gemäß zumindest einer hier beschriebenen Ausführungsform auszuführen.
  • 11B zeigt eine seitliche Schnittansicht einer Integrierte-Schaltungs-Baugruppenanordnung 1170 gemäß einigen hier beschriebenen Ausführungsformen. Die Integrierte-Schaltungs-Baugruppenanordnung 1170 zeigt eine Implementation eines oder mehrerer Prozessoren oder Beschleunigervorrichtungen, wie hier beschrieben. Die Baugruppenanordnung 1170 weist mehrere Einheiten von Hardwarelogik 1172, 1174 auf, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in einer konfigurierbaren Logik- oder Festfunktionalitäts-Logikhardware implementiert sein und einen oder mehrere Abschnitte eines oder mehrerer Prozessorkerne, eines oder mehrerer Grafikprozessoren oder anderer hier beschriebener Beschleunigervorrichtungen aufweisen. Jede Logikeinheit 1172, 1174 kann innerhalb eines Halbleiter-Dies implementiert und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu übertragen und Verbindungen aufweisen, die Kontakthöcker oder - säulen einschließen können, jedoch nicht darauf beschränkt sind. Gemäß einigen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale beispielsweise in der Art von Ein-/Ausgabe(E/A)-Signalen und/oder Strom- oder Massesignalen in Zusammenhang mit dem Betrieb der Logik 1172, 1174 zu übertragen. Gemäß einigen Ausführungsformen ist das Substrat 1180 ein epoxidbasiertes Laminatsubstrat. Das Substrat 1180 kann gemäß anderen Ausführungsformen andere geeignete Typen von Substraten aufweisen. Die Baugruppenanordnung 1170 kann über eine Baugruppenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Baugruppenverbindung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen in der Art einer Hauptplatine, eines anderen Chipsatzes oder eines Mehrchipmoduls zu übertragen.
  • Gemäß einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Bridge 1182 gekoppelt, die dafür ausgelegt ist, elektrische Signale zwischen den Logiken 1172, 1174 zu übertragen. Die Bridge 1182 kann eine dichte Verbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Bridge 1182 kann ein Bridge-Substrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungswegmerkmale können auf dem Bridge-Substrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen den Logiken 1172, 1174 bereitzustellen.
  • Wenngleich zwei Logikeinheiten 1172, 1174 und eine Bridge 1182 dargestellt sind, können hier beschriebene Ausführungsformen mehr oder weniger Logikeinheiten auf einem oder mehreren Dies aufweisen. Der eine oder die mehreren Dies können durch null oder mehr Bridges verbunden sein, weil die Bridge 1182 fortgelassen werden kann, wenn die Logik auf einem einzigen Die ausgebildet ist. Alternativ können mehrere Dies oder Logikeinheiten durch eine oder mehrere Bridges verbunden werden. Zusätzlich können mehrere Logikeinheiten, Dies und Bridges in anderen möglichen Konfigurationen, einschließlich dreidimensionaler Konfigurationen, miteinander verbunden werden.
  • 11C zeigt eine Baugruppenanordnung 1190, die mehrere Einheiten mit einem Substrat 1180 (beispielsweise Basis-Die) verbundener Hardwarelogik-Chiplets aufweist. Eine Grafikverarbeitungseinheit, ein Parallelprozessor und/oder ein Rechenbeschleuniger, wie hier verwendet, kann aus verschiedenen Silicium-Chiplets, die getrennt hergestellt werden, zusammengesetzt werden. In diesem Zusammenhang ist ein Chiplet eine zumindest teilweise gekapselte integrierte Schaltung, die verschiedene Logikeinheiten aufweist, die mit anderen Chiplets zu einer größeren Baugruppe zusammengesetzt werden können. Ein diversifizierter Satz von Chiplets mit verschiedenen IP-Kernlogiken kann zu einer einzigen Vorrichtung zusammengesetzt werden. Zusätzlich können die Chiplets unter Verwendung einer aktiven Verdrahtungslagentechnologie in einen Basis-Die oder ein Basis-Chiplet integriert werden. Die hier beschriebenen Konzepte ermöglichen die Verbindung und Kommunikation zwischen den verschiedenen IP-Formen innerhalb der GPU. IP-Kerne können unter Verwendung verschiedener Prozesstechnologien hergestellt und während der Herstellung zusammengesetzt werden, wodurch die Komplexität des Zusammenführens mehrerer IPs, insbesondere auf einem großen SoC mit mehreren IP-Spielarten, zum selben Herstellungsprozess vermieden wird. Die Ermöglichung der Verwendung der Prozesstechnologien verbessert die Zeit bis zur Markteinführung und bietet eine kostenwirksame Art zur Erzeugung mehrerer Produkt-SKUs. Zusätzlich sind die nicht aggregierten IPs besser dafür geeignet, unabhängig stromgeschaltet zu werden, und können Komponenten, die bei einer gegebenen Arbeitslast nicht verwendet werden, abgeschaltet werden, wodurch der Gesamtstromverbrauch verringert wird.
  • Die Hardwarelogik-Chiplets können Hardwarelogik-Chiplets 1172 für spezielle Zwecke, Logik- oder E/A-Chiplets 1174 und/oder Speicher-Chiplets 1175 umfassen. Die Hardwarelogik-Chiplets 1172 und die Logik- oder E/A-Chiplets 1174 können zumindest teilweise in konfigurierbarer Logik- oder Festfunktionalitätslogik-Hardware implementiert werden und einen oder mehrere Teile von jeglichen des einen oder der mehreren Prozessorkerne, des einen oder der mehreren Grafikprozessoren, des einen oder der mehreren Parallelprozessoren oder anderer Beschleunigervorrichtungen, wie hier beschrieben, aufweisen. Die Speicher-Chiplets 1175 können ein DRAM(beispielsweise GDDR, HBM)-Speicher oder ein Cache(SRAM)-Speicher sein.
  • Jedes Chiplet kann als ein getrennter Halbleiter-Die hergestellt werden und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt werden. Die Verbindungsstruktur 1173 kann dafür ausgelegt sein, elektrische Signale zwischen den verschiedenen Chiplets und Logik innerhalb des Substrats 1180 zu übertragen. Die Verbindungsstruktur 1173 kann Zwischenverbindungen beispielsweise in der Art von Kontakthöckern oder -säulen, jedoch ohne Einschränkung darauf, aufweisen. Gemäß einigen Ausführungsformen kann die Verbindungsstruktur 1173 dafür ausgelegt sein, elektrische Signale beispielsweise in der Art von Ein-/Ausgabe(E/A)-Signalen und/oder Strom- oder Massesignalen in Zusammenhang mit dem Betrieb der Logik-, E/A- und Speicher-Chiplets zu übertragen.
  • Gemäß einigen Ausführungsformen ist das Substrat 1180 ein epoxidbasiertes Laminatsubstrat. Das Substrat 1180 kann gemäß anderen Ausführungsformen andere geeignete Typen von Substraten aufweisen. Die Baugruppenanordnung 1190 kann über eine Baugruppenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Baugruppenverbindung 1183 kann mit einer Fläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Vorrichtungen in der Art einer Hauptplatine, eines anderen Chipsatzes oder eines Mehrchipmoduls zu übertragen.
  • Gemäß einigen Ausführungsformen können ein Logik- oder E/A-Chiplet 1174 und ein Speicher-Chiplet 1175 elektrisch über eine Bridge 1187 gekoppelt sein, die dafür ausgelegt ist, elektrische Signale zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 zu übertragen. Die Bridge 1187 kann eine dichte Verbindungsstruktur sein, die einen Weg für elektrische Signale bereitstellt. Die Bridge 1187 kann ein Bridge-Substrat aufweisen, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungswegmerkmale können auf dem Bridge-Substrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen dem Logik- oder E/A-Chiplet 1174 und einem Speicher-Chiplet 1175 bereitzustellen. Die Bridge 1187 kann auch als Silicium-Bridge oder Zwischenverbindungs-Bridge bezeichnet werden. Beispielsweise ist die Bridge 1187 gemäß einigen Ausführungsformen eine eingebettete Mehr-Die-Zwischenverbindungs-Bridge (EMIB). Gemäß einigen Ausführungsformen kann die Bridge 1187 einfach eine direkte Verbindung von einem Chiplet zu einem anderen Chiplet sein.
  • Das Substrat 1180 kann Hardwarekomponenten für die E/A 1191, den Cache-Speicher 1192 und andere Hardwarelogik 1193 aufweisen. Ein Fabric 1185 kann in das Substrat 1180 eingebettet sein, um eine Kommunikation zwischen den verschiedenen Logik-Chiplets und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. Gemäß einer Ausführungsform können die E/A 1191, das Fabric 1185, Cache-, Bridge- und andere Hardwarelogik 1193 in einen Basis-Die integriert sein, der auf das Substrat 1180 geschichtet ist.
  • Gemäß verschiedenen Ausführungsformen kann eine Baugruppenanordnung 1190 eine geringere oder eine größere Anzahl von Komponenten und Chiplets aufweisen, die über ein Fabric 1185 oder eine oder mehrere Bridges 1187 miteinander verbunden sind. Die Chiplets innerhalb der Baugruppenanordnung 1190 können in einer 3D- oder 2,5D-Anordnung eingerichtet sein. Im Allgemeinen können Bridge-Strukturen 1187 verwendet werden, um eine Punkt-zu-Punkt-Verbindung beispielsweise zwischen Logik- oder E/A-Chiplets und Speicher-Chiplets zu ermöglichen. Das Fabric 1185 kann zur Verbindung der verschiedenen Logik- und/oder E/A-Chiplets (beispielsweise der Chiplets 1172, 1174, 1191, 1193) mit anderen Logik- und/oder E/A-Chiplets verwendet werden. Gemäß einer Ausführungsform kann der Cache-Speicher 1192 innerhalb des Substrats als globaler Cache für die Baugruppenanordnung 1190, Teil eines verteilten globalen Caches oder dedizierter Cache für das Fabric 1185 wirken.
  • 11D zeigt eine Baugruppenanordnung 1194, die untereinander austauschbare Chiplets 1195 aufweist, gemäß einer Ausführungsform. Die untereinander austauschbaren Chiplets 1195 können zu standardisierten Slots auf einem oder mehreren Basis-Chiplets 1196, 1198 zusammengesetzt werden. Die Basis-Chiplets 1196, 1198 können durch eine Bridge-Zwischenverbindung 1197 gekoppelt werden, die den anderen hier beschriebenen Bridge-Zwischenverbindungen ähneln kann und beispielsweise eine EMIB sein kann. Speicher-Chiplets können auch über eine Bridge-Zwischenverbindung mit Logik- oder E/A-Chiplets verbunden werden. E/A- und Logik-Chiplets können über ein Zwischenverbindungs-Fabric kommunizieren. Die Basis-Chiplets können jeweils einen oder mehrere Slots in einem standardisierten Format für eine von Logik oder E/A oder Speicher/Cache unterstützen.
  • Gemäß einer Ausführungsform können SRAM- und Stromzufuhrschaltungen in einem oder mehreren der Basis-Chiplets 1196, 1198 hergestellt werden, die unter Verwendung einer anderen Prozesstechnologie als die untereinander austauschbaren Chiplets 1195, die auf die Basis-Chiplets gestapelt sind, hergestellt werden können. Beispielsweise können die Basis-Chiplets 1196, 1198 unter Verwendung einer größeren Prozesstechnologie hergestellt werden, während die untereinander austauschbaren Chiplets unter Verwendung einer kleineren Prozesstechnologie hergestellt werden können. Eines oder mehrere der untereinander austauschbaren Chiplets 1195 kann aus einem oder mehreren Speicher(beispielsweise DRAM)-Chiplets bestehen. Auf der Grundlage der für das Produkt, welches die Baugruppenanordnung 1194 verwendet, angestrebten Leistungsaufnahme und/oder Leistungsfähigkeit können für die Baugruppenanordnung 1194 unterschiedliche Speicherdichten ausgewählt werden. Zusätzlich können Logik-Chiplets mit einer anderen Anzahl oder einem anderen Typ funktioneller Einheiten bei der Montage auf der Grundlage der für das Produkt angestrebten Leistungsaufnahme und/oder Leistungsfähigkeit ausgewählt werden. Zusätzlich können Chiplets, die IP-Logikkerne unterschiedlicher Typen enthalten, in die untereinander austauschbaren Chiplet-Slots eingefügt werden, wodurch hybride Prozessorentwürfe ermöglicht werden, die IP-Blöcke unterschiedlicher Technologien mischen und anpassen können.
  • Beispielhafte System-on-a-Chip-integrierte-Schaltung
  • Die 12 und 13A - 13B zeigen beispielhafte integrierte Schaltungen und zugeordnete Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden können, gemäß verschiedenen hier beschriebenen Ausführungsformen. Zusätzlich zum Dargestellten können andere Logiken und Schaltungen aufgenommen werden, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Steuereinrichtungen oder Prozessorkerne für allgemeine Zwecke.
  • 12 ist ein Blockdiagramm, das eine beispielhafte System-on-a-Chip-integrierte-Schaltung 1200 zeigt, die unter Verwendung eines oder mehrerer IP-Kerne hergestellt werden kann, gemäß einer Ausführungsform. Die beispielhafte integrierte Schaltung 1200 weist einen oder mehrere Anwendungsprozessoren 1205 (beispielsweise CPUs) und wenigstens einen Grafikprozessor 1210 auf und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 aufweisen, die jeweils ein modularer IP-Kern von derselben oder mehreren verschiedenen Entwurfseinrichtungen sein können. Die integrierte Schaltung 1200 weist eine Peripherie- oder Buslogik, einschließlich einer USB-Steuereinrichtung 1225, einer UART-Steuereinrichtung 1230, einer SPI/SDIO-Steuereinrichtung 1235 und einer I2S/I2C-Steuereinrichtung 1240, auf. Zusätzlich kann die integrierte Schaltung eine Anzeigevorrichtung 1245 aufweisen, die mit einer oder mehreren von einer High-Definition-Multimedia-Interface(HDMI)-Steuereinrichtung 1250 und einer Mobile-Industry-Processor-Interface(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Speicher kann durch ein Flash-Speicheruntersystem 1260 einschließlich eines Flash-Speichers und einer Flash-Speichersteuereinrichtung, bereitgestellt sein. Die Speicherschnittstelle kann durch eine Speichersteuereinrichtung 1265 zum Zugriff auf SDRAM- oder SRAM-Speichervorrichtungen bereitgestellt sein. Einige integrierte Schaltungen weisen zusätzlich eine eingebettete Sicherheits-Engine 1270 auf.
  • Die 13A - 13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung mit einem SoC zeigen, gemäß hier beschriebenen Ausführungsformen. 13A zeigt einen beispielhaften Grafikprozessor 1310 einer System-on-a-Chip-integrierten-Schaltung, der unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform. 13B zeigt einen zusätzlichen beispielhaften Grafikprozessor 1340 einer System-on-a-Chip-integrierten-Schaltung, der unter Verwendung eines oder mehrerer IP-Kerne hergestellt sein kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 aus 13A ist ein Beispiel eines Grafikprozessorkerns mit geringer Leistungsaufnahme. Der Grafikprozessor 1340 aus 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistungsfähigkeit. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 aus 12 sein.
  • Wie in 13A dargestellt ist, weist der Grafikprozessor 1310 einen Vertex-Prozessor 1305 und einen oder mehrere Fragmentprozessoren 1315A - 1315N (beispielsweise 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N) auf. Der Grafikprozessor 1310 kann verschiedene Shader-Programme über eine getrennte Logik ausführen, so dass der Vertex-Prozessor 1305 optimiert ist, Operationen für Vertex-Shader-Programme auszuführen, während der eine oder die mehreren Fragmentprozessoren 1315A - 1315N Fragment(beispielsweise Pixel)-Shading-Operationen für Fragment- oder Pixel-Shader-Programme ausführen. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline aus und erzeugt Grundform- und Vertex-Daten. Der eine oder die mehreren Fragmentprozessoren 1315A - 1315N verwenden die durch den Vertex-Prozessor 1305 erzeugten Grundform- und Vertex-Daten zur Erzeugung eines Framebuffers, der auf einer Anzeigevorrichtung angezeigt wird. Gemäß einer Ausführungsform sind der eine oder die mehreren Fragmentprozessoren 1315A - 1315N dafür optimiert, Fragment-Shader-Programme auszuführen, wie sie in der OpenGL-API vorgesehen sind, welche verwendet werden können, um ähnliche Operationen wie ein Pixel-Shader-Programm auszuführen, das in der Direct3D-API vorgesehen ist.
  • Der Grafikprozessor 1310 weist zusätzlich eine oder mehrere Speicherverwaltungseinheiten (MMUs) 1320A - 1320B, Caches 1325A - 1325B und Schaltungsverbindungen 1330A - 1330B auf. Die eine oder die mehreren MMUs 1320A - 1320B stellen eine Abbildung von virtuellen auf physische Adressen für den Grafikprozessor 1310 bereit, einschließlich für den Vertex-Prozessor 1305 und/oder den einen oder die mehreren Fragmentprozessoren 1315A - 1315N, die im Speicher gespeicherte Vertex- oder Bild-/Texturdaten zusätzlich zu in dem einen oder den mehreren Caches 1325A - 1325B gespeicherten Vertex- oder Bild-/Texturdaten referenzieren können. Gemäß einer Ausführungsform können die eine oder die mehreren MMUs 1320A - 1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs in Zusammenhang mit dem einen oder den mehreren Anwendungsprozessoren 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 aus 12, so dass jeder Prozessor 1205 - 1220 an einem geteilten oder vereinheitlichten virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltungsverbindungen 1330A - 1330B ermöglichen es dem Grafikprozessor 1310, sich gemäß Ausführungsformen entweder über einen internen Bus des SoCs oder über eine direkte Verbindung mit anderen IP-Kernen innerhalb des SoCs zu verbinden.
  • Wie in 13B dargestellt ist, weist der Grafikprozessor 1340 die eine oder die mehreren MMUs 1320A - 1320B, Caches 1325A - 1325B und Schaltungsverbindungen 1330A - 1330B des Grafikprozessors 1310 aus 13A auf. Der Grafikprozessor 1340 weist einen oder mehrere Shader-Kerne 1355A - 1355N (beispielsweise 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N) auf, wodurch eine vereinheitlichte Shader-Kernarchitektur bereitgestellt wird, bei der ein einziger Kern oder Kerntyp alle Typen eines programmierbaren Shader-Codes, einschließlich eines Shader-Programmcodes zur Implementierung von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern, ausführen kann. Die genaue Anzahl der vorhandenen Shader-Kerne kann sich zwischen Ausführungsformen und Implementationen unterscheiden. Zusätzlich weist der Grafikprozessor 1340 einen Zwischenkernaufgabenmanager 1345, der als Thread-Abfertiger zur Übergabe von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A - 1355N wirkt, und eine Kachelerzeugungseinheit 1358 zur Beschleunigung von Kachelungsoperationen für ein kachelbasiertes Rendern auf, wobei Renderoperationen für eine Szene im Bildraum unterteilt werden, beispielsweise um eine lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder die Verwendung interner Caches zu optimieren.
  • Compiler-unterstützte Befehlsordnung für Teilregisteraktualisierungen
  • Befehle, die einen Zieldatentyp aufweisen, dessen Größe geringer ist als eine des Quelldatentyps, bewirken Teil-Registerschreibvorgänge in die Registerdatei. Beispielsweise weist eine Registerdatei bei einigen aktuellen Ausführungseinheits(EU)-Architekturen eine Byteniveau-Schreibgranularität auf, womit jede Teilmenge durch eine Befehlssatzarchitektur (ISA) repräsentierter Bytes aktualisiert werden kann. Teil-Registerschreibvorgänge können verfügbare Schreibbandbreite verschwenden. Die Registerdatei-Schreibbandbreite ist bei einigen Anwendungen ein wesentlicher Flaschenhals, insbesondere bei den Anwendungen, die auf mehrere parallele Rechenlogikeinheiten (ALUs) in EUs zugreifen. Ein Mangel an GRF-Schreibbandbreite bewirkt Staus in ALU-Pipes und kann zu einem Verlust an Leistungsfähigkeit führen. Befehle des Zieldatentyps, deren Größe geringer ist als jene des Quelldatentyps, sind bei Maschinenlernanwendungen üblich. ResNet ist lediglich ein Beispiel von Maschinenlernanwendungen.
  • Der Flaschenhals bei der Registerdatei-Schreibbandbreite kann durch Erhöhen der Schreibbandbreite, beispielsweise durch Hinzufügen von Schreib-Ports oder durch Unterteilen der Registerdatei in mehrere Bänke, adressiert werden. Die Bandbreitenerhöhung geht jedoch mit erheblichen Hardwarekosten einher, die sich beispielsweise dadurch ergeben, dass mehr Die-Fläche und Schaltungen verwendet werden. Eine Erhöhung der Registerdatei-Schreibbandbreite führt zu einer erheblichen Erhöhung der Fläche sowie der Leistungsaufnahme.
  • Durch eine Wort(beispielsweise 2 Bytes)-Niveau-Schreibgranularität oder eine Granularität, die größer als ein Byte ist, kann die Registerdateifläche erheblich verringert werden, dadurch wird jedoch physisch eine Aktualisierung eines Bytes auf den Bereich innerhalb einer Wortgrenze beschränkt. Zur Aktualisierung eines Bytes innerhalb einer Wortgrenze werden Lese-Modifizier-Schreib(RMW)-Operationen für solche Schreibvorgänge verwendet. Eine hardwarebasierte RMW ist eine bekannte Lösung dafür, dass Registerdateien eine Byteniveau-Schreibfähigkeit mit einer physischen Wort-Schreibgranularität haben. Eine Hardwareimplementation von RMW weist den Overhead eines zusätzlichen Registerdateilesens für jeden Teil-Byteschreibvorgang auf. Überdies kann RMW den Stromverbrauch erhöhen, weil mehrere Speicherzugriffe ausgeführt werden.
  • Befehle mit Operanden verschiedener Datentypen sind sowohl in Maschinenlerntrainings- als auch -inference-kernels üblich. Verschiedene Ausführungsformen stellen eine gemeinsame Software- und Hardwareoptimierung bereit, welche die Schreibbandbreite zumindest für Szenarien, in denen eine Schreiboperation in ein Register, die kleiner als die Gesamtheit des Registers ist, optimiert wird. Ein Compiler erkennt Befehle, die Teilschreibvorgänge in dasselbe Register vornehmen, gruppiert diese Befehle und stellt der Hardware durch ein ISA-Bit oder einen anderen Indikator Hinweise bereit. Hardware (beispielsweise eine EU) kombiniert die Ausgangsdaten für gruppierte Befehle und aktualisiert das Zielregister als Einzelschreibvorgang an Stelle mehrerer getrennter Teilschreibvorgänge. Verschiedene Ausführungsformen können die Gesamtzahl der Registerdatei-Schreibvorgänge für Anwendungen, die Kernels mit mehreren Datentypen haben, verringern.
  • Verschiedene Ausführungsformen können einen Compiler zur Emulation der RMW verwenden, um Byteniveau-Schreibvorgänge in eine Registerdatei mit einer physischen Wort-Schreibgranularität auszuführen. Die emulierte RMW kann einen Overhead eines zusätzlichen Registerdatei-Lesevorgangs nur für eine Teilmenge der Fälle erzeugen, wohingegen eine Hardware-RMW einen Overhead eines zusätzlichen Lesevorgangs für jeden Teilschreibvorgang erzeugt.
  • Verschiedene Ausführungsformen verringern die Gesamtzahl der Schreibvorgänge in die Registerdatei. Verschiedene Ausführungsformen können die Leistungsfähigkeit der Registerdatei verbessern sowie den Stromverbrauch verringern. Stromeinsparungen können sich aus reduzierten Registerschreibvorgängen und reduzierten Fehlerkorrekturcodier(ECC)-Berechnungen ergeben.
  • Verschiedene Ausführungsformen adressieren Teil-Registerschreibvorgänge und sind auf eine SIMD-Architektur mit Registerdateien anwendbar. Verschiedene Ausführungsformen können auch verwendet werden, um die Registerdateifläche durch Ändern der Schreibgranularität zu höheren Größen zu verringern. Eine höhere Granularitätsgröße stellt größere Flächeneinsparungen bereit, während weiterhin Schreibvorgänge mit geringerer Granularität unterstützt werden können.
  • 14 zeigt ein beispielhaftes System. Eine Rechenplattform 1400 kann einen oder mehrere Prozessoren 1402, einen Speicher 1410 und Grafikverarbeitungseinheiten (GPUs) 1420 verwenden. Verschiedene Verbindungen können die Prozessoren 1402, den Speicher 1410 und die GPUs 1420 koppeln. Beispielsweise kann eine Zwischenverbindung, ein Bus, ein Fabric oder ein Netz als Verbindung verwendet werden. Die Rechenplattform 1400 kann eine aus verteilten Rechenressourcen gebildete zusammengesetzte Plattform sein.
  • Die Prozessoren 1402 können einen beliebigen Typ einer Zentralverarbeitungseinheit (CPU), eines Kerns, einer Grafikverarbeitungseinheit (GPU), eines feldprogrammierbaren Gate-Arrays (FPGAs) oder einer anwendungsspezifischen integrierten Schaltung (ASIC) umfassen. Der Speicher 1410 kann ein beliebiger Typ eines flüchtigen oder nichtflüchtigen Speichers sein, einschließlich eines permanenten Speichers und eines byteadressierbaren Speichers.
  • Bei einigen Beispielen können die Prozessoren 1402 ein Betriebssystem (OS) 1404 und Anwendungen 1408 ausführen. Eine Anwendung 1408 kann das Abrufen oder Speichern von Daten, das Verarbeiten von Daten, Maschinenlernen, Inferences oder eine Erzeugung von Bilddaten unter Verwendung von Plattformressourcen in der Art der Prozessoren 1402, des Speichers 1410 und der GPU 1420 anfordern. Der Prozessor 1402 kann einen Compiler 1406 ausführen, der Befehle für Ausführungseinheiten 1422 der GPU 1420 bereitstellt. Der Compiler 1406 kann Befehle des Programms 1412 kompilieren und eine Befehlssequenz in Maschinensprache 1414 (beispielsweise Binärcodes), die von den EUs 1422 auszuführen ist, erzeugen. Das Programm 1412 kann von einem beliebigen Format sein, wie beispielsweise OpenGL, OpenCL, DirectX, Python, DPC++, TensorFlow, Metal oder einer Shader-Sprache, jedoch ohne Einschränkung darauf.
  • Verschiedene Ausführungsformen verringern die Gesamtzahl der Schreibvorgänge in die Registerdatei 1426 zumindest für Fälle, in denen der Zieldatentyp eine geringere Größe aufweist als jeglicher Quelldatentyp. Gemäß verschiedenen Ausführungsformen kann der Compiler 1406 dafür sorgen, dass Maschinensprachen- oder Shader-Befehle sequenziell ausgeführt werden, so dass Teil-Registerschreibvorgänge in ein Register bereitgestellt werden. Der Compiler 1406 identifiziert durch Befehle an ein Register erzeugte benachbarte Bytes und gruppiert die Befehle zur sequenziellen Ausführung. Beispielsweise können Befehle, die gruppiert werden, Werte erzeugen, die das gleiche Datenformat aufweisen. Ein Datenformat kann Gleitkomma(FP)-8-Bits, FP16, FP32, FP64 oder ein beliebiges Gleitkommaformat mit einer Anzahl von Bits, die ein Vielfaches von 2 oder Integer(Int)-8-Bit, Integer-16-, Integer-32- oder eine beliebige natürliche Zahl mit einer Anzahl von Bits, die ein Vielfaches von 2 ist, sein. Bei einigen Beispielen stellt der Compiler 1406 Gruppen von Befehlen zur Ausführung durch eine einzige Rechenlogikeinheit (Alu) der EU 1422 bereit.
  • Beispielsweise kann der Compiler 1406 FP16 in eine ALU, Integer16 in eine ALU, FP32 in eine ALU, Integer32 in eine ALU und FP64 in eine andere ALU kombinieren. Bei einigen Beispielen stellt der Compiler 1406 einer ALU verschiedene Datenformate bereit. Beispielsweise stellt der Compiler 1406 einer einzigen ALU Befehle bereit, die Daten des Formats FP16, FP32 und FP64 erzeugen, und er stellt einer anderen ALU Befehle bereit, die Daten eines anderen Formats Int16 und 32 erzeugen, und trennt die Ausführung von Wort- und dword-Datenausgaben.
  • Der Compiler 1406 stellt mit einem Befehl, der als Teil der Befehlssequenz gruppiert ist, einen Hinweis bereit, wobei der Hinweis angibt, dass die durch die Ausführung des Befehls erzeugte Ausgabe in einem Schreibsteuerpuffer (WCB) 1424 zu speichern ist. Für Maschinenspracheanwendungen kompiliert der Compiler 1406 beispielsweise Befehle, die mehrere Elemente pro Register (geringerer oder höherer Betrag als 64 Bits) erzeugen.
  • Der Compiler 1406 kann eine Byteschrittweite auswählen, bei der ein Befehl Ausgangsdaten in den WCB 1424 schreiben soll. Beispielsweise konfiguriert der Compiler 1406 einen Befehl zum Schreiben beginnend mit Byte 0 und mit einer Schrittweite von 4 für den WCB 1424 und konfiguriert einen anderen Befehl zum Schreiben beginnend mit Byte 1 mit einer Schrittweite von 4 für den WCB 1424 usw.
  • Eine ALU führt einen Befehl mit einem Hinweis zur Bereitstellung einer Teildatenausgabe, wobei nicht in den gesamten WCB 1424 geschrieben wird, aus, gefolgt von der Ausführung eines anderen Befehls mit einem Hinweis stellt eine Teildatenausgabe bereit, die nicht in den gesamten WCB 1424 schreibt, wobei, wenn ein Befehl ohne Hinweis ausgeführt wird, der Befehl ohne Hinweis eine Teildatenausgabe bereitstellt, die nicht in den gesamten WCB 1424 schreibt, wobei die Inhalte des WCBs 1424 in ein Register 1426 kopiert werden. Das Register 1426 kann beispielsweise eine GRF sein.
  • Das Datenformat im Register 1426 kann beliebig sein. Bei einigen Beispielen kann das Register 1426 32 Bytes, 64 Bytes, 128 Bytes oder eine beliebige Anzahl von Bytes, die ein Vielfaches von 2 ist, aufweisen. Im Register 1426 gespeicherte Daten können in den Speicher zurückgeschrieben werden und einer Anwendung bereitgestellt werden, die lokal an der GPU 1420 oder fern von dieser ausgeführt wird. Daten aus dem Register 1426 können als erzeugte Daten 1416 in den Speicher 1410 geschrieben werden. Die erzeugten Daten 1416 können Bilddaten, Inference-Daten oder andere verarbeitete Daten sein.
  • Der beispielhafte Pseudocode stellt einen Teilschreibvorgang in eine Registerdatei bereit.
    Mov (8) r64.0<4>:b r82.0<1>:f
  • Bei diesem beispielhaften Pseudocode werden Gleitkommaelemente einfacher Genauigkeit im Quellregister r82 in den Bytedatentyp umgewandelt und beginnend mit Byte Nummer 0 bei 4-Byte-Schritten in das Ziel-r64-Register geschrieben (wobei beispielsweise alle vier Bytes geschrieben wird). „Mov“ repräsentiert einen Verschiebungsbefehl, und die in Klammern gesetzte Zahl „8“ bezeichnet die SIMD-Breite. Die Bezeichnung „<4>“ neben dem Zielregister r82 bezeichnet eine Zielschrittweite von 4-Byte-Elementen. Die Zielschrittweite ist der Abstand zwischen zwei in das Zielregister zu schreibenden benachbarten Elementen in der Zieldatentypgröße (Bytes in diesem Beispiel). Die Bezeichnung „<1>“ neben dem Quellregister r82 gibt eine Schrittweite von 1 eines Gleitkommaelements einfacher Genauigkeit (mit einer Größe von 32 Bits) an.
  • 15 stellt eine bildliche Darstellung der Datenverschiebung gemäß dem Pseudocode bereit. Auch wenn der Befehl nur ein Viertel des Zielregisters (8 Bytes) aktualisiert, wird für diesen Fall die gesamte Registerbandbreite (32 Bytes) verbraucht. Eine Lesen-Modifizieren-Schreiben-Operation könnte zur Aktualisierung anderer Teile des Registers verwendet werden. Die restlichen Elemente im Zielregister werden wegen einer hohen Registerdrucknatur dieser Kernels im Allgemeinen in späteren Befehlen aktualisiert. Beispielsweise werden vier Register (r82 bis r85) an Daten einfacher Genauigkeit in Bytes umgewandelt und später in das Register r64 geschrieben.
  • Nachfolgend wird ein Beispiel eines Pseudocodes für das Aktualisieren aller Elemente in einem Zielregister angegeben: Mov ( 8 ) r 64.0 < 4 > : b r 82.0 < 1 > : f
    Figure DE102020133275A1_0001
     Mov ( 8 ) r 64.1 < 4 > : b r 83.0 < 1 > : f
    Figure DE102020133275A1_0002
     Mov ( 8 ) r 64.2 < 4 > : b r 84.0 < 1 > : f
    Figure DE102020133275A1_0003
     Mov ( 8 ) r 64.3 < 4 > : b r 85.0 < 1 > : f
    Figure DE102020133275A1_0004
  • Es wurde zuvor eine Beschreibung von „Mov (8) r64.0<4>:b r82.0<1>:f“ bereitgestellt. Nachfolgende Befehle bewirken ein Verschieben von Inhalt von r83 - r85-Registern in das r64-Register und ein Schreiben in jeweilige Anfangsbytes 1, 2 und 3 von r64 mit 4-Byte-Schrittweiten. Die Befehlssequenz bewirkt bei einigen Architekturen vier Registerdatei-Schreibvorgänge in dasselbe Register. Es treten mehrere Befehle mit Teilschreibvorgängen in dasselbe Register auf.
  • Beispielsweise wird ein eingegebener Gleitkomma-32-Bit-Wert in Bytes umgewandelt und in ein r64-Register geschrieben. Wenn die Bytegranularität entfernt wird und zu Wort oder Doppelwort (dword) geändert wird, wird eine Lesen-Modifizieren-Schreiben-Operation ausgeführt, um 32 Bits aus einem Register zu lesen, 8 Bits zu aktualisieren und dann 32 Bits in das Register zu schreiben.
  • 16 zeigt ein Beispiel einer von einer Ausführungseinheit (EU) verwendeten vereinfachten Mikroarchitektur. Mehrere Hardware-Thread-Slots können zur Verwendung durch eine EU verfügbar sein. Eine Befehlswarteschlange (IQ) 1602 speichert Befehle zur Ausführung durch einen Thread. Ein Thread weist eine Vordecodierstufe 1604 auf, die den Thread anhält, bis alle Abhängigkeiten für einen aktuellen Befehl gelöscht wurden. Threads werden als bereit markiert, wenn keine Abhängigkeiten existieren, und sie nehmen in der Arbiter-Stufe 1606 teil. Ein Arbiter der Arbiter-Stufe 1606 wählt einen oder mehrere Threads auf der Grundlage der Verfügbarkeit von ALUs aus und überführt entsprechende Befehle in ALU-Pipelines. Eine ALU-Pipeline kann eine Decodierstufe 1608, eine Registerlesestufe 1610, eine Ausführungsstufe 1612, eine Schreibkombinierpuffer(WCB)-Stufe 1614 und eine Rückschreib(WB)-Stufe 1616 aufweisen. Dieses Beispiel zeigt lediglich zwei ALUs, und es kann eine beliebige Anzahl von ALUs verwendet werden. Eine Ausführungsstufe 1612 kann eine oder mehrere von einer Rechenlogikeinheit (ALU), einer Adresserzeugungseinheit (AGU), einer Gleitkommaeinheit (FPU), einer Lade-Speicher-Einheit (LSU) und einer Verzweigungsausführungseinheit (BEU) verwenden.
  • Verschiedene Ausführungsformen verwenden den WCB 1614 zur Kombination von Schreibvorgängen mehrerer Befehle, die in dasselbe Register schreiben müssen. Der WCB 1614 kann von einer Ausführungsstufe 1612 ausgegebenen Inhalt speichern, bevor er den Inhalt zum WB 1616 weiterleitet. Ein Compiler stellt maschinenausführbare Befehle mit einem in der Decodierstufe 1608 decodierten Kombinierhinweis, der zusammen mit dem decodierten Befehl zur nachfolgenden Stufe weitergeleitet wird, bereit. Wenn ein Befehl mit einem festgelegten Kombinierhinweis kommt, werden die von der Ausführungsstufe 1612 ausgegebenen Daten am WCB 1614 gesammelt. Der WCB 1614 sammelt Daten von der Ausführungsstufe 1612, bis er einen Befehl mit einem nicht festgelegten Kombinierhinweis empfängt. Mit anderen Worten stellen sequenzielle Befehle mit einem festgelegten Kombinierhinweis ihre Ausgabe dem WCB 1614 bereit, bis ein Befehl in der Sequenz keinen Kombinierhinweis aufweist. Nachdem ein Befehl, der keinen Kombinierhinweis aufweist, ausgeführt wurde und dem WCB 1614 Inhalt bereitstellt, stellt der WCB 1614 all seine gesammelten Daten einem WB 1616 zur Verfügung (beispielsweise durch einen Daten-Push- oder-Pull-Vorgang). Der WB 1616 kann ein Zielregister mit diesen Daten aktualisieren.
  • Der Arbiter 1606 kann keinen anderen Thread zwischen Befehlen mit einem Halte-Tag einplanen. Der Arbiter 1606 kann Befehle ohne ein Halte-Tag zur Ausführung in der Ausführungsstufe 1612 und zur Erzeugung von Daten zum Speichern in der WB 1616 planen.
  • Verschiedene Ausführungsformen verwenden einen Compiler-Hinweis zum Sammeln von Daten, die bei der Ausführung mehrerer Befehle gesammelt werden, die teilweise in dasselbe Register schreiben, zum Gruppieren von Befehlen, die teilweise in dasselbe Register schreiben, und zur Aktualisierung des Zielregisters mit einem einzigen Schreibvorgang. Die Befehle brauchen einander nicht unbedingt benachbart zu sein, wie im Beispiel dargestellt, und sie können in einem Kernel verteilt sein. Der Compiler scannt den gesamten Kernel und erkennt die Befehle, deren Ausgabe zusammengeführt werden kann, bevor er ein Register aktualisiert. Der Compiler ordnet die Befehle als Gruppe an und legt den „Kombinier“-Hinweis an allen Befehlen mit Ausnahme des letzten in der Gruppe fest. Der „Kombinier“-Hinweis kann ein 1-Bit-Indikator sein, um einer Pipeline mitzuteilen, dass eine aktuelle Befehlsausgabe im WCB 1614 mit einer Ausgabe eines nächsten Befehls in der Pipeline vor der Ausgabe in einen WB 1616 zusammenzuführen ist.
  • Wenn der WCB 1614 einen Schreibkombinierhinweis an einem Befehl erkennt, aktualisiert er die WB 1616 nicht mit Ausgangsdaten. Stattdessen wartet der WCB 1614 auf die Ausgabe eines nächsten Befehls, um Ausgangsdaten zu kombinieren. Der WCB 1614 aktualisiert die WB 1616 mit kombinierten Daten, wenn an einem Befehl kein Kombinierhinweis gefunden wird.
  • Nachfolgend wird eine beispielhafte Befehlssequenz mit einem Compiler-Hinweis Kombinieren („{Kombinieren}“ in diesem Beispiel) angegeben: Mov ( 8 ) r 64.0 < 4 > : b r 82.0 < 1 > : f { Kombinieren }
    Figure DE102020133275A1_0005
     Mov ( 8 ) r 64.1 < 4 > : b r 83.0 < 1 > : f { Kombinieren }
    Figure DE102020133275A1_0006
     Mov ( 8 ) r 64.2 < 4 > : b r 84.0 < 1 > : f { Kombinieren }
    Figure DE102020133275A1_0007
     Mov ( 8 ) r 64.3 < 4 > : b r 85.0 < 1 > : f
    Figure DE102020133275A1_0008
  • 17 zeigt eine beispielhafte Darstellung der Verwendung eines WCBs zur Ausführung von Befehlen der beispielhaften Befehlssequenz. Bei diesem Beispiel werden Daten über vier Befehle gesammelt, wobei die Zielaktualisierung jedoch nach der Ausführung des letzten Befehls geschieht. Bei diesem Beispiel führt eine einzige ALU die Befehle über 4 Zyklen aus. Bei anderen Beispielen können mehrere ALUs jedoch Teilaktualisierungen in denselben WCB schreiben.
  • Ähnliche Ansätze können auch auf andere Datentypen und Mehrquellenbefehle erweitert werden. Der nachstehende Pseudocode ist ein Beispiel für das Finden eines Maximalwerts zwischen zwei Gleitkommawerten mit einfacher Genauigkeit und für das Umwandeln von ihnen in einen Gleitkommawert mit halber Genauigkeit. Ein Beispiel von 2 Quellbefehlen mit einem Kombinierhinweis wird nachstehend bereitgestellt. Sel ( 8 ) ( ge ) r 10.0 < 2 > : hf r 14.0 < 8 ; 8,1 > : f r 24.0 : f { Kombinieren }
    Figure DE102020133275A1_0009
     Sel ( 8 ) ( ge ) r 10.1 < 2 > : hf r 15.0 < 8 ; 8,1 > : f r 25.0 : f
    Figure DE102020133275A1_0010
  • Die Operation „Sel“ ist eine Wähloperation, wodurch zwei Befehle teilweise in einen WCB schreiben und die Inhalte des WCBs nach der Ausführung des zweiten Befehls in eine WB kopiert werden. Die Operation findet einen größeren Wert zwischen zwei Quellen und wandelt den größeren Wert in eine halbe Genauigkeit um. Beispielsweise wird ein größerer Wert zwischen den Registern r14.0 und r24.0, r14.1 und r24.1 usw. gefunden und in halbe Genauigkeit umgewandelt.
  • Andere beispielhafte Operationen umfassen Rechen- oder Logikoperationen. Einige Beispiele sind ohne Einschränkung Addieren, Multiplizieren, Vergleichen, Multiplizieren-und-dann-Addieren (Mad), Bitverschiebung-nach-links (Shl), Bitverschiebung-nachrechts (Shr), Oder, Und, Exklusiv-Oder usw.
  • Ein mögliches Szenario besteht darin, die Ausgangsdaten von Befehlen in aufeinander folgende Ausgangsbytes zu packen. Ein Beispiel eines Gleitkommabefehls einfacher Genauigkeit zur Gepackte-Bytes-Wandlung mit einem Kombinierhinweis ist das Folgende: Befehl0 Mov ( 8 ) r 64.0 < 1 > : b r 82.0 < 1 > : f { Kombinieren }
    Figure DE102020133275A1_0011
     Befehl1 Mov ( 8 ) r 64.8 < 1 > : b r 83.0 < 1 > : f { Kombinieren }
    Figure DE102020133275A1_0012
     Befehl2 Mov ( 8 ) r 64.16 < 1 > : b r 84.0 < 10 > : f { Kombinieren }
    Figure DE102020133275A1_0013
     Befehl3 Mov ( 8 ) r 64.24 < 1 > : b r 85.0 < 1 > : f
    Figure DE102020133275A1_0014
  • Die Zielschrittweite <1> neben dem Ziel bezeichnet die Packung von Ausgangsdaten. Bei diesen Beispielen wird die Schrittweite auf 1 gesetzt, um in aufeinander folgende Bytes zu schreiben, jedoch eine Teilregisteraktualisierung vorzunehmen. Die Anzahl der Schreibvorgänge kann auch für dieses Szenario von 4 Aktualisierungen des Ausgangsregisters auf 1 Aktualisierung des Ausgangsregisters verringert werden.
  • 18 zeigt eine Datenverschiebung für eine Gepackte-Bytes-Wandlung. Ein Befehle in der oberen Zeile erzeugt die Bytes 0 - 7, ein Befehl 1 in der zweiten bis obersten Zeile erzeugt die Bytes 8 - 15 usw. Nach der Ausführung des Befehls3 erfolgt ein Teilschreibvorgang des WCBs und wird der gesamte Inhalt des WCBs in ein anderes Register kopiert.
  • Bei einigen Beispielen gruppiert ein Compiler einen Befehl nicht mit anderen Befehlen und wird ein einziger Teil-Byteschreibvorgang in ein Register mit einem anderen Inhalt im Register kombiniert. Ein einziger Befehl aktualisiert einen WCB teilweise, und der Rest des WCBs, der nicht aktualisiert wird, wird als „Abfall“ betrachtet. Falls ein Register zum ersten Mal aktualisiert wird oder die existierenden Daten in einem Register nicht mehr benötigt werden, sind die Daten „Abfall“ oder nicht mehr verwendbar. Beispielsweise schreibt eine Ausführungsstufe gerade Bytes, und ungerade Bytes können ignoriert werden. Bei diesem Beispiel gibt es einen Befehl ohne einen Kombinierhinweis.
  • Teil-Byteschreibvorgänge können für solche Register vorgenommen werden, und die RMW wird nicht ausgeführt. In diesem Fall wird vom Compiler kein Hinweis erzeugt. Eine WCB-Stufe führt berechnete Daten auf verwendeten Kanälen mit einigen Abfalldaten auf nicht verwendeten Kanälen zusammen und aktualisiert das Ausgangsregister.
  • In manchen Fällen wird eine Teilregisteraktualisierung ausgeführt, wenn andere Bytes nicht aktualisiert werden. Die Fläche einer Registerdatei mit Wortschreibgranularität ist kleiner als die Fläche bei einer Bytegranularität. Die RMW kann durch den Compiler emuliert werden, wobei insgesamt weniger Overhead auftritt als bei einer Hardware-RMW.
  • Ein Compiler kann die RMW wie im nachstehenden Pseudocode gezeigt emulieren. Befehl0 Mov ( 8 ) r 64.0 < 1 > : b r64 .0 < 1 ; 1,0 > : b { Kombinieren }
    Figure DE102020133275A1_0015
     Befehl1 Mov ( 8 ) r 64.0 < 2 > : b r 82.0 < 1 ; 1,0 > : hf
    Figure DE102020133275A1_0016
  • Der erste Mov-Befehl ist ein vom Compiler für die Emulierung der RMW hinzugefügter Overhead. In diesem Fall werden Inhalte eines Registers, die als Daten, die nicht aktualisiert werden, in den WCB kopiert werden, verwendet und nicht als „Abfall“ angesehen.
  • Befehle liest Inhalt aus einem Register und schreibt den gesamten Inhalt aus dem Register in den WCB, wenn die Schrittweite 1 Byte ist. Befehl1 führt eine Teilaktualisierung mit einer Schrittweite von 2 Bytes in den WCB aus. Jedes andere Byte wird durch Befehl 1 im WCB überschrieben. Ein Compiler verwendet eine Sequenz von Befehle und Befehl 1, um Teilaktualisierungen in das Register zu schreiben.
  • 19 zeigt eine beispielhafte Implementation eines WCBs. Eine Ausführungseinheit 1902 (beispielsweise eine Rechenlogikeinheit (ALU), eine Adresserzeugungseinheit (AGU), eine Gleitkommaeinheit (FPU), eine Lade-Speicher-Einheit (LSU), eine Verzweigungsausführungseinheit (BEU)) kann Ausgaben ausgeführter Befehle für Flops 1904-0 bis 1904-3 erzeugen. Die Flops 1904-0 bis 1904-3 können von einer Ausführungseinheit 1902 ausgegebenen Inhalt speichern, während ein Haltesignal aktiviert ist. Wenn ein Freigabesignal aktiviert wird, geben die Flops 1904-0 bis 1904-3 ihren Inhalt frei oder kopieren ihn in ein Register 1906. Das Register 1906 kann beispielsweise eine GRF oder ein Register eines anderen Typs sein.
  • 20 zeigt einen beispielhaften Prozess. Der Prozess kann von einem Compiler ausgeführt werden, der einen Shader-Programmcode kompiliert. Bei 2002 werden Befehle identifiziert, die einen Teilschreibvorgang in ein Register ausführen. Beispielsweise können Befehle Teilschreibaktualisierungen in zu identifizierende verschiedene Teile eines Einzelregisters ausführen.
  • Bei 204 werden Befehle, die Teilaktualisierungen am selben Register ausführen, zusammengruppiert, und es wird ein Hinweis bereitgestellt, Teilaktualisierungen in einem Zwischenpuffer zu halten. Der Hinweis kann angeben, die Ausgabe im Zwischenpuffer zu halten, bis eine Freigabe angegeben wird. Der Zwischenpuffer kann ein WCB-Register sein. Der letzte Befehl in der Befehlsgruppe weist keinen zugeordneten Hinweis zum Halten von Teilaktualisierungen in einem Zwischenpuffer auf. Dadurch, dass er keinen zugeordneten Hinweis für das Halten von Teilaktualisierungen in einem Zwischenpuffer aufweist, kann die Ausführung des Befehls bewirken, dass der Zwischenpuffer mit der Ausgabe infolge der Ausführung des Befehls ohne zugeordneten Hinweis aktualisiert wird und dass der Inhalt des Zwischenpuffers in ein Zielregister kopiert wird.
  • Bei 2006 wird ein maschinenausführbarer Code anhand der gruppierten Befehle mit einem oder mehreren Hinweisen erzeugt. Der maschinenausführbare Code kann im Speicher zur Ausführung beispielsweise durch eine Ausführungseinheit einer GPU gespeichert werden.
  • 21 zeigt einen beispielhaften Prozess. Der Prozess kann durch eine Ausführungspipeline ausgeführt werden. Bei einigen Beispielen kann eine Ausführungseinheit (beispielsweise Rechenlogikeinheit (ALU), Adresserzeugungseinheit (AGU), Gleitkommaeinheit (FPU), Lade-Speicher-Einheit (LSU), Verzweigungsausführungseinheit (BEU)) den Prozess ausführen. Bei 2102 wird festgestellt, ob ein Befehl mit einem Kombinierhinweis empfangen wird. Falls der Befehl einen Kombinierhinweis aufweist, folgt 2104. Bei 2104 wird ein Befehl mit einem Kombinierhinweis, der ein Register teilweise aktualisiert, ausgeführt und wird seine Ausgabe in einem Zwischenpuffer gespeichert.
  • Falls der Befehl keinen Kombinierhinweis aufweist und einem Befehl mit einem Kombinierhinweis folgt, folgt 2106. Bei 2106 bewirkt die Ausführung des Befehls, dass eine Teilaktualisierung des Zwischenpuffers erfolgt und der Inhalt aus dem Zwischenpuffer in einen Zielpuffer kopiert wird.
  • Bei einigen Beispielen geht ein Befehl mit einem Kombinierhinweis einem Befehl ohne Kombinierhinweis vorher und emuliert eine RMW-Operation. Einiger Inhalt des Zwischenpuffers ist eine Kopie des Inhalts des Zielregisters, und einiger Inhalt wird durch die Ausführung eines Befehls aktualisiert.
  • Verschiedene Ausführungsformen ermöglichen eine Änderung der Schreibgranularität vom Byteniveau auf das Wortniveau für Registerdateien in einer EU, wodurch die Fläche von Registerdateien um etwa 5 % verringert wird. Schreibvorgänge auf dem Byteniveau werden unterstützt. Der Gesamt-GRF-Verkehr kann auch zusammen mit der GRF-Fläche verringert werden. Für vier Befehle beim Beispiel, die 4 GRF-Lesevorgänge und 4 GRF-Schreibvorgänge für Registerdateien mit der Bytegranularität hervorrufen, bewirkt das Beispiel 4 GRF-Lesevorgänge und 4 GRF-Lese-Modifizier-Schreibvorgänge, was insgesamt 8 GRF-Lesevorgängen und 4 GRF-Schreibvorgängen für Registerdateien mit der Wortgranularität entspricht. Dagegen bewirken verschiedene Ausführungsformen 4 GRF-Lesevorgänge und 1 GRF-Schreibvorgang selbst bei Registerdateien mit der Wortgranularität. Eine Verringerung des GRF-Verkehrs um etwa 38 % kann gegenüber dem Registerdateiszenario mit der Bytegranularität erreicht werden, und es kann eine Verringerung des GRF-Verkehrs um etwa 58 % gegenüber dem Registerdateiszenario mit der Wortgranularität erreicht werden. Die GRF-Verkehrsverringerung kommt zu den 5 % Flächeneinsparungen infolge der Wortgranularität hinzu. Der verringerte GRF-Verkehr hilft dabei, die Leistungsfähigkeit für rechenbegrenzte Arbeitslasten zu verbessern, bei denen im Allgemeinen durch die GRF-Bandbreite ein Flaschenhals auftritt, und den Stromverbrauch zu verringern.
  • Die Stellen, an denen der Ausdruck „ein einziges Beispiel“ oder „ein Beispiel“ auftritt, beziehen sich nicht notwendigerweise alle auf dasselbe Beispiel oder dieselbe Ausführungsform. Jeder hier beschriebene Aspekt kann mit jedem anderen Aspekt oder einem ähnlichen Aspekt, der hier beschrieben wird, kombiniert werden, unabhängig davon, ob die Aspekte mit Bezug auf dieselbe Figur oder dasselbe Element beschrieben werden.
  • Einige Beispiele können unter Verwendung des Ausdrucks „gekoppelt“ und „verbunden“ zusammen mit ihren Ableitungen beschrieben werden. Diese Begriffe sind nicht notwendigerweise als Synonyme füreinander zu verstehen. Beispielsweise können Beschreibungen, welche die Begriffe „verbunden“ und/oder „gekoppelt“ verwenden, angeben, dass zwei oder mehr Elemente in direktem physischen oder elektrischen Kontakt miteinander stehen. Der Begriff „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, aber dennoch zusammenwirken oder miteinander interagieren.
  • Die Begriffe „erster“, „zweiter“ und dergleichen bezeichnen hier keine Reihenfolge, keinen Betrag oder keine Wichtigkeit, sondern sie werden vielmehr verwendet, um ein Element von einem anderen zu unterscheiden. Die Begriffe „ein/eine/eines“ bezeichnen hier keine Beschränkung eines Betrags, sondern vielmehr das Vorhandensein zumindest eines der erwähnten Bestandteile. Der hier mit Bezug auf ein Signal verwendete Begriff „aktiviert“ bezeichnet einen Zustand des Signals, bei dem das Signal aktiv ist, und der durch Anlegen eines Logikpegels von entweder logisch 0 oder logisch 1 an das Signal erreicht werden kann. Die Begriffe „folgen“ oder „nach“ können sich auf unmittelbar folgend oder nach einem oder mehreren anderen Ereignissen folgend beziehen. In Flussdiagrammen können gemäß alternativen Ausführungsformen auch andere Schrittsequenzen ausgeführt werden. Ferner können abhängig von den jeweiligen Anwendungen zusätzliche Schritte hinzugefügt werden oder Schritte entfernt werden. Es kann eine beliebige Kombination von Änderungen verwendet werden, und Durchschnittsfachleute auf dem Gebiet, welche diese Offenbarung gelesen haben, werden die vielen Variationen, Modifikationen und alternativen Ausführungsformen davon verstehen.
  • Ein disjunktiver Sprachgebrauch in der Art des Ausdrucks „wenigstens einer von X, Y oder Z“ ist, sofern nichts anderes spezifisch ausgesagt wird, innerhalb des verwendeten Zusammenhangs im Allgemeinen so zu verstehen, dass ein Bestandteil, ein Begriff usw. entweder X, Y oder Z oder eine Kombination davon (beispielsweise X, Y und/oder Z) sein kann. Demgemäß soll dieser disjunktive Sprachgebrauch im Allgemeinen nicht implizieren, dass bestimmte Ausführungsformen fordern, dass wenigstens einer von X, wenigstens einer von Y oder wenigstens einer von Z vorhanden ist. Zusätzlich sollte ein konjunktiver Sprachgebrauch in der Art des Ausdrucks „wenigstens einer von X, Y und Z“, sofern nichts anderes spezifisch ausgesagt wird, auch so verstanden werden, dass damit X, Y, Z oder eine Kombination davon einschließlich „X, Y und/oder Z“ gemeint ist.
  • Ausführungsformen der Erfindung können verschiedene Schritte aufweisen, die vorstehend beschrieben wurden. Die Schritte können in maschinenausführbaren Befehlen verwirklicht werden, die verwendet werden können, um einen Prozessor für allgemeine oder spezielle Zwecke zu veranlassen, die Schritte auszuführen. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, die eine festverdrahtete Logik zur Ausführung der Schritte enthalten, oder durch eine Kombination programmierter Computerkomponenten und kundenspezifischer Hardwarekomponenten ausgeführt werden.
  • Wie hier beschrieben, können sich Befehle auf spezifische Konfigurationen von Hardware in der Art anwendungsspezifischer integrierter Schaltungen (ASICs), die dafür ausgelegt sind, bestimmte Operationen auszuführen oder eine vorgegebene Funktionalität aufweisen, oder auf Softwarebefehle, die in einem Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium verwirklicht ist, beziehen. Demgemäß können die in den Figuren dargestellten Techniken unter Verwendung von Code und Daten implementiert werden, die auf einer oder mehreren elektronischen Vorrichtungen (beispielsweise einer Endstation, einem Netzelement usw.) gespeichert sind und ausgeführt werden. Diese elektronischen Vorrichtungen speichern und übermitteln (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netz) Code und Daten unter Verwendung computermaschinenlesbarer Medien in der Art nichtflüchtiger computermaschinenlesbarer Speichermedien (beispielsweise Magnetplatten, optische Platten, Direktzugriffsspeicher, Nurlesespeicher, Flash-Speichervorrichtungen, Phasenänderungsspeicher) und tflüchtiger computermaschinenlesbarer Kommunikationsmedien (beispielsweise durch elektrische, optische, akustische oder eine andere Form ausgebreiteter Signale in der Art von Trägerwellen, Infrarotsignalen, Digitalsignalen usw.).
  • Zusätzlich weisen solche elektronischen Vorrichtungen typischerweise einen Satz aus einem oder mehreren mit einer oder mehreren anderen Komponenten in der Art einer oder mehrerer Speichervorrichtungen (beispielsweise nichtflüchtiger maschinenlesbarer Speichermedien), einer oder mehrerer Benutzer-Ein-/Ausgabevorrichtungen (beispielsweise einer Tastatur, eines Touchscreens und/oder einer Anzeige) und Netzverbindungen gekoppelten Prozessoren auf. Die Kopplung des Satzes von Prozessoren und anderen Komponenten erfolgt typischerweise durch einen oder mehrere Busse und Bridges (auch als Bussteuereinrichtungen bezeichnet). Die Speichervorrichtung und die Signale, die jeweils den Netzverkehr übertragen, repräsentieren ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien. Demgemäß speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz aus einem oder mehreren Prozessoren dieser elektronischen Vorrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen von Software, Firmware und/oder Hardware implementiert werden. In dieser detaillierten Beschreibung wurden für die Zwecke der Erklärung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Fachleuten auf dem Gebiet wird jedoch verständlich sein, dass die Erfindung auch ohne einige dieser spezifischen Einzelheiten verwirklicht werden kann. Unter gewissen Umständen wurden wohlbekannte Strukturen und Funktionen nicht in eingehenden Einzelheiten beschrieben, um es zu vermeiden, den Gegenstand der vorliegenden Erfindung unklar zu machen. Dementsprechend sollten der Schutzumfang und der Grundgedanke der Erfindung angesichts der folgenden Ansprüche beurteilt werden.
    • Beispiel 1 weist eine Grafikverarbeitungsvorrichtung auf, welche Folgendes aufweist: eine Schnittstelle zu einer Speichervorrichtung, einen Zwischenpuffer und eine Ausführungseinheit, die mit der Schnittstelle gekoppelt ist, wobei: die Speichervorrichtung Befehle speichern soll, wenigstens einer der Befehle einen Indikator einer Teilaktualisierung eines Registers aufweist, die Ausführungseinheit die Befehle ausführen soll und dem Zwischenpuffer auf der Grundlage des Vorhandenseins des Indikators Daten bereitstellen soll und der Zwischenpuffer auf der Grundlage eines Hinweiszeichens in Zusammenhang mit einem Befehl, das einen letzten Schreibvorgang in den Zwischenpuffer angibt, dem Register Inhalt bereitstellen soll.
    • Beispiel 2 weist ein Beispiel auf, wobei der wenigstens eine der Befehle, die einen Indikator einer Teilaktualisierung eines Registers aufweisen, für die Ausführung sequenziell geordnet sind.
    • Beispiel 3 weist ein Beispiel auf, wobei die Befehle, die das Register teilweise aktualisieren, für die Ausführung sequenziell geordnet sind.
    • Beispiel 4 weist ein Beispiel auf, wobei die Befehle von einem Compiler erzeugte maschinenausführbare Codes aufweisen.
    • Beispiel 5 weist ein Beispiel auf, wobei der Befehl, der einen letzten Schreibvorgang in den Zwischenpuffer angibt, nach wenigstens einem Befehl mit einer Angabe zum Schreiben einer Ausgabe von der Ausführung in den Zwischenpuffer auszuführen ist.
    • Beispiel 6 weist ein Beispiel auf, wobei die Ausführungseinheit eine oder mehrere von einer Rechenlogikeinheit (ALU), einer Adresserzeugungseinheit (AGU), einer Gleitkommaeinheit (FPU), einer Lade-Speicher-Einheit (LSU) oder einer Verzweigungsausführungseinheit (BEU) aufweist.
    • Beispiel 7 weist ein Beispiel auf, wobei der Zwischenpuffer wenigstens einen Flop zum Speichern der Ausgabe von der Ausführungseinheit aufweist.
    • Beispiel 8 weist ein Beispiel auf, wobei das Register mit der Ausführungseinheit gekoppelt ist.
    • Beispiel 9 weist ein Beispiel auf, wobei die Ausführungseinheit Inhalt des Registers in den Speicher kopieren soll.
    • Beispiel 10 weist ein Beispiel auf, wobei die Befehle auf das Maschinenlernen bezogene Anwendungen oder auf Shader bezogene Anwendungen bereitstellen.
    • Beispiel 11 weist ein Beispiel auf, wobei ein Datentyp der Befehle einen oder mehrere von FP8, FP16, FP32, FP64, int8, int16 oder int32 umfasst und eine Datengröße des Registers ein Wort und/oder ein Doppelwort umfasst.
    • Beispiel 12 weist ein computerlesbares Medium auf, auf dem Befehle gespeichert sind, die, falls sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, Folgendes auszuführen: Ausführen eines Compilers, der Folgendes ausführen soll: Empfangen eines Programms zur Ausführung durch eine Grafikverarbeitungseinheit (GPU), Identifizieren einer Gruppe von zwei oder mehr Befehlen, die eine Teilaktualisierung eines Ausgangspuffers bereitstellen, Identifizieren eines Befehls in der Gruppe, um eine Übertragung auszulösen, Formatieren der Gruppe von Befehlen zur Ausführung durch eine Ausführungs-Pipeline der GPU und Speichern eines maschinenausführbaren Formats der Gruppe von Befehlen.
    • Beispiel 13 weist ein Beispiel auf, wobei das Identifizieren einer Gruppe von zwei oder mehr Befehlen, die eine Teilaktualisierung eines Ausgangspuffers bereitstellen, das Schreiben einer Ausgabe von der Ausführung der Gruppe von zwei oder mehr Befehlen in einen Zwischenpuffer bewirkt.
    • Beispiel 14 weist ein Beispiel auf, wobei das Identifizieren eines Befehls in der Gruppe zur Auslösung einer Übertragung das Schreiben einer Ausgabe von der Ausführung der Befehle in einen Zwischenpuffer und das Kopieren des Inhalts des Zwischenpuffers in den Ausgangspuffer bewirken soll.
    • Beispiel 15 weist ein Beispiel auf, wobei der Compiler für ein teilweises, jedoch nicht vollständiges Aktualisieren des Ausgangspuffers Folgendes ausführen soll: Bilden eines Befehls, der Inhalt des Ausgangspuffers in einen Zwischenpuffer kopiert, Gruppieren des Befehls, der Inhalt des Ausgangspuffers in den Zwischenpuffer kopiert, mit einem Befehl, der ein teilweises, jedoch nicht vollständiges Aktualisieren des Ausgangspuffers bereitstellt, und Identifizieren des Befehls, der Inhalt des Ausgangspuffers in den Zwischenpuffer kopiert, mit einem Befehl, der ein teilweises, jedoch nicht vollständiges Aktualisieren des Ausgangspuffers bereitstellt, um eine Übertragung auszulösen.
    • Beispiel 16 weist ein Beispiel auf, wobei die Befehle für Bildverarbeitungs- oder Maschinenlernanwendungen vorgesehen sind.
    • Beispiel 17 weist ein Beispiel auf, wobei die Befehle einen Byteversatz, bei dem Inhalt in den Ausgangspuffer zu schreiben ist, spezifizieren.
    • Beispiel 18 weist ein System auf, welches Folgendes aufweist: eine Zentralverarbeitungseinheit (CPU), einen Speicher und eine Grafikverarbeitungseinheit (GPU), die eine Ausführungseinheit, einen Zwischenpuffer und ein Register aufweist, wobei die GPU mit der CPU und dem Speicher gekoppelt ist, wobei: der Speicher Befehle speichern soll, wenigstens einer der Befehle einen Indikator einer Teilaktualisierung eines Registers aufweist, die Ausführungseinheit die Befehle ausführen soll und dem Zwischenpuffer Daten bereitstellen soll und der Zwischenpuffer auf der Grundlage eines Hinweiszeichens in Zusammenhang mit einem Befehl, das einen letzten Schreibvorgang in den Zwischenpuffer angibt, dem Register Inhalt bereitstellen soll.
    • Beispiel 19 weist ein Beispiel auf, wobei die CPU einen Compiler ausführen soll, um Folgendes auszuführen: Zugreifen auf ein Programm zur Ausführung durch eine Grafikverarbeitungseinheit (GPU), Identifizieren einer Gruppe von zwei oder mehr Befehlen, die eine Teilaktualisierung des Registers bereitstellt, Identifizieren eines Befehls in der Gruppe, um eine Übertragung auszulösen, Formatieren der Gruppe von Befehlen zur Ausführung in einer Reihe durch eine Ausführungs-Pipeline der GPU und Speichern eines maschinenausführbaren Formats der Gruppe von Befehlen im Speicher.
    • Beispiel 20 weist ein Beispiel auf, wobei der wenigstens eine der Befehle, die einen Indikator einer Teilaktualisierung eines Registers aufweisen, für die Ausführung sequenziell geordnet sind.
    • Beispiel 21 weist ein Beispiel auf, wobei der Befehl, der einen letzten Schreibvorgang in den Zwischenpuffer angibt, nach dem wenigstens einen der Befehle, die einen Indikator einer Teilaktualisierung eines Registers aufweisen, auszuführen ist.
    • Beispiel 22 weist ein Beispiel auf, wobei ein erster Befehl ein teilweises Schreiben in ein Register identifizieren soll und der Rest des Registers nicht überschrieben wird.
    • Beispiel 23 weist ein Beispiel auf, wobei die Ausführungs-Pipeline eine oder mehrere von einer Rechenlogikeinheit (ALU), einer Adresserzeugungseinheit (AGU), einer Gleitkommaeinheit (FPU), einer Lade-Speicher-Einheit (LSU) oder einer Verzweigungsausführungseinheit (BEU) aufweist.

Claims (15)

  1. Grafikverarbeitungsvorrichtung, welche Folgendes aufweist: eine Schnittstelle zu einer Speichervorrichtung, einen Zwischenpuffer und eine Ausführungseinheit, die mit der Schnittstelle gekoppelt ist, wobei: die Speichervorrichtung Befehle speichern soll, wenigstens einer der Befehle einen Indikator einer Teilaktualisierung eines Registers aufweist, die Ausführungseinheit die Befehle ausführen soll und dem Zwischenpuffer auf der Grundlage des Vorhandenseins des Indikators Daten bereitstellen soll und der Zwischenpuffer auf der Grundlage eines Hinweiszeichens in Zusammenhang mit einem Befehl, das einen letzten Schreibvorgang in den Zwischenpuffer angibt, dem Register Inhalt bereitstellen soll.
  2. Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Befehle, die das Register teilweise aktualisieren, für die Ausführung sequenziell geordnet sind.
  3. Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei der Befehl, der einen letzten Schreibvorgang in den Zwischenpuffer angibt, nach wenigstens einem Befehl mit einer Angabe zum Schreiben einer Ausgabe von der Ausführung in den Zwischenpuffer auszuführen ist.
  4. Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Ausführungseinheit eine oder mehrere von einer Rechenlogikeinheit (ALU), einer Adresserzeugungseinheit (AGU), einer Gleitkommaeinheit (FPU), einer Lade-Speicher-Einheit (LSU) oder einer Verzweigungsausführungseinheit (BEU) aufweist und wobei der Zwischenpuffer wenigstens einen Flop zum Speichern einer Ausgabe von der Ausführungseinheit aufweist.
  5. Grafikverarbeitungsvorrichtung nach Anspruch 1, welche ferner das Register aufweist, und wobei das Register mit der Ausführungseinheit gekoppelt ist, wobei die Ausführungseinheit Inhalt des Registers in den Speicher kopieren soll.
  6. Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei ein Datentyp der Befehle einen oder mehrere von FP8, FP16, FP32, FP64, int8, int16 oder int32 umfasst und eine Datengröße des Registers ein Wort und/oder ein Doppelwort umfasst.
  7. Grafikverarbeitungsvorrichtung nach einem der Ansprüche 1-6, wobei die Befehle auf das Maschinenlernen bezogene Anwendungen oder auf Shader bezogene Anwendungen bereitstellen.
  8. Computerlesbares Medium, auf dem Befehle gespeichert sind, die, falls sie durch einen Prozessor ausgeführt werden, den Prozessor veranlassen, Folgendes auszuführen: Ausführen eines Compilers, der Folgendes ausführen soll: Empfangen eines Programms zur Ausführung durch eine Grafikverarbeitungseinheit (GPU), Identifizieren einer Gruppe von zwei oder mehr Befehlen, die eine Teilaktualisierung eines Ausgangspuffers bereitstellen, Identifizieren eines Befehls in der Gruppe, um eine Übertragung auszulösen, Formatieren der Gruppe von Befehlen zur Ausführung durch eine Ausführungs-Pipeline der GPU und Speichern eines maschinenausführbaren Formats der Gruppe von Befehlen.
  9. Computerlesbares Medium nach Anspruch 8, wobei das Identifizieren einer Gruppe von zwei oder mehr Befehlen, die eine Teilaktualisierung eines Ausgangspuffers bereitstellen, das Schreiben einer Ausgabe von der Ausführung der Gruppe von zwei oder mehr Befehlen in einen Zwischenpuffer bewirkt.
  10. Computerlesbares Medium nach Anspruch 8, wobei der Compiler für ein teilweises, jedoch nicht vollständiges Aktualisieren des Ausgangspuffers Folgendes ausführen soll: Bilden eines Befehls, der das Kopieren von Inhalt des Ausgangspuffers in einen Zwischenpuffer bewirkt, Bilden einer Gruppe, die den Befehl, der das Kopieren von Inhalt des Ausgangspuffers in den Zwischenpuffer bewirkt, und einen Befehl, der ein teilweises, jedoch nicht vollständiges Aktualisieren des Ausgangspuffers bereitstellt, aufweist, und Identifizieren der Gruppe, die den Befehl, der das Kopieren von Inhalt des Ausgangspuffers in den Zwischenpuffer bewirkt, und den Befehl, der ein teilweises, jedoch nicht vollständiges Aktualisieren des Ausgangspuffers bereitstellt, um eine Übertragung auszulösen, aufweist.
  11. Computerlesbares Medium nach Anspruch 8, wobei die Befehle für Bildverarbeitungs- oder Maschinenlernanwendungen vorgesehen sind.
  12. Computerlesbares Medium nach einem der Ansprüche 8-11, wobei das Identifizieren eines Befehls in der Gruppe zur Auslösung einer Übertragung das Schreiben einer Ausgabe von der Ausführung der Befehle in einen Zwischenpuffer und das Kopieren von Inhalt des Zwischenpuffers in den Ausgangspuffer bewirkt.
  13. System, welches Folgendes aufweist: eine Zentralverarbeitungseinheit (CPU), einen Speicher und eine Grafikverarbeitungseinheit (GPU), die eine Ausführungseinheit, einen Zwischenpuffer und ein Register aufweist, wobei die GPU mit der CPU und dem Speicher gekoppelt ist, wobei: der Speicher Befehle speichern soll, wenigstens einer der Befehle einen Indikator einer Teilaktualisierung eines Registers aufweist, die Ausführungseinheit die Befehle ausführen soll und dem Zwischenpuffer Daten bereitstellen soll und der Zwischenpuffer auf der Grundlage eines Hinweiszeichens in Zusammenhang mit einem Befehl, das einen letzten Schreibvorgang in den Zwischenpuffer angibt, dem Register Inhalt bereitstellen soll.
  14. System nach Anspruch 13, wobei die CPU einen Compiler ausführen soll, um Folgendes auszuführen: Zugreifen auf ein Programm zur Ausführung durch eine Grafikverarbeitungseinheit (GPU), Identifizieren einer Gruppe von zwei oder mehr Befehlen, die eine Teilaktualisierung des Registers bereitstellt, Identifizieren eines Befehls in der Gruppe, um eine Übertragung auszulösen, Formatieren der Gruppe von Befehlen zur Ausführung in einer Sequenz durch eine Ausführungs-Pipeline der GPU und Speichern eines maschinenausführbaren Formats der Gruppe von Befehlen im Speicher.
  15. System nach Anspruch 13 oder 14, wobei die Befehle, die einen Indikator einer Teilaktualisierung eines Registers aufweisen, für die Ausführung sequenziell geordnet sind und wobei der Befehl, der einen letzten Schreibvorgang in den Zwischenpuffer angibt, nach dem wenigstens einen der Befehle, die einen Indikator einer Teilaktualisierung eines Registers aufweisen, auszuführen ist.
DE102020133275.0A 2019-12-24 2020-12-14 Compiler-unterstützte registerdatei-schreibverringerung Pending DE102020133275A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/726,659 US11321799B2 (en) 2019-12-24 2019-12-24 Compiler assisted register file write reduction
US16/726,659 2019-12-24

Publications (1)

Publication Number Publication Date
DE102020133275A1 true DE102020133275A1 (de) 2021-06-24

Family

ID=76206055

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020133275.0A Pending DE102020133275A1 (de) 2019-12-24 2020-12-14 Compiler-unterstützte registerdatei-schreibverringerung

Country Status (7)

Country Link
US (2) US11321799B2 (de)
JP (1) JP2021103512A (de)
KR (1) KR20210082060A (de)
CN (1) CN113032159A (de)
BR (1) BR102021004500A2 (de)
DE (1) DE102020133275A1 (de)
TW (1) TW202125222A (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11586580B2 (en) * 2021-07-08 2023-02-21 Avago Technologies International Sales Pte. Limited Parallel processor optimized for machine learning
KR102631214B1 (ko) * 2023-06-23 2024-01-31 주식회사 하이퍼엑셀 대규모 언어 모델 추론을 가속화하기 위한 효율적인 데이터 포워딩 방법 및 시스템

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3452771B2 (ja) * 1997-10-02 2003-09-29 富士通株式会社 命令制御システム及びその方法
US7818356B2 (en) * 2001-10-29 2010-10-19 Intel Corporation Bitstream buffer manipulation with a SIMD merge instruction
US8245199B2 (en) * 2006-05-05 2012-08-14 International Business Machines Corporation Selectively marking and executing instrumentation code
US9652233B2 (en) * 2013-08-20 2017-05-16 Apple Inc. Hint values for use with an operand cache
US10346170B2 (en) * 2015-05-05 2019-07-09 Intel Corporation Performing partial register write operations in a processor
US10699362B2 (en) * 2016-06-23 2020-06-30 Intel Corporation Divergent control flow for fused EUs
US10146691B2 (en) * 2016-12-09 2018-12-04 Intel Corporation System and method for performing partial cache line writes without fill-reads or byte enables
US11157407B2 (en) * 2016-12-15 2021-10-26 Optimum Semiconductor Technologies Inc. Implementing atomic primitives using cache line locking
US10262388B2 (en) * 2017-04-10 2019-04-16 Intel Corporation Frequent data value compression for graphics processing units
US10853989B2 (en) * 2018-09-26 2020-12-01 Intel Corporation Coarse compute shading
US11132326B1 (en) * 2020-03-11 2021-09-28 Nvidia Corporation Techniques to transfer data among hardware devices

Also Published As

Publication number Publication date
JP2021103512A (ja) 2021-07-15
US20210192673A1 (en) 2021-06-24
US11900502B2 (en) 2024-02-13
US20220261949A1 (en) 2022-08-18
US11321799B2 (en) 2022-05-03
KR20210082060A (ko) 2021-07-02
TW202125222A (zh) 2021-07-01
BR102021004500A2 (pt) 2021-07-20
CN113032159A (zh) 2021-06-25

Similar Documents

Publication Publication Date Title
DE112020000874T5 (de) Systeme und Methoden zum Aktualisieren von speicherseitigen Caches in einer Multi-GPU-Konfiguration
DE102020120372A1 (de) Programmierbare wandlungshardware
DE102020115026A1 (de) Systeme und Verfahren zur Tonabbildung von Bildern mit hohem Dynamikumfang für auf tiefem Lernen basierende Verarbeitung von hoher Qualität
DE102020121814A1 (de) Vorrichtung und Verfahren zum Verwenden von Dreieckspaaren und gemeinsam genutzten Transformationsschaltungen zum Verbessern der Strahlverfolgungsleistung
DE102020115680A1 (de) LESEZUSAMMENFüGUNG UND M ULTICAST-RÜCKFÜHRUNG FÜR EINEN GETEILTEN LOKALEN SPEICHER
DE102019101118A1 (de) Anweisung und Logik für systolisches Skalarprodukt mit Akkumulation
DE102020129623A1 (de) Blickgedämpfter virtueller desktop
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE102020124872A1 (de) Verwendung von innere-abdeckung-informationen durch eine konservative-rasterung-pipeline zum aktivieren von earlyz für eine konservative rasterung
DE102020131704A1 (de) Multikachelspeicherverwaltungsmechanismus
DE102019110027A1 (de) Kachelbasiertes rendern für mehrere auflösungen von bildern
DE102020132871A1 (de) Verbessern von hierarchischer tiefenpuffer-cullingeffizienz durch maskenakkumulation
DE102020127035A1 (de) Programmierbarer umordnungspuffer für dekomprimierung
DE102020130880A1 (de) Mechanismus zur partitionierung eines geteilten lokalen speichers
DE102019117545A1 (de) Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors
DE102020126177A1 (de) Verfahren und vorrichtung zum planen der threadreihenfolge, um den cache-wirkungsgrad zu verbessern
DE102020115578A1 (de) Management von partiellem schreiben in einer grafik-enginemit mehreren kacheln
DE102020130865A1 (de) Anweisungen und logik für vektor-multiplikation-addition mit zero-skipping
DE102020131293A1 (de) Einrichtung und verfahren zur multi-adapter-kodierung
DE102020129625A1 (de) Seitentabellen-mapping-mechanismus
DE102020113400A1 (de) Registerteilungsmechanismus
DE102020113789A1 (de) Asynchroner ausführungsmechanismus
DE112018003999T5 (de) Verfahren und Vorrichtung für effiziente Verarbeitung von abgeleiteten einheitlichen Werten in einem Grafikprozessor
DE102019120922A1 (de) Vorrichtung und verfahren für multifrequenz-vertex-shadinghintergrund
DE102020133275A1 (de) Compiler-unterstützte registerdatei-schreibverringerung