DE102019117545A1 - Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors - Google Patents

Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors Download PDF

Info

Publication number
DE102019117545A1
DE102019117545A1 DE102019117545.3A DE102019117545A DE102019117545A1 DE 102019117545 A1 DE102019117545 A1 DE 102019117545A1 DE 102019117545 A DE102019117545 A DE 102019117545A DE 102019117545 A1 DE102019117545 A1 DE 102019117545A1
Authority
DE
Germany
Prior art keywords
register
instruction
registers
banks
instructions
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
DE102019117545.3A
Other languages
English (en)
Inventor
Chandra Gurram
Subramaniam Maiyuran
Buqi Cheng
Ashutosh Garg
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 DE102019117545A1 publication Critical patent/DE102019117545A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • 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/44—Encoding
    • G06F8/441—Register allocation; Assignment of physical memory space to logical memory space
    • 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/30098—Register arrangements
    • G06F9/30141—Implementation provisions of register files, e.g. ports
    • 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/30145—Instruction analysis, e.g. decoding, instruction word fields
    • G06F9/3016—Decoding the operand specifier, e.g. specifier format
    • 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/3824—Operand accessing
    • 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/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • 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/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3887—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by a single instruction for multiple data lanes [SIMD]
    • 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

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 Graphics (AREA)
  • Multimedia (AREA)
  • Image Generation (AREA)
  • Advance Control (AREA)

Abstract

Die Ausführungsformen richten sich im Allgemeinen auf eine Reduzierung von Registerbankkonflikten für Ausführungseinheiten eines Multithread-Prozessors. Eine Ausführungsform einer Vorrichtung beinhaltet einen Prozessor, der eine oder mehrere Ausführungseinheiten (EUs) beinhaltet, wobei mindestens eine erste Ausführungseinheit (EU) mehrere Threads verarbeiten soll, wobei die erste EU eine Registerdatei beinhaltet, die mehrere Registerbanken beinhaltet, wobei jede Registerbank mehrere Register beinhaltet, sowie einen oder mehrere Lese-Multiplexer zum Lesen von Registern aus der Registerdatei, wobei der Versuch, mehr als ein Register aus einer einzelnen Registerbank der Registerdatei in einem gleichen Taktzyklus zu lesen, einen Registerbankkonflikt erzeugt. Die Register für jeden Thread für die erste EU sind derart über die Registerbanken innerhalb der Registerdatei hinweg verteilt, dass sich ein erstes Register für einen ersten Thread der mehreren Threads und ein folgendes zweites Register für den ersten Thread in unterschiedlichen Registerbanken innerhalb der Registerdatei befinden.

Description

  • TECHNISCHES GEBIET
  • Hierin beschriebene Ausführungsformen betreffen im Allgemeinen das Gebiet elektronischer Geräte und insbesondere die Reduzierung von Registerbankkonflikten für Ausführungseinheiten eines Multithread-Prozessors.
  • ALLGEMEINER STAND DER TECHNIK
  • Bei Rechenoperationen sind Mehrbank-Registerdateien übliche Strukturen für die Berechnungsdatenspeicherung, wie z.B. in Ausführungseinheiten (EUs - Execution Units) für grafische Verarbeitungseinheiten (GPUs - Graphical Processing Units). Die Mehrbankstrukturen beinhalten im Allgemeinen eine Reihe von Registerbanken, die zusammengelegt sind, wobei die Anschlüsse für einen verringerten Flächenbedarf gemeinsam genutzt werden.
  • Die Registerbanken einer Mehrbankstruktur sind üblicherweise jeweils mit einem Element zum Auswählen einer Registerbank zum Lesen gekoppelt, wie z.B. einem Registerdatei-Lese-Multiplexer. Auf diese Weise ist es möglich, mehrere Register, ein Register pro Anschluss, im gleichen Taktzyklus zu lesen, solange die Register alle zu unterschiedlichen Banken gehören.
  • Jedoch resultiert das Lesen von zwei oder mehr Registern, die zur gleichen Bank gehören, in einem gleichen Taktzyklus in einem Registerbankkonflikt, der dann die Leseanfragen serialisiert und potentiell Verzögerungen in der Pipeline verursacht. Bei GPUs resultiert die Mehrzahl von Registerbankkonflikten aus Thread-internen Konflikten, was in einer verminderten Effizienz bei der Verarbeitung der mehreren Threads für die GPU-Ausführungseinheiten resultiert.
  • Figurenliste
  • Hier beschriebene Ausführungsformen sind in den Figuren der beigefügten Zeichnungen, in welchen sich gleiche Referenzziffern auf ähnliche Elemente beziehen, beispielhaft und nicht einschränkend veranschaulicht.
    • 1 ist ein Blockdiagramm eines Verarbeitungssystems gemäß einiger Ausführungsformen;
    • 2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors, der einen oder mehrere Prozessorkerne, einen integrierten Speicher-Controller und einen integrierten Grafikprozessor aufweist;
    • 3 ist ein Blockdiagramm eines Grafikprozessors gemäß einiger Ausführungsformen;
    • 4 ist ein Blockdiagramm einer Grafikverarbeitungsmaschine eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen;
    • 5 ist ein Blockdiagramm von Hardware-Logik eines Grafikprozessorkerns gemäß einiger Ausführungsformen;
    • 6A-6B veranschaulichen Thread-Ausführungslogik, einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß einiger Ausführungsformen;
    • 7 ist ein Blockdiagramm, welches Grafikprozessor-Anweisungsformate gemäß einiger Ausführungsformen veranschaulicht;
    • 8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors;
    • 9A ist ein Blockdiagramm, welches ein Grafikprozessor-Befehlsformat gemäß einiger Ausführungsformen veranschaulicht;
    • 9B ist ein Blockdiagramm, welches eine Grafikprozessor-Befehlssequenz gemäß einer Ausführungsform veranschaulicht;
    • 10 veranschaulicht beispielhaft eine Grafiksoftwarearchitektur für ein Datenverarbeitungssystem gemäß einiger Ausführungsformen;
    • 11A ist ein Blockdiagramm, welches ein IP-Kern-Entwicklungssystem, das zur Herstellung einer integrierten Schaltung zum Durchführen von Operationen verwendet werden kann, gemäß einer Ausführungsform veranschaulicht;
    • 11B veranschaulicht eine Querschnitt-Seitenansicht einer Paketbaugruppe einer integrierten Schaltung gemäß einiger Ausführungsformen;
    • 12 ist ein Blockdiagramm, welches eine beispielhafte integrierte Ein-Chip-System-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform veranschaulicht;
    • 13A veranschaulicht einen beispielhaften Grafikprozessor einer integrierten Ein-Chip-System-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform;
    • 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor einer integrierten Ein-Chip-System-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform;
    • 14A veranschaulicht einen Grafikkern, der innerhalb eines Grafikprozessors enthalten sein kann, gemäß einiger Ausführungsformen;
    • 14B veranschaulicht eine hochparallele Universal-Grafikverarbeitungseinheit, die zum Einsatz auf einem Mehrchip-Modul geeignet ist, gemäß einiger Ausführungsformen;
    • 15 ist eine Veranschaulichung eines Verarbeitungssystems, das eine Architektur zur Reduzierung von Registerbankkonflikten für Multithread-Ausführungseinheiten beinhaltet, gemäß einiger Ausführungsformen;
    • 16 ist eine Veranschaulichung eines Mehrbank-Register-Arrays in einer Vorrichtung oder einem System;
    • 17 ist eine Veranschaulichung eines Mehrbank-Register-Arrays in einer Vorrichtung oder einem System, welche/s eine Registerverteilung über Registerbanken hinweg bereitstellt, gemäß einiger Ausführungsformen;
    • 18 ist eine Veranschaulichung von Mehrbank-Register-Arrays in einer Vorrichtung oder einem System, welche/s eine Registerverteilung über Registerbanken hinweg bereitstellt, gemäß einiger Ausführungsformen;
    • 19 ist eine Veranschaulichung einer Pipeline mit mehreren Registerlesestufen gemäß einiger Ausführungsformen;
    • 20 ist eine Veranschaulichung von logischen und physischen SIMD-Anweisungen, die in einem System oder einer Vorrichtung verarbeitet werden, gemäß einiger Ausführungsformen;
    • 21 ist eine Veranschaulichung des Tauschens von Operandenpositionen für eine Zwei-Quellen-Anweisung gemäß einiger Ausführungsformen;
    • 22 ist eine Veranschaulichung des Tauschens von Operandenpositionen für eine Drei-Quellen-Anweisung gemäß einiger Ausführungsformen; und
    • 23 ist ein Flussdiagramm zum Veranschaulichen eines Prozesses zum Tauschen von Operandenpositionen zur Reduzierung von Registerbankkonflikten gemäß einiger Ausführungsformen.
  • DETAILLIERTE BESCHREIBUNG
  • Hierin beschriebene Ausführungsformen richten sich im Allgemeinen auf die Reduzierung von Registerbankkonflikten für Ausführungseinheiten eines Multithread -Prozessors.
  • Bei Rechenoperationen sind Mehrbank-Registerdateien übliche Strukturen für die Berechnungsdatenspeicherung in Ausführungseinheiten (EUs - Execution Units) für grafische Verarbeitungseinheiten (GPUs - Graphical Processing Units). Die Mehrbankstrukturen beinhalten im Allgemeinen eine Reihe von Registerbanken, die zusammengelegt sind, wobei die Anschlüsse für einen verringerten Flächenbedarf gemeinsam genutzt werden. Die Register können Quelloperanden für Anweisungen und Ziele für Anweisungsergebnisse beinhalten. Die Registerbanken sind üblicherweise jeweils mit einem Element zum Auswählen einer Registerbank zum Lesen gekoppelt, wie z.B. einem Registerdatei-Lese-Multiplexer. Auf diese Weise ist es möglich, mehrere Register, ein Register pro Anschluss, im gleichen Taktzyklus zu lesen, solange sich jedes der mehreren Register in einer unterschiedlichen Registerbank befindet. Jedoch resultiert das Lesen von zwei oder mehr Registern, die zur gleichen Bank gehören, in einem Registerbankkonflikt, der die Leseanfragen in der Pipeline serialisiert. Bei GPUs resultiert die Mehrzahl von Registerbankkonflikten aus Thread-internen Konflikten.
  • Es können verschiedene Hardware-Modifikationen implementiert werden, um Registerbankkonflikte anzugehen, wie z.B. das Hinzufügen von mehr Registerbanken und Anschlüssen und das Puffern von Daten. Ferner könnte ein Compiler auch ausgefeilte Registerzuteilungsalgorithmen anwenden, um die Wahrscheinlichkeit von Konflikten zu verringern. Jedoch ist die Implementierung dieser Optionen teuer. Die Hardware-Modifikationen erfordern einen Flächen- und Energiemehraufwand und Designkomplexität, und eine ausgefeilte Registerzuteilung im Compiler geht häufig mit einer längeren Übersetzungszeit einher. Ferner wird die Effizienz der Registerzuteilung aufgrund der Zusatzauswirkung aus einer bankspezifischen Zuteilung verringert. In einigen Fällen verlangsamt der Speicherzugriff mit langer Latenz, der durch den Registerüberlauf eingeführt wird, die Verarbeitung der Anwendung.
  • In einigen Ausführungsformen sorgt eine Vorrichtung, ein System oder ein Prozess durch eine Kombination von einem oder mehreren aus einer Registerverteilung über Registerbanken hinweg, mehreren Stufen zum Lesen von Registern in einer Pipeline und der Bereitstellung eines Operandenpositionstauschs für Anweisungen für eine Reduzierung von Registerbankkonflikten.
  • Systemüberblick
  • 1 ist ein Blockdiagramm eines Verarbeitungssystems 100 gemäß einer Ausführungsform. In verschiedenen Ausführungsformen beinhaltet das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein Einzelprozessor-Desktopsystem, ein Mehrprozessor-Workstation-System oder ein Serversystem mit einer großen Zahl von Prozessoren 102 oder Prozessorkernen 107 sein. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die innerhalb einer integrierten Ein-Chip-System (SoC - System-on-a-Chip) -Schaltung integriert ist, zur Verwendung in Mobil-, Handheld- oder eingebetteten Geräten.
  • In einer Ausführungsform kann das System 100 eine serverbasierte Spieleplattform, eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, eine mobile Spielekonsole, eine Handheld-Spielekonsole oder eine Online-Spielekonsole beinhalten oder darin integriert sein. In einigen Ausführungsformen ist das System 100 ein Mobiltelefon, ein Smartphone, ein Tablet oder ein mobiles Internetgerät. Das Verarbeitungssystem 100 kann auch ein tragbares Gerät, wie z.B. eine Smartwatch, Smartglasses, ein Augmented-Reality-Gerät oder ein Virtual-Reality-Gerät, beinhalten, damit gekoppelt sein oder darin integriert sein. In einigen Ausführungsformen ist das Verarbeitungssystem 100 ein Fernseher oder eine Set-Top-Box mit einem oder mehreren Prozessoren 102 und einer grafischen Schnittstelle, die durch einen oder mehrere Grafikprozessoren 108 erzeugt wird.
  • In einigen Ausführungsformen beinhalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zum Verarbeiten von Anweisungen, welche, wenn sie ausgeführt werden, Operationen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder des einen oder der mehreren Prozessorkerne 107 zum Verarbeiten eines spezifischen Anweisungssatzes 109 konfiguriert. In einigen Ausführungsformen kann der Anweisungssatz 109 Berechnungen mit einem komplexen Anweisungssatz (CISC - Complex Instruction Set Computing), Berechnungen mit einem reduzierten Anweisungssatz (RISC - Reduced Instruction Set Computing) oder Berechnungen über ein sehr langes Befehlswort (VLIW - Very Long Instruction Word) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Anweisungssatz 109 verarbeiten, welcher Anweisungen beinhalten kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsgeräte beinhalten, wie z.B. einen digitalen Signalprozessor (DSP - Digital Signal Processor).
  • In einigen Ausführungsformen beinhaltet der Prozessor 102 einen Cachespeicher 104. In Abhängigkeit von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Level von internem Cache aufweisen. In einigen Ausführungsformen wird der Cachespeicher durch verschiedene Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Cache (z.B. einen Level-3 (L3) -Cache oder Last-Level-Cache (LLC)) (nicht gezeigt), welcher durch die Prozessorkerne 107 unter Verwendung bekannter Cache-Kohärenztechniken gemeinsam genutzt werden kann. Eine Registerdatei 106 ist zusätzlich im Prozessor 102 enthalten, welche unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten (z.B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister) beinhalten kann. Einige Register können Universalregister sein, während andere Register spezifisch für das Design des Prozessors 102 sein können.
  • In einigen Ausführungsformen sind ein oder mehrere Prozessor(en) 102 mit einem oder mehreren Schnittstellenbus(sen) 110 gekoppelt, um Kommunikationssignale, wie z.B. Adress-, Daten- oder Steuersignale, zwischen dem Prozessor 102 und anderen Komponenten in dem System 100 zu übermitteln. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus sein, wie z.B. eine Version des DMI (Direct Media Interface) -Busses. Jedoch sind Prozessorbusse nicht auf den DMI-Bus beschränkt und können einen oder mehrere PCI (Peripheral Component Interconnect) -Busse (z.B. PCI, PCI Express), Speicherbusse oder andere Arten von Schnittstellenbussen beinhalten. In einer Ausführungsform beinhalten der/die Prozessor(en) 102 einen integrierten Speicher-Controller 116 und einen Plattform-Controller-Hub 130. Der Speicher-Controller 116 ermöglicht die Kommunikation zwischen einem Speichergerät und anderen Komponenten des Systems 100, während der Plattform-Controller-Hub (PCH - Platform Controller Hub) 130 Verbindungen zu E/A-Geräten über einen lokalen E/A-Bus bereitstellt.
  • Das Speichergerät 120 kann ein dynamisches Direktzugriffsspeicher (DRAM - Dynamic Random-Access Memory) -Gerät, ein statisches Direktzugriffsspeicher (SRAM - Static Random-Access Memory) -Gerät, ein Flashspeichergerät, ein Phasenwechselspeichergerät oder ein anderes Speichergerät, das eine geeignete Leistung aufweist, um als ein Prozessspeicher zu dienen, sein. In einer Ausführungsform kann das Speichergerät 120 als Systemspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung zu speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Der Speicher-Controller 116 ist auch mit einem optionalen externen Grafikprozessor 112 gekoppelt, welcher mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen kann ein Anzeigegerät 111 mit dem/den Prozessor(en) 102 verbunden sein. Das Anzeigegerät 111 kann eines oder mehrere aus einem internen Anzeigegerät, wie bei einem elektronischen Mobilgerät oder einem Laptop, oder einem externen Anzeigegerät, das über eine Anzeigeschnittstelle (z.B. einen DisplayPort usw.) angeschlossen ist, sein. In einer Ausführungsform kann das Anzeigegerät 111 eine am Kopf befestigte Anzeige (HMD - HeadMounted Display), wie z.B. ein stereoskopisches Anzeigegerät, zur Verwendung bei Virtual-Reality (VR) - Anwendungen oder Augmented-Reality (AR) -Anwendungen sein.
  • In einigen Ausführungsformen ermöglicht der Plattform-Controller-Hub 130 Peripheriegeräten das Verbinden mit dem Speichergerät 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A-Bus. Zu den E/A-Peripheriegeräten zählen, jedoch nicht darauf beschränkt, ein Audio-Controller 146, ein Netzwerk-Controller 134, eine Firmware-Schnittstelle 128, ein drahtloser Sendeempfänger 126, Berührungssensoren 125, ein Datenspeichergerät 124 (z.B. Festplattenlaufwerk, Flashspeicher usw.). Das Datenspeichergerät 124 kann über eine Speicherschnittstelle (z.B. SATA) oder über einen Peripheriebus, wie z.B. einen PCI (Peripheral Component Interconnect) -Bus (z.B. PCI, PCI Express), verbunden sein. Zu den Berührungssensoren 125 können Touchscreen-Sensoren, Drucksensoren oder Fingerabdruck-Sensoren zählen. Der drahtlose Sendeempfänger 126 kann ein Wi-Fi-Sendeempfänger, ein Bluetooth-Sendeempfänger oder ein Mobilnetz-Sendeempfänger, wie z.B. ein 3G, 4G oder LTE (Long-Term Evolution) -Sendeempfänger, sein. Die Firmware-Schnittstelle 128 ermöglicht die Kommunikation mit System-Firmware und kann zum Beispiel eine UEFI (Unified Extensible Firmware Interface) sein. Der Netzwerk-Controller 134 kann eine Netzwerkverbindung zu einem verdrahteten Netzwerk sein. In einigen Ausführungsformen ist ein Hochleistungs-Netzwerk-Controller (nicht gezeigt) mit dem Schnittstellenbus 110 gekoppelt. Der Audio-Controller 146 ist in einer Ausführungsform ein Mehrkanal-High-Definition-Audio-Controller. In einer Ausführungsform beinhaltet das System 100 einen optionalen älteren E/A-Controller 140 zum Koppeln von älteren Geräten (z.B. Personal System 2 (PS/2)) an das System. Der Plattform-Controller-Hub 130 kann auch mit einem oder mehreren USB (Universal Serial Bus) -Controllern 142 verbunden sein, um Eingabegeräte, wie z.B. Kombinationen von Tastatur und Maus 143, eine Kamera 144 oder andere USB-Eingabegeräte, anzuschließen.
  • Es wird verstanden werden, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, verwendet werden können. Zum Beispiel kann eine Instanz des Speicher-Controllers 116 und des Plattform-Controller-Hubs 130 in einen diskreten externen Grafikprozessor, wie z.B. den externen Grafikprozessor 112, integriert sein. In einer Ausführungsform können sich der Plattform-Controller-Hub 130 und/oder der Speicher-Controller 160 außerhalb des einen oder der mehreren Prozessors(en) 102 befinden. Zum Beispiel kann das System 100 einen externen Speicher-Controller 116 und Plattform-Controller-Hub 130 beinhalten, welche als ein Speicher-Controller-Hub und Peripherie-Controller-Hub innerhalb eines System-Chipsatzes konfiguriert sein können, der in Kommunikation mit dem/den Prozessor(en) 102 steht.
  • 2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einem integrierten Speicher-Controller 214 und einem integrierten Grafikprozessor 208. Diejenigen Elemente von 2, welche die gleichen Referenznummern (oder Namen) wie die Elemente einer jeden anderen Figur hierin aufweisen, können in jeglicher Art und Weise arbeiten oder funktionieren, die ähnlich der anderswo hierin beschriebenen ist, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann zusätzliche Kerne bis einschließlich des zusätzlichen Kerns 202N beinhalten, der durch die gestrichelten Kästchen dargestellt ist. Jeder der Prozessorkerne 202A-202N beinhaltet eine oder mehrere interne Cacheeinheiten 204A-204N. In einigen Ausführungsformen hat jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Cacheeinheiten 206.
  • Die internen Cacheeinheiten 204A-204N und die gemeinsam genutzten Cacheeinheiten 206 stellen eine Cachespeicher-Hierarchie innerhalb des Prozessors 200 dar. Die Cachespeicher-Hierarchie kann mindestens ein Level von Anweisungs- und Datencache innerhalb jedes Prozessorkerns und ein oder mehrere Level von gemeinsam genutztem Mittel-Level-Cache, wie z.B. ein Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Level von Cache beinhalten, wobei das höchste Level von Cache vor einem externen Speicher als der LLC klassifiziert ist. In einigen Ausführungsformen hält eine Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cacheeinheiten 206 und 204A-204N aufrecht.
  • In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einer oder mehreren Bus-Controller-Einheiten 216 und einen Systemagentkern 210 beinhalten. Die eine oder die mehreren Bus-Controller-Einheiten 216 managen einen Satz von Peripheriebussen, wie z.B. einen oder mehrere PCI- oder PCI Express-Busse. Der Systemagentkern 210 stellt Managementfunktionalität für die verschiedenen Prozessorkomponenten bereit. In einigen Ausführungsformen beinhaltet der Systemagentkern 210 einen oder mehrere integrierte Speicher-Controller 214 zum Managen des Zugriffs auf verschiedene externe Speichergeräte (nicht gezeigt).
  • In einigen Ausführungsformen beinhalten ein oder mehrere der Prozessorkerne 202A-202N Unterstützung für gleichzeitiges Multithreading. In einer derartigen Ausführungsform beinhaltet der Systemagentkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während der Multithread-Verarbeitung. Der Systemagentkern 210 kann außerdem eine Leistungssteuerungseinheit (PCU - Power Control Unit) beinhalten, welche Logik und Komponenten zum Regulieren des Leistungszustands der Prozessorkerne 202A-202N und des Grafikprozessors 208 beinhaltet.
  • In einigen Ausführungsformen beinhaltet der Prozessor 200 außerdem den Grafikprozessor 208 zum Ausführen von Grafikverarbeitungsoperationen. In einigen Ausführungsformen ist der Grafikprozessor 208 mit dem Satz gemeinsam genutzter Cacheeinheiten 206 und dem Systemagentkern 210, einschließlich des einen oder der mehreren integrierten Speicher-Controller 214, gekoppelt. In einigen Ausführungsformen beinhaltet der Systemagentkern 210 auch einen Anzeige-Controller 211 zum Antreiben der Grafikprozessorausgabe an eine oder mehrere gekoppelte Anzeigen. In einigen Ausführungsformen kann der Anzeige-Controller 211 auch ein separates Modul sein, das über mindestens eine Verbindung mit dem Grafikprozessor gekoppelt ist, oder er kann in den Grafikprozessor 208 integriert sein.
  • In einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 zum Koppeln der internen Komponenten des Prozessors 200 verwendet. Jedoch kann auch eine alternative Verbindungseinheit verwendet werden, wie z.B. eine Punktzu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich Techniken, die in der Technik gut bekannt sind. In einigen Ausführungsformen ist der Grafikprozessor 208 über einen E/A-Link 213 mit der Ringverbindung 212 gekoppelt.
  • Der beispielhafte E/A-Link 213 stellt mindestens eine von mehreren Varianten von E/A-Verbindungen dar, einschließlich einer On-Package-E/A-Verbindung, welche die Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungs-Speichermodul 218, wie z.B. einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als einen gemeinsam genutzten Last-Level-Cache.
  • In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, welche die gleiche Anweisungssatzarchitektur ausführen. In einer weiteren Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Anweisungssatzarchitektur (ISA-Instruction SetArchitecture), wobei einer oder mehrere der Prozessorkerne 202A-202N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne eine Teilmenge des ersten Anweisungssatzes oder einen unterschiedlichen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N heterogen in Bezug auf die Mikroarchitektur, wobei ein oder mehrere Kerne, die einen relativ höheren Energieverbrauch aufweisen, mit einem oder mehreren Leistungskernen, die einen geringeren Energieverbrauch aufweisen, gekoppelt sind. Außerdem kann der Prozessor 200 auf einem oder mehreren Chips oder als eine integrierte SoC-Schaltung, welche die veranschaulichten Komponenten zusätzlich zu anderen Komponenten aufweist, implementiert sein.
  • 3 ist ein Blockdiagramm eines Grafikprozessors 300, bei welchem es sich um eine diskrete Grafikverarbeitungseinheit handeln kann, oder welcher ein Grafikprozessor sein kann, der in mehreren Verarbeitungskernen integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherabgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die im Prozessorspeicher platziert werden. In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 eine Speicherschnittstelle 314 zum Zugreifen auf den Speicher. Die Speicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Speicher, einem oder mehreren internen Caches, einem oder mehreren gemeinsam genutzten externen Caches und/oder zum Systemspeicher sein.
  • In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 auch einen Anzeige-Controller 302 zum Antreiben von Anzeigeausgabedaten zu einem Anzeigegerät 320. Der Anzeige-Controller 302 beinhaltet Hardware für eine oder mehrere Overlay-Ebenen für die Anzeige und Zusammensetzung mehrerer Schichten von Video- oder Benutzerschnittstellenelementen. Das Anzeigegerät 320 kann ein internes oder externes Anzeigegerät sein. In einer Ausführungsform ist das Anzeigegerät 320 ein am Kopf befestigtes Anzeigegerät, wie z.B. ein Virtual-Reality (VR) -Anzeigegerät oder ein Augmented-Reality (AR) -Anzeigegerät. In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 eine Video-Codec-Maschine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einem oder mehreren Mediencodierungsformaten, einschließlich, jedoch nicht darauf beschränkt, MPEG (Moving Picture Experts Group) -Formate, wie z.B. MPEG-2, AVC (Advanced Video Coding) -Formate, wie z.B. H.264/MPEG-4 AVC, sowie der SMPTE (Society of Motion Picture & Television Engineers) 421M/VC-1 und JPEG (Joint Photographic Experts Group) -Formate, wie z.B. JPEG, und MJPEG (Motion JPEG) -Formate.
  • In einigen Ausführungsformen beinhaltet der Grafikprozessor 300 eine Blockbildtransfer (BLIT - Block Image Transfer) -Maschine 304 zum Durchführen zweidimensionaler (2D) Rasterer-Operationen, zum Beispiel einschließlich Bitgrenzen-Blocktransfers. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung von einer oder mehreren Komponenten der Grafikverarbeitungsmaschine (GPE - Graphics Processing Engine) 310 durchgeführt. In einigen Ausführungsformen ist die GPE 310 eine Rechenmaschine zum Durchführen von Grafikoperationen, einschließlich dreidimensionaler (3D) Grafikoperationen und Medienoperationen.
  • In einigen Ausführungsformen beinhaltet die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie z.B. das Rendern dreidimensionaler Bilder und Szenen unter Verwendung von Verarbeitungsfunktionen, die mit 3D-Grundkörperformen (z.B. Rechteck, Dreieck usw.) arbeiten. Die 3D-Pipeline 312 beinhaltet programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungs-Threads für ein 3D/Medien-Untersystem 315 erzeugen. Während die 3D-Pipeline 312 zum Durchführen von Medienoperationen verwendet werden kann, beinhaltet eine Ausführungsform der GPE 310 auch eine Medien-Pipeline 316, die spezifisch zum Durchführen von Medienoperationen verwendet wird, wie z.B. Video-Nachbearbeitung und Bildverbesserung.
  • In einigen Ausführungsformen beinhaltet die Medien-Pipeline 316 Feste-Funktion- oder programmierbare Logikeinheiten zum Durchführen von einer oder mehreren spezialisierten Medienoperationen, wie z.B. Videodecodierungsbeschleunigung, Videoentflechtung und Videocodierungsbeschleunigung, anstelle der oder für die Video-Codec-Maschine 306. In einigen Ausführungsformen beinhaltet die Medien-Pipeline 316 außerdem eine Thread-Erzeugungseinheit zum Erzeugen von Threads zur Ausführung auf dem 3D/Medien-Untersystem 315. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Medien-Untersystem 315 enthalten sind.
  • In einigen Ausführungsformen beinhaltet das 3D/Medien-Untersystem 315 Logik für das Ausführen von Threads, die durch die 3D-Pipeline 312 und die Medien-Pipeline 316 erzeugt werden. In einer Ausführungsform senden die Pipelines Thread-Ausführungsanfragen an das 3D/Medien-Untersystem 315, welches Thread-Versendungslogik zum Vermitteln und Versenden der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen beinhaltet. Die Ausführungsressourcen beinhalten ein Array von Grafikausführungseinheiten zum Verarbeiten der 3D- und Medien-Threads. In einigen Ausführungsformen beinhaltet das 3D/Medien-Untersystem 315 einen oder mehrere interne Caches für Thread-Anweisungen und -Daten. In einigen Ausführungsformen beinhaltet das Untersystem auch gemeinsam genutzten Speicher, einschließlich Register und adressierbaren Speicher, zum gemeinsamen Nutzen von Daten zwischen Threads und zum Speichern von Ausgabedaten.
  • Grafikverarbeitungsmaschine
  • 4 ist ein Blockdiagramm einer Grafikverarbeitungsmaschine 410 eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen. In einer Ausführungsform ist die Grafikverarbeitungsmaschine (GPE) 410 eine Version der in 3 gezeigten GPE 310. Elemente von 4, welche die gleichen Referenznummern (oder Namen) wie die Elemente einer jeden anderen Figur hierin aufweisen, können in jeglicher Art und Weise arbeiten oder funktionieren, die ähnlich der anderswo hierin beschriebenen ist, sind jedoch nicht darauf beschränkt. Zum Beispiel sind die 3D-Pipeline 312 und die Medien-Pipeline 316 von 3 veranschaulicht. Die Medien-Pipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit innerhalb der GPE 410 enthalten. Zum Beispiel ist in mindestens einer Ausführungsform ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
  • In einigen Ausführungsformen ist die GPE 410 mit einem Befehl-Streamer 403 gekoppelt oder beinhaltet diesen, welcher einen Befehlsstrom an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316 bereitstellt. In einigen Ausführungsformen ist der Befehl-Streamer 403 mit einem Speicher gekoppelt, bei welchem es sich um Systemspeicher oder einen oder mehrere aus internem Cachespeicher und gemeinsam genutztem Cachespeicher handeln kann. In einigen Ausführungsformen empfängt der Befehl-Streamer 403 Befehle aus dem Speicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medien-Pipeline 316. Die Befehle sind Anweisungen, die aus einem Ringpuffer abgerufen werden, welcher Befehle für die 3D-Pipeline 312 und die Medien-Pipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Stapelbefehlspuffer beinhalten, welche Stapel von mehreren Befehlen speichern. Die Befehle für die 3D-Pipeline 312 können auch Verweise auf Daten beinhalten, die im Speicher gespeichert sind, wie z.B., jedoch nicht darauf beschränkt, Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Speicherobjekte für die Medien-Pipeline 316. Die 3D-Pipeline 312 und die Medien-Pipeline 316 verarbeiten die Befehle und Daten durch das Durchführen von Operationen über Logik innerhalb der entsprechenden Pipeline oder durch das Versenden von einem oder mehreren Ausführungs-Threads an ein Grafikkern-Array 414. In einer Ausführungsform beinhaltet das Grafikkern-Array 414 einen oder mehrere Blöcke von Grafikkernen (z.B. den/die Grafikkern(e) 415A, den/die Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne beinhaltet. Jeder Grafikkern beinhaltet einen Satz von Grafikausführungsressourcen, die Universal- und grafikspezifische Ausführungslogik zum Durchführen von Grafik- und Berechnungsoperationen sowie Texturverarbeitungslogik mit fester Funktion und/oder Maschinenlernlogik und Beschleunigungslogik für künstliche Intelligenz beinhalten.
  • In verschiedenen Ausführungsformen beinhaltet die 3D-Pipeline 312 Feste-Funktion- und programmierbare Logik zum Verarbeiten von einem oder mehreren Shader-Programmen, wie z.B. Vertex-Shader, Geometrie-Shader, Pixel-Shader, Fragment-Shader, Rechen-Shader oder andere Shader-Programme, durch das Verarbeiten der Anweisungen und das Versenden von Ausführungs-Threads an das Grafikkern-Array 414. Das Grafikkern-Array 414 stellt einen einheitlichen Block von Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shader-Programme bereit. Mehrzweck-Ausführungslogik (z.B. Ausführungseinheiten) innerhalb des/der Grafikkerns (e) 415A-414B des Grafikkern-Arrays 414 beinhaltet Unterstützung für verschiedene 3D-API-Shader-Sprachen und kann mehrere gleichzeitige Ausführungs-Threads im Zusammenhang mit mehreren Shadern ausführen.
  • In einigen Ausführungsformen beinhaltet das Grafikkern-Array 414 auch Ausführungslogik zum Durchführen von Medienfunktionen, wie z.B. Video- und/oder Bildverarbeitung. In einer Ausführungsform beinhalten die Ausführungseinheiten außerdem Universallogik, die zum Durchführen paralleler Universalberechnungsoperationen, zusätzlich zu Grafikverarbeitungsoperationen, programmierbar ist. Die Universallogik kann Verarbeitungsoperationen parallel zu oder in Verbindung mit Universallogik innerhalb des/der Prozessorkerns(e) 107 von 1 oder der Kerne 202A-202N wie in 2 durchführen.
  • Ausgabedaten, die durch Threads erzeugt werden, die auf dem Grafikkern-Array 414 ausgeführt werden, können Daten an einen Speicher in einem einheitlichen Rückgabepuffer (URB - Unified Return Buffer) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 zum Senden von Daten zwischen unterschiedlichen Threads, die auf dem Grafikkern-Array 414 ausgeführt werden, verwendet werden. In einigen Ausführungsformen kann der URB 418 außerdem zur Synchronisation zwischen Threads auf dem Grafikkern-Array und Logik mit fester Funktion innerhalb der gemeinsam genutzten Funktionslogik 420 verwendet werden.
  • In einigen Ausführungsformen ist das Grafikkern-Array 414 derart skalierbar, dass das Array eine variable Zahl von Grafikkernen beinhaltet, welche, basierend auf der Zielleistung und dem Leistungsniveau der GPE 410, jeweils eine variable Zahl von Ausführungseinheiten aufweisen. In einer Ausführungsform sind die Ausführungsressourcen derart dynamisch skalierbar, dass die Ausführungsressourcen wie benötigt aktiviert oder deaktiviert werden können.
  • Das Grafikkern-Array 414 ist mit der gemeinsam genutzten Funktionslogik 420 gekoppelt, die mehrere Ressourcen beinhaltet, welche zwischen den Grafikkernen in dem Grafikkern-Array gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420 sind Hardware-Logikeinheiten, die spezialisierte ergänzende Funktionalität an das Grafikkern-Array 414 bereitstellen. In verschiedenen Ausführungsformen beinhaltet die gemeinsam genutzte Funktionslogik 420, jedoch nicht darauf beschränkt, Logik für den Sampler 421, Mathematik 422 und Kommunikation zwischen Threads (ITC - Inter-Thread Communication) 423. Außerdem implementieren einige Ausführungsformen einen oder mehrere Cache(s) 425 innerhalb der gemeinsam genutzten Funktionslogik 420.
  • Eine gemeinsam genutzte Funktion wird implementiert, wenn der Bedarf an einer gegebenen spezialisierten Funktion unzureichend für den Einschluss in das Grafikkern-Array 414 ist. Stattdessen wird eine einzelne Instanziierung dieser spezialisierten Funktion als eine eigenständige Einheit in der gemeinsam genutzten Funktionslogik 420 implementiert und durch die Ausführungsressourcen innerhalb des Grafikkern-Arrays 414 gemeinsam genutzt. Der präzise Satz von Funktionen, die durch das Grafikkern-Array 414 gemeinsam genutzt werden und innerhalb des Grafikkern-Arrays 414 enthalten sind, variiert über die Ausführungsformen hinweg. In einigen Ausführungsformen können spezifische gemeinsam genutzte Funktionen innerhalb der gemeinsam genutzten Funktionslogik 420, die durch das Grafikkern-Array 414 extensiv genutzt werden, innerhalb der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 einen Teil der oder die gesamte Logik innerhalb der gemeinsam genutzten Funktionslogik 420 beinhalten. In einer Ausführungsform können alle Logikelemente innerhalb der gemeinsam genutzten Funktionslogik 420 innerhalb der gemeinsam genutzten Funktionslogik 416 des Grafikkern-Arrays 414 dupliziert sein. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 innerhalb des Grafikkern-Arrays 414 ausgeschlossen.
  • 5 ist ein Blockdiagramm von Hardware-Logik eines Grafikprozessorkerns 500 gemäß einiger hierin beschriebener Ausführungsformen. Elemente von 5, welche die gleichen Referenznummern (oder Namen) wie die Elemente einer jeden anderen Figur hierin aufweisen, können in jeglicher Art und Weise arbeiten oder funktionieren, die ähnlich der anderswo hierin beschriebenen ist, sind jedoch nicht darauf beschränkt. Der veranschaulichte Grafikprozessorkern 500 ist in einigen Ausführungsformen innerhalb des Grafikkern-Arrays 414 von 4 enthalten. Der Grafikprozessorkern 500, gelegentlich als eine Kernscheibe bezeichnet, kann ein oder mehrere Grafikkerne innerhalb eines modularen Grafikprozessors sein. Der Grafikprozessorkern 500 ist ein Beispiel einer Grafikkernscheibe, und ein Grafikprozessor wie hierin beschrieben kann basierend auf Zielleistung und Leistungsvermögen mehrere Grafikkernscheiben beinhalten. Jeder Grafikkern 500 kann einen Feste-Funktion-Block 530 beinhalten, der mit mehreren Teilkernen 501A- 501F, auch als Teilscheiben bezeichnet, gekoppelt ist, die modulare Blöcke von Universal- und Feste-Funktion-Logik beinhalten.
  • In einigen Ausführungsformen beinhaltet der Feste-Funktion-Block 530 eine Geometrie-/Feste-Funktion-Pipeline 536, die durch alle Teilkerne in dem Grafikprozessor 500 gemeinsam genutzt werden kann, zum Beispiel bei Grafikprozessorimplementierungen mit niedrigerer Leistung und/oder niedrigerer Energie. In verschiedenen Ausführungsformen beinhaltet die Geometrie-/Feste-Funktion-Pipeline 536 eine 3D-Feste-Funktion-Pipeline (z.B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Front-End-Einheit, einen Thread-Erzeuger und Thread-Dispatcher und einen Manager der einheitlichen Rückgabepuffer, welcher die einheitlichen Rückgabepuffer, wie z.B. den einheitlichen Rückgabepuffer 418 von 4, managt.
  • In einer Ausführungsform beinhaltet der Feste-Funktion-Block 530 auch eine Grafik-SoC-Schnittstelle 537, einen Grafik-Mikrocontroller 538 und eine Medien-Pipeline 539. Die Grafik-SoC-Schnittstelle 537 stellt eine Schnittstelle zwischen dem Grafikkern 500 und anderen Prozessorkernen innerhalb einer integrierten Ein-Chip-System-Schaltung zur Verfügung. Der Grafik-Mikrocontroller 538 ist ein programmierbarer Unterprozessor, der zum Managen verschiedener Funktionen des Grafikprozessors 500, einschließlich Thread-Versendung, -Zeitplanung und - Bevorrechtigung, konfigurierbar ist. Die Medien-Pipeline 539 (z.B. die Medien-Pipeline 316 von 3 und 4) beinhaltet Logik zum Ermöglichen der Decodierung, Codierung, Vorverarbeitung und/oder Nachbearbeitung von Multimedia-Daten, einschließlich Bild- und Videodaten. Die Medien-Pipeline 539 implementiert Medienoperationen über Anfragen zum Berechnen oder Abtastlogik innerhalb der Teilkerne 501-501F.
  • In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 dem Grafikkern 500 das Kommunizieren mit Universal-Anwendungsprozessorkernen (z.B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Speicherhierarchieelementen, wie z.B. einem gemeinsam genutzten Last-Level-Cachespeicher, dem System-RAM und/oder eingebettetem On-Chip- oder On-Package-DRAM. Die SoC-Schnittstelle 537 kann auch die Kommunikation mit Geräten mit fester Funktion innerhalb des SoC, wie z.B. Kamerabildgebungs-Pipelines, ermöglichen und ermöglicht die Verwendung von und/oder implementiert globale Speicheratomik, die zwischen dem Grafikkern 500 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 537 kann auch Leistungsmanagementsteuerungen für den Grafikkern 500 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 500 und anderen Taktdomänen innerhalb des SoC bereitstellen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 537 den Empfang von Befehlspuffern von einem Befehl-Streamer und einem globalen Thread-Dispatcher, die zum Bereitstellen von Befehlen und Anweisungen an jeden von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors konfiguriert sind. Die Befehle und Anweisungen können an die Medien-Pipeline 539 versendet werden, wenn Medienoperationen durchgeführt werden sollen, oder an eine Geometrie- und Feste-Funktion-Pipeline (z.B. die Geometrie- und Feste-Funktion-Pipeline 536, die Geometrie- und Feste-Funktion-Pipeline 514), wenn Grafikverarbeitungsoperationen durchgeführt werden sollen.
  • Der Grafik-Mikrocontroller 538 kann zum Durchführen verschiedener Zeitplanungs- und Managementaufgaben für den Grafikkern 500 konfiguriert sein. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 Grafik- und/oder Rechenarbeitslast-Zeitplanung auf den verschiedenen parallelen Grafikmaschinen innerhalb der Ausführungseinheit (EU - Execution Unit) -Arrays 502A-502F, 504A-504F innerhalb der Teilkerne 501A-501F durchführen. Bei diesem Zeitplanungsmodell kann Host-Software, die auf einem CPU-Kern eines SoC, das den Grafikkern 500 beinhaltet, ausgeführt wird, Arbeitslasten an einen von mehreren Grafikprozessoren übermitteln, wodurch eine Zeitplanungsoperation auf der entsprechenden Grafikmaschine aufgerufen wird. Die Zeitplanungsoperationen beinhalten das Bestimmen, welche Arbeitslast als nächstes laufen soll, das Übermitteln einer Arbeitslast an einen Befehl-Streamer, das Vorwegnehmen vorhandener Arbeitslasten, die auf einer Maschine laufen, das Überwachen des Voranschreitens einer Arbeitslast und das Benachrichtigen der Host-Software, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafik-Mikrocontroller 538 auch Niedrigenergie- oder Ruhezustände für den Grafikkern 500 ermöglichen, wodurch der Grafikkern 500 die Fähigkeit erhält, Register innerhalb des Grafikkerns 500 über Niedrigenergie-Zustandsübergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreiber-Software auf dem System zu sichern und wiederherzustellen.
  • Der Grafikkern 500 kann mehr oder weniger als die veranschaulichten Teilkerne 501A-501F und bis zu N modulare Teilkerne aufweisen. Für jeden Satz von N Teilkernen kann der Grafikkern 500 auch gemeinsam genutzte Funktionslogik 510, gemeinsam genutzten und/oder Cachespeicher 512, eine Geometrie-/Feste-Funktion-Pipeline 514 sowie zusätzliche Feste-Funktion-Logik 516 zum Beschleunigen verschiedener Grafik- und Rechenverarbeitungsoperationen beinhalten. Die gemeinsam genutzte Funktionslogik 510 kann Logikeinheiten im Zusammenhang mit der gemeinsam genutzten Funktionslogik 420 von 4 (z.B. Logik für Sampler, Mathematik und Kommunikation zwischen Threads) beinhalten, die durch alle N Teilkerne innerhalb des Grafikkerns 500 gemeinsam genutzt werden können. Der gemeinsam genutzte und/oder Cachespeicher 512 kann ein Last-Level-Cache für den Satz von N Teilkernen 501A-501F innerhalb des Grafikkerns 500 sein und kann auch als gemeinsam genutzter Speicher dienen, auf den mehrere Teilkerne zugreifen können. Die Geometrie-/Feste-Funktion-Pipeline 514 kann anstelle der Geometrie-/Feste-Funktion-Pipeline 536 innerhalb des Feste-Funktion-Blocks 530 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten beinhalten.
  • In einer Ausführungsform beinhaltet der Grafikkern 500 zusätzliche Feste-Funktion-Logik 516, die verschiedene Feste-Funktion-Beschleunigungslogik zur Verwendung durch den Grafikkern 500 beinhalten kann. In einer Ausführungsform beinhaltet die zusätzliche Feste-Funktion-Logik 516 eine zusätzliche Geometrie-Pipeline zur Verwendung bei der Schattierung nur der Position. Bei der Schattierung nur der Position existieren zwei Geometrie-Pipelines, die vollständige Geometrie-Pipeline innerhalb der Geometrie-/Feste-Funktion-Pipeline 516, 536 und eine aussortierte Pipeline, bei welcher es sich um eine zusätzliche Geometrie-Pipeline handelt, die innerhalb der zusätzlichen Feste-Funktion-Logik 516 enthalten sein kann. In einer Ausführungsform ist die aussortierte Pipeline eine abgeschlankte Version der vollständigen Geometrie-Pipeline. Die vollständige Pipeline und die aussortierte Pipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Die Schattierung nur der Position kann lange Ausleseläufe verworfener Dreiecke verbergen, wodurch in einigen Fällen ein früherer Abschluss der Schattierung ermöglicht wird. Zum Beispiel kann in einer Ausführungsform die Logik der aussortierten Pipeline innerhalb der zusätzlichen Feste-Funktion-Logik 516 Positions-Shader parallel zur Hauptanwendung ausführen und erzeugt so kritische Ergebnisse im Allgemeinen schneller als die vollständige Pipeline, da die aussortierte Pipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterung und ein Rendern der Pixel in den Frame-Puffer durchzuführen. Die aussortierte Pipeline kann die erzeugten kritischen Ergebnisse zum Berechnen von Sichtbarkeitsinformationen für sämtliche Dreiecke verwenden, ohne berücksichtigen zu müssen, ob diese Dreiecke aussortiert wurden. Die vollständige Pipeline (welche in diesem Fall auch als eine Wiedergabe-Pipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die aussortierten Dreiecke zu überspringen, um nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase übergeben werden.
  • In einer Ausführungsform kann die zusätzliche Feste-Funktion-Logik 516 auch Maschinenlernen-Beschleunigungslogik, wie z.B. die Feste-Funktion-Matrixmultiplikationslogik, beinhalten, für Implementierungen, die Optimierungen für das Maschinenlernen oder Inferencing beinhalten.
  • Innerhalb jedes Grafikteilkerns 501A-501F ist ein Satz von Ausführungsressourcen enthalten, die zum Durchführen von Grafik-, Medien- und Rechenoperationen als Reaktion auf Anfragen von der Grafik-Pipeline, der Medien-Pipeline oder Shader-Programmen verwendet werden können. Die Grafikteilkerne 501A-501F beinhalten mehrere EU-Arrays 502A-502F, 504A-504F, Logik für die Thread-Versendung und Kommunikation zwischen Threads (TD/IC - Thread Dispatch and Inter-Thread Communication) 503A-503F, einen 3D (z.B. Textur) -Sampler 505A-505F, einen Medien-Sampler 506A-506F, einen Shader-Prozessor 507A-507F und gemeinsam genutzten lokalen Speicher (SLM - Shared Local Memory) 508A-508F. Die EU-Arrays 502A-502F, 504A-504F beinhalten jeweils mehrere Ausführungseinheiten, bei welchen es sich um Universal-Grafikverarbeitungseinheiten handelt, die zum Durchführen von Gleitkomma- und Ganzzahl-/Festpunkt-Logikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation, einschließlich Grafik-, Medien- oder Rechen-Shader-Programmen, in der Lage sind. Die TD/IC-Logik 503A-503F führt lokale Thread-Versendungs- und Thread-Steuerungsoperationen für die Ausführungseinheiten innerhalb eines Teilkerns durch und ermöglicht die Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Teilkerns ausgeführt werden. Der 3D-Sampler 505A-505F kann Textur- oder andere 3D-Grafik-bezogene Daten in den Speicher lesen. Der 3D-Sampler kann Texturdaten basierend auf einem konfigurierten Abtastzustand und dem Texturformat im Zusammenhang mit einer gegebenen Textur unterschiedlich lesen. Der Medien-Sampler 506A-506F kann ähnliche Leseoperationen basierend auf der Art und dem Format im Zusammenhang mit Mediendaten durchführen. In einer Ausführungsform kann jeder Grafikteilkern 501A-501F abwechselnd einen einheitlichen 3D- und Medien-Sampler beinhalten. Threads, die auf den Ausführungseinheiten innerhalb jedes der Teilkerne 501A-501F ausgeführt werden, können den gemeinsam genutzten lokalen Speicher 508A-508F innerhalb jedes Teilkerns nutzen, um zu ermöglichen, dass Threads, die innerhalb einer Thread-Gruppe ausgeführt werden, unter Verwendung eines gemeinsamen Pools von On-Chip-Speicher ausgeführt werden.
  • Ausführungseinheiten
  • 6A-6B veranschaulichen die Thread-Ausführungslogik 600 einschließlich eines Arrays von Verarbeitungselementen, die in einem Grafikprozessorkern eingesetzt werden, gemäß hierin beschriebener Ausführungsformen. Elemente von 6A-6B, welche die gleichen Referenznummern (oder Namen) wie die Elemente einer jeden anderen Figur hierin aufweisen, können in jeglicher Art und Weise arbeiten oder funktionieren, die ähnlich der anderswo hierin beschriebenen ist, sind jedoch nicht darauf beschränkt. 6A veranschaulicht einen Überblick über die Thread-Ausführungslogik 600, welche eine Variante der Hardware-Logik, die für jeden Teilkern 501A-501F von 5 veranschaulicht ist, beinhalten kann. 6B veranschaulicht beispielhafte interne Details einer Ausführungseinheit.
  • Wie in 6A veranschaulicht, beinhaltet die Thread-Ausführungslogik 600 in einigen Ausführungsformen einen Shader-Prozessor 602, einen Thread-Dispatcher 604, einen Anweisungscache 606, ein skalierbares Ausführungseinheit-Array, das mehrere Ausführungseinheiten 608A-608N beinhaltet, einen Sampler 610, einen Datencache 612 und einen Datenanschluss 614. In einer Ausführungsform kann das skalierbare Ausführungseinheit-Array dynamisch skaliert werden, indem eine oder mehrere Ausführungseinheiten (z.B. jegliche der Ausführungseinheiten 608A, 608B, 608C, 608D bis 608N-1 und 608N) basierend auf den Rechenanforderungen einer Arbeitslast aktiviert oder deaktiviert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Verbindungsstruktur, die mit jeder der Komponenten verknüpft ist, miteinander verbunden. In einigen Ausführungsformen beinhaltet die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen zu einem Speicher, wie z.B. dem Systemspeicher oder Cachespeicher, über eines oder mehrere aus dem Anweisungscache 606, dem Datenanschluss 614, dem Sampler 610 und den Ausführungseinheiten 608A-608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z.B. 608A) eine eigenständige programmierbare Universalrecheneinheit, die zum Ausführen mehrerer gleichzeitiger Hardware-Threads in der Lage ist, während parallel mehrere Datenelemente für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist das Array von Ausführungseinheiten 608A-608N derart skalierbar, dass es jegliche Zahl einzelner Ausführungseinheiten beinhaltet.
  • In einigen Ausführungsformen werden die Ausführungseinheiten 608A-608N primär zum Ausführen von Shader-Programmen verwendet. Ein Shader-Prozessor 602 kann die verschiedenen Shader-Programme verarbeiten und Ausführungs-Threads im Zusammenhang mit den Shader-Programmen über einen Thread-Dispatcher 604 versenden. In einer Ausführungsform beinhaltet der Thread-Dispatcher Logik zum Vermitteln von Thread-Initiierungsanfragen von der Grafik- und der Medien-Pipeline und zum Instanziieren der angefragten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 608A-608N. Zum Beispiel kann eine Geometrie-Pipeline Vertex-, Tessellations- oder Geometrie-Shader zur Verarbeitung an die Thread-Ausführungslogik versenden. In einigen Ausführungsformen kann der Thread-Dispatcher 604 auch Laufzeit-Thread-Erzeugungsanfragen von den ausführenden Shader-Programmen verarbeiten.
  • In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafik-Shader-Anweisungen beinhaltet, sodass Shader-Programme aus Grafikbibliotheken (z.B. Direct 3D und OpenGL) mit minimaler Translation ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z.B. Vertex-Programme, Geometrieprogramme, Vertex-Shader), Pixelverarbeitung (z.B. Pixel-Shader, Fragment-Shader) und Universalverarbeitung (z.B. Rechen- und Medien-Shader). Jede der Ausführungseinheiten 608A-608N ist zur Mehrfachausgabe-SIMD (Single Instruction Multiple Data) -Ausführung in der Lage und der Multithread-Betrieb ermöglicht eine effiziente Ausführungsumgebung angesichts von Speicherzugriffen mit höherer Latenz. Jeder Hardware-Thread innerhalb jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen assoziierten unabhängigen Thread-Zustand auf. Die Ausführung ist eine Mehrfachausgabe pro Takt an Pipelines, die zu Ganzzahloperationen, Gleitkommaoperationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen in der Lage sind. Während auf Daten aus einem Speicher oder eine der gemeinsam genutzten Funktionen gewartet wird, veranlasst eine Abhängigkeitslogik innerhalb der Ausführungseinheiten 608A-608N, dass ein wartender Thread schläft, bis die angeforderten Daten zurückgesendet wurden. Während der wartende Thread schläft können Hardware-Ressourcen für die Verarbeitung anderer Threads eingesetzt werden. Zum Beispiel kann eine Ausführungseinheit während einer Verzögerung im Zusammenhang mit einer Vertex-Shader-Operation Operationen für einen Pixel-Shader, Fragment-Shader oder eine andere Art von Shader-Programm, einschließlich eines unterschiedlichen Vertex-Shaders, durchführen.
  • Jede Ausführungseinheit in den Ausführungseinheiten 608A-608N arbeitet mit Arrays von Datenelementen. Die Zahl von Datenelementen ist die „Ausführungsgröße“ oder die Zahl von Kanälen für die Anweisung. Ein Ausführungskanal ist eine logische Ausführungseinheit für den Datenelementzugriff, Maskierung und Flussteuerung innerhalb von Anweisungen. Die Zahl von Kanälen kann unabhängig von der Zahl physischer arithmetischer Logikeinheiten (ALUs - Arithmetic Logic Units) oder Gleitkommaeinheiten (FPUs - Floating Point Units) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A-608N Ganzzahl- und Gleitkomma-Datentypen.
  • Der Anweisungssatz der Ausführungseinheit beinhaltet SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Wenn zum Beispiel mit einem 256 Bit breiten Vektor gearbeitet wird, werden die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet mit dem Vektor als vier separate gepackte 64-Bit-Datenelemente (Datenelemente mit Größe QW (Quad-Word)), acht separate gepackte 32-Bit-Datenelemente (Datenelemente mit Größe DW (Double Word)), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente mit Größe W (Word)) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente mit Größe B (Byte)). Jedoch sind auch unterschiedliche Vektorbreiten und Registergrößen möglich.
  • In einer Ausführungsform können eine oder mehrere Ausführungseinheiten zu einer verschmolzenen Ausführungseinheit 609A-609N kombiniert werden, welche Thread-Steuerungslogik (607A-607N) aufweist, die den verschmolzenen EUs gemeinsam ist. Mehrere EUs können zu einer EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann zum Ausführen eines separaten SIMD-Hardware-Threads konfiguriert sein. Die Zahl von EUs in einer verschmolzenen EU-Gruppe kann gemäß Ausführungsformen variieren. Außerdem können pro EU verschiedene SIMD-Breiten durchgeführt werden, einschließlich, jedoch nicht darauf beschränkt, SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 609A-609N beinhaltet mindestens zwei Ausführungseinheiten. Zum Beispiel beinhaltet die verschmolzene Ausführungseinheit 609A eine erste EU 608A, eine zweite EU 608B und die Thread-Steuerungslogik 607A, die der ersten EU 608A und der zweiten EU 608B gemeinsam ist. Die Thread-Steuerungslogik 607A steuert Threads, die auf der verschmolzenen Grafikausführungseinheit 609A ausgeführt werden, wodurch jeder EU innerhalb der verschmolzenen Ausführungseinheiten 609A-609N die Ausführung unter Verwendung eines gemeinsamen Anweisungszeigerregisters gestattet wird.
  • Ein oder mehrere interne Anweisungscaches (z.B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Thread-Anweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z.B. 612) enthalten, um Thread-Daten während der Thread-Ausführung zwischenzuspeichern. In einigen Ausführungsformen ist ein Sampler 610 enthalten, um Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen beinhaltet der Sampler 610 eine spezialisierte Textur- oder Medienabtastfunktionalität zum Verarbeiten von Textur- oder Mediendaten während des Abtastprozesses vor der Bereitstellung der abgetasteten Daten an eine Ausführungseinheit.
  • Während der Ausführung senden die Grafik- und die Medien-Pipeline über Thread-Erzeugungs- und -Versendungslogik Thread-Initiierungsanfragen an die Thread-Ausführungslogik 600. Nachdem eine Gruppe geometrischer Objekte verarbeitet und zu Pixeldaten gerastert wurde, wird die Pixelprozessorlogik (z.B. die Pixel-Shader-Logik, die Fragment-Shader-Logik usw.) innerhalb des Shader-Prozessors 602 aufgerufen, um weiter Ausgabeinformationen zu berechnen und zu veranlassen, dass Ergebnisse auf Ausgabeoberflächen geschrieben werden (z.B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In einigen Ausführungsformen berechnet ein Pixel-Shader oder ein Fragment-Shader die Werte der verschiedenen Vertex-Attribute, die über die gerasterten Objekte hinweg interpoliert werden sollen. In einigen Ausführungsformen führt die Pixelprozessorlogik innerhalb des Shader-Prozessors 602 dann ein von einer Anwendungsprogrammierungsschnittstelle (API - Application Programming Interface) bereitgestelltes Pixel- oder Fragment-Shader-Programm aus. Zum Ausführen des Shader-Programms sendet der Shader-Prozessor 602 über den Thread-Dispatcher 604 Threads an eine Ausführungseinheit (z.B. 608A). In einigen Ausführungsformen verwendet der Shader-Prozessor 602 Texturabtastlogik in dem Sampler 610 zum Zugreifen auf Texturdaten in Texturabbildungen, die im Speicher gespeichert sind. Arithmetische Operationen an den Texturdaten und den eingegebenen Geometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel aus der weiteren Verarbeitung.
  • In einigen Ausführungsformen stellt der Datenanschluss 614 einen Speicherzugriffsmechanismus für die Thread-Ausführungslogik 600 zum Ausgeben verarbeiteter Daten an den Speicher zur weiteren Verarbeitung auf einer GrafikprozessorAusgabe-Pipeline bereit. In einigen Ausführungsformen beinhaltet der Datenanschluss 614 einen oder mehrere Cachespeicher (z.B. den Datencache 612) oder ist daran gekoppelt, um Daten für den Speicherzugriff über den Datenanschluss zwischenzuspeichern.
  • Wie in 6B veranschaulicht, kann eine Grafikausführungseinheit 608 eine Anweisungsabrufeinheit 637, ein allgemeines Registerdatei (GRF - General Register File) -Array 624, ein Architekturregisterdatei (ARF - Architectural Register File) -Array 626, einen Thread-Arbiter 622, eine Sendeeinheit 630, eine Verzweigungseinheit 632, einen Satz von SIMD-Gleitkommaeinheiten (FPUs - Floating Point Units) 634 und in einer Ausführungsform einen Satz dedizierter Ganzzahl-SIMD-ALUs 635 beinhalten. Die GRF 624 und die ARF 626 beinhalten den Satz von allgemeinen Registerdateien und Architekturregisterdateien im Zusammenhang mit jedem gleichzeitigen Hardware-Thread, der in der Grafikausführungseinheit 608 aktiv sein kann. In einer Ausführungsform wird der Architekturzustand pro Thread in der ARF 626 gepflegt, während Daten, die während der Thread-Ausführung verwendet werden, in der GRF 624 gespeichert werden. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in Thread-spezifischen Registern in der ARF 626 enthalten sein.
  • In einer Ausführungsform weist die Grafikausführungseinheit 608 eine Architektur auf, bei der es sich um eine Kombination aus SMT (Simultaneous Multi-Threading) und feinstrukturiertem IMT (Interleaved Multi-Threading) handelt. Die Architektur weist eine modulare Konfiguration auf, die in der Designphase basierend auf einer Zielzahl gleichzeitiger Threads und einer Zahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei die Ressourcen der Ausführungseinheit über Logik hinweg aufgeteilt werden, die zum Ausführen mehrerer gleichzeitiger Threads verwendet wird.
  • In einer Ausführungsform kann die Grafikausführungseinheit 608 mehrere Anweisungen gemeinsam ausgeben, wobei es sich jeweils um unterschiedliche Anweisungen handeln kann. Der Thread-Arbiter 622 der Grafikausführungseinheit 608 kann die Anweisungen zur Verarbeitung an eine aus der Sendeeinheit 630, der Verzweigungseinheit 642 oder der/den SIMD-FPU(s) 634 versenden. Jeder Ausführungs-Thread kann auf 128 Universalregister innerhalb der GRF 624 zugreifen, wobei jedes Register 32 Bytes speichern kann, die als ein SIMD-8-Elementvektor von 32-Bit-Datenelementen zugänglich sind. In einer Ausführungsform hat jeder Ausführungseinheit-Thread Zugriff auf 4 KBytes innerhalb der GRF 624, obwohl Ausführungsformen nicht darauf beschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform können bis zu sieben Threads gleichzeitig ausgeführt werden, obwohl die Zahl der Threads pro Ausführungseinheit auch gemäß Ausführungsformen variieren kann. In einer Ausführungsform, in welcher sieben Threads auf 4 KBytes zugreifen können, kann die GRF 624 insgesamt 28 KBytes speichern. Flexible Adressierungsmodi können es gestatten, dass Register zusammen adressiert werden, um effektiv breitere Register aufzubauen oder um mit Schritten versehene rechteckige Blockdatenstrukturen darzustellen.
  • In einer Ausführungsform werden Speicheroperationen, Sampler-Operationen und andere Systemkommunikationen mit längerer Latenz über „Senden“-Anweisungen versendet, die durch die Nachrichten weiterleitende Sendeeinheit 630 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 632 versendet, um SIMD-Divergenz und letztendlich Konvergenz zu ermöglichen.
  • In einer Ausführungsform beinhaltet die Grafikausführungseinheit 608 eine oder mehrere SIMD-Gleitkommaeinheit(en) (FPU(s)) 634 zum Durchführen von Gleitkommaoperationen. In einer Ausführungsform unterstützen die FPU(s) 634 auch Ganzzahlberechnung. In einer Ausführungsform können die FPU(s) 634 mittels SIMD bis zu einer Zahl M von 32-Bit-Gleitkomma- (oder Ganzzahl-) Operationen ausführen oder mittels SIMD bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen ausführen. In einer Ausführungsform stellt mindestens eine der FPU(s) eine erweiterte Mathematikfähigkeit bereit, um transzendente Mathematikfunktionen mit hohem Durchsatz und 64-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen kann auch ein Satz von 8-Bit-Ganzzahl-SIMD-ALUs 635 vorliegen und kann spezifisch für die Durchführung von Operationen im Zusammenhang mit Maschinenlernen-Berechnungen optimiert sein.
  • In einer Ausführungsform können Arrays von mehreren Instanzen der Grafikausführungseinheit 608 in einer Grafikteilkern-Gruppierung (z.B. einer Teilscheibe) instanziiert sein. Für die Skalierbarkeit können Produktarchitekten die exakte Zahl von Ausführungseinheiten pro Teilkern-Gruppierung auswählen. In einer Ausführungsform kann die Ausführungseinheit 608 Anweisungen über mehrere Ausführungskanäle hinweg ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 608 ausgeführt wird, auf einem unterschiedlichen Kanal ausgeführt.
  • 7 ist ein Blockdiagramm, welches die Grafikprozessor-Anweisungsformate 700 gemäß einiger Ausführungsformen veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die durchgezogenen Kästchen veranschaulichen die Komponenten, die im Allgemeinen in einer Anweisung einer Ausführungseinheit enthalten sind, während die gestrichelten Linien Komponenten beinhalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen handelt es sich bei dem beschriebenen und veranschaulichten Anweisungsformat 700 um Makroanweisungen, wobei es sich um Anweisungen handelt, die an die Ausführungseinheit bereitgestellt werden, im Gegensatz zu Mikrooperationen, die aus einer Anweisungsdecodierung resultieren, nachdem die Anweisung verarbeitet wurde.
  • In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Ein komprimiertes 64-Bit-Anweisungsformat 730 steht basierend auf der ausgewählten Anweisung, Anweisungsoptionen und der Zahl von Operanden für einige Anweisungen zur Verfügung. Das native 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 730 begrenzt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren je nach Ausführungsform. In einigen Ausführungsformen ist die Anweisung mit Hilfe eines Satzes von Indexwerten in einem Indexfeld 713 teilweise komprimiert. Die Hardware der Ausführungseinheit verweist auf einen Satz von Komprimierungstabellen basierend auf den Indexwerten und verwendet die Ausgaben der Komprimierungstabellen zum Rekonstruieren einer nativen Anweisung im 128-Bit-Anweisungsformat 710.
  • Für jedes Format definiert der Anweisungs-Operationscode 712 die Operation, welche die Ausführungseinheit durchführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente von jedem Operanden hinweg aus. Zum Beispiel führt die Ausführungseinheit als Reaktion auf eine Hinzufügen-Anweisung eine gleichzeitige Hinzufügen-Operation über jeden Farbkanal, der ein Texturelement oder ein Bildelement darstellt, hinweg durch. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg durch. In einigen Ausführungsformen ermöglicht das Anweisungssteuerungsfeld 714 die Kontrolle über gewisse Ausführungsoptionen, wie z.B. Kanalauswahl (z.B. Prädikation) und Datenkanalreihenfolge (z.B. Umstellung). Bei Anweisungen im 128-Bit-Anweisungsformat 710 begrenzt ein Ausführungsgrößenfeld 716 die Zahl von Datenkanälen, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 nicht zur Verwendung beim komprimierten 64-Bit-Anweisungsformat 730 zur Verfügung.
  • Einige Anweisungen der Ausführungseinheit weisen bis zu drei Operanden auf, einschließlich zweier Quelloperanden, Src0 720, Src1 722, und eines Ziels 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Doppelziel-Anweisungen, wobei eines der Ziele impliziert ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z.B. Src2 724), wobei der Anweisungs-Operationscode 712 die Zahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein unmittelbarer (z.B. festcodierter) Wert sein, der mit der Anweisung weitergegeben wird.
  • In einigen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodus-Feld 726, welches zum Beispiel spezifiziert, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse von einem oder mehreren Operanden direkt durch Bits in der Anweisung bereitgestellt.
  • In einigen Ausführungsformen beinhaltet das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodus-Feld 726, welches einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung spezifiziert. In einer Ausführungsform wird der Zugriffsmodus verwendet, um eine Datenzugriffsausrichtung für die Anweisung zu definieren. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines ausgerichteten 16-Byte-Zugriffsmodus und eines ausgerichteten 1-Byte-Zugriffsmodus, wobei die Byte-Ausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Zum Beispiel kann die Anweisung, wenn sie sich in einem ersten Modus befindet, eine Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und, wenn sie sich in einem zweiten Modus befindet, kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
  • In einer Ausführungsform bestimmt der Adressmodus-Abschnitt des Zugriffs-/Adressmodus-Feldes 726, ob die Anweisung direkte oder indirekte Adressierung verwenden soll. Wenn ein direkter Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung direkt die Registeradresse von einem oder mehreren Operanden bereit. Wenn ein indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse von einem oder mehreren Operanden basierend auf einem Adressregisterwert und einem unmittelbaren Adressfeld in der Anweisung berechnet werden.
  • In einigen Ausführungsformen sind Anweisungen basierend auf Bit-Feldern des Operationscodes 712 gruppiert, um die Operationscode-Decodierung 740 zu vereinfachen. Bei einem 8-Bit-Operationscode gestatten die Bits 4, 5 und 6 der Ausführungseinheit das Bestimmen der Art des Operationscodes. Die gezeigte präzise Operationscode-Gruppierung ist lediglich ein Beispiel. In einigen Ausführungsformen beinhaltet eine Bewegungs- und Logik-Operationscode-Gruppe 742 Datenbewegungs- und Logikanweisungen (z.B. Bewegen (mov - move)), Vergleichen (cmp - compare)). In einigen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 742 die ersten fünf signifikantesten Bits (MSB - Most Significant Bit) gemeinsam, wobei Bewegungs-(mov) Anweisungen die Form 0000xxxxb aufweisen und Logikanweisungen die Form 0001xxxxb aufweisen. Eine Flusssteuerungs-Anweisungsgruppe 744 (z.B. Rufen (call), Springen (jmp -jump)) beinhaltet Anweisungen in der Form 0010xxxxb (z.B. 0x20). Eine Gruppe für sonstige Anweisungen 746 beinhaltet eine Mischung aus Anweisungen, einschließlich Synchronisationsanweisungen (z.B. Warten (wait), Senden (send)) in der Form 0011xxxxb (z.B. 0x30). Eine Gruppe für parallele Mathematikanweisungen 748 beinhaltet komponentenweise arithmetische Anweisungen (z.B. Addieren (add), Multiplizieren (mul - multiply)) in der Form 0100xxxxb (z.B. 0x40). Die parallele Mathematik-Gruppe 748 führt die arithmetischen Operationen über Datenkanäle hinweg parallel durch. Die Vektormathematik-Gruppe 750 beinhaltet arithmetische Anweisungen (z.B. dp4) in der Form 0101xxxxb (z.B. 0x50). Die Vektormathematik-Gruppe führt Arithmetik durch, wie z.B. Skalarprodukt-Berechnungen an Vektoroperanden.
  • Grafik-Pipeline
  • 8 ist ein Blockdiagramm einer weiteren Ausführungsform eines Grafikprozessors 800. Elemente von 8, welche die gleichen Referenznummern (oder Namen) wie die Elemente einer jeden anderen Figur hierin aufweisen, können in jeglicher Art und Weise arbeiten oder funktionieren, die ähnlich der anderswo hierin beschriebenen ist, sind jedoch nicht darauf beschränkt.
  • In einigen Ausführungsformen beinhaltet der Grafikprozessor 800 eine Geometrie-Pipeline 820, eine Medien-Pipeline 830, eine Anzeigemaschine 840, Thread-Ausführungslogik 850 und eine Renderausgabe-Pipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkern-Verarbeitungssystems, das einen oder mehrere Universalverarbeitungskerne beinhaltet. Der Grafikprozessor wird durch Registerschreibvorgänge auf ein oder mehrere Steuerregister (nicht gezeigt) oder über Befehle, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten, wie z.B. andere Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden durch einen Befehl-Streamer 803 interpretiert, welcher Anweisungen an einzelne Komponenten der Geometrie-Pipeline 820 oder der Medien-Pipeline 830 bereitstellt.
  • In einigen Ausführungsformen steuert der Befehl-Streamer 803 die Operation eines Vertex-Fetchers 805, der Vertex-Daten aus dem Speicher liest und Vertex-Verarbeitungsbefehle ausführt, die durch den Befehl-Streamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertex-Fetcher 805 Vertex-Daten an einen Vertex-Shader 807 bereit, welcher Koordinatenraum-Transformations- und - Beleuchtungsoperationen an jedem Vertex durchführt. In einigen Ausführungsformen führen der Vertex-Fetcher 805 und der Vertex-Shader 807 Vertex-Verarbeitungsanweisungen aus, indem sie über einen Thread-Dispatcher 831 Ausführungs-Threads an die Ausführungseinheiten 852A-852B versenden.
  • In einigen Ausführungsformen handelt es sich bei den Ausführungseinheiten 852A-852B um ein Array von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen angeschlossenen LI-Cache 851 auf, der spezifisch für jedes Array ist oder durch die Arrays gemeinsam genutzt wird. Der Cache kann als ein Datencache, ein Anweisungscache oder ein einzelner Cache konfiguriert sein, der partitioniert ist, sodass er Daten und Anweisungen in unterschiedlichen Partitionen enthält.
  • In einigen Ausführungsformen beinhaltet die Geometrie-Pipeline 820 Tessellationskomponenten zum Durchführen einer Hardware-beschleunigten Tessellation von 3D-Objekten. In einigen Ausführungsformen konfiguriert ein programmierbarer Hull-Shader 811 die Tessellationsoperationen. Ein programmierbarer Domain-Shader 817 stellt eine Back-End-Evaluierung der Tessellationsausgabe bereit. Ein Tessellator 813 arbeitet unter der Regie des Hull-Shaders 811 und enthält Speziallogik zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe an die Geometrie-Pipeline 820 bereitgestellt wird. In einigen Ausführungsformen können, wenn keine Tessellation verwendet wird, die Tessellationskomponenten (z.B. der Hull-Shader 811, der Tessellator 813 und der Domain-Shader 817) umgangen werden.
  • In einigen Ausführungsformen können komplette geometrische Objekte durch einen Geometrie-Shader 819 über einen oder mehrere Threads, die an die Ausführungseinheiten 852A-852B versendet werden, verarbeitet werden, oder sie können direkt an den Clipper 829 weitergegeben werden. In einigen Ausführungsformen arbeitet der Geometrie-Shader an ganzen geometrischen Objekten anstelle von Vertices oder Patches von Vertices wie in vorhergehenden Stufen der Grafik-Pipeline. Wenn die Tessellation deaktiviert ist, empfängt der Geometrie-Shader 819 eine Eingabe vom Vertex-Shader 807. In einigen Ausführungsformen kann der Geometrie-Shader 819 durch ein Geometrie-Shader-Programm programmiert werden, um Geometrie-Tessellation durchzuführen, wenn die Tessellationseinheiten deaktiviert sind.
  • Vor einer Rasterung verarbeitet ein Clipper 829 die Vertex-Daten. Der Clipper 829 kann ein Clipper mit fester Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrie-Shader-Funktionen sein. In einigen Ausführungsformen versendet eine Rasterer- und Tiefentest-Komponente 873 in der Renderausgabe-Pipeline 870 Pixel-Shader zum Umwandeln der geometrischen Objekte in Darstellungen pro Pixel. In einigen Ausführungsformen ist Pixel-Shader-Logik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterer- und Tiefentest-Komponente 873 umgehen und über eine Stream-Out-Einheit 823 auf ungerasterte Vertex-Daten zugreifen.
  • Der Grafikprozessor 800 weist einen Verbindungsbus, eine Verbindungsstruktur oder einen anderen Verbindungsmechanismus auf, der/die das Weitergeben von Daten und Nachrichten unter den wichtigsten Komponenten des Prozessors gestattet. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und assoziierte Logikeinheiten (z.B. der LI-Cache 851, der Sampler 854, der Texturcache 858 usw.) über einen Datenanschluss 856 miteinander verbunden, um Speicherzugriff durchzuführen und mit den Renderausgabe-Pipeline-Komponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A-852B jeweils getrennte Speicherzugriffspfade auf. In einer Ausführungsform kann der Texturcache 858 auch als ein Sampler-Cache konfiguriert sein.
  • In einigen Ausführungsformen enthält die Renderausgabe-Pipeline 870 eine Rasterer- und Tiefentest-Komponente 873, die Vertex-basierte Objekte in eine assoziierte Pixel-basierte Darstellung umwandelt. In einigen Ausführungsformen beinhaltet die Rastererlogik eine Windower/Maskierer-Einheit zum Durchführen von Dreiecks- und Linienrasterung mit fester Funktion. Ein assoziierter Rendercache 878 und Tiefencache 879 stehen in einigen Ausführungsformen auch zur Verfügung. Eine Pixeloperationskomponente 877 führt Pixel-basierte Operationen an den Daten durch, jedoch werden in einigen Fällen Pixeloperationen im Zusammenhang mit 2D-Operationen (z.B. Bit-Block-Bildtransfers mit Vermischung) durch die 2D-Maschine 841 durchgeführt oder zur Anzeigezeit durch den Anzeige-Controller 843 mit Hilfe von Overlay-Anzeigeebenen substituiert. In einigen Ausführungsformen steht ein gemeinsam genutzter L3-Cache 875 allen Grafikkomponenten zur Verfügung, wodurch die gemeinsame Nutzung von Daten ohne Verwendung des Hauptsystemspeichers gestattet wird.
  • In einigen Ausführungsformen beinhaltet die Grafikprozessor-Medien-Pipeline 830 eine Medienmaschine 837 und ein Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipeline-Befehle vom Befehl-Streamer 803. In einigen Ausführungsformen beinhaltet die Medien-Pipeline 830 einen separaten Befehl-Streamer. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle vor dem Senden des Befehls an die Medienmaschine 837. In einigen Ausführungsformen beinhaltet die Medienmaschine 837 Thread-Erzeugungsfunktionalität zum Erzeugen von Threads zum Versenden an die Thread-Ausführungslogik 850 über den Thread-Dispatcher 831.
  • In einigen Ausführungsformen beinhaltet der Grafikprozessor 800 eine Anzeigemaschine 840. In einigen Ausführungsformen befindet sich die Anzeigemaschine 840 außerhalb des Prozessors 800 und ist über die Ringverbindung 802 oder eine/n andere/n Verbindungsbus oder -struktur mit dem Grafikprozessor gekoppelt. In einigen Ausführungsformen beinhaltet die Anzeigemaschine 840 eine 2D-Maschine 841 und einen Anzeige-Controller 843. In einigen Ausführungsformen enthält die Anzeigemaschine 840 Speziallogik, die in der Lage ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen ist der Anzeige-Controller 843 mit einem Anzeigegerät (nicht gezeigt) gekoppelt, bei welchem es sich um ein systemintegriertes Anzeigegerät, wie bei einem Laptop, oder ein externes Anzeigegerät, das über einen Anzeigegerätanschluss angeschlossen ist, handeln kann.
  • In einigen Ausführungsformen sind die Geometrie-Pipeline 820 und die Medien-Pipeline 830 zum Durchführen von Operationen basierend auf mehreren Grafik- und Medienprogrammierungsschnittstellen konfigurierbar und sind nicht spezifisch für jegliche eine Anwendungsprogrammierungsschnittstelle (API - Application Programming Interface). In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die spezifisch für eine bestimmte Grafik- oder Medienbibliothek sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die OpenGL (Open Graphics Library), OpenCL (Open Computing Language) und/oder Vulkan-Grafik- und - Berechnungs-API, alle von der Khronos Group, bereitgestellt. In einigen Ausführungsformen kann auch Unterstützung für die Direct3D-Bibliothek von der Microsoft Corporation bereitgestellt werden. In einigen Ausführungsformen kann eine Kombination dieser Bibliotheken unterstützt werden. Unterstützung kann auch für die OpenCV (Open Source Computer Vision Library) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde auch unterstützt werden, wenn eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors erfolgen kann.
  • Programmierung der Grafik-Pipeline
  • 9A ist ein Blockdiagramm, welches ein Grafikprozessor-Befehlsformat 900 gemäß einiger Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, welches eine Grafikprozessor-Befehlssequenz 910 gemäß einer Ausführungsform veranschaulicht. Die durchgezogenen Kästchen in 9A veranschaulichen die Komponenten, die im Allgemeinen in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten beinhalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A beinhaltet Datenfelder zum Identifizieren eines Client 902, eines Befehlsoperationscodes (Operationscode) 904 und von Daten 906 für den Befehl. Ein Teiloperationscode 905 und eine Befehlsgröße 908 sind auch in einigen Befehlen enthalten.
  • In einigen Ausführungsformen spezifiziert der Client 902 die Client-Einheit des Grafikgerätes, das die Befehlsdaten verarbeitet. In einigen Ausführungsformen prüft ein Grafikprozessor-Befehl-Parser das Client-Feld jedes Befehls zum Konditionieren der weiteren Verarbeitung des Befehls und Routen der Befehlsdaten zu der entsprechenden Client-Einheit. In einigen Ausführungsformen beinhalten die Grafikprozessor-Client-Einheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Client-Einheit weist eine entsprechende Verarbeitungs-Pipeline auf, welche die Befehle verarbeitet. Nachdem der Befehl durch die Client-Einheit empfangen wurde, liest die Client-Einheit den Operationscode 904 und, falls vorhanden, den Teiloperationscode 905 zum Bestimmen der durchzuführenden Operation. Die Client-Einheit führt den Befehl mit Hilfe von Informationen im Datenfeld 906 durch. Bei einigen Befehlen wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls spezifiziert. In einigen Ausführungsformen bestimmt der Befehl-Parser automatisch die Größe von zumindest einigen der Befehle basierend auf dem Befehlsoperationscode. In einigen Ausführungsformen werden Befehle über Vielfache eines Doppelwortes ausgerichtet.
  • Das Flussdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlssequenz 910. In einigen Ausführungsformen verwenden Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors aufweist, eine Version der gezeigten Befehlssequenz zum Einrichten, Ausführen und Beenden eines Satzes von Grafikoperationen. Eine Beispielbefehlssequenz ist lediglich beispielhaft gezeigt und beschrieben, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlssequenz beschränkt sind. Darüber hinaus können die Befehle als ein Befehlsstapel in einer Befehlssequenz ausgegeben werden, sodass der Grafikprozessor die Sequenz von Befehlen mit zumindest teilweiser Gleichzeitigkeit verarbeitet.
  • In einigen Ausführungsformen kann die Grafikprozessor-Befehlssequenz 910 mit einem Pipeline-Bereinigungsbefehl 912 beginnen, um zu veranlassen, dass jegliche aktive Grafik-Pipeline die gegenwärtig ausstehenden Befehle für die Pipeline abschließt. In einigen Ausführungsformen arbeiten die 3D-Pipeline 922 und die Medien-Pipeline 924 nicht gleichzeitig. Die Pipeline-Bereinigung wird durchgeführt, um zu veranlassen, dass die aktive Grafik-Pipeline jegliche ausstehenden Befehle abschließt. Als Reaktion auf eine Pipeline-Bereinigung pausiert der Befehl-Parser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichenmaschinen ausstehende Operationen abgeschlossen haben und die relevanten Lesecaches aufgehoben wurden. Wahlweise können jegliche Daten in dem Rendercache, die als ,schmutzig‘ markiert sind, in den Speicher verschoben werden. In einigen Ausführungsformen kann der Pipeline-Bereinigungsbefehl 912 zur Pipeline-Synchronisation verwendet werden oder bevor der Grafikprozessor in einen Niedrigenergiezustand geschaltet wird.
  • In einigen Ausführungsformen wird ein Pipeline-Auswahlbefehl 913 verwendet, wenn eine Befehlssequenz erfordert, dass der Grafikprozessor explizit zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Pipeline-Auswahlbefehl 913 nur einmal innerhalb eines Ausführungskontextes erforderlich, bevor Pipeline-Befehle ausgegeben werden, es sei denn der Kontext ist das Ausgeben von Befehlen für beide Pipelines. In einigen Ausführungsformen ist ein Pipeline-Bereinigungsbefehl 912 unmittelbar vor einer Pipeline-Umschaltung über den Pipeline-Auswahlbefehl 913 erforderlich.
  • In einigen Ausführungsformen konfiguriert ein Pipeline-Steuerbefehl 914 eine Grafik-Pipeline für den Betrieb und wird zum Programmieren der 3D-Pipeline 922 und der Medien-Pipeline 924 verwendet. In einigen Ausführungsformen konfiguriert der Pipeline-Steuerbefehl 914 den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Pipeline-Steuerbefehl 914 zur Pipeline-Synchronisation und zum Löschen von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline vor der Verarbeitung eines Befehlsstapels verwendet.
  • In einigen Ausführungsformen werden die
  • Rückgabepufferzustandsbefehle 916 zum Konfigurieren eines Satzes von Rückgabepuffern für die entsprechenden Pipelines zum Schreiben von Daten verwendet. Einige Pipeline-Operationen erfordern die Zuteilung, Auswahl oder Konfiguration von einem oder mehreren Rückgabepuffern, in welche die Operationen Zwischendaten während der Verarbeitung schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer zum Speichern von Ausgabedaten und zum Durchführen von Thread-übergreifender Kommunikation. In einigen Ausführungsformen beinhaltet der Rückgabepufferzustand 916 das Auswählen der Größe und Zahl von Rückgabepuffern zur Verwendung für einen Satz von Pipeline-Operationen.
  • Die übrigen Befehle in der Befehlssequenz unterscheiden sich basierend auf der aktiven Pipeline für Operationen. Basierend auf einer Pipeline-Bestimmung 920 wird die Befehlssequenz auf die 3D-Pipeline 922, die mit dem 3D-Pipeline-Zustand 930 beginnt, oder auf die Medien-Pipeline 924, die beim Medien-Pipeline-Zustand 940 beginnt, zugeschnitten.
  • Zu den Befehlen zum Konfigurieren des 3D-Pipeline-Zustands 930 zählen 3D-Zustandseinstell-Befehle für den Vertex-Puffer-Zustand, den Vertex-Element-Zustand, den Konstantfarben-Zustand, den Tiefenpuffer-Zustand und andere Zustandsvariable, die zu konfigurieren sind, bevor 3D-Primitiven-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest zum Teil basierend auf der bestimmten in Verwendung befindlichen 3D-API bestimmt. In einigen Ausführungsformen sind die Befehle zum 3D-Pipeline-Zustand 930 auch in der Lage, gewisse Pipeline-Elemente selektiv zu deaktivieren oder zu umgehen, wenn diese Elemente nicht verwendet werden.
  • In einigen Ausführungsformen wird der Befehl für die 3D-Primitive 932 verwendet, um 3D-Primitive zu übermitteln, die durch die 3D-Pipeline verarbeitet werden sollen. Befehle und assoziierte Parameter, die über den Befehl für die 3D-Primitive 932 an den Grafikprozessor weitergegeben werden, werden an die Vertex-Abruffunktion in der Grafik-Pipeline weitergeleitet. Die Vertex-Abruffunktion verwendet die Befehlsdaten für die 3D-Primitive 932 zum Erzeugen von Vertex-Datenstrukturen. Die Vertex-Datenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der Befehl für die 3D-Primitive 932 zum Durchführen von Vertex-Operationen an 3D-Primitiven über Vertex-Shader verwendet. Zum Verarbeiten von Vertex-Shadern sendet die 3D-Pipeline 922 Shader-Ausführungs-Threads an die Grafikprozessor-Ausführungseinheiten.
  • In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl oder ein Ereignis zum Ausführen 934 ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang die Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen ,Go‘- oder ,Kick‘-Befehl in der Befehlssequenz ausgelöst. In einer Ausführungsform wird die Befehlsausführung mit Hilfe eines Pipeline-Synchronisationsbefehls zum Bereinigen der Befehlssequenz durch die Grafik-Pipeline ausgelöst. Die 3D-Pipeline führt die Geometrieverarbeitung für die 3D-Primitiven durch. Nachdem die Operationen abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixelmaschine färbt die resultierenden Pixel ein. Zusätzliche Befehle zum Steuern von Pixelschattierungs- und Pixel-Back-End-Operationen können auch für diese Operationen enthalten sein.
  • In einigen Ausführungsformen folgt die Grafikprozessor-Befehlssequenz 910 dem Pfad der Medien-Pipeline 924, wenn Medienoperationen durchgeführt werden. Im Allgemeinen hängt die spezifische Verwendung und Art und Weise der Programmierung für die Medien-Pipeline 924 von den durchzuführenden Medien- oder Berechnungsoperationen ab. Spezifische Mediendecodierungsoperationen können während der Mediendecodierung an die Medien-Pipeline übergeben werden. In einigen Ausführungsformen kann die Medien-Pipeline auch umgangen werden und die Mediendecodierung kann im Ganzen oder zum Teil mit Hilfe von Ressourcen erfolgen, die durch einen oder mehrere Universalverarbeitungskerne bereitgestellt werden. In einer Ausführungsform beinhaltet die Medien-Pipeline auch Elemente für Operationen einer Universal-Grafikprozessoreinheit (GPGPU - General-Purpose Graphics Processor Unit), wobei der Grafikprozessor zum Durchführen von SIMD-Vektoroperationen mit Hilfe von Shader-Rechenprogrammen, die sich nicht explizit auf das Rendern von Grafikprimitiven beziehen, verwendet wird.
  • In einigen Ausführungsformen ist die Medien-Pipeline 924 in ähnlicher Weise wie die 3D-Pipeline 922 konfiguriert. Ein Satz von Befehlen zum Konfigurieren des Medien-Pipeline-Zustands 940 wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange gesendet oder darin platziert. In einigen Ausführungsformen beinhalten die Befehle für den Medien-Pipeline-Zustand 940 Daten zum Konfigurieren der Medien-Pipeline-Elemente, die zum Verarbeiten der Medienobjekte verwendet werden. Zu diesen zählen Daten zum Konfigurieren der Videodecodierungs- und Videocodierungslogik innerhalb der Medien-Pipeline, wie z.B. das Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen Befehle für den Medien-Pipeline-Zustand 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente, die einen Stapel von Zustandseinstellungen enthalten.
  • In einigen Ausführungsformen liefern die Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medien-Pipeline. Die Medienobjekte beinhalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medien-Pipeline-Zustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Nachdem der Pipeline-Zustand konfiguriert wurde und die Medienobjektbefehle 942 aufgereiht wurden, wird die Medien-Pipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z.B. ein Registerschreibvorgang) ausgelöst. Die Ausgabe aus der Medien-Pipeline 924 kann dann durch Operationen nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medien-Pipeline 924 bereitgestellt werden. In einigen Ausführungsformen werden GPGPU-Operationen in ähnlicher Weise wie Medienoperationen konfiguriert und ausgeführt.
  • Grafiksoftwarearchitektur
  • 10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 gemäß einiger Ausführungsformen. In einigen Ausführungsformen beinhaltet die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen beinhaltet der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkern(e) 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemspeicher 1050 des Datenverarbeitungssystems ausgeführt.
  • In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shader-Programme, die Shader-Anweisungen 1012 beinhalten. Die Shader-Sprachanweisungen können in einer Shader-Hochsprache, wie z.B. der HLSL (High Level Shader Language) oder der GLSL (OpenGL Shader Language) vorliegen. Die Anwendung beinhaltet auch die ausführbaren Anweisungen 1014 in einer Maschinensprache, die zur Ausführung durch den Universalprozessorkern 1034 geeignet ist. Die Anwendung beinhaltet auch die Grafikobjekte 1016, die durch Vertex-Daten definiert werden.
  • In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source-UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 unterstützen, wie z.B. die Direct3D-API, die OpenGL-API oder die Vulkan-API. Wenn die Direct3D-API in Betrieb ist, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024 zum Kompilieren jeglicher Shader-Anweisungen 1012 in HLSL in eine Shader-Sprache auf niedrigerer Ebene. Die Kompilierung kann eine JIT (Just-In-Time) -Kompilierung sein oder die Anwendung kann eine Shader-Vorkompilierung durchführen. In einigen Ausführungsformen werden Shader einer höheren Ebene während der Kompilierung der 3D-Grafikanwendung 1010 zu Shadern einer niedrigeren Ebene kompiliert. In einigen Ausführungsformen werden die Shader-Anweisungen 1012 in einer Zwischenform bereitgestellt, wie z.B. einer Version der SPIR (Standard Portable Intermediate Representation), die durch die Vulkan-API verwendet wird.
  • In einigen Ausführungsformen enthält der Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027 zum Umwandeln der Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung. Wenn die OpenGL-API in Betrieb ist, werden die Shader-Anweisungen 1012 in der GLSL-Hochsprache zur Kompilierung an einen Benutzermodus-Grafiktreiber 1026 weitergegeben. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 die Betriebssystem-Kernelmodus-Funktionen 1028 zum Kommunizieren mit einem Kernelmodus-Grafiktreiber 1029. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032 zum Versenden von Befehlen und Anweisungen.
  • IP-Kern-Implementierungen
  • Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch einen repräsentativen Code, der auf einem maschinenlesbaren Medium gespeichert ist, implementiert werden, welcher Logik innerhalb einer integrierten Schaltung, wie z.B. einem Prozessor, darstellt und/oder definiert. Zum Beispiel kann das maschinenlesbare Medium Anweisungen beinhalten, welche verschiedene Logik innerhalb des Prozessors darstellen. Wenn sie durch eine Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zum Durchführen der hierin beschriebenen Techniken herzustellen. Derartige Darstellungen, bekannt als „IP-Kerne“, sind wiederverwendbare Logikeinheiten für eine integrierte Schaltung, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardware-Modell, das die Struktur der integrierten Schaltung beschreibt, gespeichert werden können. Das Hardware-Modell kann an verschiedene Kunden oder Herstellungseinrichtungen bereitgestellt werden, welche das Hardware-Modell auf Herstellungsmaschinen laden, welche die integrierte Schaltung herstellen. Die integrierte Schaltung kann derart hergestellt werden, dass die Schaltung Operationen durchführt, die im Zusammenhang mit jeglichen der hierin beschriebenen Ausführungsformen beschrieben sind.
  • 11A ist ein Blockdiagramm, welches ein IP-Kern-Entwicklungssystem 1100, das zur Herstellung einer integrierten Schaltung zum Durchführen von Operationen verwendet werden kann, gemäß einer Ausführungsform veranschaulicht. Das IP-Kern-Entwicklungssystem 1100 kann zum Erzeugen von modularen, wiederverwendbaren Designs, die in ein größeres Design integriert werden können, oder zum Konstruieren einer gesamten integrierten Schaltung (z.B. eine integrierte SOC-Schaltung) verwendet werden. Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z.B. C/C++) erzeugen. Die Softwaresimulation 1110 kann zum Entwickeln, Testen und Verifizieren des Verhaltens des IP-Kerns unter Verwendung eines Simulationsmodells 1112 verwendet werden. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Timing-Simulationen beinhalten. Ein Registertransferlevel (RTL) -Design 1115 kann dann aus dem Simulationsmodell 1112 erstellt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens der integrierten Schaltung, die den Fluss von Digitalsignalen zwischen Hardware-Registern modelliert, einschließlich der assoziierten Logik, die mit Hilfe der modellierten Digitalsignale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs einer niedrigeren Ebene auf der Logikebene oder der Transistorebene erstellt, entwickelt oder synthetisiert werden. Somit können die genauen Details des Anfangsdesigns und der Simulation variieren.
  • Das RTL-Design 1115 oder ein Äquivalent kann durch die Designeinrichtung weiter zu einem Hardware-Modell 1120 synthetisiert werden, welches in einer Hardware-Beschreibungssprache (HDL - Hardware Description Language) oder einer anderen Darstellung physikalischer Designdaten vorliegen kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Bereitstellung an eine Herstellungseinrichtung einer dritten Partei 1165 mit Hilfe von nichtflüchtigem Speicher 1140 (z.B. eine Festplatte, ein Flashspeicher oder jegliches nichtflüchtiges Speichermedium) gespeichert werden. Alternativ dazu kann das IP-Kern-Design über eine verdrahtete Verbindung 1150 oder eine drahtlose Verbindung 1160 übermittelt werden (z.B. über das Internet). Die Herstellungseinrichtung 1165 kann dann eine integrierte Schaltung herstellen, die zumindest teilweise auf dem IP-Kern-Design basiert. Die hergestellte integrierte Schaltung kann zum Durchführen von Operationen in Übereinstimmung mit mindestens einer hierin beschriebenen Ausführungsform konfiguriert werden.
  • 11B veranschaulicht eine Querschnitt-Seitenansicht einer Paketbaugruppe 1170 einer integrierten Schaltung gemäß einiger hierin beschriebener Ausführungsformen. Die Paketbaugruppe 1170 der integrierten Schaltung veranschaulicht eine Implementierung von einem oder mehreren Prozessor- oder Beschleunigergeräten wie hierin beschrieben. Die Paketbaugruppe 1170 beinhaltet mehrere Einheiten Hardware-Logik 1172, 1174 verbunden mit einem Substrat 1180. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logikhardware oder Logikhardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte von jedem der hierin beschriebenen Prozessorkern(e), Grafikprozessor(en) oder anderen Beschleunigergeräten beinhalten. Jede Einheit der Logik 1172, 1174 kann innerhalb eines Halbleiterchips implementiert sein und über eine Verbindungsstruktur 1173 mit dem Substrat 1180 gekoppelt sein. Die Verbindungsstruktur 1173 kann zum Routen elektrischer Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 konfiguriert sein und kann Verbindungen wie z.B., jedoch nicht darauf beschränkt, Kontakthügel oder -stifte beinhalten. In einigen Ausführungsformen kann die Verbindungsstruktur 1173 zum Routen elektrischer Signale, wie zum Beispiel Eingabe/Ausgabe (E/A) -Signale und/oder Leistungs- oder Massesignale im Zusammenhang mit dem Betrieb der Logik 1172, 1174, konfiguriert sein. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. In anderen Ausführungsformen kann das Paketsubstrat 1180 auch andere geeignete Arten von Substraten beinhalten. Die Paketbaugruppe 1170 kann über eine Paketverbindung 1183 mit anderen elektrischen Geräten verbunden sein. Die Paketverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale zu anderen elektrischen Geräten zu routen, wie z.B. einer Hauptplatine, einem anderen Chipsatz oder einem Mehrchip-Modul.
  • In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch mit einer Brücke 1182 gekoppelt, die zum Routen elektrischer Signale zwischen der Logik 1172, 1174 konfiguriert ist. Die Brücke 1182 kann eine dichte Verbindungsstruktur sein, die einen Pfad für elektrische Signale bereitstellt. Die Brücke 1182 kann ein Brückensubstrat beinhalten, das aus Glas oder einem geeigneten Halbleitermaterial zusammengesetzt ist. Elektrische Routing-Merkmale können auf dem Brückensubstrat ausgebildet sein, um eine Chip-zu-Chip-Verbindung zwischen der Logik 1172, 1174 bereitzustellen.
  • Obwohl zwei Logikeinheiten 1172, 1174 und eine Brücke 1182 veranschaulicht sind, können hierin beschriebene Ausführungsformen auch mehr oder weniger Logikeinheiten auf einem oder mehreren Chips beinhalten. Der eine oder die mehreren Chips können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 möglicherweise ausgeschlossen ist, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ dazu können mehrere Chips oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Außerdem können mehrere Logikeinheiten, Chips und Brücken in anderen möglichen Konfigurationen miteinander verbunden sein, einschließlich dreidimensionaler Konfigurationen.
  • Beispielhafte integrierte Ein-Chip-System-Schaltung
  • 12-14 veranschaulichen beispielhafte integrierte Schaltungen und assoziierte Grafikprozessoren, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden können, gemäß verschiedener hierin beschriebener Ausführungsformen. Zusätzlich zu dem, was veranschaulicht ist, können andere Logik und Schaltungen enthalten sein, einschließlich zusätzlicher Grafikprozessoren/-kerne, Peripherieschnittstellen-Controller oder Universalprozessorkerne.
  • 12 ist ein Blockdiagramm, welches eine beispielhafte integrierte Ein-Chip-System-Schaltung 1200, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform veranschaulicht. Die beispielhafte integrierte Schaltung 1200 beinhaltet einen oder mehrere Anwendungsprozessor(en) 1205 (z.B. CPUs), mindestens einen Grafikprozessor 1210, und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 beinhalten, wobei es sich jeweils um einen modularen IP-Kern von der gleichen oder mehreren unterschiedlichen Designeinrichtungen handeln kann. Die integrierte Schaltung 1200 beinhaltet Peripherie- oder Buslogik, einschließlich eines USB-Controllers 1225, eines UART-Controllers 1230, eines SPI/SDIO-Controllers 1235 und eines I2S/I2C-Controllers 1240. Außerdem kann die integrierte Schaltung ein Anzeigegerät 1245 gekoppelt an eine/n oder mehrere aus einem HDMI (High-Definition Multimedia Interface) -Controller 1250 und einer MIPI (Mobile Industry Processor Interface) -Anzeigeschnittstelle 1255 beinhalten. Die Speicherung kann durch ein Flashspeicher-Untersystem 1260 bereitgestellt werden, das Flashspeicher und einen Flashspeicher-Controller beinhaltet. Die Speicherschnittstelle kann über einen Speicher-Controller 1265 für den Zugriff auf SDRAM- oder SRAM-Speichergeräte bereitgestellt werden. Einige integrierte Schaltungen beinhalten zusätzlich eine eingebettete Sicherheitsmaschine 1270.
  • 13A-13B sind Blockdiagramme, welche beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC gemäß hierin beschriebener Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 einer integrierten Ein-Chip-System-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform. 13B veranschaulicht einen zusätzlichen beispielhaften Grafikprozessor 1340 einer integrierten Ein-Chip-System-Schaltung, die unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann, gemäß einer Ausführungsform. Der Grafikprozessor 1310 von 13A ist ein Beispiel eines Niedrigenergie-Grafikprozessorkerns. Der Grafikprozessor 1340 von 13B ist ein Beispiel eines Grafikprozessorkerns mit höherer Leistung. Jeder der Grafikprozessoren 1310, 1340 kann eine Variante des Grafikprozessors 1210 von 12 sein.
  • Wie in 13A gezeigt, beinhaltet der Grafikprozessor 1310 einen Vertex-Prozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann unterschiedliche Shader-Programme über separate Logik ausführen, sodass der Vertex-Prozessor 1305 zum Ausführen von Operationen für Vertex-Shader-Programme optimiert ist, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragment (z.B. Pixel) -Schattierungsoperationen für Fragment- oder Pixel-Shader-Programme ausführt. Der Vertex-Prozessor 1305 führt die Vertex-Verarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt Primitiven- und Vertex-Daten. Der/Die Fragmentprozessor(en) 1315A-1315N verwenden die Primitiven- und Vertex-Daten, die durch den Vertex-Prozessor 1305 erzeugt werden, zum Erzeugen eines Frame-Puffers, der auf einem Anzeigegerät angezeigt wird. In einer Ausführungsform sind der/die Fragmentprozessor(en) 1315A-1315N zum Ausführen von Fragment-Shader-Programmen, wie sie in der OpenGL-API bereitgestellt werden, optimiert, welche zum Durchführen ähnlicher Operationen wie ein Pixel-Shader-Programm, wie es in der Direct 3D-API bereitgestellt wird, verwendet werden können.
  • Der Grafikprozessor 1310 beinhaltet außerdem eine/n oder mehrere Speichermanagementeinheiten (MMU - Memory Management Units) 1320A-1320B, Cache(s) 1325A-1325B und Schaltungsverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B sorgen für eine Virtuell-zu-Physisch-Adressabbildung für den Grafikprozessor 1310, einschließlich für den Vertex-Prozessor 1305 und/oder den/die Fragmentprozessor(en) 1315A-1315N, welche auf Vertex- oder Bild/Textur-Daten, die im Speicher gespeichert sind, zusätzlich zu Vertex- oder Bild/Textur-Daten, die in dem einen oder den mehreren Cache(s) 1325A-1325B gespeichert sind, verweisen kann. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs innerhalb des Systems synchronisiert werden, einschließlich einer oder mehrerer MMUs im Zusammenhang mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12, derart, dass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder einheitlichen virtuellen Speichersystem teilnehmen kann. Die eine oder die mehreren Schaltungsverbindung(en) 1330A-1330B ermöglichen es dem Grafikprozessor 1310, eine Schnittstelle mit anderen IP-Kernen innerhalb des SoC zu bilden, je nach Ausführungsform entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
  • Wie in 13B gezeigt, beinhaltet der Grafikprozessor 1340 die eine oder die mehreren MMU(s) 1320A-1320B, die Caches 1325A-1325B und die Schaltungsverbindungen 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 beinhaltet einen oder mehrere Shader-Kern(e) 1355A-1355N (z.B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), wodurch eine einheitliche Shader-Kernarchitektur entsteht, in welcher ein einzelner Kern oder eine Art von Kern alle Arten von programmierbarem Shader-Code ausführen kann, einschließlich Shader-Programmcode zum Implementieren von Vertex-Shadern, Fragment-Shadern und/oder Rechen-Shadern. Die genaue Zahl vorliegender Shader-Kerne kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich beinhaltet der Grafikprozessor 1340 einen Inter-Kern-Aufgabenmanager 1345, welcher als ein Thread-Dispatcher zum Versenden von Ausführungs-Threads an einen oder mehrere Shader-Kerne 1355A-1355N dient, und eine Tiling-Einheit 1358 zum Beschleunigen von Tiling-Operationen für Kachel-basiertes Rendern, wobei Renderoperationen für eine Szene in Bildraum unterteilt sind, zum Beispiel zur Ausnutzung einer lokalen räumlichen Kohärenz innerhalb einer Szene oder zur Optimierung der Verwendung interner Caches.
  • 14A-14B veranschaulichen zusätzliche beispielhafte Grafikprozessorlogik gemäß hierin beschriebener Ausführungsformen. 14A veranschaulicht einen Grafikkern 1400, der innerhalb des Grafikprozessors 1210 von 12 enthalten sein kann, und es kann sich dabei um einen einheitlichen Shader-Kern 1355A-1355N wie in 13B handeln. 14B veranschaulicht eine hochparallele Universal-Grafikverarbeitungseinheit 1430, die für den Einsatz auf einem Mehrchip-Modul geeignet ist.
  • Wie in 14A gezeigt, beinhaltet der Grafikkern 1400 einen gemeinsam genutzten Anweisungscache 1402, eine Textureinheit 1418 und einen Cache/gemeinsam genutzten Speicher 1420, die den Ausführungsressourcen innerhalb des Grafikkerns 1400 gemeinsam sind. Der Grafikkern 1400 kann mehrere Scheiben 1401A-1401N oder eine Partition für jeden Kern beinhalten und ein Grafikprozessor kann mehrere Instanzen des Grafikkerns 1400 beinhalten. Die Scheiben 1401A-1401N können Unterstützungslogik beinhalten, einschließlich eines lokalen Anweisungscaches 1404A-1404N, eines Thread-Schedulers 1406A-1406N, eines Thread-Dispatchers 1408A-1408N und eines Satzes von Registern 1410A. Zum Durchführen von Logikoperationen können die Scheiben 1401A-1401N einen Satz zusätzlicher Funktionseinheiten (AFUs - Additional Functional Units) 1412A-1412N, Gleitkommaeinheiten (FPU - Floating-Point Units) 1414A-1414N, Ganzzahl-Arithmetik-Logikeinheiten (ALUs -Arithmetic Logic Units) 1416-1416N, Adressrecheneinheiten (ACU -Address Computational Units) 1413A-1413N, doppelt präziser Gleitkommaeinheiten (DPFPU - Double-Precision Floating-Point Units) 1415A-1415N und Matrixverarbeitungseinheiten (MPU -Matrix Processing Units) 1417A-1417N beinhalten.
  • Einige der Recheneinheiten arbeiten mit einer spezifischen Präzision. Zum Beispiel können die FPUs 1414A-1414N Gleitkommaoperationen mit einfacher Präzision (32-Bit) und halber Präzision (16-Bit) durchführen, während die DPFPUs 1415A-1415N Gleitkommaoperationen mit doppelter Präzision (64-Bit) durchführen. Die ALUs 1416A-1416N können Ganzzahloperation mit variabler Präzision mit 8-Bit-, 16-Bit- und 32-Bit-Präzision durchführen und können für Operationen mit gemischter Präzision konfiguriert sein. Die MPUs 1417A-1417N können auch für Matrixoperationen mit gemischter Präzision konfiguriert sein, einschließlich Gleitkomma- und 8-Bit-Ganzzahloperationen mit halber Präzision. Die MPUs 1417-1417N können eine Vielzahl von Matrixoperationen zum Beschleunigen von Maschinenlernen-Anwendungsframeworks durchführen, einschließlich der Ermöglichung von Unterstützung für beschleunigte allgemeine Matrix-Matrix-Multiplikation (GEMM - General Matrix To Matrix Multiplication). Die AFUs 1412A-1412N können zusätzliche Logikoperationen durchführen, die durch die Gleitkomma- oder Ganzzahleinheiten nicht unterstützt werden, einschließlich trigonometrischer Operationen (z.B. Sinus, Cosinus usw.).
  • Wie in 14B gezeigt, kann eine Universalverarbeitungseinheit (GPGPU - General-Purpose Processing Unit) 1430 zum Ermöglichen von hochparallelen Rechenoperationen zur Durchführung durch ein Array von Grafikverarbeitungseinheiten konfiguriert sein. Außerdem kann die GPGPU 1430 direkt mit anderen Instanzen der GPGPU verknüpft sein, um ein Multi-GPU-Cluster zur Verbesserung der Trainingsgeschwindigkeit für besonders tiefe neuronale Netzwerke zu erzeugen. Die GPGPU 1430 beinhaltet eine Host-Schnittstelle 1432 zum Ermöglichen einer Verbindung mit einem Host-Prozessor. In einer Ausführungsform ist die Host-Schnittstelle 1432 eine PCI Express-Schnittstelle. Jedoch kann die Host-Schnittstelle auch eine verkäuferspezifische Kommunikationsschnittstelle oder Kommunikationsstruktur sein. Die GPGPU 1430 empfängt Befehle von dem Host-Prozessor und verwendet einen globalen Scheduler 1434 zum Verteilen von Ausführungs-Threads, die mit diesen Befehlen assoziiert sind, an einen Satz von Rechenclustern 1436A-1436H. Die Rechencluster 1436A-1436H nutzen einen Cachespeicher 1438 gemeinsam. Der Cachespeicher 1438 kann als ein Cache eines höheren Levels für Cachespeicher innerhalb der Rechencluster 1436A-1436H dienen.
  • Die GPGPU 1430 beinhaltet den Speicher 1434A-1434B, der über einen Satz von Speicher-Controllern 1442A-1442B mit den Rechenclustern 1436A-1436H gekoppelt ist. In verschiedenen Ausführungsformen kann der Speicher 1434A-1434B verschiedene Arten von Speichergeräten beinhalten, einschließlich dynamischen Direktzugriffsspeicher (DRAM - Dynamic Random-Access Memory) oder Grafik-Direktzugriffsspeicher, wie z.B. synchronen Grafik-Direktzugriffsspeicher (SGRAM-Synchronous Graphics Random Access Memory), einschließlich eines Speichers für Grafiken mit doppelter Datenrate (GDDR - Graphics Double Data Rate).
  • In einer Ausführungsform beinhalten die Rechencluster 1436A-1436H jeweils einen Satz von Grafikkernen, wie z.B. den Grafikkern 1400 von 14A, welche mehrere Arten von Ganzzahl- und Gleitkomma-Logikeinheiten beinhalten können, die Rechenoperationen in einem Präzisionsbereich, einschließlich geeignet für Maschinenlernen-Berechnungen, durchführen können. Zum Beispiel kann in einer Ausführungsform mindestens eine Teilmenge der Gleitkommaeinheiten in jedem der Rechencluster 1436A-1436H zum Durchführen von 16-Bit- oder 32-Bit-Gleitkommaoperationen konfiguriert sein, während eine unterschiedliche Teilmenge der Gleitkommaeinheiten zum Durchführen von 64-Bit-Gleitkommaoperationen konfiguriert sein kann.
  • Mehrere Instanzen der GPGPU 1430 können zum Arbeiten als ein Rechencluster konfiguriert sein. Der durch das Rechencluster für Synchronisation und Datenaustausch verwendete Kommunikationsmechanismus variiert über Ausführungsformen hinweg. In einer Ausführungsform kommunizieren die mehreren Instanzen der GPGPU 1430 über die Host-Schnittstelle 1432. In einer Ausführungsform beinhaltet die GPGPU 1430 einen E/A-Hub 1439, der die GPGPU 1430 mit einem GPU-Link 1440 koppelt, der eine direkte Verbindung zu anderen Instanzen der GPGPU ermöglicht. In einer Ausführungsform ist der GPU-Link 1440 an eine dedizierte GPUzu-GPU-Brücke gekoppelt, die Kommunikation und Synchronisation zwischen mehreren Instanzen der GPGPU 1430 ermöglicht. In einer Ausführungsform ist der GPU-Link 1440 mit einer Hochgeschwindigkeitsverbindung zum Senden und Empfangen von Daten an/von andere/n GPGPUs oder Parallelprozessoren gekoppelt. In einer Ausführungsform befinden sich die mehreren Instanzen der GPGPU 1430 in separaten Datenverarbeitungssystemen und kommunizieren über ein Netzwerkgerät, auf das über die Host-Schnittstelle 1432 zugegriffen werden kann. In einer Ausführungsform kann der GPU-Link 1440 zum Ermöglichen einer Verbindung zu einem Host-Prozessor zusätzlich oder als eine Alternative zu der Host-Schnittstelle 1432 konfiguriert sein.
  • Während die veranschaulichte Konfiguration der GPGPU 1430 zum Trainieren neuronaler Netzwerke konfiguriert sein kann, sieht eine Ausführungsform eine alternative Konfiguration der GPGPU 1430 vor, die zum Einsatz innerhalb einer Hochleistungs- oder Niedrigenergie-Inferencing-Plattform konfiguriert sein kann. Bei einer Inferencing-Konfiguration beinhaltet die GPGPU 1430 weniger der Rechencluster 1436A-1436H relativ zu der Trainingskonfiguration. Außerdem kann sich die Speichertechnologie im Zusammenhang mit dem Speicher 1434A-1434B zwischen Inferencing- und Trainingskonfigurationen unterscheiden, wobei bei Trainingskonfigurationen Speichertechnologien mit höherer Bandbreite zum Einsatz kommen. In einer Ausführungsform kann die Inferencing-Konfiguration der GPGPU 1430 Inferencing-spezifische Anweisungen unterstützen. Zum Beispiel kann eine Inferencing-Konfiguration Unterstützung für eine oder mehrere 8-Bit-Ganzzahl-Skalarprodukt-Anweisungen bereitstellen, welche üblicherweise während Inferencing-Operationen für eingesetzte neuronale Netzwerke verwendet werden.
  • Reduzierung von Registerbankkonflikten für Ausführungseinheiten eines Multithread-Prozessors
  • In einigen Ausführungsformen sorgen eine Vorrichtung, ein System oder ein Prozess für die Reduzierung von Registerbankkonflikten für Ausführungseinheiten (EUs - Execution Units) eines Multithread-Prozessors. In einigen Ausführungsformen beinhalten die Ausführungseinheiten Ausführungseinheiten innerhalb einer oder mehrerer GPUs.
  • In einigen Ausführungsformen sorgen eine Vorrichtung, ein System oder ein Prozess für die Reduzierung von Registerbankkonflikten durch eines oder mehrere der Folgenden:
    • (1) Registerverteilung über Registerbanken hinweg, welche eine Registerverteilung über mehrere Arrays von Registerbanken, wie z.B. ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register, hinweg beinhalten kann;
    • (2) Mehrstufen-Lesevorgänge in einer Pipeline, welche zum Beispiel eine erste Lesestufe für ungerade Quelloperanden und eine zweite Lesestufe für gerade Quelloperanden beinhalten können; und
    • (3) Registerpositionstausch für Anweisungen, welcher Positionstausche für Zwei-Quellen-Anweisungen und für Drei-Quellen-Anweisungen beinhalten kann.
  • Im Vergleich zu traditionalen Hardware- und Softwarelösungen zur Behandlung von Konflikten können die Ausführungsformen kostengünstig mit minimalen Hardware-Modifikationen und -Kosten implementiert werden. Die Ausführungsformen können eingesetzt werden, um eine signifikante Reduzierung in der Wahrscheinlichkeit von Bankkonflikten mit minimalen Nebenwirkungen auf die Compiler-Registerzuteilung und mit einer sehr geringen Algorithmus-Komplexität bereitzustellen.
  • 15 ist eine Veranschaulichung eines Verarbeitungssystems, das eine Architektur zur Reduzierung von Registerbankkonflikten für Multithread-Ausführungseinheiten beinhaltet, gemäß einiger Ausführungsformen. In einigen Ausführungsformen beinhaltet ein Verarbeitungssystem 1500, wie z.B. ein in 1 veranschaulichtes Verarbeitungssystem 100, einen oder mehrere Prozessorkerne. In einigen Ausführungsformen beinhaltet das Verarbeitungssystem 1500 einen oder mehrere Prozessoren 1505 (welche eine oder mehrere Zentraleinheiten (CPUs - Central Processing Units) beinhalten können), wie z.B. die in 1 veranschaulichten Prozessoren 102, mit einem oder mehreren Prozessorkernen und beinhaltet ferner eine oder mehrere GPUs 1510, wie z.B. die in 1 veranschaulichten Grafikprozessoren 108, mit einem oder mehreren Grafikprozessorkernen, wobei die GPUs 1510 innerhalb des einen oder der mehreren Prozessoren 1505 enthalten sein können oder davon getrennt sein können. Jedoch sind die Ausführungsformen nicht auf diese bestimmte Verarbeitungsstruktur beschränkt. Der eine oder die mehreren Prozessoren 1510 können die Elemente beinhalten, wie sie für den Prozessor 200 in 2 veranschaulicht sind, und die eine oder die mehreren GPUs 1520 können die Elemente beinhalten, wie sie für den Grafikprozessor 300 in 3 veranschaulicht sind.
  • In einigen Ausführungsformen beinhalten die eine oder die mehreren GPUs 1510 eine oder mehrere Ausführungseinheiten 1520, wie z.B. die in 6A veranschaulichten Ausführungseinheiten 609A-609N, wobei die eine oder die mehreren Ausführungseinheiten mindestens eine erste Ausführungseinheit 1521 beinhalten, wobei die erste Ausführungseinheit eine Mehrbank-Registerdatei 1525 beinhaltet. Veranschaulicht sind auch eine oder mehrere Ausführungs-Pipelines zur Verarbeitung von Anweisungen 1530.
  • In einigen Ausführungsformen ist das Verarbeitungssystem zur Reduzierung von Registerbankkonflikten für eine Multithread-Ausführungseinheit strukturiert, einschließlich Ausführungseinheiten von einer oder mehreren GPUs in einem Verarbeitungssystem. In einigen Ausführungsformen sorgt die Registerdatei 1525 für eine Registerverteilung über Registerbanken hinweg, wie z.B. in einer oder mehreren von 17 und 18 veranschaulicht. Das Verarbeitungssystem 1500 kann ferner Mehrstufen-Pipeline-Lesevorgänge in der einen oder den mehreren Pipelines 1530 bereitstellen, wie in 19 veranschaulicht. In einigen Ausführungsformen implementiert das Verarbeitungssystem ferner Operandenpositionstausche, wie z.B. in einer oder mehreren von 21 und 22 veranschaulicht, um für eine weitere Reduzierung in der Wahrscheinlichkeit des Auftretens von Registerbankkonflikten zu sorgen.
  • 16 ist eine Veranschaulichung einer Mehrbank-Registerdatei in einer Vorrichtung oder einem System. Wie in 16 veranschaulicht, kann eine Vorrichtung oder ein System eine Registerdatei 1600 mit mehreren Banken von Registern beinhalten, welche als die Banken 1610 bis 1630 veranschaulicht sind. In 16, wie auch in 17 und 18, stellt jeder Stapel von Rechtecken eine Registerbank dar, und jedes Rechteck innerhalb des Stapels stellt ein Register innerhalb der Registerbank dar. Die mehreren Banken 1610-1630 sind mit einem Element zum Auswählen und Lesen des Inhalts von Registern jeder Bank, veranschaulicht als ein Registerdatei-Lese-Multiplexer 1640, und Bereitstellen einer Ausgabe über eine Reihe von Anschlüssen, veranschaulicht als P0 bis Pp, gekoppelt. Es gibt eine Zahl von p+1 Anschlüssen für den Registerdatei-Lese-Multiplexer 1640, wodurch es dem Multiplexer gestattet wird, p+1 Register zu einer Zeit zu lesen, solange die Register alle zu unterschiedlichen Banken gehören. Jedoch erzeugt der Versuch, Register aus der gleichen Bank zur gleichen Zeit zu lesen, einen Registerbankkonflikt, was in einer Verzögerung des Lesens von einem oder mehreren Registern zum Vermeiden des Registerbankkonflikts resultieren kann.
  • In einer/m herkömmlichen Vorrichtung oder System, in welcher/m eine EU mehrere Verarbeitungs-Threads unterstützt, werden die Register für einen bestimmten Thread üblicherweise sequentiell innerhalb einer Registerbank der mehreren Registerbanken der Registerdatei 1600 strukturiert. Zum Beispiel wird ein Thread T0 durch Register in der Bank 1610 unterstützt, wobei die Register für Thread T0 als T0-R0, T0-R1, T0-R2 und jegliche zusätzlichen Register, die einer derartigen Bank zugewiesen sind, gezeigt sind. Während die Register für Thread T0 der Einfachheit der Veranschaulichung halber innerhalb einer einzelnen Bank gezeigt sind, können die Register für jeglichen der Threads in einer tatsächlichen Implementierung mehrere Banken innerhalb eines Arrays von Registern belegen. Die Register für Thread T1 befinden sich in der Bank 1615, wobei es sich um die Register T1-R0, T1 -R1, T1-R2 und jegliche zusätzlichen Register für einen derartigen Thread handelt, und die Register für Thread Tt befinden sich in der Bank 1630, wobei es sich bei den Registern um Tt-R0, Tt-R1, Tt-R2 und jegliche zusätzlichen Register für einen derartigen Thread handelt.
  • Die Absicht der in 16 veranschaulichten herkömmlichen Registerstruktur ist das Trennen der Register unterschiedlicher Threads in unterschiedliche Banken. Bei dieser Struktur kann die EU mehrere funktionale Anweisungsausführungs-Pipelines aufweisen und jede Pipeline wird zum Ausführen spezifischer Anweisungen verwendet. Diese Ausführungs-Pipelines werden durch Hardware-Threads gemeinsam genutzt. Der auf einer Abhängigkeitsverzögerung basierende Thread-Umschaltmechanismus der EU wird zum Umschalten der Threads in der Laufzeit zur maximalen Reduzierung des Leerlaufs der Anweisungs-Pipelines verwendet. Dies bedeutet, dass die Anweisungen unterschiedlicher Threads durch die EU einer entsprechenden Ausführungs-Pipeline zugewiesen werden. Das herkömmliche Schema garantiert, dass keine Konflikte zwischen Anweisungen unterschiedlicher Threads auftreten, da sie zu unterschiedlichen Banken gehören.
  • Jedoch ist bei der in 16 veranschaulichten Architektur die Wahrscheinlichkeit von Registerbankkonflikten innerhalb eines Threads höher als die Wahrscheinlichkeit von Registerbankkonflikten zwischen Threads. In einer GPU-Struktur kann die große Mehrheit der Registerbankkonflikte in den EUs tatsächlich aus Thread-internen Konflikten resultieren. Eine Analyse der 3D- und GPGPU-Arbeitslasten veranschaulicht, dass die Verarbeitung von FPU-Funktionen allein den Großteil der EU-Ausführungszeit belegt. Dies bedeutet also, dass die Chance des Lesens von Registern aus unterschiedlichen Threads zur gleichen Zeit im Allgemeinen sehr gering ist. Somit würde die herkömmliche Verteilung von Registern, wie in 16 veranschaulicht, eine höhere Zahl von Registerbankkonflikten erzeugen, da sich die Register für jeden Thread innerhalb einer bestimmten Registerbank oder einem Satz von Registerbanken innerhalb der Registerdatei 1600 befinden.
  • In einigen Ausführungsformen beinhaltet eine Vorrichtung, ein System oder ein Prozess eine modifizierte Verteilung von Registern über die Banken von Registern innerhalb einer Registerdatei hinweg, wobei die Verteilung so die Register eines Threads trennt und somit Thread-interne Konflikte reduziert werden.
  • 17 ist eine Veranschaulichung einer Mehrbank-Registerdatei in einer Vorrichtung oder einem System, die/das eine Registerverteilung über Registerbanken einer Registerdatei hinweg bereitstellt, gemäß einiger Ausführungsformen. Wie in 17 veranschaulicht, beinhaltet eine Vorrichtung oder ein System eine Registerdatei 1700 mit mehreren Banken von Registern, welche als die Banken 1710 bis 1730 veranschaulicht sind. Die mehreren Banken 1710-1730 sind mit einem Element zum Auswählen und Lesen des Inhalts von Registern jeder Bank, veranschaulicht als ein Registerdatei-Lese-Multiplexer 1740, und Bereitstellen einer Ausgabe über eine Reihe von Anschlüssen, veranschaulicht als P0 bis Pp, gekoppelt.
  • In einigen Ausführungsformen sorgt die Vorrichtung, das System oder der Prozess für eine Trennung der Sequenzen von Registern, die einem Thread zugewiesen sind, zwischen Registerbanken, sodass die Wahrscheinlichkeit eines Konflikts bei Operationen verringert wird. Im Gegensatz zu einer/m herkömmlichen Vorrichtung oder System, bei welcher/m die Register für einen bestimmten Thread sequentiell innerhalb einer Registerbank der mehreren Banken der Registerdatei 1700 strukturiert sind, sind die Register für einen bestimmten Thread stattdessen über die Banken von Registern hinweg verteilt. Die Verteilung der Register über die Registerbanken der Registerdatei 1700 hinweg bedeutet im Allgemeinen, dass sich, in einer Sequenz von Registern für einen Thread, jegliches erstes Register (wie z.B. R0) und ein nächstes folgendes zweites Register (wie z.B. R1) in unterschiedlichen Banken befinden.
  • Zum Beispiel wird ein Thread T0 durch Register unterstützt, die derart verteilt sind, dass sich ein erstes Register T0-R0 in einer ersten Bank 1710 befindet, ein zweites Register T0-R1 in einer zweiten Bank 1715 befindet, ein drittes Register T0-R2 in einer dritten Bank 1720 gespeichert ist, und bei Bedarf bis zur letzten Bank 1730 in der Registerdatei 1700 fortgefahren wird. Zusätzliche Register für den Thread T0 können sich dann in den Registerbanken der Registerdatei 1700 befinden, welche derart angesehen werden können, als wären sie um die Registerbanken gewickelt, um die zusätzlichen Register für einen Thread aufzunehmen. Die Register für zusätzliche Threads sind in der gleichen Art und Weise verteilt über die Banken von Registern hinweg gespeichert, sodass die Register für Thread T1 derart lokalisiert sind, dass sich ein erstes Register T1-R0 in der ersten Bank 1710 befindet, sich ein zweites Register T1-R1 in der zweiten Bank 1715 befindet, ein drittes Register T0-R2 in einer dritten Bank 1720 gespeichert ist, und bei Bedarf bis zur letzten Bank 1730 in der Registerdatei 1700 und zusätzlichen Reihen von Registern fortgefahren wird, und Register für Threads bis zu einem abschließenden Thread Tt ähnlich verteilt werden. Zur besseren Lesbarkeit sind nicht sämtliche Threads des veranschaulichten Systems gezeigt.
  • Die in 17 veranschaulichte Ausführungsform nutzt die Tatsache, dass die Chance des Lesens von Registern aus unterschiedlichen Threads zur gleichen Zeit in einem bestimmten Multithread-System, wie z.B. einer GPU-Umgebung, im Allgemeinen sehr gering ist. Die Struktur in 17 verteilt Register eines einzelnen Threads auf so viele Banken wie möglich, indem gestattet wird, dass Banken Register aus mehreren Threads beinhalten. Unter der Annahme einer Zahl von „b“ Registerbanken in einer Registerdatei und einer Zahl von „t“ Threads für eine Ausführungseinheit sind die Register eines einzelnen Threads über eine Zahl von „b/t“ Registerbanken in der herkömmlichen Struktur gegenüber einer Zahl von „b“ Registerbanken in einer Ausführungsform verteilt. In einem Multithread-System, in welchem im Allgemeinen nur ein einzelner Thread verarbeitet wird, kann dies die Wahrscheinlichkeit von Konflikten innerhalb eines Threads um das „t“-Fache verringern.
  • 18 ist eine Veranschaulichung von Mehrbank-Register-Arrays in einer Vorrichtung oder einem System, welche/s Registerverteilung über mehrere Arrays von Registerbanken in einer Registerdatei hinweg bereitstellt, gemäß einiger Ausführungsformen. In einigen Ausführungsformen sind die Banken von Registern in einer Registerdatei 1800 einer Ausführungseinheit in mehrere Arrays oder Sätze unterteilt, wie z.B. ein erstes Array von geraden Registerbanken 1805 und ein zweites Array von ungeraden Registerbanken 1855, wobei die Vorrichtung, das System oder der Prozess für eine weitere Trennung der Sequenz von Registern, die einem Thread zugewiesen sind, zwischen den Sätzen von Registerbanken sorgen, um so die Wahrscheinlichkeit von Registerbankkonflikten bei Operationen weiter zu verringern.
  • In einigen Ausführungsformen, wie in 18 veranschaulicht, beinhaltet eine Vorrichtung oder ein System eine Registerdatei mit mehreren Registerbanken, wobei die Registerbanken in ein erstes Array 1800 von geraden Registerbanken, welche als die Banken 1810 bis 1830 veranschaulicht sind, und ein zweites Array 1855 von ungeraden Registerbanken, welche als die Banken 1860 bis 1880 veranschaulicht sind, getrennt sind. Die geraden Registerbanken 1810-1830 des ersten Arrays 1805 sind mit einem Element zum Auswählen und Lesen des Inhalts von Registern jeder Bank, veranschaulicht als ein erster Registerdatei-Lese-Multiplexer 1840, und Bereitstellen einer Ausgabe über eine Reihe von Anschlüssen, veranschaulicht als P0 bis Pp, gekoppelt. Ähnlich sind die ungeraden Registerbanken 1860-1880 des zweiten Arrays 1855 mit einem Element zum Auswählen und Lesen des Inhalts von Registern jeder Bank, veranschaulicht als ein zweiter Registerdatei-Lese-Multiplexer 1890, und Bereitstellen einer Ausgabe über eine Reihe von Anschlüssen, veranschaulicht als P0 bis Pp, gekoppelt. Jedoch sind die Ausführungsformen nicht auf gerade und ungerade Register-Arrays beschränkt und können eine größere Zahl von Arrays und Arrays, in welchen sich die Register basierend auf einer unterschiedlichen Basis als gerade und ungerade Register innerhalb der Arrays befinden, beinhalten.
  • In einigen Ausführungsformen sorgt eine Vorrichtung, ein System oder ein Prozess für eine Trennung der Sequenz von Registern, die einem Thread zugewiesen sind, zwischen Registerbanken in mehrere Register-Arrays, sodass die Wahrscheinlichkeit von Registerbankkonflikten bei Operationen weiter verringert wird. Zum Beispiel wird ein Thread T0 durch Register unterstützt, die gemäß einer geraden und ungeraden Nummerierung derartiger Register über die geraden Registerbanken des ersten Arrays 1805 und die ungeraden Registerbanken des zweiten Arrays 1855 verteilt sind, sodass sich ein erstes Register T0-R0 (ein gerades Register) in einer ersten Bank 1810 des ersten Arrays 1855 befindet, sich ein zweites Register, das auf T0-R1 folgt (ein ungerades Register), in einer ersten Bank 1860 des zweiten Arrays 1855 befindet, sich ein drittes Register T0-R2 in einer zweiten Bank 1815 des ersten Arrays 1805 befindet, und bei Bedarf mit geraden und ungeraden Registern in einer oder mehreren Reihen von Registern in der geraden und ungeraden Registerbank des ersten und zweiten Arrays 1805 und 1855 fortgefahren wird. Im Allgemeinen ist zu sehen, dass sich jegliches erstes Register (wie z.B. ein gerades Register) und ein zweites folgendes Register (ein ungerades Register) in unterschiedlichen Arrays befinden und sich ferner jegliches Register in einem Satz von Registern (wie z.B. ein gerades Register, z.B. R0) und ein folgendes zweites Register (z.B. R2) in unterschiedlichen Banken innerhalb des Arrays befinden. Zusätzliche Register für den Thread T0 können dann in einer oder mehreren zusätzlichen Reihen von Registern in dem ersten und zweiten Array 1805 und 1855 gespeichert werden. Die Register für zusätzliche Threads werden in der gleichen Art und Weise verteilt über gerade und ungerade Registerbanken des ersten und zweiten Arrays 1805 und 1855 hinweg gespeichert, wie z.B. für die Register für Thread T1 (beginnend mit Register T1-R0) bis zu einem abschließenden Thread Tt (beginnend mit Register Tt-R0) veranschaulicht. Zur besseren Lesbarkeit sind nicht sämtliche Threads für die Ausführungseinheit in dem veranschaulichten System gezeigt.
  • 19 ist eine Veranschaulichung einer Pipeline mit mehreren Registerlesestufen gemäß einiger Ausführungsformen. In einer herkömmlichen Systemarchitektur versucht eine einzelne Pipeline-Stufe für Registerlesevorgänge in einer Pipeline sämtliche Quellen einer einzelnen Anweisung zur gleichen Zeit zu lesen. In einigen Ausführungsformen beinhaltet eine Systemarchitektur mehrere Pipeline-Stufen in einer Pipeline zum Lesen von Registern, wobei die mehreren Pipeline-Stufen Register für bestimmte Anweisungsoperanden lesen sollen. In einem Beispiel mit zwei Pipeline-Stufen, wie in 19 veranschaulicht, beinhaltet ein System eine erste Pipeline-Stufe zum Lesen ungerader Operanden und eine zweite Pipeline-Stufe zum Lesen gerader Operanden (oder umgekehrt). Das Aufteilen des Prozesses in zwei Pipeline-Stufen kann die Registerbankkonflikte beim Lesen von Registern erheblich verringern und ermöglicht weitere Optimierungen zur Reduzierung von Registerbankkonflikten, wie zum Beispiel in 20, 21 und 22 veranschaulicht.
  • In einigen Ausführungsformen, wie in 19 veranschaulicht, kann eine Pipeline Anweisungsabruf, Decodierung, Lesestufe 1 (für ungerade Quelloperanden), Lesestufe 2 (für gerade Quelloperanden), Ausführung und Zurückschreiben beinhalten. Weil die beiden Lesestufen zeitverschachtelt sind, gibt es keine Auswirkung auf den Gesamtdurchsatz. Bei Drei-Quellen-Anweisungen mit Operand 0, Operand 1 und Operand 2 als Quellen wird Quelloperand 1 (Scr1) in Lesestufe 1 gelesen und Quelloperand 0 (Scr0) und Quelloperand 2 (Scr2) werden in Lesestufe 2 gelesen. Bei Zwei-Quellen-Anweisungen kann Operand 1 in der ersten Stufe gelesen werden und Operand 0 kann in der zweiten Stufe gelesen werden. Bei Ein-Quellen-Anweisungen kann nichts in der ersten Stufe gelesen werden und Operand 0 kann in der zweiten Stufe gelesen werden. Unter der Annahme einer Sequenz von Zwei-Quellen-Anweisungen bei einer Ausführungsform eines Pipeline-Mechanismus kann der Quelloperand 1 zusammen mit dem Quelloperand 0 der vorhergehenden Anweisung gelesen werden. Ähnlich kann der Quelloperand 0 zusammen mit dem Quelloperand 1 der nächsten Anweisung gelesen werden.
  • In dem bestimmten in 19 veranschaulichten Beispiel wird eine erste Anweisung Inst0 mit drei Quelloperanden (Scr0, Scr1 und Scr2) in Takt 0 abgerufen, in Takt 1 decodiert, der Operand Scr1 in Takt 2 gelesen, die Operanden Scr0 und Scr2 in Takt 3 gelesen, in Takt 4 ausgeführt, um ein Ergebnis zu erzeugen, und das Ergebnis in Takt 5 zurückgeschrieben. 19 nimmt an, dass dann eine Anweisung mit drei Operanden in jedem Takt folgt, und so wird eine zweite Anweisung Inst1 mit drei Quelloperanden (Scr0, Scr1 und Scr2) in Takt 1 abgerufen, in Takt 2 decodiert, der Operand Scr1 in Takt 3 gelesen (parallel zum Lesen von Scr0 und Scr2 für Inst0), die Operanden Scr0 und Scr2 in Takt 4 gelesen, in Takt 5 ausgeführt, um ein Ergebnis zu erzeugen, und das Ergebnis in Takt 6 zurückgeschrieben. Die folgenden Anweisungen Inst2, Inst3, Inst4 und Inst5 folgen dann ähnlich in der in 19 veranschaulichten Pipeline. Jedoch ist dies nur ein Beispiel und im Betrieb kann es eine Mischung von Anweisungen mit einer variierenden Zahl von Operanden geben, wodurch variiert, welche Operanden in der ersten und zweiten Lesestufe der Pipeline gelesen werden.
  • 20 ist eine Veranschaulichung von logischen und physischen SIMD-Anweisungen, die in einem System oder einer Vorrichtung verarbeitet werden, gemäß einiger Ausführungsformen. In einigen Ausführungsformen können logische SIMD-Anweisungen in einem Multithread-System, wie z.B. einem System, das eine GPU mit einer oder mehreren Ausführungseinheiten beinhaltet, in mehrere physische Anweisungen für die Ausführungseinheiten umgewandelt werden. Aufgrund der hohen Parallelität bei 3D- und GPGPU-Anwendungen ist es üblich, dass die logische SIMD-Größe von Kerneln größer als eine tatsächliche physische SIMD-Größe von Ausführungseinheiten ist. Typischerweise kann die logische SIMD-Größe zweimal die physische SIMD-Größe betragen. Unter diesen Umständen werden SIMD-Anweisungen in Hardware aufgeteilt, damit sie mit der physischen SIMD-Breite übereinstimmen.
  • 20 veranschaulicht ein Beispiel, bei welchem eine logische SIMD-Breite 16 beträgt und die physische SIMD-Breite 8 beträgt. Weil die logischen Datenoperanden in diesem Beispiel zwei physische Register verbrauchen, kann eine logische Anweisung in zwei Hardware-Anweisungen aufgeteilt werden, wobei es sich bei den beiden Anweisungen um eine Anweisung mit allen geraden Registern und eine mit allen ungeraden Registern handelt. In einigen Ausführungsformen ist bei einer Vorrichtung oder einem System, die/das zwei Pipeline-Stufen für Registerlesevorgänge in einer Pipeline bereitstellt, die Vorrichtung oder das System in der Lage, ein gerades Register und ein ungerades Register zu lesen, die zu zwei aufeinanderfolgenden Hardware-Anweisungen in einem Zyklus gehören, anstatt entweder alle geraden oder alle ungeraden Register in einem Zyklus zu lesen.
  • Zum Beispiel resultiert, wie in 20 veranschaulicht, das Aufteilen der Anweisung ,ADD (16) R20 R16 R18' (die sich auf das Zielregister R20 und die Quellregister R16 und R18 bezieht) in einer ersten Anweisung ,ADD (8) R20 R16 R18' und einer zweiten Anweisung ,ADD (8) R21 R17 R19'. Die aufgeteilten Anweisungen können dann mit zwei Lesestufen in der Verarbeitungs-Pipeline verarbeitet werden, wie z.B. in 19 veranschaulicht. In diesem Szenarium gibt es keine Möglichkeit für Bankkonflikte, da gerade Banken und ungerade Banken keine Anschlüsse gemeinsam nutzen, wie in 18 veranschaulicht, wobei das Array von geraden Registerbanken die Anschlüsse des ersten Registerdatei-Lese-Multiplexers 1840 nutzt und das Array von ungeraden Registerbanken den zweiten Registerdatei-Lese-Multiplexer 1890 nutzt. Wie in 20 gezeigt, kann in einem ersten Taktzyklus R16 der ersten Anweisung gelesen werden und R18 der ersten Anweisung und R17 der zweiten Anweisung werden in einem zweiten Taktzyklus gelesen. Der Prozess fährt dann mit den Quelloperanden jeder der folgenden Anweisungen fort, wobei das Aufteilen der Anweisung ,MUL (16) R40 R36 R38' in einer dritten Anweisung ,MUL (8) R40 R36 R38' und einer vierten Anweisung ,MUL (8) R41 R37 R39' resultiert und das Aufteilen der Anweisung ,ADD (16) R60 R56 R58' in einer fünften Anweisung ,ADD (8) R60 R56 R58' und einer sechsten Anweisung ,ADD (8) R61 R57 R59' resultiert.
  • Ausführungsformen einer Vorrichtung, eines Systems oder eines Prozesses können die theoretischen Registerbankkonflikt-Verhältnisse sowohl für Zwei-Quellen- als auch Drei-Quellen-Anweisungen verringern. Berechnet für einen einzelnen Thread unter der Annahme einer gleichmäßigen Registerverteilung und ohne Skalare in den Anweisungen, können EUs in einer bestimmten Architektur 128 Register pro Thread aufweisen, die über gerade und ungerade Registerbanken hinweg verteilt sind. In einem Beispiel, in welchem zwei Anschlüsse für gerade Banken und zwei Anschlüsse für ungerade Registerbanken vorliegen, sind in einer herkömmlichen Registerstruktur die 128 Register eines einzelnen Threads über 2 gerade und 2 ungerade Registerbanken hinweg verteilt, was in einer Registerbank mit 32 Registern aus dem gleichen Thread resultiert. Dieses Beispiel resultiert in einem theoretischen Registerbankkonflikt-Verhältnis von 24,21 % (31/128) für Zwei-Quellen-Anweisungen und 48,43 % (31/128 + 31/128) für Drei-Quellen-Anweisungen. In einigen Ausführungsformen verteilt eine Registerstruktur die Register über 8 gerade und 8 ungerade Registerbanken hinweg, was in einer Registerbank resultiert, die stattdessen nur 8 Register aus dem gleichen Thread aufweist. Dies verringert das theoretische Registerbankkonflikt-Verhältnis dann auf 5,47 % (7/128) für Zwei-Quellen-Anweisungen und 29,4 % (7/128 * 6/128 + 120/128 * 7/128 * 2 + 7/64 * 7/64) für Drei-Quellen-Anweisungen.
  • In einigen Ausführungsformen können die Registerbankkonflikt-Verhältnisse dann für SIMD(16)-Kernel weiter verringert werden, und zwar aufgrund der Ermöglichung eines zweistufigen Lesemechanismus. Dies geschieht dadurch, dass nahezu sämtliche Quelloperanden von SIMD(16)-FPU-Anweisungen zwei Register belegen und der Compiler die gleichmäßig ausgerichteten Register sämtlichen Operanden zuweisen kann, ohne jegliches Fragmentierungsproblem zu verursachen. Gleichmäßig ausgerichtete Quelloperanden (mit Größe 2) und der zweistufige Lesemechanismus garantieren den Zugriff sowohl gerader als auch ungerader Sätze, wodurch das theoretische Registerbankkonflikt-Verhältnis für Zwei-Quellen-Anweisungen auf Null und für Drei-Quellen-Anweisungen auf 5,47 % (7/128) verringert wird.
  • 21 ist eine Veranschaulichung des Tauschens von Operandenpositionen für eine Zwei-Quellen-Anweisung gemäß einiger Ausführungsformen. 22 ist eine Veranschaulichung des Tauschens von Operandenpositionen für eine Drei-Quellen-Anweisung gemäß einiger Ausführungsformen. In einigen Ausführungsformen sorgt eine Vorrichtung, ein System oder ein Prozess durch den Operandenpositionstausch für eine weitere Reduzierung in der Konfliktwahrscheinlichkeit. Eine Optimierung mittels Operandenpositionstausch kann in einer Architektur, die einen Zweistufen-Registerlesemechanismus in Hardware bereitstellt, unter Ausnutzung der Tatsache, dass die meisten der Zwei-Quellen-Anweisungen (MUL, ADD, MAC usw.) ungeachtet ihrer Operandenpositionen ein gleiches Ergebnis erzeugen, implementiert werden. In einigen Ausführungsformen kann eine Vorrichtung, ein System oder ein Prozess diese Tatsache ausnutzen, wobei ein Element, wie z.B. der Compiler, Operanden einer Anweisung tauscht, für welche es aufgrund des Zweistufen-Lesemechanismus einen Registerbankkonflikt mit der folgenden Anweisung erkennt. Auf diese Weise können Registerbankkonflikt-Bedingungen vermieden werden, wenn die Operanden keinen Registerbankkonflikt erzeugen, wenn sie sich an getauschten Positionen befinden.
  • Zur weiteren Veranschaulichung können Register eines einzelnen Threads über 16 Registerbanken in einer Registerdatei einer bestimmten EU hinweg verteilt sein, was zum Beispiel darin resultiert, dass sich R0, R16 und R32 in einer gleichen Bank befinden. Das Zugreifen auf jegliche zwei dieser Register im gleichen Taktzyklus verursacht somit einen Registerlesekonflikt.
  • 21 veranschaulicht ein Beispiel einer Anweisungssequenz, welche die erste Anweisung ,ADD (8) R2 R1 R0', die das Lesen der Quelloperanden R1 und R0 erfordert, und eine nächste folgende zweite Anweisung ,MUL (8) R3 R16 R4', die das Lesen der Quelloperanden R16 und R4 erfordert, beinhaltet. Wie in 21 gezeigt, würden derartige Anweisungen herkömmlicherweise in einem Registerbankkonflikt in einem zweiten Taktzyklus zwischen dem Lesen von R0 und R16 resultieren, wodurch 4 Taktzyklen für das Lesen der Quellregister für die beiden Anweisungen erforderlich wären.
  • In einigen Ausführungsformen sollen bei Erkennung eines Konflikts zwischen R0 und R16 die Quelloperandenpositionen der zweiten Anweisung getauscht werden. Dadurch wird das Register-Paar, das in einem gleichen Zyklus gelesen werden soll, <R0,R4> anstatt <R0,R16>. Auf diese Weise wird der Registerbankkonflikt vermieden und die Zahl von Taktzyklen, die für den Leseprozess erforderlich sind, wird auf 3 verringert.
  • In einigen Ausführungsformen kann der Parameterpositionstausch bei Erkennung eines Registerbankkonflikts auch bei einer Drei-Quellen-Anweisung angewandt werden. Zum Beispiel kann der Tauschprozess für eine MAD-Anweisung (wobei Dst = Src0 + Src1 * Src2) angewandt werden, indem Src1 in einer ersten Lesestufe und Src0 und Src2 in einer zweiten Lesestufe gelesen werden. In einigen Ausführungsformen soll ein System, eine Vorrichtung oder ein Prozess sowohl Konflikte zwischen Src0 und Src2 einer aktuellen Anweisung als auch Konflikte mit dem Src1 der nächsten Anweisung erkennen. Die Quelloperandenpositionen können zwischen Src1 und Src2 getauscht werden, um einen Registerbankkonflikt zu vermeiden, ohne jeglichen Funktionsunterschied. In einigen Ausführungsformen werden, wenn nach dem Tauschen der Operanden Scr1 und Scr2 noch immer ein Konflikt mit der nächsten Anweisung vorliegt, auch die Operanden für die nächste folgende Anweisung getauscht, um den Registerbankkonflikt zu vermeiden.
  • 22 veranschaulicht ein Beispiel einer Anweisungssequenz, welche die erste Anweisung ,MAD (8) R4 R0 R1 R16', die das Lesen der Quelloperanden R0, R1 und R16 erfordert, und eine nächste folgende zweite Anweisung ,MAD (8) R5 R2 R32 R3', die das Lesen der Quelloperanden R2, R32 und R3 erfordert, beinhaltet. Wie in 22 gezeigt, würden derartige Anweisungen herkömmlicherweise in einem Registerbankkonflikt in einem zweiten Taktzyklus zwischen dem Lesen von R0 und R16 der ersten Anweisung und dann im dritten Zyklus zwischen R16 der ersten Anweisung und R32 der zweiten Anweisung resultieren, wodurch 5 Taktzyklen für das Lesen der Quellregister für die beiden Anweisungen erforderlich wären.
  • In einigen Ausführungsformen sollen bei Erkennung eines Konflikts zwischen R0 und R16 die Quelloperandenpositionen der ersten Anweisung getauscht werden und bei Erkennung des Registerbankkonflikts, der durch R16 und R32 erzeugt werden würde, die Quelloperandenpositionen der zweiten Anweisung getauscht werden. Dadurch werden die Register, die in einem gleichen Zyklus gelesen werden sollen, <R0,R1,R3> und <R2,R32>. Auf diese Weise werden beide Registerbankkonflikte vermieden und die Zahl von Taktzyklen, die für den Leseprozess erforderlich sind, wird auf 3 verringert.
  • In einigen Ausführungsformen kann ein Tauschalgorithmus mit minimaler Verarbeitung implementiert werden. Der Algorithmus erfordert einen einzelnen Abtastdurchlauf zum Prüfen auf Registerbankkonflikt-Bedingungen und zum entsprechenden Tauschen von Quelloperanden zur Vermeidung der Registerbankkonflikte, wenn dies möglich ist. Zum Beispiel kann dieser Durchlauf in einem Compiler nach dem Registerzuteilungs- und dem Anweisungszeitplanungs-Durchlauf, wenn die Operandenregister nicht mehr weiter verändert werden, angeordnet sein. Verglichen mit herkömmlichen Lösungen ist der Operandentausch-Durchlauf viel weniger teuer und sauberer zu implementieren.
  • Ferner verringert der Operandenpositionstausch Bankkonflikte sehr effizient. Etwa 95 % der Registerbankkonflikte stammen aus den Quelloperanden von „MAD“-, „MUL“-, „MAC“- und „ADD“-Anweisungen, deren Quelloperandenpositionen ohne Beeinträchtigung des Ergebnisses getauscht werden können. Die folgenden theoretischen Registerbankkonflikt-Verhältnisse wurden ohne Berücksichtigung der Auswirkung auf die nächste Anweisung im Kernel berechnet, obwohl es selbst in diesem Fall möglich ist, das Tauschen zu vermeiden und das gleiche Registerbankkonflikt-Verhältnis wie zuvor beizubehalten: ein Operandentausch kann das theoretische Registerbankkonflikt-Verhältnis auf 0,299 % (5,47 % * 5,47 %) für SIMD8-Zwei-Quellen-Anweisungen und SIMD16-Drei-Quellen-Anweisungen verringern. Bei Drei-Quellen-SIMD8-Anweisungen verringert der Tausch das Registerbankkonflikt-Verhältnis auf 8,64 % (29,4 % * 29,4 %).
  • 23 ist ein Flussdiagramm zur Veranschaulichung eines Prozesses zum Tauschen von Operandenpositionen zur Reduzierung von Registerbankkonflikten gemäß einiger Ausführungsformen. In einem Prozess, wie z.B. in einem Compiler oder bei einer anderen Verarbeitung, werden Anweisungen, die durch eine Ausführungseinheit (EU) verarbeitet werden sollen, empfangen 2302, wobei die EU mehrere Threads verarbeiten soll. Die EU kann eine EU in einem Verarbeitungssystem beinhalten, das eine oder mehrere GPUs beinhaltet, wie in 15 veranschaulicht. In einigen Ausführungsformen werden Register für die mehreren Threads für die EU über mehrere Arrays von Registerbanken in einer Registerdatei hinweg verteilt, wie z.B. die in 18 veranschaulichten geraden und ungeraden Register-Arrays. In einigen Ausführungsformen beinhaltet die EU eine Pipeline, die zwei Lesestufen beinhaltet, wie z.B. in 19 veranschaulicht.
  • In dem Prozess werden die Anweisungen analysiert, um Registerbankkonflikte zu erkennen 2304, wobei zum Beispiel ein Zähler für die Anweisungen anfänglich auf N=0 eingestellt ist. In einigen Ausführungsformen wird die Analyse zum Zweck einer, wenn möglich, Verhinderung derartiger Konflikte durch das Tauschen von Operandenpositionen, wie z.B. in 21 und 22 veranschaulicht, bereitgestellt. Obwohl in 23 nicht gezeigt, können, wenn Konflikte nicht durch das Tauschen von Operandenpositionen verhindert werden können, normale Operationen, wie z.B. eine Verzögerung des Lesens bestimmter Operanden in der Pipeline zur Vermeidung von Registerbankkonflikten, implementiert werden.
  • In einigen Ausführungsformen beinhaltet der Prozess das Analysieren der Quelloperanden einer aktuellen Anweisung Inst(N) und einer nächsten folgenden Anweisung Inst(N+1) 2306, wie z.B. zunächst einer ersten Anweisung Inst(0) und einer zweiten Anweisung Inst(1). Es wird bestimmt, ob die Zahl von Quelloperanden für Inst(N) zwei oder drei ist 2308. Mit einem Zweistufen-Lesemechanismus in der Pipeline, der Zugriff sowohl auf gerade als auch ungerade Register-Arrays garantiert, ist die Wahrscheinlichkeit eines Registerbankkonflikts innerhalb einer Zwei-Quellen-Anweisung Null und kann somit übersprungen werden.
  • Wenn Inst(N) eine Drei-Quellen-Anweisung (Quellenanweisungen Scr0, Scr1 und Scr2) ist, erfolgt eine Bestimmung, ob ein Registerbankkonflikt vorliegt, der zwischen Operanden innerhalb von Inst(N) erzeugt wird 2310, wobei es sich um einen Registerbankkonflikt zwischen den Registern für Scr0 und Scr2 handeln würde. Wenn ein Registerbankkonflikt erzeugt werden würde, können die Positionen der Operanden Scr1 und Scr2 getauscht werden 2312, wie z.B. bei dem Tausch zwischen den Positionen von R1 und R16 in 22 veranschaulicht.
  • Im Anschluss an den Tausch von Operanden 2312, oder wenn kein Konflikt innerhalb der Drei-Quellen-Anweisung vorliegt 2310, oder wenn die Inst(N) eine Zwei-Quellen-Anweisung ist 2308, erfolgt eine Bestimmung, ob ein Registerbankkonflikt durch die Register für Inst(N) und Inst(N+1) erzeugt werden würde 2314. Wenn dem so ist, erfolgt ein Tausch von Operandenpositionen in Inst(N+1) 2316, wie z.B. bei dem Tausch der Positionen von R16 und R4 in 21 oder dem Tausch der Positionen von R32 und R3 in 22 veranschaulicht.
  • In dem Prozess erfolgt dann eine Bestimmung, ob eine weitere folgende Anweisung Inst(N+2) vorliegt 2318. Wenn dem so ist, kann der Zähler inkrementiert werden, N=N+1, 2320, und der Prozess kehrt zum Analysieren der Operationen von Inst(N) und Inst(N+1) zurück 2306. Wenn dem nicht so ist, ist der Prozess abgeschlossen 2322.
  • In einigen Ausführungsformen beinhaltet eine Vorrichtung einen Prozessor, der eine oder mehrere Ausführungseinheiten (EUs) beinhaltet, wobei die eine oder die mehreren EUs mindestens eine erste Ausführungseinheit (EU) zum Verarbeiten mehrerer Threads beinhalten, wobei die erste EU eine Registerdatei, die mehrere Registerbanken beinhaltet, wobei jede Registerbank mehrere Register beinhaltet, und einen oder mehrere Lese-Multiplexer zum Lesen von Registern aus der Registerdatei, wobei der Versuch, mehr als ein Register aus einer einzelnen Registerbank der Registerdatei in einem gleichen Taktzyklus zu lesen, einen Registerbankkonflikt erzeugt, beinhaltet. Die Register für jeden Thread für die erste EU sind derart über die Registerbanken innerhalb der Registerdatei hinweg verteilt, dass sich ein erstes Register für einen ersten Thread der mehreren Threads und ein folgendes zweites Register für den ersten Thread in unterschiedlichen Registerbanken innerhalb der Registerdatei befinden.
  • In einigen Ausführungsformen beinhaltet die Registerdatei mehrere Arrays von Registerbanken, wobei die mehreren Arrays ein erstes Array von Registerbanken und ein zweites Array von Registerbanken beinhalten, und wobei die Register für jeden Thread derart verteilt sind, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  • In einigen Ausführungsformen ist ein erster Lese-Multiplexer mit den Registerbanken des ersten Arrays von Registerbanken gekoppelt und ein zweiter Lese-Multiplexer ist mit den Registerbanken des zweiten Arrays von Registerbanken gekoppelt.
  • In einigen Ausführungsformen soll die Vorrichtung jede von einer oder mehreren logischen SIMD (Single Instruction Multiple Data) -Anweisungen in mehrere physische SIMD-Anweisungen für die erste EU aufteilen.
  • In einigen Ausführungsformen beinhaltet die erste EU ferner eine oder mehrere Verarbeitungs-Pipelines für SIMD (Single Instruction Multiple Data) - Anweisungen, wobei eine erste Verarbeitungs-Pipeline der einen oder der mehreren Verarbeitungs-Pipelines mehrere Stufen zum Lesen von Registern beinhaltet, wobei die mehreren Stufen eine erste Lesestufe zum Lesen eines oder mehrerer Register in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen eines oder mehrerer Register in einem zweiten Taktzyklus beinhalten.
  • In einigen Ausführungsformen soll die Vorrichtung bestimmen, ob Quelloperanden einer ersten Anweisung einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, soll die Vorrichtung Positionen von zwei Quelloperanden der ersten Anweisung tauschen, um den Registerbankkonflikt zu vermeiden.
  • In einigen Ausführungsformen soll die Vorrichtung bestimmen, ob ein oder mehrere Quelloperanden der ersten Anweisung und ein oder mehrere Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung und die Quelloperanden der zweiten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, soll die Vorrichtung Positionen von zwei Quelloperanden der zweiten Anweisung tauschen, um den Registerbankkonflikt zu vermeiden.
  • In einigen Ausführungsformen ist die eine oder sind die mehreren EUs in einer grafischen Verarbeitungseinheit (GPU) enthalten.
  • Bei einigen Ausführungsformen handelt es sich um ein nichttransitorisches computerlesbares Speichermedium, auf welchem Daten gespeichert sind, die Sequenzen von Anweisungen darstellen, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zum Durchführen von Operationen veranlassen, welche das Empfangen mehrerer SIMD (Single Instruction Multiple Data) -Anweisungen zur Verarbeitung für eine Ausführungseinheit (EU) in einem Verarbeitungssystem, wobei die EU eine Registerdatei mit mehreren Arrays von Registerbanken beinhaltet, wobei die mehreren Arrays von Registerbanken ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register beinhalten, und eine Verarbeitungs-Pipeline beinhaltet, wobei die Verarbeitungs-Pipeline mehrere Stufen zum Lesen von Registern beinhaltet, das Analysieren von Quelloperanden der mehreren SIMD-Anweisungen, um zu identifizieren, ob ein oder mehrere Registerbankkonflikte auftreten werden, wenn Quelloperanden von einer oder mehreren Anweisungen in einem gleichen Taktzyklus gelesen werden, und beim Bestimmen, dass ein oder mehrere Registerbankkonflikte auftreten werden, das Tauschen von Positionen von Quelloperanden innerhalb einer oder mehrerer der mehreren SIMD-Anweisungen, um den einen oder die mehreren Registerbankkonflikte zu vermeiden, beinhalten.
  • In einigen Ausführungsformen beinhaltet das Analysieren von Operanden der mehreren SIMD-Anweisungen das Analysieren von Quelloperanden einer ersten Anweisung, um zu bestimmen, ob das gemeinsame Lesen mehrerer Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus einen Registerbankkonflikt erzeugen wird, wobei die erste Anweisung drei Quelloperanden beinhaltet.
  • In einigen Ausführungsformen beinhaltet das Tauschen von Positionen von Quelloperanden das Tauschen von Positionen eines ersten Quelloperanden und eines zweiten Quelloperanden der ersten Anweisung.
  • In einigen Ausführungsformen beinhaltet das Analysieren von Operanden der mehreren SIMD-Anweisungen das Analysieren von Quelloperanden einer ersten Anweisung und von Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, um zu bestimmen, ob das Lesen von einem oder mehreren Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus mit einem oder mehreren Quelloperanden der zweiten Anweisung einen Registerbankkonflikt erzeugen wird, wobei die zweite Anweisung mehrere Quelloperanden beinhaltet.
  • In einigen Ausführungsformen beinhaltet das Tauschen von Positionen von Quelloperanden das Tauschen von Positionen von einem ersten Quelloperanden und einem zweiten Quelloperanden der zweiten Anweisung.
  • In einigen Ausführungsformen sind die Register für jeden von mehreren Threads für die EU derart über die mehreren Arrays von Registerbanken hinweg verteilt, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  • In einigen Ausführungsformen ist ein erster Lese-Multiplexer mit den Registerbanken des ersten Arrays von Registerbanken gekoppelt und ein zweiter Lese-Multiplexer ist mit den Registerbanken des zweiten Arrays von Registerbanken gekoppelt.
  • In einigen Ausführungsformen beinhalten die mehreren Stufen eine erste Lesestufe zum Lesen von einem oder mehreren Registern in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen von einem oder mehreren Registern in einem zweiten Taktzyklus.
  • In einigen Ausführungsformen beinhalten die Anweisungen ferner Anweisungen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zum Durchführen von Operationen veranlassen, die das Aufteilen von jeder von einer oder mehreren logischen SIMD-Anweisungen in mehrere physische SIMD-Anweisungen beinhalten.
  • In einigen Ausführungsformen ist die EU in einer grafischen Verarbeitungseinheit (GPU) enthalten.
  • In einigen Ausführungsformen beinhaltet eine Vorrichtung ein Mittel zum Empfangen mehrerer SIMD (Single Instruction Multiple Data) -Anweisungen zur Verarbeitung für eine Ausführungseinheit (EU) in einem Verarbeitungssystem, wobei die EU eine Registerdatei mit mehreren Arrays von Registerbanken beinhaltet, wobei die mehreren Arrays von Registerdateien ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register beinhalten, und eine Verarbeitungs-Pipeline beinhaltet, wobei die Verarbeitungs-Pipeline mehrere Stufen zum Lesen von Registern beinhaltet, ein Mittel zum Analysieren von Quelloperanden der mehreren SIMD-Anweisungen, um zu identifizieren, ob ein oder mehrere Registerbankkonflikte auftreten werden, wenn Quelloperanden von einer oder mehreren Anweisungen in einem gleichen Taktzyklus gelesen werden, und ein Mittel zum Tauschen von Positionen von Quelloperanden innerhalb von einer oder mehreren der mehreren SIMD-Anweisungen zur Vermeidung des einen oder der mehreren Registerbankkonflikte beim Bestimmen, dass ein oder mehrere Registerbankkonflikte auftreten werden.
  • In einigen Ausführungsformen beinhaltet das Mittel zum Analysieren von Operanden der mehreren SIMD-Anweisungen ein Mittel zum Analysieren von Quelloperanden einer ersten Anweisung, um zu bestimmen, ob das gemeinsame Lesen mehrerer Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus einen Registerbankkonflikt erzeugen wird, wobei die erste Anweisung drei Quelloperanden beinhaltet.
  • In einigen Ausführungsformen beinhaltet das Mittel zum Tauschen von Positionen von Quelloperanden ein Mittel zum Tauschen von Positionen eines ersten Quelloperanden und eines zweiten Quelloperanden der ersten Anweisung.
  • In einigen Ausführungsformen beinhaltet das Mittel zum Analysieren von Operanden der mehreren SIMD-Anweisungen ein Mittel zum Analysieren von Quelloperanden einer ersten Anweisung und von Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, um zu bestimmen, ob das Lesen von einem oder mehreren Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus mit einem oder mehreren Quelloperanden der zweiten Anweisung einen Registerbankkonflikt erzeugen wird, wobei die zweite Anweisung mehrere Quelloperanden beinhaltet.
  • In einigen Ausführungsformen beinhaltet das Mittel zum Tauschen von Positionen von Quelloperanden ein Mittel zum Tauschen von Positionen von einem ersten Quelloperanden und einem zweiten Quelloperanden der zweiten Anweisung.
  • In einigen Ausführungsformen sind die Register für jeden von mehreren Threads für die EU derart über die mehreren Arrays von Registerbanken hinweg verteilt, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  • In einigen Ausführungsformen ist ein erster Lese-Multiplexer mit den Registerbanken des ersten Arrays von Registerbanken gekoppelt und ein zweiter Lese-Multiplexer ist mit den Registerbanken des zweiten Arrays von Registerbanken gekoppelt.
  • In einigen Ausführungsformen beinhalten die mehreren Stufen eine erste Lesestufe zum Lesen von einem oder mehreren Registern in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen von einem oder mehreren Registern in einem zweiten Taktzyklus.
  • In einigen Ausführungsformen beinhaltet die Vorrichtung ferner ein Mittel zum Aufteilen von jeder von einer oder mehreren logischen SIMD-Anweisungen in mehrere physische SIMD-Anweisungen.
  • In einigen Ausführungsformen ist die eine oder sind die mehreren EUs in einer grafischen Verarbeitungseinheit (GPU) enthalten.
  • In einigen Ausführungsformen beinhaltet ein Verfahren das Empfangen von mehreren SIMD (Single Instruction Multiple Data) -Anweisungen zur Verarbeitung für eine Ausführungseinheit (EU) in einem Verarbeitungssystem, wobei die EU eine Registerdatei mit mehreren Arrays von Registerbanken beinhaltet, wobei die mehreren Arrays von Registerdateien ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register beinhalten, und eine Verarbeitungs-Pipeline beinhaltet, wobei die Verarbeitungs-Pipeline mehrere Stufen zum Lesen von Registern beinhaltet, das Analysieren von Quelloperanden der mehreren SIMD-Anweisungen, um zu identifizieren, ob ein oder mehrere Registerbankkonflikte auftreten werden, wenn Quelloperanden von einer oder mehreren Anweisungen in einem gleichen Taktzyklus gelesen werden, und beim Bestimmen, dass ein oder mehrere Registerbankkonflikte auftreten werden, das Tauschen von Positionen von Quelloperanden innerhalb einer oder mehrerer der mehreren SIMD-Anweisungen, um den einen oder die mehreren Registerbankkonflikte zu vermeiden.
  • In einigen Ausführungsformen beinhaltet das Analysieren von Operanden der mehreren SIMD-Anweisungen das Analysieren von Quelloperanden einer ersten Anweisung, um zu bestimmen, ob das gemeinsame Lesen mehrerer Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus einen Registerbankkonflikt erzeugen wird, wobei die erste Anweisung drei Quelloperanden beinhaltet.
  • In einigen Ausführungsformen beinhaltet das Tauschen von Positionen von Quelloperanden das Tauschen von Positionen eines ersten Quelloperanden und eines zweiten Quelloperanden der ersten Anweisung.
  • In einigen Ausführungsformen beinhaltet das Analysieren von Operanden der mehreren SIMD-Anweisungen das Analysieren von Quelloperanden einer ersten Anweisung und von Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, um zu bestimmen, ob das Lesen von einem oder mehreren Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus mit einem oder mehreren Quelloperanden der zweiten Anweisung einen Registerbankkonflikt erzeugen wird, wobei die zweite Anweisung mehrere Quelloperanden beinhaltet.
  • In einigen Ausführungsformen beinhaltet das Tauschen von Positionen von Quelloperanden das Tauschen von Positionen von einem ersten Quelloperanden und einem zweiten Quelloperanden der zweiten Anweisung.
  • In einigen Ausführungsformen sind die Register für jeden von mehreren Threads für die EU derart über die mehreren Arrays von Registerbanken hinweg verteilt, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  • In einigen Ausführungsformen ist ein erster Lese-Multiplexer mit den Registerbanken des ersten Arrays von Registerbanken gekoppelt und ein zweiter Lese-Multiplexer ist mit den Registerbanken des zweiten Arrays von Registerbanken gekoppelt.
  • In einigen Ausführungsformen beinhalten die mehreren Stufen eine erste Lesestufe zum Lesen von einem oder mehreren Registern in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen von einem oder mehreren Registern in einem zweiten Taktzyklus.
  • In einigen Ausführungsformen beinhaltet das Verfahren ferner das Aufteilen von jeder von einer oder mehreren logischen SIMD-Anweisungen in mehrere physische SIMD-Anweisungen.
  • In einigen Ausführungsformen ist die eine oder sind die mehreren EUs in einer grafischen Verarbeitungseinheit (GPU) enthalten.
  • In einigen Ausführungsformen beinhaltet ein Verarbeitungssystem eine oder mehrere grafische Verarbeitungseinheiten (GPUs), wobei mindestens eine der einen oder der mehreren GPUs mehrere Ausführungseinheiten (EUs) beinhaltet, wobei die mehreren EUs mindestens eine erste EU zum Verarbeiten mehrerer Threads beinhalten, wobei das Verarbeiten eines Threads das Verarbeiten von SIMD (Single Instruction Multiple Data) -Anweisungen beinhaltet, wobei die erste EU eine Registerdatei mit mehreren Arrays von Registerbanken beinhaltet, wobei jedes der mehreren Arrays mehrere Registerbanken beinhaltet, wobei jede Registerbank mehrere Register beinhaltet, wobei die mehreren Arrays von Registerbanken ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register beinhalten, und einen ersten Lese-Multiplexer zum Lesen von Registern aus dem ersten Array von Registerbanken und einen zweiten Lese-Multiplexer zum Lesen von Registern aus dem zweiten Array von Registerbanken beinhaltet, wobei der Versuch, mehr als ein Register aus einer einzelnen Registerbank der Registerdatei in einem gleichen Taktzyklus zu lesen, einen Registerbankkonflikt erzeugt, und einen Speicher zum Speichern von Daten zur Grafikverarbeitung beinhaltet. Die Register für jeden Thread für die erste EU sind derart über die Registerbanken innerhalb der mehreren Arrays hinweg verteilt, dass sich ein erstes Register für einen Thread und ein folgendes zweites Register für den Thread innerhalb eines Arrays von Registerbanken in unterschiedlichen Registerbanken befinden und wobei die Register für jeden Thread derart verteilt sind, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  • In einigen Ausführungsformen soll das Verarbeitungssystem jede von einer oder mehreren logischen SIMD-Anweisungen in mehrere physische SIMD-Anweisungen für die erste EU aufteilen.
  • In einigen Ausführungsformen beinhaltet die erste EU ferner eine oder mehrere Verarbeitungs-Pipelines für SIMD-Anweisungen, wobei eine erste Verarbeitungs-Pipeline der einen oder der mehreren Verarbeitungs-Pipelines mehrere Stufen zum Lesen von Registern beinhaltet, wobei die mehreren Stufen eine erste Lesestufe zum Lesen eines oder mehrerer Register in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen eines oder mehrerer Register in einem zweiten Taktzyklus beinhalten.
  • In einigen Ausführungsformen soll das Verarbeitungssystem bestimmen, ob Quelloperanden einer ersten Anweisung einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, soll das Verarbeitungssystem Positionen von zwei Quelloperanden der ersten Anweisung tauschen, um den Registerbankkonflikt zu vermeiden.
  • In einigen Ausführungsformen soll das Verarbeitungssystem bestimmen, ob ein oder mehrere Quelloperanden der ersten Anweisung und ein oder mehrere Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung und die Quelloperanden der zweiten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, soll das Verarbeitungssystem Positionen von zwei Quelloperanden der zweiten Anweisung tauschen, um den Registerbankkonflikt zu vermeiden.
  • In der Beschreibung oben sind zum Zweck der Erläuterung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der beschriebenen Ausführungsformen bereitzustellen. Es wird einem Fachmann auf dem Gebiet jedoch offensichtlich sein, dass Ausführungsformen auch ohne einige dieser spezifischen Details in der Praxis umgesetzt werden können. In anderen Fällen sind gut bekannte Strukturen und Geräte in Form von Blockdiagrammen gezeigt. Es können Zwischenstrukturen zwischen den veranschaulichten Komponenten vorliegen. Die hierin beschriebenen und veranschaulichten Komponenten können zusätzliche Eingänge oder Ausgänge aufweisen, die nicht veranschaulicht oder beschrieben sind.
  • Verschiedene Ausführungsformen können verschiedene Prozesse beinhalten. Diese Prozesse können durch Hardware-Komponenten durchgeführt werden oder können in Computerprogramm- oder maschinenausführbaren Anweisungen verkörpert sein, welche verwendet werden können, um einen Universal- oder Spezialprozessor oder Logikschaltungen, die mit den Anweisungen programmiert sind, zu veranlassen, die Prozesse durchzuführen. Alternativ dazu können die Prozesse durch eine Kombination aus Hardware und Software durchgeführt werden.
  • Abschnitte verschiedener Ausführungsformen können als ein Computerprogrammprodukt bereitgestellt sein, welches ein computerlesbares Medium mit darauf gespeicherten Computerprogrammanweisungen beinhalten kann, die zum Programmieren eines Computers (oder anderer elektronischer Geräte) zur Ausführung durch einen oder mehrere Prozessoren zum Durchführen eines Prozesses gemäß bestimmter Ausführungsformen verwendet werden können. Das computerlesbare Medium kann Magnetplatten, optische Platten, Nur-Lese-Speicher (ROM - Read-Only Memory), Direktzugriffsspeicher (RAM - Random-Access Memory), löschbaren programmierbaren Nur-Lese-Speicher (EPROM - Erasable Programmable Read-Only Memory), elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM - Electrically-Erasable Programmable Read-Only Memory), magnetische oder optische Karten, Flashspeicher oder eine andere Art eines computerlesbaren Mediums, das zum Speichern elektronischer Anweisungen geeignet ist, beinhalten, jedoch nicht darauf beschränkt. Darüber hinaus können Ausführungsformen auch als ein Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem entfernten Computer an einen anfordernden Computer übertragen werden kann. In einigen Ausführungsformen weist ein nichttransitorisches computerlesbares Speichermedium darauf gespeicherte Daten auf, welche Sequenzen von Anweisungen darstellen, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor zum Durchführen bestimmter Operationen veranlassen.
  • Viele der Verfahren sind in ihrer einfachsten Form beschrieben, jedoch können zu jedem der Verfahren Prozesse hinzugefügt werden oder daraus gelöscht werden und es können Informationen zu jeder der beschriebenen Nachrichten hinzugefügt werden oder davon abgezogen werden, ohne sich vom grundlegenden Umfang der vorliegenden Ausführungsformen zu entfernen. Dem Fachmann auf dem Gebiet wird offensichtlich sein, dass viele weitere Modifikationen und Anpassungen vorgenommen werden können. Die bestimmten Ausführungsformen sind nicht zur Einschränkung des Konzepts, sondern zu dessen Veranschaulichung bereitgestellt. Der Umfang der Ausführungsformen soll nicht durch die oben bereitgestellten spezifischen Beispiele bestimmt werden, sondern lediglich durch die Ansprüche unten.
  • Wenn angegeben wird, dass ein Element „A“ an ein oder mit einem Element „B“ gekoppelt ist, kann das Element A direkt an das Element B gekoppelt sein oder es kann zum Beispiel durch ein Element C gekoppelt sein. Wenn die Spezifikation oder die Ansprüche angeben, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder eine Eigenschaft A eine Komponente, ein Merkmal, eine Struktur, einen Prozess oder eine Eigenschaft B „veranlasst“, bedeutet das, dass „A“ zumindest eine teilweise Ursache von „B“ ist, aber dass auch mindestens ein/e andere/s/r Komponente, Merkmal, Struktur, Prozess oder Eigenschaft vorliegen kann, die/das/der beim Veranlassen von „B“ hilft. Wenn die Spezifikation angibt, dass eine Komponente, ein Merkmal, eine Struktur, ein Prozess oder eine Eigenschaft enthalten sein „kann“ oder „könnte“, muss diese/s/r bestimmte Komponente, Merkmal, Struktur, Prozess oder Eigenschaft nicht notwendigerweise enthalten sein. Wenn sich die Spezifikation oder die Ansprüche auf „ein“ Element beziehen, bedeutet dies nicht, dass nur eines der beschriebenen Elemente vorliegt.
  • Eine Ausführungsform ist eine Implementierung oder ein Beispiel. Ein Verweis in der Spezifikation auf „eine Ausführungsform“, „einige Ausführungsformen“ oder „andere Ausführungsformen“ bedeutet, dass ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft, das/die in Verbindung mit der Ausführungsformen beschrieben ist, mindestens in einigen Ausführungsformen, jedoch nicht notwendigerweise in allen Ausführungsformen enthalten ist. Das verschiedene Auftreten von „eine Ausführungsform“ oder „einige Ausführungsformen“ bezieht sich nicht notwendigerweise immer auf die gleichen Ausführungsformen. Es sollte verstanden werden, dass in der vorstehenden Beschreibung beispielhafter Ausführungsformen verschiedene Merkmale gelegentlich in einer einzelnen Ausführungsform, Figur oder Beschreibung davon zusammen gruppiert sind, um die Offenbarung zu straffen und beim Verständnis von einem oder mehreren der verschiedenen neuartigen Aspekte zu helfen. Dieses Verfahren der Offenbarung soll jedoch nicht dahingehend ausgelegt werden, als dass es eine Absicht reflektiert, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern als ausdrücklich in jedem Anspruch genannt sind. Vielmehr liegen, wie es die folgenden Ansprüche reflektieren, neuartige Aspekte in weniger als allen Merkmalen einer einzelnen vorstehend offenbarten Ausführungsform. Somit sind die Ansprüche hiermit ausdrücklich in diese Beschreibung eingeschlossen, wobei jeder Anspruch für sich selbst als eine separate Ausführungsform steht.

Claims (23)

  1. Vorrichtung, welche Folgendes umfasst: einen Prozessor, der eine oder mehrere Ausführungseinheiten (EUs - Execution Units) beinhaltet, wobei die eine oder die mehreren EUs mindestens eine erste Ausführungseinheit (EU - Execution Unit) zum Verarbeiten mehrerer Threads beinhalten, wobei die erste EU Folgendes beinhaltet: eine Registerdatei, die mehrere Registerbanken beinhaltet, wobei jede Registerbank mehrere Register beinhaltet, und einen oder mehrere Lese-Multiplexer zum Lesen von Registern aus der Registerdatei, wobei der Versuch, mehr als ein Register aus einer einzelnen Registerbank der Registerdatei in einem gleichen Taktzyklus zu lesen, einen Registerbankkonflikt erzeugt; wobei Register für jeden Thread für die erste EU derart über die Registerbanken innerhalb der Registerdatei hinweg verteilt sind, dass sich ein erstes Register für einen ersten Thread der mehreren Threads und ein folgendes zweites Register für den ersten Thread in unterschiedlichen Registerbanken innerhalb der Registerdatei befinden.
  2. Vorrichtung nach Anspruch 1, wobei die Registerdatei mehrere Arrays von Registerbanken beinhaltet, wobei die mehreren Arrays ein erstes Array von Registerbanken und ein zweites Array von Registerbanken beinhalten, und wobei die Register für jeden Thread derart verteilt sind, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  3. Vorrichtung nach Anspruch 2, wobei ein erster Lese-Multiplexer mit den Registerbanken des ersten Arrays von Registerbanken gekoppelt ist und ein zweiter Lese-Multiplexer mit den Registerbanken des zweiten Arrays von Registerbanken gekoppelt ist.
  4. Vorrichtung nach Anspruch 2 oder 3, wobei die Vorrichtung jede von einer oder mehreren logischen SIMD (Single Instruction Multiple Data) -Anweisungen in mehrere physische SIMD-Anweisungen für die erste EU aufteilen soll.
  5. Vorrichtung nach einem der Ansprüche 2 bis 4, wobei die erste EU ferner eine oder mehrere Verarbeitungs-Pipelines für SIMD (Single Instruction Multiple Data) - Anweisungen beinhaltet, wobei eine erste Verarbeitungs-Pipeline der einen oder der mehreren Verarbeitungs-Pipelines mehrere Stufen zum Lesen von Registern beinhaltet, wobei die mehreren Stufen eine erste Lesestufe zum Lesen eines oder mehrerer Register in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen eines oder mehrerer Register in einem zweiten Taktzyklus beinhalten.
  6. Vorrichtung nach Anspruch 5, wobei die Vorrichtung bestimmen soll, ob Quelloperanden einer ersten Anweisung einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, die Vorrichtung Positionen von zwei Quelloperanden der ersten Anweisung tauschen soll, um den Registerbankkonflikt zu vermeiden.
  7. Vorrichtung nach Anspruch 6, wobei die Vorrichtung bestimmen soll, ob ein oder mehrere Quelloperanden der ersten Anweisung und ein oder mehrere Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung und die Quelloperanden der zweiten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, die Vorrichtung Positionen von zwei Quelloperanden der zweiten Anweisung tauschen soll, um den Registerbankkonflikt zu vermeiden.
  8. Vorrichtung nach einem der Ansprüche 1 bis 7, wobei die eine oder die mehreren EUs in einer grafischen Verarbeitungseinheit (GPU - Graphical Processing Unit) enthalten sind.
  9. Computerlesbares Speichermedium, auf welchem Daten gespeichert sind, die Sequenzen von Anweisungen darstellen, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zum Durchführen von Operationen veranlassen, welche Folgendes umfassen: Empfangen mehrerer SIMD (Single Instruction Multiple Data) -Anweisungen zur Verarbeitung für eine Ausführungseinheit (EU - Execution Unit) in einem Verarbeitungssystem, wobei die EU eine Registerdatei mit mehreren Arrays von Registerbanken beinhaltet, wobei die mehreren Arrays von Registerbanken ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register beinhalten, und eine Verarbeitungs-Pipeline beinhaltet, wobei die Verarbeitungs-Pipeline mehrere Stufen zum Lesen von Registern beinhaltet; Analysieren von Quelloperanden der mehreren SIMD-Anweisungen, um zu identifizieren, ob ein oder mehrere Registerbankkonflikte auftreten werden, wenn Quelloperanden von einer oder mehreren Anweisungen in einem gleichen Taktzyklus gelesen werden; und beim Bestimmen, dass ein oder mehrere Registerbankkonflikte auftreten werden, Tauschen von Positionen von Quelloperanden innerhalb einer oder mehrerer der mehreren SIMD-Anweisungen, um den einen oder die mehreren Registerbankkonflikte zu vermeiden.
  10. Medium nach Anspruch 9, wobei das Analysieren von Operanden der mehreren SIMD-Anweisungen das Analysieren von Quelloperanden einer ersten Anweisung beinhaltet, um zu bestimmen, ob das gemeinsame Lesen mehrerer Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus einen Registerbankkonflikt erzeugen wird, wobei die erste Anweisung drei Quelloperanden beinhaltet.
  11. Medium nach Anspruch 9 oder 10, wobei das Tauschen von Positionen von Quelloperanden das Tauschen von Positionen eines ersten Quelloperanden und eines zweiten Quelloperanden der ersten Anweisung beinhaltet.
  12. Medium nach Anspruch 9, wobei das Analysieren von Operanden der mehreren SIMD-Anweisungen das Analysieren von Quelloperanden einer ersten Anweisung und von Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, beinhaltet, um zu bestimmen, ob das Lesen von einem oder mehreren Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus mit einem oder mehreren Quelloperanden der zweiten Anweisung einen Registerbankkonflikt erzeugen wird, wobei die zweite Anweisung mehrere Quelloperanden beinhaltet.
  13. Medium nach Anspruch 12, wobei das Tauschen von Positionen von Quelloperanden das Tauschen von Positionen von einem ersten Quelloperanden und einem zweiten Quelloperanden der zweiten Anweisung beinhaltet.
  14. Medium nach einem der Ansprüche 9 bis 13, wobei die Register für jeden von mehreren Threads für die EU derart über die mehreren Arrays von Registerbanken hinweg verteilt sind, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  15. Medium nach einem der Ansprüche 9 bis 14, wobei ein erster Lese-Multiplexer mit den Registerbanken des ersten Arrays von Registerbanken gekoppelt ist und ein zweiter Lese-Multiplexer mit den Registerbanken des zweiten Arrays von Registerbanken gekoppelt ist.
  16. Medium nach einem der Ansprüche 9 bis 15, wobei die mehreren Stufen eine erste Lesestufe zum Lesen von einem oder mehreren Registern in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen von einem oder mehreren Registern in einem zweiten Taktzyklus beinhalten.
  17. Medium nach einem der Ansprüche 9 bis 16, welches ferner Anweisungen umfasst, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den einen oder die mehreren Prozessoren zum Durchführen von Operationen veranlassen, welche Folgendes umfassen: Aufteilen von jeder von einer oder mehreren logischen SIMD-Anweisungen in mehrere physische SIMD-Anweisungen.
  18. Medium nach einem der Ansprüche 9 bis 17, wobei die EU in einer grafischen Verarbeitungseinheit (GPU - Graphical Processing Unit) enthalten ist.
  19. Verarbeitungssystem, welches Folgendes umfasst: eine oder mehrere grafische Verarbeitungseinheiten (GPUs - Graphical Processing Units), wobei mindestens eine der einen oder der mehreren GPUs mehrere Ausführungseinheiten (EUs - Execution Units) beinhaltet, wobei die mehreren EUs mindestens eine erste EU zum Verarbeiten mehrerer Threads beinhalten, wobei das Verarbeiten eines Threads das Verarbeiten von SIMD (Single Instruction Multiple Data) - Anweisungen beinhaltet, wobei die erste EU Folgendes beinhaltet: eine Registerdatei mit mehreren Arrays von Registerbanken, wobei jedes der mehreren Arrays mehrere Registerbanken beinhaltet, wobei jede Registerbank mehrere Register beinhaltet, wobei die mehreren Arrays von Registerbanken ein erstes Array von Registerbanken für gerade Register und ein zweites Array von Registerbanken für ungerade Register beinhalten, und einen ersten Lese-Multiplexer zum Lesen von Registern aus dem ersten Array von Registerbanken und einen zweiten Lese-Multiplexer zum Lesen von Registern aus dem zweiten Array von Registerbanken, wobei der Versuch, mehr als ein Register aus einer einzelnen Registerbank der Registerdatei in einem gleichen Taktzyklus zu lesen, einen Registerbankkonflikt erzeugt; und einen Speicher zum Speichern von Daten zur Grafikverarbeitung; wobei Register für jeden Thread für die erste EU derart über die Registerbanken der Registerdatei hinweg verteilt sind, dass sich ein erstes Register für einen Thread und ein folgendes zweites Register für den Thread innerhalb eines Arrays von Registerbanken in unterschiedlichen Registerbanken befinden und wobei die Register für jeden Thread derart verteilt sind, dass sich alle geraden Register in dem ersten Array von Registerbanken befinden und sich alle ungeraden Register in dem zweiten Array von Registerbanken befinden.
  20. Verarbeitungssystem nach Anspruch 19, wobei das Verarbeitungssystem jede von einer oder mehreren logischen SIMD-Anweisungen in mehrere physische SIMD-Anweisungen für die erste EU aufteilen soll.
  21. Verarbeitungssystem nach Anspruch 19 oder 20, wobei die erste EU ferner eine oder mehrere Verarbeitungs-Pipelines für SIMD-Anweisungen beinhaltet, wobei eine erste Verarbeitungs-Pipeline der einen oder der mehreren Verarbeitungs-Pipelines mehrere Stufen zum Lesen von Registern beinhaltet, wobei die mehreren Stufen eine erste Lesestufe zum Lesen von einem oder mehreren Registern in einem ersten Taktzyklus und eine zweite Lesestufe zum Lesen von einem oder mehreren Registern in einem zweiten Taktzyklus beinhalten.
  22. Verarbeitungssystem nach Anspruch 21, wobei das Verarbeitungssystem bestimmen soll, ob Quelloperanden einer ersten Anweisung einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, das Verarbeitungssystem Positionen von zwei Quelloperanden der ersten Anweisung tauschen soll, um den Registerbankkonflikt zu vermeiden.
  23. Verarbeitungssystem nach Anspruch 22, wobei das Verarbeitungssystem bestimmen soll, ob ein oder mehrere Quelloperanden der ersten Anweisung und ein oder mehrere Quelloperanden einer zweiten Anweisung, die der ersten Anweisung unmittelbar folgt, einen Registerbankkonflikt erzeugen werden, wenn die Quelloperanden der ersten Anweisung und die Quelloperanden der zweiten Anweisung in einem gleichen Taktzyklus gelesen werden, und, beim Bestimmen, dass ein Registerbankkonflikt auftreten wird, das Verarbeitungssystem Positionen von zwei Quelloperanden der zweiten Anweisung tauschen soll, um den Registerbankkonflikt zu vermeiden.
DE102019117545.3A 2018-06-29 2019-06-28 Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors Pending DE102019117545A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/023,713 US10754651B2 (en) 2018-06-29 2018-06-29 Register bank conflict reduction for multi-threaded processor
US16/023,713 2018-06-29

Publications (1)

Publication Number Publication Date
DE102019117545A1 true DE102019117545A1 (de) 2020-01-02

Family

ID=68886336

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019117545.3A Pending DE102019117545A1 (de) 2018-06-29 2019-06-28 Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors

Country Status (2)

Country Link
US (1) US10754651B2 (de)
DE (1) DE102019117545A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10754651B2 (en) 2018-06-29 2020-08-25 Intel Corporation Register bank conflict reduction for multi-threaded processor
CN111857832A (zh) * 2020-07-15 2020-10-30 国家电网有限公司能源互联网技术研究院 一种超长指令插入判断方法及系统

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2578932B (en) 2019-02-14 2021-02-24 Imagination Tech Ltd Allocation of memory
US11237827B2 (en) * 2019-11-26 2022-02-01 Advanced Micro Devices, Inc. Arithemetic logic unit register sequencing
US11775301B2 (en) * 2021-09-24 2023-10-03 Apple Inc. Coprocessor register renaming using registers associated with an inactive context to store results from an active context

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7634621B1 (en) * 2004-07-13 2009-12-15 Nvidia Corporation Register file allocation
US7750915B1 (en) * 2005-12-19 2010-07-06 Nvidia Corporation Concurrent access of data elements stored across multiple banks in a shared memory resource
US8533435B2 (en) * 2009-09-24 2013-09-10 Nvidia Corporation Reordering operands assigned to each one of read request ports concurrently accessing multibank register file to avoid bank conflict
US20110208951A1 (en) * 2010-02-22 2011-08-25 Advanced Micro Devices, Inc. Instruction processor and method therefor
US9652233B2 (en) * 2013-08-20 2017-05-16 Apple Inc. Hint values for use with an operand cache
GB2540971B (en) * 2015-07-31 2018-03-14 Advanced Risc Mach Ltd Graphics processing systems
US10754651B2 (en) 2018-06-29 2020-08-25 Intel Corporation Register bank conflict reduction for multi-threaded processor

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10754651B2 (en) 2018-06-29 2020-08-25 Intel Corporation Register bank conflict reduction for multi-threaded processor
CN111857832A (zh) * 2020-07-15 2020-10-30 国家电网有限公司能源互联网技术研究院 一种超长指令插入判断方法及系统
CN111857832B (zh) * 2020-07-15 2023-10-20 国家电网有限公司能源互联网技术研究院 一种超长指令插入判断方法及系统

Also Published As

Publication number Publication date
US20200004534A1 (en) 2020-01-02
US10754651B2 (en) 2020-08-25

Similar Documents

Publication Publication Date Title
DE112020000850T5 (de) Cache-Struktur und -Nutzung
DE102019117592A1 (de) Videoverarbeitungsmechanismus
DE102019117545A1 (de) Reduzierung von registerbankkonflikten für ausführungseinheiten eines multithread-prozessors
DE112018005527T5 (de) Automatisches aufwecken von leistungsdomänen fürgrafikkonfigurationsanforderungen
DE102020107080A1 (de) Grafiksysteme und Verfahren zum Beschleunigen von Synchronisation mittels feinkörniger Abhängigkeitsprüfung und Planungsoptimierungen basierend auf verfügbarem gemeinsam genutztem Speicherplatz
DE102020121814A1 (de) Vorrichtung und Verfahren zum Verwenden von Dreieckspaaren und gemeinsam genutzten Transformationsschaltungen zum Verbessern der Strahlverfolgungsleistung
DE102020132272A1 (de) Verfahren und vorrichtung zum codieren basierend auf schattierungsraten
DE102020131704A1 (de) Multikachelspeicherverwaltungsmechanismus
DE102018110719A1 (de) Hardwareimplementierte Punkt-zu-Punkt-Kommunikationsprimitive zum Maschinenlernen
DE102019110027A1 (de) Kachelbasiertes rendern für mehrere auflösungen von bildern
DE102020124872A1 (de) Verwendung von innere-abdeckung-informationen durch eine konservative-rasterung-pipeline zum aktivieren von earlyz für eine konservative rasterung
DE102020126177A1 (de) Verfahren und vorrichtung zum planen der threadreihenfolge, um den cache-wirkungsgrad zu verbessern
DE102020105902A1 (de) Hardware-indexzuordnungsmechanismus
DE112018003999T5 (de) Verfahren und Vorrichtung für effiziente Verarbeitung von abgeleiteten einheitlichen Werten in einem Grafikprozessor
DE112018007635T5 (de) Vorrichtung und verfahren zur effizienten gemeinsamen nutzung einer lokalen anzeige für einen virtualisierten grafikprozessor
DE102020131293A1 (de) Einrichtung und verfahren zur multi-adapter-kodierung
DE102019106701A1 (de) Einrichtung und Verfahren zum virtualisierten Planen von mehreren doppelten Grafik-Engines
DE102020130995A1 (de) Verfahren und vorrichtung zur codierung basierend auf wichtigkeitswerten
DE102022130536A1 (de) Sich selbst abstimmende thread-verteilungsrichtlinie
DE102022119733A1 (de) Sammeln von nutzdaten aus beliebigen registern für sende-nachrichten in einer grafikumgebung
DE102019120922A1 (de) Vorrichtung und verfahren für multifrequenz-vertex-shadinghintergrund
DE112017004178T5 (de) Auslagern der Kernel-Ausführung zu der Grafik
DE102019124705A1 (de) Multiphasenarchitektur für Mehrraten-Pixelschattierung
DE102019123443A1 (de) Mechanismus zum gemeinsamen Benutzen von Registern
DE112018007634T5 (de) Vorrichtung und verfahren für eine virtualisierte anzeige