DE102020127035A1

DE102020127035A1 - Programmierbarer umordnungspuffer für dekomprimierung

Info

Publication number: DE102020127035A1
Application number: DE102020127035.6A
Authority: DE
Inventors: Abhishek R. Appu; Eric G. Liskay; Prasoonkumar Surti; Sudhakar Kamma; Karthik Vaidyanathan; Rajasekhar PANTANGI; Altug Koker; Abhishek Rhisheekesan; Shashank Lakshminarayana; Priyanka LADDA; Karol A. Szerszen
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-11-13
Filing date: 2020-10-14
Publication date: 2021-05-20
Also published as: KR20210058647A; US11574382B2; US20220058765A1; JP2021082261A; CN112801848A; US11113783B2; US20210142438A1

Abstract

Hierin beschriebene Beispiele betreffen eine Dekomprimierungsengine, die anfordern, kann, dass komprimierte Daten über einen Arbeitsspeicherbus übertragen werden. In einigen Fällen hat der Arbeitsspeicherbus eine Breite, die mehrere Datenübertragungen erfordert, um die angeforderten Daten zu übertragen. Im Fall, dass angeforderte Daten der Dekomprimierungsengine in Reihenfolge zu präsentieren sind, kann ein Umordnungspuffer verwendet werden, um Einträge von Daten zu speichern. Wenn ein Kopfzeileneintrag empfangen wird, kann der Eintrag der Dekomprimierungsengine bereitgestellt werden. Wenn ein letzter Eintrag in einer Gruppe von einem oder mehreren Einträgen empfangen wird, werden der Dekomprimierungsengine alle Einträge der Gruppe in Reihenfolge präsentiert. In einigen Beispielen kann eine Dekomprimierungsengine Arbeitsspeicherressourcen ausleihen, die zur Verwendung durch einen anderen Arbeitsspeicherclient zugeteilt sind, um eine zur Verwendung verfügbare Größe eines Umordnungspuffers zu erweitern. Ein Arbeitsspeicherclient mit Überschusskapazität und einer langsamsten Wachstumsrate kann zum Beispiel ausgewählt werden, um Arbeitsspeicherressourcen von ihm auszuleihen.

Description

GEBIET
Ausführungsformen allgemein das Gebiet der Datenumordnung in Verbindung mit Bildverarbeitung.
VERWANDTE TECHNIK
Mikroprozessoren und Grafikverarbeitungseinheiten (GPU) weisen mehrere interne Hardwareeinheiten als Teil verschiedener Rechenphasen auf. Diese internen Einheiten erfordern, dass Daten aus dem Arbeitsspeicher abgerufen werden, und oft wetteifern diese Einheiten miteinander um Arbeitsspeicher- oder Zwischenspeicherzugriff durch gemeinsame Zugriffskanäle auf Arbeitsspeicher oder Zwischenspeicher. Einige dieser Einheiten erfordern, dass ihre Arbeitsspeicher-Lesezugriffe geordnet sind, was durch einen Umordnungspuffer (ROB) erzielt werden kann. Die Anzahl der Arbeitsspeicher-Lesezugriffe, die für jeden Arbeitsspeicherclient erforderlich ist, variiert von Zeit zu Zeit während der Ausführung von Arbeitslasten wie Spielen oder Grafikbenchmarks. Da die Anforderungen der Arbeitsspeicher-Lesezugriffe für jeden Arbeitsspeicherclient während der Ausführung von Arbeitslasten variieren, tendieren mehrere Arbeitsspeicherclients dazu, miteinander um eine Zuteilung von ROB-Ressourcen zu wetteifern.
KURZBESCHREIBUNG DER ZEICHNUNGEN

1 ist ein Blockdiagramm eines Verarbeitungssystems nach einer Ausführungsform.
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die von hierin beschriebenen Ausführungsformen bereitgestellt werden.
3A-3C veranschaulichen Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleunigerarchitekturen, die von hierin beschriebenen Ausführungsformen bereitgestellt werden.
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine eines Grafikprozessors nach einigen Ausführungsformen.
5A-5B veranschaulichen eine Threadausführungslogik, die eine Anordnung von Verarbeitungselementen enthält, die in einem Grafikprozessorkern nach hierin beschriebenen Ausführungsformen eingesetzt wird.
6 illustriert eine zusätzliche Ausführungseinheit nach einer Ausführungsform.
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformate nach einigen Ausführungsformen veranschaulicht.
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors.
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat nach einigen Ausführungsformen veranschaulicht.
9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlsfolge nach einer Ausführungsform veranschaulicht.
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem nach einigen Ausführungsformen.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen nach einer Ausführungsform durchzuführen.
11B veranschaulicht eine seitliche Querschnittsansicht einer integrierten Schalkreisgehäuseanordnung nach einigen hierin beschriebenen Ausführungsformen.
11C veranschaulicht eine Gehäuseanordnung, die mehrere Einheiten von Hardwarelogik-Einzelchips enthält, die mit einem Substrat verbunden sind.
11D veranschaulicht eine Gehäuseanordnung, die austauschbare Einzelchips enthält, nach einer Ausführungsform.
12, 13A und 13B veranschaulichen beispielhafte integrierte Schaltkreise und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne nach verschiedenen hierin beschriebenen Ausführungsformen gefertigt werden können.
14 zeigt ein Blockdiagramm eines Arbeitsspeicher- und Umordnungspuffer(ROB)-Systems.
15A zeigt ein Beispiel von Inhalten von Nachverfolgungs-FIFO, Steuerinformationen, Indikatoren für vorhandene Daten und Datenpuffern, die verschiedenen Leseanforderungen zugeteilt sind.
15B-1 bis 15B-3 zeigen ein Beispiel einer Verwendung von Nachverfolgungs-FIFO und Indikatoren für vorhandene Daten, um einem Dekomprimierer Einträge in Reihenfolge bereitzustellen.
16A zeigt einen Prozess, der verwendet werden kann, um einen Empfang von Einträgen nachzuverfolgen, die mit einer Leseanforderung aus einem Arbeitsspeicher assoziiert sind, und Daten vor einem Bereitstellen der Daten in Reihenfolge zum Zugriff durch einen Dekomprimierer oder einer anderen Vorrichtung oder Software zu puffern.
16B zeigt einen Prozess, der verwendet werden kann, um eine Menge von zur Verwendung zum Umordnen von Einträgen zugeteiltem Arbeitsspeicherraum vor einem Verfügbarmachen von Daten zur Verarbeitung durch einen Dekomprimierer zuzuteilen.
17 zeigt mehrere Arbeitsspeicherclients, die Arbeitsspeicherzugriffsanforderungen stellen und mit ROB-Einträgen zugeteilt sind.
18 zeigt ein Beispiel eines ROB vor Ausleihen und nach Ausleihen durch einen Arbeitsspeicherclient von einem Arbeitsspeicherclientverleiher.
19A-19C zeigen ein kettenartiges Ausleihschema zum Ausleihen von ROB-Einträgen durch mehrere Arbeitsspeicherclients von einer ROB-Zuteilung für mehrere Arbeitsspeicherc lients.
20A und 20B zeigen ein Stillstehen, das eintritt, wenn ein Arbeitsspeicherclient versucht, von einem anderen Arbeitsspeicherclient auszuleihen.
21 zeigt einen Prozess, der verwendet werden kann, um Arbeitsspeicherressourcen gemeinsam zu nutzen.

AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung werden zum Zwecke der Erläuterung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der nachstehend beschriebenen Ausführungsformen der Erfindung bereitzustellen. Es ist allerdings für Fachleute auf dem Gebiet offensichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Details umgesetzt werden können. In anderen Fällen werden allgemein bekannte Strukturen und Vorrichtungen in Blockdiagrammform dargestellt, um ein Verschleiern der zugrunde liegenden Prinzipien der Ausführungsformen der Erfindung zu verhindern.
Systemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 nach einer Ausführungsform. Das System 100 kann in einem Einzelprozessor-Desktopsystem, einem Mehrprozessor-Arbeitsplatzsystem oder einem Serversystem mit einer großen Anzahl von Prozessoren 102 oder Prozessorkernen 107 verwendet werden. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einen integrierten Ein-Chip-System-Schaltkreis (SoC-Schaltkreis) zur Verwendung in mobilen, tragbaren oder eingebetteten Vorrichtungen, wie zum Beispiel in Internet-der-Dinge(IdD)-Vorrichtungen mit verkabelter oder kabelloser Konnektivität mit einem lokalen oder Weitverkehrsnetz, eingebunden ist.
In einer Ausführungsform kann das System 100 enthalten, koppeln mit oder integriert sein in: einer serverbasierten Gamingplattform; einer Spielekonsole, einschließlich einer Spiele- und Medienkonsole; einer mobilen Gamingkonsole, einer tragbaren Spielekonsole oder einer Online-Spielekonsole. In einigen Ausführungsformen ist das System 100 ein Teil eines Mobiltelefons, Smartphones, einer Tablet-Rechenvorrichtung oder mobilen, mit dem Internet verbundenen Vorrichtung, wie eines Laptops mit geringer interner Speicherkapazität. Das Verarbeitungssystem 100 kann auch enthalten, koppeln mit oder integriert sein in: einer tragbaren Vorrichtung, wie einer tragbaren Smartwatch-Vorrichtung; Smart-Brillen oder Kleidung, die mit Funktionen erweiterter Realität (AR) oder virtueller Realität (VR) erweitert ist bzw. sind, um visuelle, Audio- oder taktile Ausgaben bereitzustellen, um reale visuelle, Audio- oder taktile Erfahrungen zu ergänzen oder anderweitig Text, Audio, Grafik, Video, holografische Bilder oder holografisches Video oder eine taktile Rückmeldung bereitzustellen; einer anderen Vorrichtung für erweiterte Realität (AR); oder einer anderen Vorrichtung für virtuelle Realität (VR). In einigen Ausführungsformen enthält das Verarbeitungssystem 100 einen Fernseher oder eine Set-Top-Box-Vorrichtung oder ist Teil dieses bzw. dieser. In einer Ausführungsform kann das System 100 enthalten, koppeln mit oder integriert sein in ein selbstfahrendes Fahrzeug, wie einem Bus, Traktoranhänger, Auto, Motorrad oder elektrisch angetriebenen Fahrrad, einem Flugzeug oder Gleitflieger (oder einer beliebigen Kombination daraus). Das selbstfahrende Fahrzeug kann das System 100 verwenden, um die um das Fahrzeug herum erfasste Umgebung zu verarbeiten.
In einigen Ausführungsformen enthalten der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107, um Anweisungen zu verarbeiten, die bei Ausführung Operationen für System- oder Benutzersoftware durchführen. In einigen Ausführungsformen ist mindestens einer des einen oder der mehreren Prozessorkerne 107 ausgelegt, einen bestimmten Anweisungssatz 109 zu verarbeiten. In einigen Ausführungsformen kann der Anweisungssatz 109 ein Rechnen mit komplexem Anweisungssatz (CISC), ein Rechnen mit reduziertem Anweisungssatz (RISC) oder ein Rechnen über ein Very Long Instruction Word (VLIW) ermöglichen. Ein oder mehrere Prozessorkerne 107 können einen anderen Anweisungssatz 109 verarbeiten, der Anweisungen enthalten kann, um die Emulation anderer Anweisungssätze zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen wie einen digitalen Signalprozessor (DSP) enthalten.
In einigen Ausführungsformen enthält der Prozessor 102 einen Zwischenspeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Zwischenspeicher oder mehrere Ebenen von internen Zwischenspeichern aufweisen. In einigen Ausführungsformen wird der Zwischenspeicher unter verschiedenen Komponenten des Prozessors 102 gemeinsam genutzt. In einigen Ausführungsformen verwendet der Prozessor 102 auch einen externen Zwischenspeicher (z. B. einen Level-3(L3)-Zwischenspeicher oder einen Last-Level-Zwischenspeicher (LLC)) (nicht gezeigt), der von den Prozessorkernen 107 unter Verwendung bekannter Zwischenspeicherkohärenztechniken gemeinsam genutzt werden kann. Eine Registerdatei 106 kann zusätzlich im Prozessor 102 enthalten sein und kann unterschiedliche Arten von Registern zum Speichern unterschiedlicher Datentypen enthalten (z. B. Ganzzahlregister, Gleitkommaregister, Statusregister und ein Anweisungszeigerregister). Einige Register können Universalregister sein, während andere Register für das Design des Prozessors 102 spezifisch sein können.
In einigen Ausführungsformen ist bzw. sind ein oder mehrere Prozessor(en) 102 an einen oder mehrere Schnittstellenbusse 110 gekoppelt, um Kommunikationssignale wie Adressen, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Komponenten im System 100 zu übertragen. Der Schnittstellenbus 110 kann in einer Ausführungsform ein Prozessorbus, zum Beispiel eine Version des Direct-Media-Interface(DMI)-Busses sein. Prozessorbusse sind jedoch nicht auf den DMI-Bus beschränkt und können einen oder mehrere Peripheral-Component-Interconnect-Busse (z. B. PCI, PCI Express), Arbeitsspeicherbusse oder andere Arten von Schnittstellenbussen enthalten. In einer Ausführungsform enthält bzw. enthalten der Prozessor bzw. die Prozessoren 102 eine integrierte Arbeitsspeichersteuerung 116 und einen Plattformsteuerungshub 130. Die Arbeitsspeichersteuerung 116 ermöglicht eine Kommunikation zwischen einer Arbeitsspeichervorrichtung und anderen Komponenten des Systems 100, während der Plattformsteuerungshub (PCH) 130 Verbindungen mit E/A-Vorrichtungen über einen lokalen E/A-Bus bereitstellt.
Die Arbeitsspeichervorrichtung 120 kann eine dynamische Arbeitsspeichervorrichtung mit wahlfreiem Zugriff (DRAM-Vorrichtung), eine statische Arbeitsspeichervorrichtung mit wahlfreiem Zugriff (SRAM-Vorrichtung), eine Flashspeichervorrichtung, eine Phasenwechselspeichervorrichtung oder eine andere Arbeitsspeichervorrichtung mit geeigneter Leistung sein, um als Prozessarbeitsspeicher zu dienen. In einer Ausführungsform kann die Arbeitsspeichervorrichtung 120 als Systemarbeitsspeicher für das System 100 arbeiten, um Daten 122 und Anweisungen 121 zur Verwendung speichern, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen. Die Arbeitsspeichersteuerung 116 koppelt auch an einen optionalen externen Grafikprozessor 118, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienoperationen durchzuführen. In einigen Ausführungsformen können Grafik-, Medien- oder Rechenoperationen durch einen Beschleuniger 112 unterstützt werden, der ein Coprozessor ist, der ausgelegt sein kann, um einen Sondersatz von Grafik-, Medien- oder Rechenoperationen durchzuführen. In einer Ausführungsform ist der Beschleuniger 112 zum Beispiel ein Matrixmultiplikations-Beschleuniger, der verwendet wird, um maschinelles Lernen oder Rechenoperationen zu optimieren. In einer Ausführungsform ist der Beschleuniger 112 ein Raytracing-Beschleuniger, der verwendet werden kann, um zusammen mit dem Grafikprozessor 108 Raytracing-Operationen durchzuführen. In einer Ausführungsform kann ein externer Beschleuniger 119 anstelle des Beschleunigers 112 oder zusammen mit diesem verwendet werden.
In einigen Ausführungsformen kann eine Anzeigevorrichtung 111 an den bzw. die Prozessor(en) 102 anbinden. Die Anzeigevorrichtung 111 kann eine oder mehrere von einer internen Anzeigevorrichtung, wie zum Beispiel in einer mobilen elektronischen Vorrichtung oder einer Laptopvorrichtung, oder eine externe Anzeigevorrichtung sein, die über eine Anzeigeschnittstelle (z. B. DisplayPort, eingebetteter DisplayPort, MIPI, HDMI usw.) angebunden ist. In einer Ausführungsform kann die Anzeigevorrichtung 111 eine am Kopf montierte Anzeige (HMD) wie eine stereoskopische Anzeigevorrichtung zur Verwendung in Anwendungen mit virtueller Realität (VR) oder Anwendungen mit erweiterter Realität (AR) sein.
In einigen Ausführungsformen ermöglicht der Plattformsteuerungshub 130, dass Peripherieeinrichtungen über einen Hochgeschwindigkeits-E/A-Bus an die Arbeitsspeichervorrichtung 120 und den Prozessor 102 anbinden. Die E/A-Peripherieeinrichtungen enthalten unter anderem eine Audiosteuerung 146, eine Netzwerksteuerung 134, eine Firmwareschnittstelle 128, einen drahtlosen Sende-Empfänger 126, Berührungssensoren 125, eine Datenspeichervorrichtung 124 (z. B. nichtflüchtigen Arbeitsspeicher, flüchtigen Arbeitsspeicher, ein Festplattenlaufwerk, Flashspeicher, 3D NAND, 3D XPoint usw.). Die Datenspeichervorrichtung 124 kann über eine Speicherschnittstelle (z. B. SATA) oder über einen peripheren Bus, wie einen Peripheral-Component-Interconnect-Bus (z. B. PCI, PCI Express) verbunden sein. Die Berührungssensoren 125 können Berührungsbildschirmsensoren, Drucksensoren oder Fingerabdrucksensoren enthalten. Der drahtlose Sende-Empfänger 126 kann ein WiFi-Sende-Empfänger, ein Bluetooth-Sende-Empfänger oder ein Sende-Empfänger für mobile Netzwerke sein, wie ein 3G-, 4G-, 5G- oder Long-Term-Evolution(LTE)-Sende-Empfänger. Die Firmwareschnittstelle 128 ermöglicht eine Kommunikation mit Systemfirmware und kann beispielsweise eine vereinheitlichte erweiterbare Firmwareschnittstelle (UEFI) sein. Die Netzwerksteuerung 134 kann eine Netzwerkverbindung mit einem verdrahteten Netzwerk ermöglichen. In einigen Ausführungsformen koppelt eine Hochleistungsnetzwerksteuerung (nicht gezeigt) an den Schnittstellenbus 110. Die Audiosteuerung 146 ist in einer Ausführungsform eine hochauflösende Mehrkanal-Audiosteuerung. In einer Ausführungsform enthält das System 100 eine optionale Vorgänger-E/A-Steuerung 140, um Vorgänger-Vorrichtungen (z. B. Personal System 2 (PS/2) an das System zu koppeln. Der Plattformsteuerungshub 130 kann auch an eine oder mehrere Universal-Serial-Bus(USB)-Steuerungen 142 anbinden, um Eingabevorrichtungen wie Tastatur- und Mauskombinationen 143, eine Kamera 144 oder andere USB-Eingabevorrichtungen anzubinden.
Es ist klar, dass das gezeigte System 100 beispielhaft und nicht einschränkend ist, da andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, ebenfalls verwendet werden können. Eine Instanz der Arbeitsspeichersteuerung 116 und des Plattformsteuerungshubs 130 kann zum Beispiel in einen diskreten externen Grafikprozessor, wie den externen Grafikprozessor 118 integriert sein. In einer Ausführungsform können der Plattformsteuerungshub 130 und/oder die Arbeitsspeichersteuerung 116 zum einen oder zu den mehreren Prozessoren 102 extern sein. Das System 100 kann zum Beispiel eine externe Arbeitsspeichersteuerung 116 und einen externen Plattformsteuerungshub 130 enthalten, die als ein Arbeitsspeichersteuerungshub und ein peripherer Steuerungshub innerhalb eines Systemchipsatzes konfiguriert sein können, der in Kommunikation mit den Prozessoren 102 steht.
Beispielsweise können Leiterplatten („Schlitten“) verwendet werden, auf denen Komponenten wie CPUs, Arbeitsspeicher und andere Komponenten platziert sind und die für erhöhte Wärmeleistung konstruiert sind. In einigen Beispielen befinden sich Verarbeitungskomponenten wie die Prozessoren auf einer Oberseite eines Schlittens, wohingegen naher Arbeitsspeicher, wie DIMMs, auf einer Unterseite des Schlittens angeordnet ist. Als Ergebnis des verbesserten Luftstroms, der von diesem Design geboten wird, können die Komponenten mit höheren Frequenzen und Energiepegeln als in typischen Systemen arbeiten, wodurch die Leistung verbessert wird. Darüber hinaus sind die Einschübe ausgelegt, blind mit Energie- und Datenkommunikationskabeln in einem Rack zusammenzupassen, wodurch ihre Fähigkeit verbessert wird, schnell entfernt, nachgerüstet, neu installiert und/oder ausgetauscht zu werden. Gleichermaßen sind individuelle Komponenten, die sich auf den Schlitten befinden, wie Prozessoren, Beschleuniger, Arbeitsspeicher und Datenspeicherlaufwerke, ausgelegt, aufgrund ihrer erhöhten Beabstandung voneinander leicht hochgerüstet zu werden. In der veranschaulichenden Ausführungsform enthalten die Komponenten zusätzlich Hardwarebestätigungsmerkmale, um ihre Echtheit zu beweisen.
Ein Rechenzentrum kann eine einzelne Netzwerkarchitektur („Fabric“) einsetzen, die mehrere andere Netzwerkarchitekturen einschließlich Ethernet und Omni-Path unterstützt. Die Schlitten können über Lichtwellenleiter, die eine höhere Bandbreite und geringere Latenz als übliche verdrillte Leitungskabel (z. B. Kategorie 5, Kategorie 5e, Kategorie 6 usw.) bieten, an Switches gekoppelt sein. Aufgrund der hohen Bandbreite, Zwischenverbindungen mit geringer Latenz und Netzwerkarchitektur kann das Rechenzentrum in Verwendung Ressourcen wie Arbeitsspeicher, Beschleuniger (z. B. GPUs, Grafikbeschleuniger, FPGAs, ASICs, neuronale Netze und/oder Beschleuniger mit künstlicher Intelligenz usw.) und Datenspeicherlaufwerke, die physisch getrennt sind, zusammenlegen und diese Rechenressourcen (z. B. Prozessoren) bei Bedarf bereitstellen, was den Rechenressourcen ermöglicht, auf die zusammengelegten Ressourcen zuzugreifen, als ob sie lokal wären.
Eine Energieversorgung oder -quelle kann das System 100 oder eine beliebige Komponente oder ein beliebiges System, die bzw. das hierin beschrieben ist, mit Spannung und/oder Strom versorgen. In einem Beispiel enthält die Energieversorgung einen Wechselstrom-auf-Gleichstrom(AC-DC)-Adapter, der in eine Wandsteckdose zu stecken ist. Eine derartige Wechselstromversorgung kann eine Energiequelle erneuerbarer Energie (z. B. Sonnenenergie) sein. In einem Beispiel enthält die Energiequelle eine Gleichstromquelle, wie einen externen AC-DC-Wandler. In einem Beispiel enthält die Energieversorgung oder die Energiequelle drahtlose Ladehardware, um über eine Nähe zu einem Ladefeld aufzuladen. In einem Beispiel kann die Energiequelle eine interne Batterie, eine Wechselstromversorgung, eine bewegungsbasierte Energieversorgung, eine Solar-Energieversorgung oder eine Brennstoffzellenquelle enthalten.
2A-2D veranschaulichen Rechensysteme und Grafikprozessoren, die von hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente von 2A-2D, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
2A ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200 mit einem oder mehreren Prozessorkernen 202A-202N, einer integrierten Arbeitsspeichersteuerung 214 und einem integrierten Grafikprozessor 208. Der Prozessor 200 kann zusätzliche Kerne bis zu und enthaltend einen zusätzlichen Kern 202N enthalten, die durch die gestrichelt umrandeten Kästchen dargestellt sind. Jeder der Prozessorkerne 202A-202N enthält eine oder mehrere interne Zwischenspeichereinheiten 204A-204N. In einigen Ausführungsformen weist jeder Prozessorkern auch Zugriff auf eine oder mehrere gemeinsam genutzte Zwischenspeichereinheiten 206 auf. Die internen Zwischenspeichereinheiten 204A-204N und die gemeinsam genutzten Zwischenspeichereinheiten 206 stellen innerhalb des Prozessors 200 eine Zwischenspeicherhierarchie dar. Die Zwischenspeicherhierarchie kann mindestens eine Ebene von Anweisungs- und Datenzwischenspeicher innerhalb jedes Prozessorkerns und eine oder mehrere Ebenen von gemeinsam genutztem Zwischenspeicher einer mittleren Ebene, wie einen Level-2(L2)-, Level-3(L3)-, Level-4(L4)-Zwischenspeicher oder einen Zwischenspeicher anderer Ebenen, wobei die höchste Zwischenspeicherebene vor dem externen Arbeitsspeicher als LLC klassifiziert ist. In einigen Ausführungsformen hält Zwischenspeicherkohärenzlogik eine Kohärenz zwischen den verschiedenen Zwischenspeichereinheiten 206 und 204A-204N aufrecht.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz von einem oder mehreren Bussteuereinheiten 216 und einen Systemagentenkern 210 enthalten. Die eine oder die mehreren Bussteuereinheiten 216 verwalten einen Satz von peripheren Bussen, wie einen oder mehrere PCI- oder PCI-Express-Busse. Der Systemagentenkern 210 bietet Verwaltungsfunktionalität für die verschiedenen Prozessorkomponenten. In einigen Ausführungsformen enthält der Systemagentenkern 210 einen oder mehrere integrierte Arbeitsspeichersteuerungen 214, um den Zugriff auf verschiedene externe Arbeitsspeichervorrichtungen (nicht gezeigt) zu verwalten.
In einigen Ausführungsformen enthalten einer oder mehrere der Kerne 202A-202N Unterstützung für gleichzeitiges Multithreading. In einer derartigen Ausführungsform enthält der Systemagentenkern 210 Komponenten zum Koordinieren und Betreiben der Kerne 202A-202N während einer Multithreadingverarbeitung. Der Systemagentenkern 210 kann zusätzlich eine Leistungssteuereinheit (PCU) enthalten, die Logik und Komponenten enthält, um den Leistungszustand der Prozessorkerne 202A-202N und des Grafikprozessors 208 zu regeln.
In einigen Ausführungsformen enthält der Prozessor 200 zusätzlich einen Grafikprozessor 208, um Grafikverarbeitungsoperationen auszuführen. In einigen Ausführungsformen koppelt der Grafikprozessor 208 an den Satz von gemeinsam genutzten Zwischenspeichereinheiten 206 und den Systemagentenkern 210, einschließlich des einen oder der mehreren integrierten Arbeitsspeichersteuerungen 214. In einigen Ausführungsformen enthält der Systemagentenkern 210 auch eine Anzeigesteuerung 211, um eine Grafikprozessorausgabe zu einer oder mehreren gekoppelten Anzeigen zu lenken. In einigen Ausführungsformen kann die Anzeigesteuerung 211 auch ein separates Modul sein, das über mindestens eine Zwischenverbindung an den Grafikprozessor gekoppelt ist, oder kann innerhalb des Grafikprozessors 208 integriert sein.
In einigen Ausführungsformen wird eine Zwischenverbindungseinheit auf Ringbasis 212 verwendet, um die internen Komponenten des Prozessors 200 zu koppeln. Es kann jedoch eine alternative Zwischenverbindungseinheit verwendet werden, wie zum Beispiel eine Punkt-zu-Punkt-Zwischenverbindung, eine geschaltete Zwischenverbindung oder andere Techniken, einschließlich von Techniken, wie sie auf dem Fachgebiet wohlbekannt sind. In einigen Ausführungsformen koppelt der Grafikprozessor 208 über eine E/A-Verknüpfung 213 an die Ringzwischenverbindung 212.
Die beispielhafte E/A-Verknüpfung 213 stellt mindestens eine von mehreren Varianten von E/A-Zwischenverbindungen dar, einschließlich einer gehäuseinternen E/A-Zwischenverbindung, die eine Kommunikation zwischen verschiedenen Prozessorkomponenten und einem eingebetteten Hochleistungsarbeitsspeichermodul 218 ermöglicht, wie einem eDRAM-Modul. In einigen Ausführungsformen kann jeder der Prozessorkerne 202A-202N und der Grafikprozessor 208 eingebettete Arbeitsspeichermodule 218 als einen gemeinsam genutzten Last-Level-Zwischenspeicher verwenden.
In einigen Ausführungsformen sind die Prozessorkerne 202A-202N homogene Kerne, die die gleiche Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Anweisungssatzarchitektur (ISA) heterogen, 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 anderen Anweisungssatz ausführt. In einer Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Mikroarchitektur heterogen, wobei ein oder mehrere Kerne mit einem relativ hohen Energieverbrauch an einen oder mehrere Energiekerne mit einem niedrigeren Energieverbrauch koppeln. In einer Ausführungsform sind die Prozessorkerne 202A-202N in Bezug auf die Rechenfähigkeit heterogen. Zusätzlich kann der Prozessor 200 auf einem oder mehreren Chips oder als ein integrierter SoC-Schaltkreis implementiert werden, der zusätzlich zu anderen Komponenten die illustrierten Komponenten aufweist.
2B ist ein Blockdiagramm von Hardwarelogik eines Grafikprozessorkerns 219 nach einigen hierin beschriebenen Ausführungsformen. Elemente von 2B, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Der Grafikprozessorkern 219, manchmal als ein Kernsegment bezeichnet, kann ein oder mehrere Grafikkerne in einem modularen Grafikprozessor sein. Der Grafikprozessorkern 219 ist beispielhaft für ein Grafikkernsegment, und ein Grafikprozessor wie hierin beschrieben kann mehrere Grafikkernsegmente auf Grundlage von Zielleistung und Leistungsprofil enthalten. Jeder Grafikprozessorkern 219 kann einen festen Funktionsblock 230 enthalten, der an mehrere Subkerne 221A-221F gekoppelt ist, auch als Teilsegmente bezeichnet, die modulare Blöcke von Universal- und fester Funktionslogik enthalten.
In einigen Ausführungsformen enthält der feste Funktionsblock 230 eine Geometrie-/feste Funktionspipeline 231, die von allen Subkernen im Grafikprozessorkern 219 gemeinsam genutzt werden kann, zum Beispiel in Grafikprozessorimplementierungen mit niedrigerer Leistung und/oder niedrigerer Energie. In verschiedenen Ausführungsformen enthält die Geometrie-/feste Funktionspipeline 231 eine feste 3D-Funktionspipeline (z. B. die 3D-Pipeline 312 wie in 3 und 4), eine Video-Front-End-Einheit, einen Threaderzeuger und einen Thread-Dispatcher und eine vereinheitlichte Rückgabepufferverwaltung, die vereinheitlichte Rückgabepuffer verwaltet (z. B. den vereinheitlichten Rückgabepuffer 418 in 4, wie unten beschrieben).
In einer Ausführungsform enthält der feste Funktionsblock 230 auch eine Grafik-SoC-Schnittstelle 232, einen Grafik-Mikrocontroller 233 und eine Medienpipeline 234. Die Grafik-SoC-Schnittstelle 232 bietet eine Schnittstelle zwischen dem Grafikprozessorkern 219 und anderen Prozessorkernen innerhalb eines integrierten Ein-Chip-System-Schaltkreises. Der Grafikmikrocontroller 233 ist ein programmierbarer Subprozessor, der konfigurierbar ist, um verschiedene Funktionen des Grafikprozessorkerns 219, einschließlich von Threadversand, Planung und Vorwegnahme zu verwalten. Die Medienpipeline 234 (z. B. die Medienpipeline 316 von 3 und 4) enthält Logik, um das Decodieren, Codieren, Vorverarbeiten und/oder Nachbearbeiten von Multimediadaten, einschließlich Bild- und Videodaten zu ermöglichen. Die Medienpipeline 234 implementiert Medienoperationen über Anforderungen an Rechen- oder Abtastlogik in den Subkernen 221-221F.
In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 dem Grafikprozessorkern 219, mit Universalanwendungsprozessorkernen (z. B. CPUs) und/oder anderen Komponenten innerhalb eines SoC, einschließlich Arbeitsspeicherhierarchieelementen wie eines gemeinsam genutzten Last-Level-Zwischenspeichers, des System-RAM und/oder eingebettetem chipinternem oder paketinternem DRAM, zu kommunizieren. Die SoC-Schnittstelle 232 kann auch eine Kommunikation mit festen Funktionsvorrichtungen im SoC, wie Kameraabbildungspipelines ermöglichen und ermöglicht die Verwendung von und/oder implementiert globale Arbeitsspeicheratomik, die unter dem Grafikprozessorkern 219 und CPUs innerhalb des SoC gemeinsam genutzt werden kann. Die SoC-Schnittstelle 232 kann auch Energieverwaltungssteuerungen für den Grafikprozessorkern 219 implementieren und eine Schnittstelle zwischen einer Taktdomäne des Grafikkerns 219 und anderen Taktdomänen innerhalb des SoC ermöglichen. In einer Ausführungsform ermöglicht die SoC-Schnittstelle 232 einen Empfang von Befehlspuffern von einer Befehlsstreamingeinheit und einem globalen Thread-Dispatcher, die ausgelegt sind, jedem von einem oder mehreren Grafikkernen innerhalb eines Grafikprozessors Befehle und Anweisungen bereitzustellen. Die Befehle und Anweisungen können an die Medienpipeline 234 vergeben werden, wenn Medienoperationen durchzuführen sind, oder an eine Geometrie- und feste Funktionspipeline (z.B. die Geometrie- und feste Funktionspipeline 231, die Geometrie- und feste Funktionspipeline 237), wenn Grafikverarbeitungsoperationen durchzuführen sind.
Der Grafikmikrocontroller 233 kann ausgelegt sein, verschiedene Planungs- und Verwaltungsaufgaben für den Grafikprozessorkern 219 durchzuführen. In einer Ausführungsform kann der Grafikmikrocontroller 233 eine Grafik- und/oder Rechenarbeitslastplanung an den verschiedenen parallelen Grafikengines innerhalb der Ausführungseinheitsanordnungen (EU-Anordnungen) 222A-222F, 224A-224F innerhalb der Subkerne 221A-221F durchführen. In diesem Planungsmodell kann Hostsoftware, die auf einem CPU-Kern eines SoC ausgeführt wird, das den Grafikprozessorkern 219 enthält, Arbeitslasten an eine von mehreren Grafikprozessortürklingeln schicken, die eine Planungsoperation auf der jeweiligen Grafikengine aufruft. Planungsoperationen enthalten ein Ermitteln, welche Arbeitslast als Nächstes auszuführen ist, Übermitteln einer Arbeitslast an eine Befehlsstreamingeinheit, Vorbelegen von bestehenden Arbeitslasten, die auf einer Engine laufen, Überwachen eines Fortschritts einer Arbeitslast und Benachrichtigen einer Hostsoftware, wenn eine Arbeitslast abgeschlossen ist. In einer Ausführungsform kann der Grafikmikrocontroller 233 auch Niedrigenergie- oder Leerlaufzustände für den Grafikprozessorkern 219 ermöglichen, was dem Grafikprozessorkern 219 die Fähigkeit gibt, Register innerhalb des Grafikprozessorkerns 219 über Niedrigenergie-Übergänge hinweg unabhängig vom Betriebssystem und/oder der Grafiktreibersoftware auf dem System Register zu speichern und wiederherzustellen.
Der Grafikprozessorkern 219 kann mehr oder weniger als die veranschaulichten Subkerne 221A-221F aufweisen, bis zu N modulare Subkerne. Für jeden Satz von N Subkernen kann der Grafikprozessorkern 219 auch gemeinsam genutzte Funktionslogik 235, gemeinsam genutzten Arbeitsspeicher und/oder Zwischenspeicher 236, eine Geometrie-/feste Funktionspipeline 237 sowie zusätzliche feste Funktionslogik 238 enthalten, um verschiedene Grafik- und Rechenverarbeitungsoperationen zu beschleunigen. Die gemeinsam genutzte Funktionslogik 235 kann mit der gemeinsam genutzten Funktionslogik 420 von 4 assoziierte Logikeinheiten enthalten (z. B. Abtast-, Mathematik- und/oder Kommunikationslogik zwischen Threads), die von jedem der N Subkerne innerhalb des Grafikprozessorkerns 219 gemeinsam genutzt werden können. Der gemeinsam genutzte Arbeitsspeicher und/oder Zwischenspeicher 236 kann ein Last-Level-Zwischenspeicher für den Satz der N Subkerne 221A-221F innerhalb des Grafikprozessorkerns 219 sein und kann auch als gemeinsam genutzter Arbeitsspeicher dienen, auf den von mehreren Subkernen zugegriffen werden kann. Die Geometrie-/feste Funktionspipeline 237 kann anstatt der Geometrie-/festen Funktionspipeline 231 innerhalb des festen Funktionsblocks 230 enthalten sein und kann die gleichen oder ähnliche Logikeinheiten enthalten.
In einer Ausführungsform enthält der Grafikprozessorkern 219 eine zusätzliche feste Funktionslogik 238, die verschiedene feste Funktionsbeschleunigungslogik zur Verwendung durch den Grafikprozessorkern 219 enthalten kann. In einer Ausführungsform enthält die zusätzliche feste Funktionslogik 238 eine zusätzliche Geometriepipeline zur Verwendung bei Schattierung nur nach Position. Bei Schattierung nur nach Position gibt es zwei Geometriepipelines, die vollständige Geometriepipeline innerhalb der Geometrie-/festen Funktionspipeline 238, 231 und eine Auswahlpipeline, die eine zusätzliche Geometriepipeline ist, die in der zusätzlichen festen Funktionslogik 238 enthalten sein kann. In einer Ausführungsform ist die Auswahlpipeline eine verkürzte Version der vollständigen Geometriepipeline. Die vollständige Pipeline und die Auswahlpipeline können unterschiedliche Instanzen der gleichen Anwendung ausführen, wobei jede Instanz einen separaten Kontext aufweist. Schattierung nur nach Position kann lange Auswahlläufe verworfener Dreiecke verbergen, was in einigen Fällen ermöglicht, dass die Schattierung früher abgeschlossen wird. Beispielsweise und in einer Ausführungsform kann die Auswahlpipeline innerhalb der zusätzlichen festen Funktionslogik 238 Positionsshader parallel zur Hauptanwendung ausführen und erzeugt allgemein wichtige Ergebnisse schneller als die vollständige Pipeline, da die Auswahlpipeline nur das Positionsattribut der Vertices abruft und schattiert, ohne eine Rasterung und ein Rendern der Pixel im Framepuffer durchzuführen. Die Auswahlpipeline kann die erzeugten kritischen Ergebnisse verwenden, um Sichtbarkeitsinformationen für alle Dreiecke unabhängig davon zu berechnen, ob diese Dreiecke ausgewählt sind. Die vollständige Pipeline (die in diesem Fall als eine Wiederholungspipeline bezeichnet werden kann) kann die Sichtbarkeitsinformationen verwenden, um die ausgewählten Dreiecke zu überspringen und nur die sichtbaren Dreiecke zu schattieren, die schließlich an die Rasterungsphase weitergegeben werden.
In einer Ausführungsform kann die zusätzliche feste Funktionslogik 238 auch Beschleunigungslogik für maschinelles Lernen enthalten, wie eine feste Funktionsmatrixmultiplikationslogik, für Implementierungen, die Optimierungen zum Training bei maschinellem Lernen oder Schlussfolgerungen enthalten.
Innerhalb jedes Grafik-Subkerns 221A-221F ist ein Satz von Ausführungsressourcen enthalten, die verwendet werden können, um Grafik-, Medien- und Rechenoperationen als Reaktion auf Anforderungen von einer Grafikpipeline, einer Medienpipeline oder Shaderprogrammen durchzuführen. Die Grafik- Subkerne 221A-221F enthalten mehrere EU-Anordnungen 222A-222F, 224A-224F, Thread-Dispatch- und Logik zur Kommunikation zwischen Threads (TD/IC) 223A-223F, einen 3D-Abtaster (z. B. Texturabtaster) 225A-225F, einen Medienabtaster 206A-206F, einen Shader-Prozessor 227A-227F und gemeinsam genutzten lokalen Arbeitsspeicher (SLM) 228A-228F. Die EU-Anordnungen 222A-222F, 224A-224F enthalten jeweils mehrere Ausführungseinheiten, die Universalgrafikverarbeitungseinheiten sind, die fähig sind, Gleitkomma- und Ganzzahl-/Fixpunktlogikoperationen im Dienst einer Grafik-, Medien- oder Rechenoperation durchzuführen, einschließlich Grafik-, Medien- oder Rechenshaderprogramme. Die TD/IC-Logik 223A-223F führt lokale Thread-Dispatch- und Threadsteueroperationen für die Ausführungseinheiten innerhalb eines Subkerns durch und ermöglichen eine Kommunikation zwischen Threads, die auf den Ausführungseinheiten des Subkerns ausgeführt werden. Der 3D-Abtaster 225A-225F kann eine Textur oder andere 3D-Grafik-bezogene Daten in einen Arbeitsspeicher lesen. Der 3D-Abtaster kann Texturdaten auf Grundlage eines konfigurierten Abtastzustands und dem mit einer bestimmten Textur assoziierten Texturformat unterschiedlich lesen. Der Medienabtaster 206A-206F kann ähnliche Leseoperationen auf Grundlage des mit Mediendaten assoziierten Typs und Formats durchführen. In einer Ausführungsform kann jeder Grafik-Subkern 221A-221F alternativ einen vereinheitlichten 3D- und Medienabtaster enthalten. Threads, die auf den Ausführungseinheiten in jedem der Subkerne 221A-221F ausgeführt werden, können den gemeinsam genutzten Arbeitsspeicher 228A-228F in jedem Subkern verwenden, um zu ermöglichen, dass Threads, die in einer Threadgruppe ausgeführt werden, unter Verwendung eines gemeinsamen chipinternen Arbeitsspeicherbestands ausgeführt werden.
2C veranschaulicht eine Grafikverarbeitungseinheit (GPU) 239, die dedizierte Sätze von Grafikverarbeitungsressourcen enthält, die in Mehrkerngruppen 240A-240N angeordnet sind. Während nur die Details von einer einzigen Mehrkerngruppe 240A bereitgestellt werden, ist klar, dass die anderen Mehrkerngruppen 240B-240N mit den gleichen oder ähnlichen Sätzen von Grafikverarbeitungsressourcen ausgestattet sein können.
Wie veranschaulicht, kann eine Mehrkerngruppe 240A einen Satz von Grafikkernen 243, einen Satz von Tensorkernen 244 und einen Satz von Raytracingkernen 245 enthalten. Ein Planer/Dispatcher 241 plant und verteilt die Grafikthreads zur Ausführung auf den verschiedenen Kernen 243, 244, 245. Ein Satz von Registerdateien 242 speichert Operandenwerte, die von den Kernen 243, 244, 245 beim Ausführen der Grafikthreads verwendet werden. Diese können zum Beispiel Ganzzahlregister zum Speichern von ganzzahligen Werten, Gleitkommaregister zum Speichern von Gleitkommawerten, Vektorregister zum Speichern von gepackten Datenelementen (ganzzahligen und/oder Gleitkomma-Datenelementen) und Kachelregister zum Speichern von Tensor-/Matrixwerten enthalten. In einer Ausführungsform sind die Kachelregister als kombinierte Sätze von Vektorregistern implementiert.
Ein oder mehrere kombinierte Level-1(L1)-Zwischenspeicher und gemeinsam genutzte Arbeitsspeichereinheiten 247 speichern Grafikdaten wie Texturdaten, Vertexdaten, Pixeldaten, Strahldaten, Hüllkörperdaten usw. lokal innerhalb jeder Mehrkerngruppe 240A. Eine oder mehrere Textureinheiten 247 können auch verwendet werden, um Texturoperationen durchzuführen, wie Texturabbildung und Abtastung. Ein von allen oder einer Teilmenge der Mehrkerngruppen 240A-240N gemeinsam genutzter Level-2(L2)-Zwischenspeicher 253 speichert Grafikdaten und/oder Anweisungen für mehrere gleichzeitige Grafikthreads. Wie veranschaulicht kann der L2-Zwischenspeicher 253 über eine Vielzahl von Mehrkerngruppen 240A-240N hinweg gemeinsam genutzt werden. Eine oder mehrere Arbeitsspeichersteuerungen 248 koppeln die GPU 239 an einen Arbeitsspeicher 249, der ein Systemarbeitsspeicher (z. B. DRAM) und/oder ein dedizierter Grafikspeicher (z. B. GDDR6-Arbeitsspeicher) sein kann.
Eingabe-/Ausgabe(E/A)-Verschaltung 250 koppelt die GPU 239 an eine oder mehrere E/A-Vorrichtungen 252, wie digitale Signalprozessoren (DSPs), Netzwerksteuerungen oder Benutzereingabevorrichtungen. Eine chipinterne Zwischenverbindung kann verwendet werden, um die E/A-Vorrichtungen 252 an die GPU 239 und den Arbeitsspeicher 249 zu koppeln. Eine oder mehrere E/A-Arbeitsspeicherverwaltungseinheiten (IOMMUs) 251 der E/A-Verschaltung 250 koppeln die E/A-Vorrichtungen 252 direkt an den Systemarbeitsspeicher 249. In einer Ausführungsform verwaltet die IOMMU 251 mehrere Sätze von Seitentabellen, um virtuelle Adressen auf physische Adressen im Systemarbeitsspeicher 249 abzubilden. In dieser Ausführungsform können die E/A-Vorrichtungen 252, CPU(s) 246 und GPU(s) 239 den gleichen virtuellen Adressraum gemeinsam nutzen.
In einer Implementierung unterstützt die IOMMU 251 Virtualisierung. In diesem Fall kann sie einen ersten Satz von Seitentabellen, um virtuelle Gast-/Grafikadressen auf physische Gast-/Grafikadressen abzubilden, und einen zweiten Satz von Seitentabellen verwalten, um die physischen Gast-/Grafikadressen auf physische System-/Hostadressen (z. B. innerhalb des Systemarbeitsspeichers 249) abzubilden. Die Basisadressen jedes des ersten und des zweiten Satzes von Seitentabellen können in Steuerregistern gespeichert sein und bei einem Kontextwechsel ausgetauscht werden (sodass z. B. dem neuen Kontext Zugriff auf den relevanten Satz von Seitentabellen bereitgestellt wird). Obwohl in 2C nicht veranschaulicht, kann jeder der Kerne 243, 244, 245 und/oder der Mehrkerngruppen 240A-240N Übersetzungspuffer (TLBs) enthalten, um Übersetzungen von virtuellen Gast- auf physische Gastadressen, Übersetzungen von physischen Gast- auf physische Hostadressen und Übersetzungen von virtuellen Gast- auf physische Hostadressen zwischenzuspeichern.
In einer Ausführungsform sind die CPUs 246, GPUs 239 und E/A-Vorrichtungen 252 auf einem einzigen Halbleiterchip und/oder Chipgehäuse integriert. Der veranschaulichte Arbeitsspeicher 249 kann auf demselben Chip integriert sein oder kann über eine chipexterne Schnittstelle an die Arbeitsspeichersteuerungen 248 gekoppelt sein. In einer Implementierung umfasst der Arbeitsspeicher 249 GDDR6-Arbeitsspeicher, der den gleichen virtuellen Adressraum wie andere physische Arbeitsspeicher auf Systemebene nutzt, obwohl die zugrunde liegenden Prinzipien der Erfindung nicht auf diese spezifische Implementierung beschränkt sind.
In einer Ausführungsform enthalten die Tensorkerne 244 eine Vielzahl von Ausführungseinheiten, die spezifisch konstruiert sind, um Matrixoperationen durchzuführen, die die grundlegenden Rechenoperationen sind, die verwendet werden, um Operationen für tiefgehendes Lernen durchzuführen. Beispielsweise können gleichzeitige Matrixmultiplikationsoperationen für Training von neuronalen Netzen und Schlussfolgerungen verwendet werden. Die Tensorkerne 244 können eine Matrixverarbeitung unter Verwendung einer Vielfalt von Operandengenauigkeiten durchführen, einschließlich Gleitkomma mit einfacher Genauigkeit (z. B. 32 Bits), Gleitkomma mit halber Genauigkeit (z. B. 16 Bits), ganzzahliger Wörter (16 Bits), Bytes (8 Bits) und Halbbytes (4 Bits). In einer Ausführungsform extrahiert eine Implementierung eines neuronalen Netzes Merkmale jeder gerenderten Szene, wobei sie möglicherweise Details aus mehreren Rahmen kombiniert, um ein hochwertiges endgültiges Bild zu konstruieren.
In Implementierungen von tiefgehendem Lernen kann parallele Matrixmultiplikationsarbeit zur Ausführung auf den Tensorkernen 244 eingeplant werden. Insbesondere erfordert das Training von neuronalen Netzen eine wesentliche Anzahl von Matrix-Skalarproduktoperationen. Um eine Formulierung eines inneren Produktes einer N-mal-N-mal-N-Matrixmultiplikation zu verarbeiten, können die Tensorkerne 244 mindestens N Skalarprodukt-Verarbeitungselemente enthalten. Bevor die Matrixmultiplikation beginnt, wird eine gesamte Matrix in Kachelregister geladen und mindestens eine Spalte einer zweiten Matrix wird in jedem Zyklus für N Zyklen geladen. In jedem Zyklus gibt es N Skalarprodukte, die verarbeitet werden.
Matrixelemente können abhängig von der bestimmten Implementierung mit unterschiedlichen Präzisionen gespeichert werden, einschließlich von 16-Bit-Wörtern, 8-Bit-Bytes (z. B. INT8) und 4-Bit-Halbbytes (z. B. INT4). Unterschiedliche Präzisionsmodi können für die Tensorkerne 244 angegeben werden, um sicherzustellen, dass die effizienteste Präzision für unterschiedliche Arbeitslasten verwendet wird (wie z. B. Schlussfolgerungsarbeitslasten, die eine Quantisierung in Bytes und Halbbytes tolerieren können).
In einer Ausführungsform beschleunigen die Raytracingkerne 245 Raytracing-Operationen sowohl für Echzeit-Raytracing- als auch Nicht-Echtzeit-Raytracing-Implementierungen. Insbesondere enthalten die Raytracingkerne 245 Strahltraversierungs-/Schnittverschaltung zum Durchführen einer Strahltraversierung unter Verwendung von Hüllkörperhierarchien (BVHs) und zum Identifizieren von Schnittpunkten zwischen Strahlen und Primitiven, die innerhalb der BVH-Volumina eingeschlossen sind. Die Raytracingkerne 245 können auch Verschaltung zum Durchführen einer Tiefenprüfung und Aussonderung (z. B. unter Verwendung eines Z-Puffers oder einer ähnlichen Anordnung) enthalten. In einer Implementierung führen die Raytracingkerne 245 Traversierungs- und Schnittoperationen zusammen mit den hierin beschriebenen Bildrauschunterdrückungstechniken durch, von denen zumindest ein Teil auf den Tensorkernen 244 ausgeführt werden kann. In einer Ausführungsform implementieren die Tensorkerne 244 zum Beispiel ein neuronales Netz für tiefgehendes Lernen, um eine Rauschunterdrückung von Frames durchzuführen, die von den Raytracingkernen 245 generiert wurden. Die CPU(s) 246, die Grafikkerne 243 und/oder die Raytracingkerne 245 können jedoch auch die Gesamtheit oder einen Teil der Rauschunterdrückung und/oder Algorithmen für tiefgehendes Lernen implementieren.
Darüber hinaus, wie oben beschrieben, kann ein verteilter Ansatz für Rauschunterdrückung eingesetzt werden, bei dem sich die GPU 239 in einer Rechenvorrichtung befindet, die über ein Netzwerk oder eine Hochgeschwindigkeits-Zwischenverbindung an andere Rechenvorrichtungen gekoppelt ist. In dieser Ausführungsform nutzen die miteinander verbundenen Rechenvorrichtungen neuronale Netz-Lern-/Trainingsdaten gemeinsam, um die Geschwindigkeit zu verbessern, mit der das Gesamtsystem lernt, um eine Rauschunterdrückung für unterschiedliche Arten von Bildrahmen und/oder unterschiedliche Grafikanwendungen durchzuführen.
In einer Ausführungsform verarbeiten die Raytracingkerne 245 alle BVH-Traversierungs- und Strahl-Primitiven-Schnittpunkte, was die Grafikkerne 243 vor einem Überlasten mit Tausenden von Anweisungen pro Strahl schützt. In einer Ausführungsform enthält jeder Raytracingkern 245 einen ersten Satz von Sonderverschaltungen zum Durchführen von Begrenzungsrahmenprüfungen (z. B. für Traversierungsoperationen) und einen zweiten Satz von Sonderverschaltung zum Durchführen der Strahl-Dreieck-Schnittprüfungen (z. B. sich schneidende Strahlen, die durchlaufen wurden). Deshalb kann die Mehrkerngruppe 240A in einer Ausführungsform einfach eine Strahlabtastung starten und die Raytracingkerne 245 unabhängig eine Strahltraversierung und Schnittpunktbestimmung durchführen und Trefferdaten (z. B. ein Treffer, keine Treffer, mehrere Treffer usw.) an den Threadkontext zurückgeben. Die anderen Kerne 243, 244 sind freigegeben, um eine andere Grafik- oder Rechenarbeit durchzuführen, während die Raytracingkerne 245 die Traversierungs- und Schnittoperationen durchführen.
In einer Ausführungsform enthält jeder Raytracingkern 245 eine Traversierungseinheit, um BVH-Testoperationen durchzuführen, und eine Schnitteinheit, die Strahl-Primitiven-Schnittpunkttests durchführt. Die Schnitteinheit generiert eine Antwort mit „Treffer“, „kein Treffer“ oder „mehrere Treffer“, die sie dem passenden Thread bereitstellt. Während der Traversierungs- und Schnittoperationen sind die Ausführungsressourcen der anderen Kerne (z. B. der Grafikkerne 243 und der Tensorkerne 244) freigegeben, um andere Formen von Grafikarbeit durchzuführen.
In einer bestimmten Ausführungsform, die unten beschrieben ist, wird ein hybrider Rasterungs-/Raytracing-Ansatz verwendet, bei dem Arbeit auf die Grafikkerne 243 und die Raytracingkerne 245 verteilt ist.
In einer Ausführungsform enthalten die Raytracingkerne 245 (und/oder andere Kerne 243, 244) Hardwareunterstüzung für einen Raytracing-Anweisungssatz, wie DirectX Ray Tracing (DXR) von Microsoft, der einen DispatchRays-Befehl sowie Strahlengenerierungs-, Nächstliegender-Treffer-, Beliebiger-Treffer- und Verfehlungs-Shader enthält, was die Zuweisung eindeutiger Sätze von Shadern und Texturen für jedes Objekt ermöglicht. Eine weitere Raytracing-Plattform, die von den Raytracingkernen 245, Grafikkernen 243 und Tensorkernen 244 unterstützt werden kann, ist Vulkan 1.1.85. Es ist jedoch anzumerken, dass die zugrunde liegenden Prinzipien der Erfindung nicht auf einen bestimmten Raytracing-ISA beschränkt ist.
Im Allgemeinen können verschiedene Kerne 245, 244, 243 einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlengenerierung, für den nächstgelegenen Treffer, einen beliebigen Treffer, einen Strahl-Primitiven-Schnitt, eine Konstruktion von Begrenzungsrahmen pro Primitiv und eine hierarchische Konstruktion von Begrenzungsrahmen, Verfehlung, Besuch und Ausnahmen enthält. Genauer enthält eine Ausführungsform Raytracing-Anweisungen, um die folgenden Funktionen durchzuführen:

Strahlgenerierung - Strahlgenerierungsanweisungen können für jedes Pixel, jede Probe oder eine andere benutzerdefinierte Arbeitszuweisung ausgeführt werden.
Nächstgelegener Treffer - Eine Anweisung für den nächstgelegenen Treffer kann ausgeführt werden, um den nächstgelegenen Schnittpunkt eines Strahls mit Primitiven innerhalb einer Szene aufzufinden.
Beliebiger Treffer - Eine Anweisung für einen beliebigen Treffer identifiziert mehrere Schnitte zwischen einem Strahl und Primitiven innerhalb einer Szene, um möglicherweise einen neuen nächstgelegenen Schnittpunkt zu identifizieren.
Schnitt - Eine Schnittanweisung führt einen Schnitttest zwischen Strahl und
Primitivem durch und gibt ein Ergebnis aus.
Begrenzungsrahmenkonstruktion pro Primitivem - Diese Anweisung baut einen Begrenzungsrahmen um einen bestimmten Primitiven oder eine Gruppe von Primitiven auf (z. B. beim Aufbauen einer neuen BVH oder anderen Beschleunigungsdatenstruktur).
Verfehlung - Zeigt an, dass ein Strahl die gesamte Geometrie innerhalb einer Szene oder einem angegebenen Bereich einer Szene verfehlt.
Besuch - Zeigt die untergeordneten Volumina an, die ein Strahl durchläuft.
Ausnahmen - Enthält verschiedene Arten von Ausnahmehandlern (die z. B. für verschiedene Fehlerbedingungen aufgerufen werden).

2D ist ein Blockdiagramm einer Universal-Grafikprozessoreinheit (GPGPU) 270, die als ein Grafikprozessor und/oder Rechenbeschleuniger konfiguriert werden kann, nach hierin beschriebenen Ausführungsformen. Die GPGPU 270 kann über einen oder mehrere System- und/oder Arbeitsspeicherbusse mit Hostprozessoren (z. B. einer oder mehreren CPU(s) 246) und Arbeitsspeicher 271, 272 verbunden sein. In einer Ausführungsform ist der Arbeitsspeicher 271 Systemarbeitsspeicher, der mit der einen oder den mehreren CPU(s) 246 gemeinsam genutzt werden kann, während der Arbeitsspeicher 272 Vorrichtungsarbeitsspeicher ist, der für die GPGPU 270 dediziert ist. In einer Ausführungsform können Komponenten innerhalb der GPGPU 270 und des Vorrichtungsarbeitsspeichers 272 in Arbeitsspeicheradressen abgebildet werden, die für die eine oder die mehreren CPU(s) 246 zugänglich sind. Ein Zugriff auf die Arbeitsspeicher 271 und 272 kann über eine Arbeitsspeichersteuerung 268 ermöglicht werden. In einer Ausführungsform enthält die Arbeitsspeichersteuerung 268 eine interne Steuerung für direkten Speicherzugriff (DMA) 269 oder kann Logik enthalten, um Operationen durchzuführen, die andernfalls von einer DMA-Steuerung durchgeführt würden.
Die GPGPU 270 enthält mehrere Zwischenspeicher, einschließlich eines L2-Zwischenspeichers 253, eines LI-Zwischenspeichers 254, eines Anweisungszwischenspeichers 255 und eines gemeinsam genutzten Arbeitsspeichers 256, von dem zumindest ein Abschnitt auch als ein Zwischenspeicher partitioniert sein kann. Die GPGPU 270 enthält auch mehrere Recheneinheiten 260A-260N. Jede Recheneinheit 260A-260N enthält einen Satz von Vektorregistern 261, Skalarregistern 262, Vektorlogikeinheiten 263 und Skalarlogikeinheiten 264. Die Recheneinheiten 260A-260N können auch lokalen gemeinsam genutzten Arbeitsspeicher 265 und einen Programmzähler 266 enthalten. Die Recheneinheiten 260A-260N können an einen Konstantzwischenspeicher 267 koppeln, der verwendet werden kann, um konstante Daten zu speichern, die Daten sind, die sich während des Ablaufs des Kernel- oder Shaderprogramms nicht ändern, das auf der GPGPU 270 ausgeführt wird. In einer Ausführungsform ist der Konstantzwischenspeicher 267 ein skalarer Datenzwischenspeicher und zwischengespeicherte Daten können direkt in die Skalarregister 262 abgerufen werden.
Während des Betriebs können die eine oder die mehreren CPU(s) 246 Befehle in Register oder Arbeitsspeicher in der GPGPU 270 schreiben, die bzw. der auf einen zugänglichen Adressraum abgebildet wurden bzw. wurde. Die Befehlsprozessoren 257 können die Befehle aus Registern oder Arbeitsspeicher lesen und ermitteln, wie diese Befehle innerhalb der GPGPU 270 verarbeitet werden. Ein Thread-Dispatcher 258 kann dann verwendet werden, um Threads an die Recheneinheiten 260A-260N zu verteilen, um diese Befehle durchzuführen. Jede Recheneinheit 260A-260N kann Threads unabhängig von anderen Recheneinheiten ausführen. Zusätzlich kann jede Recheneinheit 260A-260N unabhängig für eine bedingte Berechnung konfiguriert sein und kann bedingt die Ergebnisse der Berechnung an einen Arbeitsspeicher ausgeben. Die Befehlsprozessoren 257 können die eine oder die mehreren CPU(s) 246 unterbrechen, wenn die vorgelegten Befehle abgeschlossen sind.
3A-3C veranschaulichen Blockdiagramme von zusätzlichen Grafikprozessor- und Rechenbeschleunigerarchitekturen, die von hierin beschriebenen Ausführungsformen bereitgestellt werden. Die Elemente von 3A-3C, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
3A ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit sein kann oder ein Grafikprozessor sein kann, der in eine Vielzahl von Verarbeitungskernen oder anderen Halbleitervorrichtungen, wie unter anderem Arbeitsspeichervorrichtungen oder Netzwerkschnittstellen, integriert ist. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine in den Arbeitsspeicher abgebildete E/A-Schnittstelle mit Registern auf dem Grafikprozessor und mit in den Prozessorarbeitsspeicher platzierten Befehlen. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Arbeitsspeicherschnittstelle 314, um auf den Arbeitsspeicher zuzugreifen. Die Arbeitsspeicherschnittstelle 314 kann eine Schnittstelle zu einem lokalen Arbeitsspeicher, einem oder mehreren internen Zwischenspeichern, einem oder mehreren gemeinsam genutzten externen Zwischenspeichern und/oder Systemarbeitsspeicher sein.
In einigen Ausführungsformen enthält der Grafikprozessor 300 auch eine Anzeigesteuerung 302, um eine Anzeigevorrichtung 318 mit Anzeigedaten anzusteuern. Die Anzeigesteuerung 302 enthält Hardware für eine oder mehrere Überlagerungsebenen für die Anzeige und für eine Zusammensetzung mehrerer Schichten von Video oder Benutzerschnittstellenelementen. Die Anzeigevorrichtung 318 kann eine interne oder externe Anzeigevorrichtung sein. In einer Ausführungsform kann die Anzeigevorrichtung 318 eine am Kopf montierte Anzeigevorrichtung wie eine Anzeigevorrichtung mit virtueller Realität (VR) oder eine Anzeigevorrichtung mit erweiterter Realität (AR) sein. In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Videocodecengine 306, um Medien in ein oder mehrere Mediencodierformate zu codieren, aus diesen zu decodieren oder zwischen diesen transcodieren, einschließlich unter anderem Formaten der Moving Picture Experts Group (MPEG) wie MGEG-2, Advanced-Video-Coding(AVC)-Formaten wie H.264/MPEG-4 AVC, H.265/HEVC, VP8, VP9 der Alliance for Open Media (AOMedia) sowie 421M/VC-1 der Society of Motion Picture & Television Engineers (SMPTE) und Formaten der Joint Photographic Experts Group (JPEG) wie JPEG- und Motion-JPEG(MJPEG)-Formate.
In einigen Ausführungsformen enthält der Grafikprozessor 300 eine Blockbildtransfer(BLIT)-Engine 304, um zweidimensionale (2D) Rasteroperationen einschließlich beispielsweise Bitgrenzen-Blocktransfers. In einer Ausführungsform werden 2D-Grafikoperationen jedoch unter Verwendung einer oder mehrerer Komponenten der Grafikverarbeitungsengine (GPE) 310 durchgeführt. In einigen Ausführungsformen ist GPE 310 eine Rechenengine zum Durchführen von Grafikoperationen, einschließlich von dreidimensionalen (3D) Grafikoperationen und Medienoperationen.
In einigen Ausführungsformen enthält die GPE 310 eine 3D-Pipeline 312 zum Durchführen von 3D-Operationen, wie Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die primitive 3D-Formen (z. B. Rechteck, Dreieck usw.) bearbeiten. Die 3D-Pipeline 312 enthält programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements durchführen und/oder Ausführungsthreads in einem 3D/Medien-Subsystem 315 zu erzeugen. Während die 3D-Pipeline 312 verwendet werden kann, um Medienoperationen durchzuführen, enthält eine Ausführungsform der GPE 310 auch eine Medienpipeline 316, die spezifisch verwendet wird, um Medienoperationen wie eine Video-Nachbearbeitung und Bildverbesserung durchzuführen.
In einigen Ausführungsformen enthält die Medienpipeline 316 feste Funktions- oder programmierbare Logikeinheiten, um statt der oder im Auftrag der Videocodecengine 306 eine oder mehrere spezialisierte Medienoperationen durchzuführen, wie eine Videocodecbeschleunigung, Videozeilenentflechtung und Videocodierbeschleunigung. In einigen Ausführungsformen enthält die Medienpipeline 316 zusätzlich eine Threaderzeugungseinheit, um Threads zur Ausführung im 3D-Medien-Subsystem 315 zu erzeugen. Die erzeugten Threads führen Berechnungen für die Medienoperationen auf einer oder mehreren Grafikausführungseinheiten durch, die im 3D/Medien-Subsystem 315 enthalten sind.
In einigen Ausführungsformen enthält das 3D/Medien-Subsystem 315 Logik zum Ausführen von Threads, die von der 3D-Pipeline 312 und der Medienpipeline 316 erzeugt wurden. In einer Ausführungsform senden die Pipelines Threadausführungsanforderungen an das 3D/Medien-Subsystem 315, das Threadversandlogik zum Vermitteln und Versenden der verschiedenen Anforderungen an verfügbare Threadausführungsressourcen enthält. Die Ausführungsressourcen enthalten eine Anordnung von Grafikausführungseinheiten, um die 3D- und Medienthreads zu verarbeiten. In einigen Ausführungsformen enthält das 3D/Medien-Subsystem 315 einen oder mehrere interne Zwischenspeicher für Threadanweisungen und Daten. In einigen Ausführungsformen enthält das Subsystem auch gemeinsam genutzten Arbeitsspeicher, einschließlich von Registern und adressierbarem Arbeitsspeicher, um Daten zwischen Threads zu übermitteln und Ausgabedaten zu speichern.
3B veranschaulicht einen Grafikprozessor 320 mit einer gekachelten Architektur nach hierin beschriebenen Ausführungsformen. In einer Ausführungsform enthält der Grafikprozessor 320 ein Grafikverarbeitungsengine-Cluster 322 mit mehreren Instanzen der Grafikverarbeitungsengine 310 von 3A innerhalb einer Grafikenginekachel 310A-310D. Jede Grafikenginekachel 310A-310D kann über einen Satz von Kachelzwischenverbindungen 323A-323F miteinander verbunden werden. Jede Grafikenginekachel 310A-310D kann auch über Arbeitsspeicherzwischenverbindungen 325A-325D mit einem Arbeitsspeichermodul oder einer Arbeitsspeichervorrichtung 326A-326D verbunden sein. Die Arbeitsspeichervorrichtungen 326A-326D können eine beliebige Grafikspeichertechnologie verwenden. Die Arbeitsspeichervorrichtungen 326A-326D können beispielsweise Grafikspeicher mit doppelter Datenrate (GDDR) sein. Die Arbeitsspeichervorrichtungen 326A-326D sind in einer Ausführungsform Arbeitsspeichermodule mit hoher Bandbreite (HBM-Module), die mit ihrer jeweiligen Grafikenginekachel 310A-310D chipintern sein können. In einer Ausführungsform sind die Arbeitsspeichervorrichtungen 326A-326D gestapelte Arbeitsspeichervorrichtungen, die oben auf ihrer jeweiligen Grafikenginekachel 310A-310D gestapelt sein können. In einer Ausführungsform residiert jede Grafikenginekachel 310A-310D und zugehöriger Arbeitsspeicher 326A-326D auf separaten Einzelchips, die auf einen Basischip oder ein Basissubstrat gebondet sind, wie ausführlicher in 11B-11D beschrieben wird.
Das Grafikverarbeitungsengine-Cluster 322 kann mit einer chipinternen oder gehäuseinternen Fabric-Zwischenverbindung 324 verbunden sein. Die Fabric-Zwischenverbindung 324 kann eine Kommunikation zwischen Grafikenginekacheln 310A-310D und Komponenten wie dem Videocodec 306 und einer oder mehreren Kopierengines 304 ermöglichen. Die Kopierengines 304 können verwendet werden, um Daten aus den, in die und zwischen den Arbeitsspeichervorrichtungen 326A-326D und Arbeitsspeicher zu bewegen, der zum Grafikprozessor 320 extern ist (z. B. Systemarbeitsspeicher). Die Fabric-Zwischenverbindung 324 kann auch verwendet werden, um die Grafikenginekacheln 310A-310D miteinander zu verbinden. Der Grafikprozessor 320 kann optional eine Anzeigesteuerung 302 enthalten, um eine Verbindung mit einer externen Anzeigevorrichtung 318 zu ermöglichen. Der Grafikprozessor kann auch als ein Grafik- oder Rechenbeschleuniger konfiguriert sein. In der Beschleunigerkonfiguration können die Anzeigesteuerung 302 und die Anzeigevorrichtung 318 weggelassen sein.
Der Grafikprozessor 320 kann über eine Hostschnittstelle 328 an ein Hostsystem anbinden. Die Hostschnittstelle 328 kann eine Kommunikation zwischen dem Grafikprozessor 320, Systemarbeitsspeicher und/oder anderen Systemkomponenten ermöglichen. Die Hostschnittstelle 328 kann beispielsweise ein PCI-Express-Bus oder ein anderer Typ von Hostsystemschnittstelle sein.
3C veranschaulicht einen Rechenbeschleuniger 330 nach hierin beschriebenen Ausführungsformen. Der Rechenbeschleuniger 330 kann architekturelle Ähnlichkeiten mit dem Grafikprozessor 320 von 3B enthalten und ist für eine Rechenbeschleunigung optimiert. Ein Rechenenginecluster 332 kann einen Satz von Rechenenginekacheln 340A-340D enthalten, die Ausführungslogik enthalten, die für parallele oder vektorbasierte Universal-Rechenoperationen optimiert ist. In einigen Ausführungsformen enthalten die Rechenenginekacheln 340A-340D keine feste Funktionsgrafikverarbeitungslogik, obwohl eine oder mehrere der Rechenenginekacheln 340A-340D in einer Ausführungsform Logik enthalten kann, um eine Medienbeschleunigung durchzuführen. Die Rechenenginekacheln 340A-340D können über Arbeitsspeicherzwischenverbindungen 325A-325D an Arbeitsspeicher 326A-326D anbinden. Der Arbeitsspeicher 326A-326D und Arbeitsspeicherzwischenverbindungen 325A-325D können eine ähnliche Technologie wie im Grafikprozessor 320 sein oder können unterschiedlich sein. Die Grafikrechenenginekacheln 340A-340D können auch über einen Satz von Kachelzwischenverbindungen 323A-323F miteinander verbunden sein und können mit und/oder miteinander durch eine Fabric-Zwischenverbindung 324 verbunden sein. In einer Ausführungsform enthält der Rechenbeschleuniger 330 enthält einen großen L3-Zwischenspeicher 336, der als ein vorrichtungsweiter Zwischenspeicher konfiguriert sein kann. Der Rechenbeschleuniger 330 kann auch über eine Hostschnittstelle 328 auf eine ähnliche Weise wie der Grafikprozessor 320 von 3B an einen Hostprozessor und einem Arbeitsspeicher anbinden.
Grafikverarbeitungsengine
4 ist ein Blockdiagramm einer Grafikverarbeitungsengine 410 eines Grafikprozessors in Übereinstimmung mit einigen Ausführungsformen. Die Grafikverarbeitungsengine (GPE) 410 ist in einer Ausführungsform eine Version der in 3A gezeigten GPE 310 und kann auch eine Grafikenginekachel 310A-310D von 3B repräsentieren. Elemente von 4, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. Beispielsweise sind die 3D-Pipeline 312 und die Medienpipeline 316 von 3A veranschaulicht. Die Medienpipeline 316 ist in einigen Ausführungsformen der GPE 410 optional und ist möglicherweise nicht explizit in der GPE 410 enthalten. In mindestens einer Ausführungsform ist ein separater Medien- und/oder Bildprozessor an die GPE 410 gekoppelt.
In einigen Ausführungsformen koppelt die GPE 410 an eine Befehlsstreamingeinheit 403, die der 3D-Pipeline 312 und/oder den Medienpipelines 316 einen Befehlsstrom bereitstellt, oder enthält eine solche. In einigen Ausführungsformen ist die Befehlsstreamingeinheit 403 an Arbeitsspeicher gekoppelt, der Systemarbeitsspeicher oder einer oder mehrerer von einem internen Zwischenspeicher und einem gemeinsam genutzten Zwischenspeicher sein kann. In einigen Ausführungsformen empfängt die Befehlsstreamingeinheit 403 Befehle vom Arbeitsspeicher und sendet die Befehle an die 3D-Pipeline 312 und/oder die Medienpipeline 316. Die Befehle sind Direktiven, die von einem Ringpuffer abgerufen wurden, der Befehle für die 3D-Pipeline 312 und die Medienpipeline 316 speichert. In einer Ausführungsform kann der Ringpuffer zusätzlich Batchbefehlspuffer enthalten, die Batches mehrerer Befehle speichern. Die Befehle für die 3D-Pipeline 312 können auch Bezüge auf im Arbeitsspeicher gespeicherte Daten enthalten, wie zum Beispiel unter anderem Vertex- und Geometriedaten für die 3D-Pipeline 312 und/oder Bilddaten und Arbeitsspeicherobjekte für die Medienpipeline 316. Die 3D-Pipeline 312 und die Medienpipeline 316 verarbeiten die Befehle und Daten durch Durchführen von Operationen durch Logik in den jeweiligen Pipelines oder durch Vergeben eines oder mehrerer Ausführungsthreads an eine Grafikkernanordnung 414. In einer Ausführungsform enthält die Grafikkernanordnung 414 einen oder mehrere Blöcke von Grafikkernen (z. B. Grafikkern(e) 415A, Grafikkern(e) 415B), wobei jeder Block einen oder mehrere Grafikkerne enthält. Jeder Grafikkern enthält einen Satz von Grafikausführungsressourcen, die Universal- und grafikspezifische Ausführungslogik enthalten, um Grafik- und Rechenoperationen durchzuführen, sowie feste Funktionslogik zur Texturverarbeitung und/oder für maschinelles Lernen und Beschleunigung künstlicher Intelligenz.
In verschiedenen Ausführungsformen kann die 3D-Pipeline 312 feste Funktions- und programmierbare Logik enthalten, um ein oder mehrere Shaderprogramme zu verarbeiten, wie Vertexshadern, Geometrieshadern, Pixelshadern, Fragmentshadern, Rechenshadern oder andere Shaderprogramme, durch Verarbeiten der Anweisungen und Vergeben von Ausführungsthreads an die Grafikkernanordnung 414. Die Grafikkernanordnung 414 stellt einen einheitlichen Block mit Ausführungsressourcen zur Verwendung bei der Verarbeitung dieser Shaderprogramme bereit. Mehrzweckausführungslogik (z. B. Ausführungseinheiten) innerhalb des Grafikkerns bzw. der Grafikkerne 415A-414B der Grafikkernanordnung 414 enthält Unterstützung für verschiedene 3D-API-Shadersprachen und kann mehrere gleichzeitige Ausführungsthreads ausführen, die mit mehreren Shadern assoziiert sind.
In einigen Ausführungsformen enthält die Grafikkernanordnung 414 Ausführungslogik, um Medienfunktionen durchzuführen, wie Video- und/oder Bildverarbeitung. In einer Ausführungsform enthalten die Ausführungseinheiten Universallogik, die programmierbar ist, um zusätzlich zu Grafikverarbeitungsoperationen parallele Universalrechenoperationen durchzuführen. Die Universallogik kann Verarbeitungsoperationen parallel oder zusammen mit Universallogik im Prozessorkern bzw. in den Prozessorkernen 107 von 1 oder im Kern 202A-202N wie in 2A durchführen.
Ausgabedaten, die von Threads generiert werden, die auf der Grafikkernanordnung 414 ausgeführt werden, können Daten in den Arbeitsspeicher in einen vereinheitlichten Rückgabepuffer (URB) 418 ausgeben. Der URB 418 kann Daten für mehrere Threads speichern. In einigen Ausführungsformen kann der URB 418 verwendet werden, um Daten zwischen unterschiedlichen Threads zu senden, die auf der Grafikkernanordnung 414 ausgeführt werden. In einigen Ausführungsformen kann der URB 418 zusätzlich zur Synchronisierung zwischen Threads auf der Grafikkernanordnung und fester Funktionslogik in der gemeinsam genutzten Funktionslogik 420 verwendet werden.
In einigen Ausführungsformen ist die Grafikkernanordnung 414 skalierbar, sodass die Anordnung eine variable Anzahl von Grafikkernen enthält, die jeweils eine variable Anzahl von Ausführungseinheiten auf Grundlage der Zielleistung und des Leistungspegels der GEP 410 aufweisen. In einer Ausführungsform sind die Ausführungsressourcen dynamisch skalierbar, sodass die Ausführungsressourcen je nach Bedarf aktiviert oder deaktiviert werden können.
Die Grafikkernanordnung 414 koppelt an die gemeinsam genutzte Funktionslogik 420, die mehrere Ressourcen enthält, die unter den Grafikkernen in der Grafikkernanordnung gemeinsam genutzt werden. Die gemeinsam genutzten Funktionen in der gemeinsam genutzten Funktionslogik 420 sind Hardwarelogikeinheiten, die der Grafikkernanordnung 414 spezialisierte ergänzende Funktionalität bereitstellen. In verschiedenen Ausführungsformen enthält die gemeinsam genutzte Funktionslogik 420 unter anderem Abtaster 421, Mathematik- 422 und Zwischenthreadkommunikationslogik (ITC-Logik) 423. Zusätzlich implementieren einige Ausführungsformen einen oder mehrere Zwischenspeicher 425 in der gemeinsam genutzten Funktionslogik 420.
Eine gemeinsam genutzte Funktion ist zumindest in einem Fall implementiert, in dem der Bedarf an einer bestimmten spezialisierten Funktion zur Aufnahme in die Grafikkernanordnung 414 unzureichend ist. Stattdessen ist eine einzelne Instantiierung dieser spezialisierten Funktion als eine eigenständige Entität in der gemeinsam genutzten Funktionslogik 420 implementiert und wird von den Ausführungsressourcen in der Grafikkernanordnung 414 gemeinsam genutzt. Die genaue Funktionsgruppe, die in der Grafikkernanordnung 414 gemeinsam genutzt ist und in der Grafikkernanordnung 414 enthalten ist, variiert über Ausführungsformen. In einigen Ausführungsformen können bestimmte gemeinsam genutzte Funktionen in der gemeinsam genutzten Funktionslogik 420, die von der Grafikkernanordnung 414 umfangreich genutzt werden, in der gemeinsam genutzten Funktionslogik 416 in der Grafikkernanordnung 414 enthalten sein. In verschiedenen Ausführungsformen kann die gemeinsam genutzte Funktionslogik 416 in der Grafikkernanordnung 414 einige der oder die gesamte Logik in der gemeinsam genutzten Funktionslogik 420 enthalten. In einer Ausführungsform können alle Logikelemente in der gemeinsam genutzten Funktionslogik 420 in der gemeinsam genutzten Funktionslogik 416 der Grafikkernanordnung 414 dupliziert werden. In einer Ausführungsform ist die gemeinsam genutzte Funktionslogik 420 zugunsten der gemeinsam genutzten Funktionslogik 416 in der Grafikkernanordnung 414 ausgeschlossen.
Ausführungseinheiten
5A-5B veranschaulichen eine Threadausführungslogik 500, die eine Anordnung von Verarbeitungselementen enthält, die in einem Grafikprozessorkern nach hierin beschriebenen Ausführungsformen eingesetzt wird. Elemente von 5A-5B, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist. 5A-5B veranschaulichen eine Übersicht von Threadausführungslogik 500, die für Hardwarelogik repräsentativ sein kann, die mit jedem Subkern 221A-221F von 2B veranschaulicht ist. 5A ist für eine Ausführungseinheit innerhalb eines Universal-Grafikprozessors repräsentativ, während 5B für eine Ausführungseinheit repräsentativ ist, die innerhalb einer Rechenarchitektur verwendet werden kann.
Wie in 5A veranschaulicht, enthält die Threadausführungslogik 500 einen Shaderprozessor 502, einen Thread-Dispatcher 504, einen Anweisungszwischenspeicher 506, eine skalierbare Ausführungseinheitsanordnung, die eine Vielzahl von Ausführungseinheiten 508A-508N enthält, eine Abtasteinheit 510, einen gemeinsam genutzten Arbeitsspeicher 511, einen Datenzwischenspeicher 512 und einen Datenanschluss 514. In einer Ausführungsform kann die skalierbare Ausführungseinheitsanordnung dynamisch durch Aktivieren oder Deaktivieren einer oder mehrerer Ausführungseinheiten (z. B. beliebige der Ausführungseinheiten 508A, 508B, 508C, 508D bis 508N-1 und 508N) auf Grundlage der rechnerischen Anforderungen einer Arbeitslast skaliert werden. In einer Ausführungsform sind die enthaltenen Komponenten über eine Zwischenverbindungsfabric verbunden, die mit jeder der Komponenten verknüpft ist. In einigen Ausführungsformen enthält die Threadausführungslogik 500 eine oder mehrere Verbindungen mit einem Arbeitsspeicher, wie einem Systemarbeitsspeicher oder einem Zwischenspeicher, über eines oder mehrere vom Anweisungszwischenspeicher 506, dem Datenanschluss 514, der Abtasteinheit 510 und den Ausführungseinheiten 508A-508N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 508A) eine eigenständige programmierbare Universalrecheneinheit, die fähig ist, mehrere gleichzeitige Hardwarethreads auszuführen, während mehrere Datenelemente parallel für jeden Thread verarbeitet werden. In verschiedenen Ausführungsformen ist die Anordnung von Ausführungseinheiten 508A-508N skalierbar, um eine beliebige Anzahl individueller Ausführungseinheiten aufzunehmen.
In einigen Ausführungsformen werden die Ausführungseinheiten 508A-508N hauptsächlich verwendet, um Shaderprogramme auszuführen. Ein Shaderprozessor 502 kann die verschiedenen Shaderprogramme verarbeiten und Ausführungsthreads, die mit den Shaderprogrammen assoziiert sind, über einen Thread-Dispatcher 504 versenden. In einer Ausführungsform enthält der Thread-Dispatcher Logik, um Threadinitiierungsanforderungen von den Grafik- und Medienpipelines zu vermitteln und die angeforderten Threads auf einer oder mehreren Ausführungseinheiten in den Ausführungseinheiten 508A-508N zu instanziieren. Eine Geometriepipeline kann zum Beispiel Vertex-, Tessellations- oder Geometrieshader an die Threadausführungslogik zur Verarbeitung vergeben. In einigen Ausführungsformen kann der Thread-Dispatcher 504 auch Laufzeit-Threaderzeugungsanforderungen von den ausgeführten Shaderprogrammen verarbeiten.
In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N einen Anweisungssatz, der native Unterstützung für viele Standard-3D-Grafikshaderanweisungen enthält, sodass Shaderprogamme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen eine Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertexshader), eine Pixelverarbeitung (z. B. Pixelshader, Fragmentshader) und eine Universalverarbeitung (z. B. Rechen- und Medienshader). Jede der Ausführungseinheiten 508A-508N ist zu einer mehrfach erteilten Einzelanweisungs-Mehrfachdaten(SIMD)-Ausführung fähig, und eine Operation mit mehreren Threads ermöglicht eine effiziente Ausführungsumgebung angesichts Arbeitsspeicherzugriffe mit höherer Latenz. Jeder Hardwarethread in jeder Ausführungseinheit weist eine dedizierte Registerdatei mit hoher Bandbreite und einen zugehörigen unabhängigen Threadzustand auf. Die Ausführung erfolgt in mehrfacher Erteilung pro Takt an Pipelines, die zu Ganzzahl- und Gleitkomma-Operationen mit einfacher und doppelter Genauigkeit, SIMD-Verzweigungsfähigkeit, logischen Operationen, transzendenten Operationen und anderen sonstigen Operationen fähig sind. Während des Wartens auf Daten aus dem Arbeitsspeicher oder von einer der gemeinsam genutzten Funktionen verursacht Abhängigkeitslogik in den Ausführungseinheiten 508A-508N, dass ein wartender Thread im Ruhezustand ist, bis die angeforderten Daten zurückgegeben wurden. Während sich der wartende Thread im Ruhezustand befindet, können Hardwareressourcen dem Verarbeiten anderer Threads gewidmet werden. Während einer mit einer Vertexshaderoperation assoziierten Verzögerung kann eine Ausführungseinheit beispielsweise Operationen für einen Pixelshader, Fragmentshader oder einen anderen Typ von Shaderprogramm durchführen, einschließlich eines anderen Vertexshaders. Verschiedene Ausführungsformen können anwenden, eine Ausführung durch Verwendung von Einzelanweisung-Mehrfachthreads (SIMT) als eine Alternative zur Verwendung von SIMD oder zusätzlich zur Verwendung von SIMD zu verwenden. Eine Bezugnahme auf einen SIMD-Kern oder eine SIMD-Operation kann auch für SIMT gelten oder für SIMD in Kombination mit SIMT gelten.
Jede Ausführungseinheit in den Ausführungseinheiten 508A-508N arbeitet an Arrays von Datenelementen. Die Anzahl der Datenelemente ist die „Ausführungsgröße“ oder die Anzahl der Kanäle für die Anweisung. Ein Ausführungskanal ist eine logische Einheit der Ausführung zum Zugriff auf Datenelemente, zur Maskierung und Ablaufsteuerung innerhalb von Anweisungen. Die Anzahl der Kanäle kann von der Anzahl der physischen arithmetisch-logischen Einheiten (ALUs) oder Gleitkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor unabhängig sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 508A-508N Ganzzahl- und Gleitkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheiten enthält SIMD-Anweisungen. Die verschiedenen Datenelemente können als ein gepackter Datentyp in einem Register gespeichert sein und die Ausführungseinheit verarbeitet die verschiedenen Elemente auf Grundlage der Datengröße der Elemente. Beim Arbeiten an einem 256-Bit breiten Vektor werden die 256 Bits des Vektors zum Beispiel in einem Register gespeichert und die Ausführungseinheit bearbeitet den Vektor als vier separate gepackte 54-Bit-Datenelemente (Datenelemente von Quadwort(QW)-Größe), acht separate gepackte 32-Bit-Datenelemente (Datenelemente von Doppelwort(DW)-Datengröße), sechzehn separate gepackte 16-Bit-Datenelemente (Datenelemente von Wort(W)-Größe) oder zweiunddreißig separate 8-Bit-Datenelemente (Datenelemente von Byte(B)-Größe). Unterschiedliche Vektorbreiten und Registergrößen sind jedoch möglich.
In einer Ausführungsform können eine oder mehrere Ausführungseinheiten in eine verschmolzene Ausführungseinheit 509A-509N mit Threadsteuerlogik (507A-507N) kombiniert werden, die den verschmolzenen EUs gemeinsam ist. Mehrere EUs können in eine EU-Gruppe verschmolzen werden. Jede EU in der verschmolzenen EU-Gruppe kann ausgelegt sein, einen separaten SIMD-Hardwarethread auszuführen. Die Anzahl der EUs in einer verschmolzenen EU-Gruppe kann je nach Ausführungsformen variieren. Darüber hinaus können verschiedene SIMD-Breiten pro EU durchgeführt werden, einschließlich unter anderem SIMD8, SIMD16 und SIMD32. Jede verschmolzene Grafikausführungseinheit 509A-509N enthält mindestens zwei Ausführungseinheiten. Die verschmolzene Ausführungseinheit 509A enthält zum Beispiel eine erste EU 508A, eine zweite EU 508B und Threadsteuerlogik 507A, die der ersten EU 508A und der zweiten EU 508B gemeinsam ist. Die Threadsteuerlogik 507A steuert Threads, die auf der verschmolzenen Grafikausführungseinheit 509A ausgeführt werden, was jeder EU innerhalb den verschmolzenen Ausführungseinheiten 509A-509N ermöglicht, unter Verwendung eines gemeinsamen Anweisungszeigerregisters ausgeführt zu werden.
Ein oder mehrere interne Anweisungszwischenspeicher (z. B. 506) sind in der Threadausführungslogik 500 enthalten, um Threadanweisungen für die Ausführungseinheiten zwischenzuspeichern. In einigen Ausführungsformen sind ein oder mehrere Datenzwischenspeicher (z. B. 512) enthalten, um Threaddaten während der Threadausführung zwischenzuspeichern. Threads, die auf der Ausführungslogik 500 ausgeführt werden, können auch explizit verwaltete Daten im gemeinsam genutzten Arbeitsspeicher 511 speichern. In einigen Ausführungsformen ist ein Abtaster 510 enthalten, um eine Texturabtastung für 3D-Operationen und Medienabtastung für Medienoperationen bereitzustellen. In einigen Ausführungsformen enthält der Abtaster 510 spezialisierte Textur- oder Medienabtastfunktionalität, um Textur- oder Mediendaten während des Abtastprozesses vor dem Bereitstellen der abgetasteten Daten an eine Ausführungseinheit zu verarbeiten.
Während der Ausführung senden die Grafik- und Medienpipelines Threadinitiierungsanforderungen über Threaderzeugungs- und Dispatch-Logik an die Threadausführungslogik 500. Sobald eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten rasterisiert worden ist, wird Pixelprozessorlogik (z. B. Pixelshaderlogik, Fragmentshaderlogik usw.) im Shaderprozessor 502 aufgerufen, um Ausgabeinformationen weiter zu berechnen und zu bewirken, dass Ergebnisse in Ausgabeflächen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.) geschrieben werden. In einigen Ausführungsformen berechnet ein Pixelshader oder Fragmentshader die Werte der verschiedenen Vertexattribute, die über das rasterisierte Objekt zu interpolieren sind. In einigen Ausführungsformen führt dann Pixelprozessorlogik im Shaderprozessor 502 ein von einer Anwendungsprogrammierschnittstelle (API) geliefertes Pixel- oder Fragmentshaderprogramm durch. Um das Shaderprogramm auszuführen, vergibt der Shaderprozessor 502 Threads über den Thread-Dispatcher 504 an eine Ausführungseinheit (z. B. 508A). In einigen Ausführungsformen verwendet der Shaderprozessor 502 Texturabtastlogik im Abtaster 510, um auf Texturdaten in im Arbeitsspeicher gespeicherten Texturabbildungen zuzugreifen. Arithmetische Operationen an den Texturdaten und den Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel von einer weiteren Verarbeitung.
In einigen Ausführungsformen bietet der Datenanschluss 514 einen Arbeitsspeicherzugriffsmechanismus für die Threadausführungslogik 500, um verarbeitete Daten in den Arbeitsspeicher zur weiteren Verarbeitung in einer Grafikprozessorausgabepipeline auszugeben. In einigen Ausführungsformen enthält der Datenanschluss 514 einen oder mehrere Zwischenspeicher (z. B. den Datenzwischenspeicher 512) oder koppelt an diese, um Daten für einen Arbeitsspeicherzugriff über den Datenanschluss zwischenzuspeichern.
In einer Ausführungsform kann die Ausführungslogik 500 auch eine Raytracing-Einheit 505 enthalten, die Raytracing-Beschleunigungsfunktionalität bereitstellen kann. Die Raytracing-Einheit 505 kann einen Raytracing-Anweisungssatz unterstützen, der Anweisungen/Funktionen zur Strahlengenerierung enthält. Der Raytracing-Anweisungssatz kann dem Raytracing-Anweisungssatz ähnlich sein, der von den Raytracingkernen 245 in 2C unterstützt wird, oder von diesem verschieden sein.
5B veranschaulicht beispielhafte interne Details einer Ausführungseinheit 508 nach Ausführungsformen. Eine Grafikausführungseinheit 508 kann eine Anweisungsabrufeinheit 537, eine allgemeine Registerdateianordnung (GRF-Anordnung) 524, eine Architekturregisterdateianordnung (ARF-Anordnung) 526, einen Threadarbiter 522, eine Sendeeinheit 530, eine Verzweigungseinheit 532, einen Satz von SIMD-Gleitkommaeinheiten (FPUs) 534 und in einer Ausführungsform einen Satz von dedizierten Ganzzahl-SIMD-ALUs 535 enthalten. Die GRF 524 und ARF 526 enthalten den Satz von allgemeinen Registerdateien und Architekturregisterdateien, die mit jedem gleichzeitigen Hardwarethread assoziiert sind, die in der Grafikausführungseinheit 508 aktiv sein können. In einer Ausführungsform wird ein architektonischer Zustand pro Thread in der ARF 526 gepflegt, während Daten, die während der Threadausführung verwendet werden, in der GRF 524 gespeichert sind. Der Ausführungszustand jedes Threads, einschließlich der Anweisungszeiger für jeden Thread, kann in threadspezifischen Registern in der ARF 526 gehalten werden.
In einer Ausführungsform weist die Grafikausführungseinheit 508 eine Architektur auf, die eine Kombination von simultanem Multithreading (SMT) und feinkörnigem verschachteltem Multithreading (IMT) ist. Die Architektur weist eine modulare Konfiguration auf, die zum Zeitpunkt des Designs auf Grundlage einer Zielanzahl gleichzeitiger Threads und einer Anzahl von Registern pro Ausführungseinheit feinabgestimmt werden kann, wobei Ausführungseinheitsressourcen über Logik aufgeteilt werden, die verwendet wird, um mehrere gleichzeitige Threads auszuführen. Die Anzahl von logischen Threads, die von der Grafikausführungseinheit 508 ausgeführt werden kann, ist nicht auf die Anzahl von Hardwarethreads beschränkt, und mehrere logische Threads können jedem Hardwarethread zugewiesen werden.
In einer Ausführungsform kann die Grafikausführungseinheit 508 gemeinsam mehrere Anweisungen erteilen, die jeweils unterschiedliche Anweisungen sein können. Der Threadarbiter 522 des Grafikausführungsthreads 508 kann die Anweisungen an eine der Sendeinheit 530, Verzweigungseinheit 532 oder SIMD-FPU(s) 534 zur Ausführung vergeben. Jeder Ausführungsthread kann auf 128 Universalregister in der GRF 524 zugreifen, wobei jedes Register 32 Bytes speichern kann, auf die als ein SIMD-8-Element-Vektor aus 32-Bit-Datenelementen zugegriffen werden kann. In einer Ausführungsform weist jeder Ausführungseinheitsthread Zugriff auf 4 kBytes innerhalb der GRF 524 auf, obwohl Ausführungsformen derart nicht eingeschränkt sind und in anderen Ausführungsformen mehr oder weniger Registerressourcen bereitgestellt werden können. In einer Ausführungsform ist die Grafikausführungseinheit 508 in sieben Hardwarethreads partitioniert, die unabhängig rechnerische Operationen durchführen können, obwohl die Anzahl von Threads pro Ausführungseinheit auch nach Ausführungsformen variieren kann. In einer Ausführungsform werden zum Beispiel bis zu 16 Hardwarethreads unterstützt. In einer Ausführungsform, in der sieben Threads auf 4 kBytes zugreifen können, kann die GRF 524 insgesamt 28 kBytes speichern. Wo 16 Threads auf 4 kBytes zugreifen können, kann die GRF 524 insgesamt 64 kBytes speichern. Flexible Adressierungsmodi können ermöglichen, dass Register gemeinsam adressiert werden, um effektiv breitere Register zu bilden oder schrittweise rechteckige Blockdatenstrukturen zu repräsentieren.
In einer Ausführungsform werden Arbeitsspeicheroperationen, Abtastoperationen und andere Systemkommunikationen mit längerer Latenz über „Sende“-Anweisungen versandt, die von der Nachrichten übermittelnden Sendeeinheit 530 ausgeführt werden. In einer Ausführungsform werden Verzweigungsanweisungen an eine dedizierte Verzweigungseinheit 532 versandt, um eine SIMD-Divergenz und letztendliche Konvergenz zu ermöglichen.
In einer Ausführungsform enthält die Grafikausführungseinheit 508 eine oder mehrere SIMD-Gleitkommaeinheiten (FPU(s)) 534, um Gleitkomma-Operationen durchzuführen. In einer Ausführungsform unterstützen die FPU(s) 534 auch eine ganzzahlige Berechnung. In einer Ausführungsform kann bzw. können die FPU(s) 534 bis zu M 32-Bit-Gleitkomma- (oder Ganzzahl-)Operationen via SIMD ausführen oder bis zu 2M 16-Bit-Ganzzahl- oder 16-Bit-Gleitkomma-Operationen via SIMD ausführen. In einer Ausführungsform bietet mindestens eine der FPU(s) erweiterte Mathematikfähigkeiten, um transzendente Mathematikfunktionen mit hohem Durchsatz und 54-Bit-Gleitkomma mit doppelter Genauigkeit zu unterstützen. In einigen Ausführungsformen ist auch eine Gruppe von 8-Bit-Ganzzahl-SIMD-ALUs 535 vorhanden und diese kann spezifisch optimiert sein, um Operationen durchzuführen, die mit Berechnungen für maschinelles Lernen assoziiert sind.
In einer Ausführungsform können Anordnungen mehrerer Instanzen der Grafikausführungseinheit 508 in einer Grafik-Subkerngruppierung (z. B. eines Teilsegments) instanziiert sein. Zur Skalierbarkeit können Produktarchitekten die genaue Anzahl der Ausführungseinheiten pro Subkerngruppierung wählen. In einer Ausführungsform kann die Ausführungseinheit 508 Anweisungen über eine Vielzahl von Ausführungskanälen ausführen. In einer weiteren Ausführungsform wird jeder Thread, der auf der Grafikausführungseinheit 508 ausgeführt wird, in einem anderen Kanal ausgeführt.
6 veranschaulicht eine zusätzliche Ausführungseinheit 600 nach einer Ausführungsform. Die Ausführungseinheit 600 kann eine rechenoptimierte Ausführungseinheit beispielsweise zur Verwendung in einer Rechenenginekachel 340A-340D wie in 3C sein, aber ist derartig nicht eingeschränkt. Varianten der Ausführungseinheit 600 können auch in einer Grafikenginekachel 310A-310D wie in 3B verwendet werden. In einer Ausführungsform enthält die Ausführungseinheit 600 eine Threadsteuereinheit 601, eine Threadzustandseinheit 602, eine Anweisungsabruf-/-vorabrufeinheit 603 und eine Anweisungsdecodiereinheit 604. Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die Register speichert, die Hardwarethreads innerhalb der Ausführungseinheit zugewiesen werden können. Die Ausführungseinheit 600 enthält zusätzlich eine Sendeeinheit 607 und eine Verzweigungseinheit 608. In einer Ausführungsform können die Sendeeinheit 607 und die Verzweigungseinheit 608 ähnlich wie die Sendeeinheit 530 und eine Verzweigungseinheit 532 der Grafikausführungseinheit 508 von 5B arbeiten.
Die Ausführungseinheit 600 enthält auch eine Recheneinheit 610, die mehrere verschiedene Arten von funktionalen Einheiten enthält. In einer Ausführungsform enthält die Recheneinheit 610 eine ALU-Einheit 611, die eine Anordnung von arithmetisch-logischen Einheiten enthält. Die ALU-Einheit 611 kann ausgelegt sein, 64-Bit-, 32-Bit- und 16-Bit-Ganzzahl- und Gleitkomma-Operationen durchzuführen. Ganzzahlige und Gleitkomma-Operationen können gleichzeitig durchgeführt werden. Die Recheneinheit 610 kann auch eine systolische Anordnung 612 und eine Mathematikeinheit 613 enthalten. Die systolische Anordnung 612 enthält ein Netzwerk von Datenverarbeitungseinheiten der Breite W und Tiefe D, die verwendet werden können, um Vektor- oder andere datenparallele Operationen auf systolische Weise durchzuführen. In einer Ausführungsform kann die systolische Anordnung 612 ausgelegt sein, Matrixoperationen durchzuführen, wie Matrix-SkalarproduktOperationen. In einer Ausführungsform unterstützt die systolische Anordnung 612 16-Bit-Gleitkomma-Operationen sowie 8-Bit- und 4-Bit-Ganzzahl-Operationen. In einer Ausführungsform kann die systolische Anordnung 612 ausgelegt sein, Operationen für maschinelles Lernen zu beschleunigen. In derartigen Ausführungsformen kann die systolische Anordnung 612 mit Unterstützung für das bfloat-16-Bit-Gleitkomma-Format konfiguriert sein. In einer Ausführungsform kann eine Mathematikeinheit 613 enthalten sein, um eine bestimmte Teilmenge von mathematischen Operationen auf effiziente Weise und mit niedriger Energie als die ALU-Einheit 611 durchzuführen. Die Mathematikeinheit 613 kann eine Variante mathematischer Logik enthalten, die in gemeinsam genutzter Funktionslogik einer Grafikverarbeitungsengine gefunden werden kann, die von anderen Ausführungsformen (z. B. die Mathematiklogik 422 der gemeinsam genutzten Funktionslogik 420 von 4) bereitgestellt wird. In einer Ausführungsform kann die Mathematikeinheit 613 ausgelegt sein, 32-Bit- und 64-Bit-Gleitkomma-Operationen durchzuführen.
Die Threadsteuereinheit 601 enthält Logik, um die Ausführung von Threads innerhalb der Ausführungseinheit zu steuern. Die Threadsteuereinheit 601 kann Threadvermittlungslogik enthalten, um eine Ausführung von Threads innerhalb der Ausführungseinheit 600 zu starten, zu stoppen und vorwegzunehmen. Die Threadzustandseinheit 602 kann verwendet werden, um einen Threadzustand für Threads zu speichern, die zur Ausführung auf der Ausführungseinheit 600 zugewiesen wurden. Das Speichern des Threadzustands innerhalb der Ausführungseinheit 600 ermöglicht die rasche Vorwegnahme von Threads, wenn diese Threads blockiert werden oder im Leerlauf sind. Die Anweisungsabruf-/-vorabrufeinheit 603 kann Anweisungen aus einem Anweisungszwischenspeicher einer Ausführungslogik auf höherer Ebene (z. B. dem Anweisungszwischenspeicher 506 wie in 5A) abrufen. Die Anweisungsabruf-/-vorabrufeinheit 603 kann auch Vorabrufanforderungen für Anweisungen erteilen, die auf Grundlage einer Analyse von Threads, die derzeit ausgeführt werden, in den Anweisungszwischenspeicher zu laden sind. Die Anweisungsdecodiereinheit 604 kann verwendet werden, um Anweisungen zu decodieren, die von den Recheneinheiten auszuführen sind. In einer Ausführungsform kann die Anweisungsdecodiereinheit 604 als ein sekundärer Decoder verwendet werden, um komplexe Anweisungen in Mikrooperationsbestandteile zu decodieren.
Die Ausführungseinheit 600 enthält zusätzlich eine Registerdatei 606, die von Hardwarethreads verwendet werden kann, die auf der Ausführungseinheit 600 ausgeführt werden. Register in der Registerdatei 606 können über die Logik verteilt werden, die verwendet wird, um mehrere simultane Threads innerhalb der Recheneinheit 610 der Ausführungseinheit 600 auszuführen. Die Anzahl von logischen Threads, die von der Grafikausführungseinheit 600 ausgeführt werden kann, ist nicht auf die Anzahl von Hardwarethreads beschränkt, und mehrere logische Threads können jedem Hardwarethread zugewiesen werden. Die Größe der Registerdatei 606 kann über Ausführungsformen auf Grundlage der Anzahl von unterstützten Hardwarethreads variieren. In einer Ausführungsform kann eine Registerumbenennung verwendet werden, um dynamisch Register zu Hardwarethreads zuzuteilen.
7 ist ein Blockdiagramm, das ein Grafikprozessoranweisungsformat nach einigen Ausführungsformen 700 veranschaulicht. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz mit Anweisungen in mehreren Formaten. Die durchgezogen umrandeten Kästchen veranschaulichen die Komponenten, die allgemein in einer Ausführungseinheitsanweisung enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Anweisungen enthalten sind. In einigen Ausführungsformen des Anweisungsformats 700 sind Makroanweisungen beschrieben und veranschaulicht, dahingehend, dass sie Anweisungen sind, die der Ausführungseinheit geliefert werden, im Gegensatz zu Mikrooperationen, die sich aus einer Decodierung der Anweisung ergeben, sobald die Anweisung verarbeitet wurde.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Ein kompaktes 64-Bit-Anweisungsformat 730 ist für einige Anweisungen verfügbar, auf Grundlage der ausgewählten Anweisung, der Anweisungsoptionen und der Anzahl der Operanden. Das native 128-Bit-Anweisungsformat 710 bietet Zugriff auf alle Anweisungsoptionen, während einige Optionen und Operationen im 64-Bit-Format 730 eingeschränkt sind. Die nativen Anweisungen, die im 64-Bit-Format 730 verfügbar sind, variieren nach Ausführungsform. In einigen Ausführungsformen wird die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 komprimiert. Die Hardware der Ausführungseinheit nimmt auf Grundlage der Indexwerte auf einen Satz von Komprimierungstabellen Bezug und verwendet die Ausgaben der Komprimierungstabelle, um eine native Anweisung im 128-Bit-Anweisungsformat 710 zu rekonstruieren. Andere Größen und Formate von Anweisungen können verwendet werden.
Für jedes Format definiert der Anweisungsopcode 712 die Operation, die die Ausführungseinheit durchzuführen hat. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden aus. Beispielsweise führt die Ausführungseinheit als Reaktion auf eine Additionsanweisung eine gleichzeitige Additionsoperation über jeden Farbkanal durch, der ein Texturelement oder Bildelement repräsentiert. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden durch. In einigen Ausführungsformen ermöglicht das Anweisungssteuerfeld 714 eine Steuerung bestimmter Ausführungsoptionen, wie eine Kanalauswahl (z. B. Prädikation) und Datenkanalreihenfolge (z. B. Swizzeln). Für Anweisungen im 128-Bit-Anweisungsformat 710 schränkt ein Ausführungsgrößenfeld 716 die Anzahl der Datenkanäle ein, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Ausführungsgrößenfeld 716 nicht zur Verwendung im kompakten 64-Bit-Anweisungsformat 730 zur Verfügung.
Einige Ausführungseinheitsanweisungen weisen bis zu drei Operanden einschließlich zweier Quelloperanden src0 720, src1 722 und eines Ziels 718 auf. In einigen Ausführungsformen unterstützen die Ausführungseinheiten Anweisungen mit zwei Zielen, wobei eines der Ziele implizit ist. Datenmanipulationsanweisungen können einen dritten Quelloperanden aufweisen (z. B. SRC2 724), wobei der Anweisungsopcode 712 die Anzahl der Quelloperanden bestimmt. Ein letzter Quelloperand einer Anweisung kann ein unmittelbarer (z. B. fest codierter) Wert sein, der mit der Anweisung übergeben wird.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das beispielsweise angibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein direkter Registeradressierungsmodus verwendet wird, wird die Registeradresse eines oder mehrerer Operanden direkt durch Bits in der Anweisung bereitgestellt.
In einigen Ausführungsformen enthält das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das 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, die einen ausgerichteten 16-Byte-Zugriffsmodus und einen ausgerichteten 1-Byte-Zugriffsmodus enthalten, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. In einem ersten Modus kann die Anweisung zum Beispiel Byte-ausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus kann die Anweisung eine 16-Byte-ausgerichtete Adressierung für alle Quell- und Zieloperanden verwenden.
In einer Ausführungsform bestimmt der Adressmodusabschnitt des Zugriffs-/Adressmodusfelds 726, ob die Anweisung eine direkte oder eine indirekte Adressierung zu verwenden hat. Wenn ein direkter Registeradressierungsmodus verwendet wird, stellen Bits in der Anweisung direkt die Registeradresse eines oder mehrerer Operanden bereit. Wenn ein indirekter Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden auf Grundlage eines Adressregisterwerts und eines Adressen-Direktfelds in der Anweisung berechnet werden.
In einigen Ausführungsformen werden Anweisungen auf Grundlage von Opcode-Bitfeldern 712 gruppiert, um eine Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode ermöglichen Bits 4, 5 und 6 der Ausführungseinheit, den Typ von Opcode zu ermitteln. Die präzise gezeigte Opcodegruppierung ist nur ein Beispiel. In einigen Ausführungsformen enthält eine Bewegungs- und Logik-Opcodegruppe 742 Anweisungen zur Datenbewegung und Logikanweisungen (z. B. Bewegen (mov), Vergleichen (cmp)). In einigen Ausführungsformen nutzt die Bewegungs- und Logikgruppe 742 die fünf höchstwertigen Bits (MSB) gemeinsam, wobei Bewegungsanweisungen (mov) die Form von 0000xxxxb haben und Logikanweisungen die Form von 0001xxxxb haben. Eine Ablaufsteuerungsanweisungsgruppe 744 (z. B. Aufruf, Springen (jmp)) enthält Anweisungen in der Form von 001 Oxxxxb (z. B. 0x20). Eine Gruppe für sonstige Anweisungen 746 enthält eine Mischung von Anweisungen, einschließlich Synchronisierungsanweisungen (z. B. Warten, Senden) in Form von OOllxxxxb (z.B. 0x30). Eine parallele Mathematikanweisungsgruppe 748 enthält komponentenweise arithmetische Anweisungen (z. B. Addieren, Multiplizieren (mul)) in Form von 0100xxxxb (z. B. 0x40). Die Parallelmathematikgruppe 748 führt die arithmetischen Operationen parallel über Datenkanäle hinweg durch. Die Vektormathematikgruppe 750 enthält arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektormathematikgruppe führt Arithmetik wie Skalarproduktberechnungen an Vektoroperanden durch. Die veranschaulichte Opcode-Decodierung 740 kann in einer Ausführungsform verwendet werden, um zu ermitteln, welcher Abschnitt einer Ausführungseinheit verwendet werden wird, um eine decodierte Anweisung auszuführen. Einige Anweisungen können zum Beispiel als systolische Anweisungen designiert sein, die von einer systolischen Anordnung durchgeführt werden. Andere Anweisungen, wie Raytracing-Anweisungen (nicht gezeigt), können zu einem Raytracingkern oder Raytracinglogik innerhalb einer Scheibe oder einer Partition von Ausführungslogik geleitet werden.
Grafikpipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente von 8, die die gleichen Bezugsziffern (oder Namen) wie die Elemente einer beliebigen anderen Figur hierin aufweisen, können auf eine Weise arbeiten oder funktionieren, die der hierin anderswo beschriebenen ähnlich ist, aber nicht darauf beschränkt ist.
In einigen Ausführungsformen enthält ein Grafikprozessor 800 eine Geometriepipeline 820, eine Medienpipeline 830, eine Anzeigeengine 840, Threadausführungslogik 850 und eine Ausgaberenderpipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor in einem Mehrkernverarbeitungssystem, das einen oder mehrere Universalverarbeitungskerne enthält. Der Grafikprozessor wird durch Registerschreibvorgänge in ein oder mehrere Steuerregister (nicht gezeigt) oder durch Befehle gesteuert, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 an andere Verarbeitungskomponenten, wie andere Grafikprozessoren oder Universalprozessoren. Befehle von der Ringverbindung 802 werden durch eine Befehlsstreamingeinheit 803 interpretiert, die Anweisungen an individuelle Komponenten der Geometriepipeline 820 oder der Medienpipeline 830 liefert.
In einigen Ausführungsformen leitet die Befehlsstreamingeinheit 803 die Operation einer Vertexabrufeinheit 805, die Vertexdaten aus dem Arbeitsspeicher liest und Vertexverarbeitungsbefehle ausführt, die von der Befehlsstreamingeinheit 803 bereitgestellt werden. In einigen Ausführungsformen stellt die Vertexabrufeinheit 805 einem Vertexshader 807 Vertexdaten bereit, der an jedem Vertex eine Koordinatenraumtransformation und Beleuchtungsoperationen durchführt. In einigen Ausführungsformen führen die Vertexabrufeinheit 805 und der Vertexshader 807 Vertexverarbeitungsanweisungen durch Vergeben von Ausführungsthreads über einen Thread-Dispatcher 831 an die Ausführungseinheiten 852A-852B aus.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B eine Anordnung von Vektorprozessoren mit einem Anweisungssatz zum Durchführen von Grafik- und Medienoperationen. In einigen Ausführungsformen weisen die Ausführungseinheiten 852A-852B einen zugehörigen L1-Zwischenspeicher 851 auf, der für jede Anordnung spezifisch ist oder unter den Anordnungen gemeinsam genutzt wird. Der Zwischenspeicher kann als ein Datenzwischenspeicher, ein Anweisungszwischenspeicher oder ein einzelner Zwischenspeicher konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen enthält die Geometriepipeline 820 Tessellationskomponenten, um eine hardwarebeschleunigte Tessellation von 3D-Objekten durchzuführen. In einigen Ausführungsformen konfiguriert ein programmierbarer Hüllenshader 811 die Tessellationsoperationen. Ein programmierbarer Domänenshader 817 stellt eine Back-End-Auswertung der Tessellationsausgabe bereit. Eine Tessellationseinheit 813 arbeitet auf Anweisung des Hüllenshaders 811 und enthält Sonderlogik, um auf Grundlage eines groben geometrischen Modells, das als Eingabe in die Geometriepipeline 820 bereitgestellt wurde, einen Satz von detaillierten geometrischen Objekten zu erzeugen. In einigen Ausführungsformen, falls keine Tessellation verwendet wird, können Tessellationskomponenten (z. B. der Hüllenshader 811, die Tessellationseinheit 813 und der Domänenshader 817) umgangen werden.
In einigen Ausführungsformen können vollständige geometrische Objekte durch einen Geometrieshader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A-852B vergeben werden, oder können direkt zum Clipper 829 weitergehen. In einigen Ausführungsformen arbeitet der Geometrieshader an geometrischen Gesamtobjekten anstatt an Vertices oder Gruppen von Vertices, wie in vorangehenden Phasen der Grafikpipeline. Falls die Tessellation deaktiviert ist, empfängt der Geometrieshader 819 eine Eingabe vom Vertexshader 807. In einigen Ausführungsformen ist der Geometrieshader 819 durch ein Geometrieshaderprogramm programmierbar, um Geometrietessellationen durchzuführen, falls die Tessellationseinheiten deaktiviert sind.
Vor einer Rasterung verarbeitet ein Clipper 829 Vertexdaten. Der Clipper 829 kann ein fester Funktionsclipper oder ein programmierbarer Clipper mit Clipping- und Geometrieshaderfunktionen sein. In einigen Ausführungsformen verteilt eine Rasterungs- und Tiefentestkomponente 873 in der Ausgaberenderpipeline 870 Pixelshader, um die geometrischen Objekte in Darstellungen pro Pixel umzuwandeln. In einigen Ausführungsformen ist Pixelshaderlogik in der Threadausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung die Rasterungs- und Tiefentestkomponente 873 umgehen und über eine Ausgabestreamingeinheit 823 auf nicht gerasterte Vertexdaten zugreifen.
Der Grafikprozessor 800 weist einen Zwischenverbindungsbus, ein Zwischenverbindungsfabric oder einen anderen Zwischenverbindungsmechanismus auf, der ermöglicht, dass Daten und Nachrichten zwischen den Hauptkomponenten des Prozessors übermittelt werden. In einigen Ausführungsformen sind die Ausführungseinheiten 852A-852B und zugehörige Logikeinheiten (z. B. der L1-Zwischenspeicher 851, der Abtaster 854, der Texturzwischenspeicher 858 usw.) über einen Datenanschluss 856 verbunden, um auf Arbeitsspeicher zuzugreifen und mit Ausgaberenderpipelinekomponenten des Prozessors zu kommunizieren. In einigen Ausführungsformen weisen der Abtaster 854, die Zwischenspeicher 851, 858 und die Ausführungseinheiten 852A-852B jeweils separate Arbeitsspeicherzugriffspfade auf. In einer Ausführungsform kann der Texturzwischenspeicher 858 auch als ein Abtastzwischenspeicher konfiguriert sein.
In einigen Ausführungsformen enthält die Ausgaberenderpipeline 870 eine Rasterungs- und Tiefentestkomponente 873, die vertexbasierte Objekte in eine assoziierte pixelbasierte Darstellung umwandelt. In einigen Ausführungsformen enthält die Rasterungslogik eine Fenster-/Maskierungseinheit, um eine feste Funktions-Dreieck- und Linien-Rasterung durchzuführen. Ein assoziierter Renderzwischenspeicher 878 und Tiefenzwischenspeicher 879 sind ebenfalls in einigen Ausführungsformen verfügbar. Eine Pixeloperationskomponente 877 führt pixelbasierte Operationen an den Daten durch, obwohl mit 2D-Operationen assoziierte Pixeloperationen (z. B. Bitblockbildtransfers mit Mischen) in einigen Fällen von der 2D-Engine 841 durchgeführt werden oder zum Zeitpunkt der Anzeige von der Anzeigesteuerung 843 unter Verwendung von Überlagerungsanzeigeebenen substituiert werden. In einigen Ausführungsformen steht ein gemeinsam genutzter L3-Zwischenspeicher 875 allen Grafikkomponenten zur Verfügung, was das gemeinsame Nutzen von Daten ohne die Verwendung von Hauptsystemarbeitsspeicher ermöglicht.
In einigen Ausführungsformen enthält die Grafikprozessor-Medienpipeline 830 eine Medienengine 837 und ein Video-Front-End 834. In einigen Ausführungsformen empfängt das Video-Front-End 834 Pipelinebefehle von der Befehlsstreamingeinheit 803. In einigen Ausführungsformen enthält die Medienpipeline 830 eine separate Befehlsstreamingeinheit. In einigen Ausführungsformen verarbeitet das Video-Front-End 834 Medienbefehle, bevor es den Befehl an die Medienengine 837 sendet. In einigen Ausführungsformen enthält die Medienengine 837 Threaderzeugungsfunktionalität, um Threads zum Versand über den Thread-Dispatcher 831 an die Threadausführungslogik 850 zu erzeugen.
In einigen Ausführungsformen enthält der Grafikprozessor 800 eine Anzeigeengine 840. In einigen Ausführungsformen ist die Anzeigeengine 840 zum Prozessor 800 extern und koppelt über die Ringzwischenverbindung 802 oder einen anderen Zwischenverbindungsbus oder eine andere Zwischenverbindungsfabric an den Grafikprozessor. In einigen Ausführungsformen enthält die Anzeigeengine 840 eine 2D-Engine 841 und eine Anzeigesteuerung 843. In einigen Ausführungsformen enthält die Anzeigeengine 840 Sonderlogik, die fähig ist, unabhängig von der 3D-Pipeline zu arbeiten. In einigen Ausführungsformen koppelt die Anzeigesteuerung 843 an eine Anzeigevorrichtung (nicht gezeigt), die eine in das System integrierte Anzeigevorrichtung sein kann, wie in einem Laptopcomputer, oder eine externe Anzeigevorrichtung sein kann, die über einen Anzeigevorrichtungsanschluss angebunden ist.
In einigen Ausführungsformen sind die Geometriepipeline 820 und die Medienpipeline 830 konfigurierbar, um Operationen auf Grundlage mehrerer Grafik- und Medienprogrammierschnittstellen durchzuführen, und sind nicht für eine bestimmte Anwendungsprogrammierschnittstelle (API) spezifisch. In einigen Ausführungsformen übersetzt Treibersoftware für den Grafikprozessor API-Aufrufe, die für eine bestimmte Grafik- oder Medienbibliothek spezifisch sind, in Befehle, die vom Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL), Open Computing Language (OpenCL) und/oder Vulkan-Grafik- und Rechen-API, alle von der Khronos-Gruppe, bereitgestellt. In einigen Ausführungsformen kann Unterstützung auch 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 Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine zukünftige API mit einer kompatiblen 3D-Pipeline würde ebenfalls unterstützt werden, falls eine Abbildung von der Pipeline der zukünftigen API auf die Pipeline des Grafikprozessors erstellt werden kann.
Programmierung der Grafikpipeline
9A ist ein Blockdiagramm, das ein Grafikprozessor-Befehlsformat 900 nach einigen Ausführungsformen veranschaulicht. 9B ist ein Blockdiagramm, das eine Grafikprozessor-Befehlsfolge 910 nach einer Ausführungsform veranschaulicht. Die durchgezogen umrandeten Kästchen in 9A veranschaulichen die Komponenten, die allgemein in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Komponenten enthalten, die optional sind oder die nur in einer Teilmenge der Grafikbefehle enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 von 9A enthält Datenfelder, um einen Client 902 zu identifizieren, einen Befehlsoperationscode (Opcode) 904 und Daten 906 für den Befehl. Ein Sub-Opcode 905 und eine Befehlsgröße 908 sind in einigen Befehlen ebenfalls enthalten.
In einigen Ausführungsformen gibt der Client 902 die Clienteinheit der Grafikvorrichtung an, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Clientfeld jedes Befehls, um die weitere Verarbeitung des Befehls aufzubereiten und die Befehlsdaten an die passende Clienteinheit zu leiten. In einigen Ausführungsformen enthalten die Grafikprozessor-Clienteinheiten eine Arbeitsspeicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Clienteinheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Sobald der Befehl von der Clienteinheit empfangen wurde, liest die Clienteinheit den Opcode 904 und den Sub-Opcode 905, falls vorhanden, um die durchzuführende Operation zu ermitteln. Die Clienteinheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 durch. Für einige Befehle wird erwartet, dass eine explizite Befehlsgröße 908 die Größe des Befehls angibt. In einigen Ausführungsformen ermittelt der Befehlsparser die Größe von mindestens einigen der Befehle auf Grundlage des Befehlsopcodes. In einigen Ausführungsformen sind die Befehle über Mehrfache eines Doppelworts ausgerichtet. Andere Befehlsformate können verwendet werden.
Das Ablaufdiagramm in 9B veranschaulicht eine beispielhafte Grafikprozessor-Befehlsfolge 910. In einigen Ausführungsformen verwendet Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors umfasst, eine Version der gezeigten Befehlsfolge, um einen Satz von Grafikoperationen einzurichten, auszuführen und abzuschließen. Eine beispielhafte Befehlsfolge wird nur zu Beispielzwecken gezeigt, da Ausführungsformen nicht auf diese spezifischen Befehle oder auf diese Befehlsfolge beschränkt sind. Darüber hinaus können die Befehle als ein Batch von Befehlen in einer Befehlsfolge erteilt werden, sodass der Grafikprozessor die Befehlsfolge zumindest teilweise gleichzeitig verarbeitet.
In einigen Ausführungsformen kann die Grafikprozessor-Befehlsfolge 910 mit einem Pipelineleerungsbefehl 912 beginnen, um zu bewirken, dass alle aktiven Grafikpipelines die aktuell anstehenden Befehle für die Pipeline abschließen. In einigen Ausführungsformen können die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig arbeiten. Die Pipelineleerung wird durchgeführt, um zu veranlassen, dass die aktive Grafikpipeline alle anstehenden Befehle abschließt. Als Reaktion auf eine Pipelineleerung hält der Befehlsparser für den Grafikprozessor eine Befehlsverarbeitung an, bis die aktiven Zeichenengines anstehende Operationen abschließen und die relevanten Lesezwischenspeicher ungültig gemacht sind. Optional können alle Daten im Renderzwischenspeicher, die als „verändert‟ markiert sind, in den Arbeitsspeicher geleert werden. In einigen Ausführungsformen kann der Pipelineleerungsbefehl 912 zur Pipelinesynchronisierung oder vor dem Platzieren des Grafikprozessors in einen Ruhezustand verwendet werden.
In einigen Ausführungsformen wird ein Pipelineauswahlbefehl 913 verwendet, wenn eine Befehlsfolge erfordert, dass der Grafikprozessor explizit zwischen Pipelines wechselt. In einigen Ausführungsformen ist ein Pipelineauswahlbefehl 913 nur einmal innerhalb eines Ausführungskontexts erforderlich, bevor Pipelinebefehle erteilt werden, es sei denn, der Kontext hat Befehle für beide Pipelines auszugeben. In einigen Ausführungsformen ist ein Pipelineleerungsbefehl 912 unmittelbar vor einem Pipelinewechsel über den Pipelineauswahlbefehl 913 erforderlich.
In einigen Ausführungsformen konfiguriert ein Pipelinesteuerbefehl 914 eine Grafikpipeline zum Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Pipelinesteuerbefehl 914 den Pipelinezustand für die aktive Pipeline. In einer Ausführungsform wird der Pipelinesteuerbefehl 914 zur Pipelinesynchronisierung und dazu verwendet, vor dem Verarbeiten eines Batchs von Befehlen Daten aus einem oder mehreren Zwischenspeichern in der aktiven Pipeline zu löschen.
In einigen Ausführungsformen werden Rückgabepufferzustandsbefehle 916 verwendet, um einen Satz von Rückgabepuffern für die jeweiligen Pipelines zum Schreiben von Daten zu konfigurieren. Einige Pipelineoperationen erfordern die Zuordnung, Auswahl oder Konfiguration eines oder mehrerer Rückgabepuffer, in die die Operationen während der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor auch einen oder mehrere Rückgabepuffer, um Ausgabedaten zu speichern und eine threadübergreifende Kommunikation durchzuführen. In einigen Ausführungsformen enthält der Rückgabepufferzustand 916 ein Auswählen der Größe und Anzahl der Rückgabepuffer, die für einen Satz von Pipelineoperationen zu verwenden sind.
Die verbleibenden Befehle in der Befehlsfolge unterscheiden sich auf Grundlage der aktiven Pipeline für Operationen. Auf Grundlage einer Pipelineermittlung 920 ist die Befehlsfolge auf die 3D-Pipeline 922, beginnend mit dem 3D-Pipelinezustand 930, oder die Medienpipeline 924, beginnend mit dem Medienpipelinezustand 940, zugeschnitten.
Die Befehle, um den 3D-Pipelinezustand 930 zu konfigurieren, enthalten Festlegungsbefehle für den 3D-Zustand für den Vertexpufferzustand, Vertexelementzustand, konstanten Farbzustand, Tiefenpufferzustand und andere Zustandsvariablen, die zu konfigurieren sind, bevor 3D-Primitiven-Befehle verarbeitet werden. Die Werte dieser Befehle werden zumindest teilweise auf Basis der bestimmten 3D-API in Verwendung ermittelt. In einigen Ausführungsformen sind 3D-Pipelinezustandsbefehle 930 auch fähig, bestimmte Pipelineelemente selektiv zu deaktivieren oder zu umgehen, falls diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird ein 3D-Primitiven-Befehl 932 verwendet, um 3D-Primitiven zu übermitteln, die von der 3D-Pipeline zu verarbeiten sind. Befehle und zugehörige Parameter, die an den Grafikprozessor über den 3D-Primitiven-Befehl 932 übermittelt werden, werden an die Vertexabruffunktion in der Grafikpipeline weitergeleitet. Die Vertexabruffunktion verwendet die Daten des 3D-Primitiven-Befehls 932, um Vertexdatenstrukturen zu generieren. Die Vertexdatenstrukturen werden in einem oder mehreren Rückgabepuffern gespeichert. In einigen Ausführungsformen wird der 3D-Primitiven-Befehl 932 verwendet, um über Vertexshader Vertexoperationen an 3D-Primitiven durchzuführen. Um Vertexshader zu verarbeiten, verteilt die 3D-Pipeline 922 Shaderausführungsthreads an Grafikprozessor-Ausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Ausführungsbefehl 934 oder ein Ereignis ausgelöst. In einigen Ausführungsformen löst ein Registerschreibvorgang eine Befehlsausführung aus. In einigen Ausführungsformen wird die Ausführung über einen ,Los'- oder „Anstoß‟-Befehl in der Befehlsfolge ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipelinesynchronisationsbefehls ausgelöst, um die Befehlsfolge durch die Grafikpipeline zu spülen. Die 3D-Pipeline führt eine Geometrieverarbeitung für die 3D-Primitiven aus. Sobald die Vorgänge abgeschlossen sind, werden die resultierenden geometrischen Objekte gerastert und die Pixelengine färbt die resultierenden Pixel ein. Zusätzliche Befehle, um eine Pixelschattierung und Pixel-Hintergrundoperationen zu steuern, können für diese Operationen auch enthalten sein.
In einigen Ausführungsformen folgt die Grafikprozessor-Befehlsfolge 910 beim Durchführen von Medienoperationen dem Pfad der Medienpipeline 924. Im Allgemeinen hängen die bestimmte Verwendung und die Art der Programmierung für die Medienpipeline 924 von den durchzuführenden Medien- oder Rechenoperationen ab. Spezifische Mediendecodieroperationen können während der Mediendecodierung an die Medienpipeline ausgelagert werden. In einigen Ausführungsformen kann die Medienpipeline auch umgangen werden und eine Mediendecodierung kann gänzlich oder teilweise unter Verwendung von Ressourcen durchgeführt werden, die von einem oder mehreren Universalverarbeitungskernen bereitgestellt werden. In einer Ausführungsform enthält die Medienpipeline auch Elemente für Operationen einer Universalgrafikprozessoreinheit (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektoroperationen unter Verwendung von rechnerischen Shaderprogrammen durchzuführen, die nicht explizit mit dem Rendern von Grafikgrundtypen verbunden sind.
In einigen Ausführungsformen ist die Medienpipeline 924 auf eine ähnliche Weise wie die 3D-Pipeline 922 konfiguriert. Ein Befehlssatz, um den Zustand der Medienpipeline 940 zu konfigurieren, wird vor den Medienobjektbefehlen 942 in eine Befehlswarteschlange verteilt oder platziert. In einigen Ausführungsformen enthalten die Befehle für den Medienpipelinezustand 940 Daten, um die Medienpipelineelemente zu konfigurieren, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies enthält Daten, um die Videodecodier- und Videocodierlogik in der Medienpipeline zu konfigurieren, wie ein Codier- oder Decodierformat. In einigen Ausführungsformen unterstützen Befehle für den Medienpipelinezustand 940 auch die Verwendung von einem oder mehreren Zeigern auf „indirekte“ Zustandselemente, die eine Gruppe von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Zeiger auf Medienobjekte zur Verarbeitung durch die Medienpipeline. Die Medienobjekte enthalten Speicherpuffer, die zu verarbeitende Videodaten enthalten. In einigen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 erteilt wird. Sobald der Pipelinezustand konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange gereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein äquivalentes Ausführungsereignis (z. B. einen Registerschreibvorgang) ausgelöst. Eine Ausgabe von der Medienpipeline 924 kann dann durch von der 3D-Pipeline 922 oder der Medienpipeline 924 bereitgestellte Operationen nachbearbeitet werden. In einigen Ausführungsformen werden GPGPU-Operationen auf eine ähnliche Weise wie Medienoperationen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 veranschaulicht eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 nach einigen Ausführungsformen. In einigen Ausführungsformen enthält die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen enthält der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Universalprozessorkerne 1034. Die Grafikanwendung 1010 und das Betriebssystem 1020 werden jeweils im Systemarbeitsspeicher 1050 des Datenverarbeitungssystems ausgeführt.
In einigen Ausführungsformen enthält die 3D-Grafikanwendung 1010 ein oder mehrere Shaderprogramme, die Shaderanweisungen 1012 enthalten. Die Shader-Sprachanweisungen können in einer höheren Shadersprache, wie der High Level Shader Language (HLSL) von Direct3D oder der OpenGL Shader Language (GLSL) und so weiter sein. Die Anwendung enthält auch ausführbare Anweisungen 1014 in einer zur Ausführung durch den Universalprozessorkern 1034 geeigneten Maschinensprache. Die Anwendung enthält auch Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows®-Betriebssystem von der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein quelloffenes UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie die Direct3D-API, die OpenGL-API oder die Vulkan-API unterstützen. Wenn die Direct3D-API in Verwendung ist, verwendet das Betriebssystem 1020 einen Front-End-Shader-Compiler 1024, um eine Shader-Anweisung 1012 in HLSL in eine niedrigere Shadersprache zu compilieren. Die Compilierung kann eine einsatzsynchrone (JIT) Compilierung sein oder die Anwendung kann eine Shader-Vorcompilierung durchführen. In einigen Ausführungsformen werden Shader auf hoher Ebene während der Compilierung der 3D-Grafikanwendung 1010 in Shader auf niedriger Ebene compiliert. In einigen Ausführungsformen werden die Shaderanweisungen 1012 in einer Zwischenform bereitgestellt, wie einer Version der von der Vulkan-API verwendeten Standard Portable Intermediate Representation (SPIR).
In einigen Ausführungsformen enthält ein Benutzermodus-Grafiktreiber 1026 einen Back-End-Shader-Compiler 1027, um die Shaderanweisungen 1012 in eine hardwarespezifische Darstellung umzuwandeln. Wenn die OpenGL-API in Verwendung ist, werden Shaderanweisungen 1012 in der GLSL-Sprache auf hoher Ebene an einen Benutzermodus-Grafiktreiber 1026 zur Compilierung weitergeleitet. In einigen Ausführungsformen verwendet der Benutzermodus-Grafiktreiber 1026 Betriebssystemkernelmodusfunktionen 1028, um mit einem Kernelmodus-Grafiktreiber 1029 zu kommunizieren. In einigen Ausführungsformen kommuniziert der Kernelmodus-Grafiktreiber 1029 mit dem Grafikprozessor 1032, um Befehle und Anweisungen zu versenden.
IP- Kern-Implementierungen
Ein oder mehrere Gesichtspunkte mindestens einer Ausführungsform können durch repräsentativen Code implementiert sein, der auf einem maschinenlesbaren Medium gespeichert ist, das Logik in einem integrierten Schaltkreis wie einem Prozessor repräsentiert und/oder definiert. Das maschinenlesbare Medium kann zum Beispiel Anweisungen enthalten, die verschiedene Logik im Prozessor repräsentiert. Wenn sie von einer Maschine gelesen werden, können die Anweisungen die Maschine veranlassen, die Logik zu erzeugen, um die hierin beschriebenen Techniken durchzuführen. Derartige Darstellungen, als „IP-Kerne“ bekannt, sind wiederverwendbare Logikeinheiten für einen integrierten Schaltkreis, die auf einem greifbaren, maschinenlesbaren Medium als ein Hardwaremodell gespeichert sein können, das die Struktur des integrierten Schaltkreises beschreibt. Das Hardwaremodell kann an verschiedene Kunden oder Fertigungsanlagen geliefert werden, die das Hardwaremodell in Fertigungsmaschinen laden, die den integrierten Schaltkreis herstellen. Der integrierte Schaltkreis kann so gefertigt werden, dass der Schaltkreis Operationen durchführt, die im Zusammenhang mit beliebigen der hierin beschriebenen Ausführungsformen beschrieben wurden.
11A ist ein Blockdiagramm, das ein IP-Kern-Entwicklungssystem 1100 veranschaulicht, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Operationen nach einer Ausführungsform durchzuführen. Das IP-Kern-Entwicklungssystem 1100 kann verwendet werden, um modulare, wiederverwendbare Designs zu erstellen, die in ein größeres Design eingebunden werden können oder verwendet werden können, um einen gesamten integrierten Schaltkreis (z. B. einen integrierten SoC-Schaltkreis) zu konstruieren. Eine Designanlage 1130 kann eine Softwaresimulation 1110 eines IP-Kern-Designs in einer höheren Programmiersprache (z. B. C/C++) generieren. Die Softwaresimulation 1110 kann verwendet werden, um das Verhalten des IP-Kerns unter Verwendung eines Simulationsmodells 1112 zu konstruieren, testen und zu verifizieren. Das Simulationsmodell 1112 kann funktionale, Verhaltens- und/oder Zeitgebungssimulationen enthalten. Ein Design auf Registertransferebene (RTL) 1115 kann dann erstellt oder aus dem Simulationsmodell 1112 zusammengesetzt werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens des integrierten Schaltkreises, das den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der assoziierten Logik, die unter Verwendung der modellierten digitalen Signale durchgeführt wird. Zusätzlich zu einem RTL-Design 1115 können auch Designs niedrigerer Ebenen auf Logikebene oder Transistorebene erstellt, konstruiert oder zusammengesetzt werden. Deshalb können die bestimmten Details des anfänglichen Designs und der Simulation variieren.
Das RTL-Design 1115 oder ein äquivalentes können weiter von der Designanlage in ein Hardwaremodell 1120 zusammengesetzt werden, das in einer Hardwarebeschreibungssprache (HDL) oder einer anderen Darstellung von physikalischen Designdaten sein kann. Die HDL kann weiter simuliert oder getestet werden, um das IP-Kern-Design zu verifizieren. Das IP-Kern-Design kann zur Lieferung an eine Fertigungsanlage von Dritten 1165 unter Verwendung von nichtflüchtigem Speicher 1140 (z. B. einer Festplatte, Flashspeicher oder einem beliebigen nichtflüchtigen Speichermedium) gespeichert werden. Alternativ kann das IP-Kern-Design über eine verdrahtete Verbindung 1150 oder drahtlose Verbindung 1160 (z.B. über das Internet) gesendet werden. Die Fertigungsanlage 1165 kann dann einen integrierten Schaltkreis fertigen, der zumindest teilweise auf dem IP-Kern-Design basiert. Der gefertigte integrierte Schaltkreis kann konfiguriert sein, Operationen nach mindestens einer hierin beschriebenen Ausführungsform durchzuführen.
11B veranschaulicht eine seitliche Querschnittsansicht einer integrierten Schaltkreisgehäuseanordnung 1170 nach einigen hierin beschriebenen Ausführungsformen. Die integrierte Schaltkreisgehäuseanordnung 1170 veranschaulicht eine Implementierung eines oder mehrerer Prozessor- oder Beschleunigervorrichtungen, wie sie hierin beschrieben sind. Die Gehäuseanordnung 1170 enthält mehrere Einheiten von Hardwarelogik 1172, 1174, die mit einem Substrat 1180 verbunden sind. Die Logik 1172, 1174 kann zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und kann einen oder mehrere Abschnitte eines der Prozessoren(e), Grafikprozessor(en) oder anderer hierin beschriebenen Beschleunigervorrichtungen enthalten. Jede Logikeinheit 1172, 1174 kann in einem Halbleiterchip implementiert sein und über eine Zwischenverbindungsstruktur 1173 an das Substrat 1180 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann konfiguriert sein, elektrische Signale zwischen der Logik 1172, 1174 und dem Substrat 1180 zu leiten und kann Zwischenverbindungen wie unter anderem Lötperlen oder Säulen enthalten. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale wie beispielsweise Eingabe/Ausgabe(E/A)-Signale und/oder Energie- oder Erdungssignale zu leiten, die mit dem Betrieb der Logik 1172, 1174 assoziiert sind. In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Gehäuseanordnung 1170 kann über eine Gehäusezwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Gehäusezwischenverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen zu leiten, wie eine Hauptplatine, einen anderen Chipsatz oder ein Mehrchipmodul.
In einigen Ausführungsformen sind die Logikeinheiten 1172, 1174 elektrisch an eine Brücke 1182 gekoppelt, die konfiguriert ist, elektrische Signale zwischen der Logik 1172, 1174 zu leiten. Die Brücke 1182 kann eine dichte Zwischenverbindungsstruktur sein, die eine Route für elektrische Signale bietet. Die Brücke 1182 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet werden, 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 mehr oder weniger Logikeinheiten auf einem oder mehreren Chips enthalten. Der eine oder die mehreren Chips können durch null oder mehr Brücken verbunden sein, da die Brücke 1182 ausgeschlossen sein kann, wenn die Logik auf einem einzelnen Chip enthalten ist. Alternativ können mehrere Chips oder Logikeinheiten durch eine oder mehrere Brücken verbunden sein. Zusätzlich können mehrere Logikeinheiten und Brücken zusammen in anderen möglichen Konfigurationen verbunden sein, einschließlich dreidimensionaler Konfigurationen.
11C veranschaulicht eine Gehäuseanordnung 1190, die mehrere Einheiten von Hardwarelogik-Einzelchips enthält, die mit einem Substrat 1180 (z. B. einem Basischip) verbunden sind. Eine Grafikverarbeitungseinheit, Parallelprozessor und/oder Rechenbeschleuniger wie hierin beschrieben kann bzw. können aus verschiedenen Silizium-Einzelchips bestehen, die getrennt hergestellt werden. In diesem Kontext ist ein Einzelchip ein zumindest teilweise eingehauster integrierter Schaltkreis, der individuelle Logikeinheiten enthält, die mit anderen Einzelchips in ein größeres Gehäusepaket zusammengesetzt werden können. Ein verschiedenartiger Satz von Einzelchips mit unterschiedlicher IP-Kernlogik kann in eine einzige Vorrichtung zusammengesetzt werden. Zusätzlich können die Einzelchips unter Verwendung von aktiver Zwischenschaltungstechnologie in einen Basischip oder Basis-Einzelchip integriert werden. Die hierin beschriebenen Konzepte ermöglichen die Zwischenverbindung und Kommunikation zwischen den verschiedenen Formen von IP innerhalb der GPU. IP-Kerne können unter Verwendung verschiedener Prozesstechnologien hergestellt sein und während der Herstellung zusammengesetzt werden, was die Komplexität eines Zusammenlegens mehrerer IPs, insbesondere auf einem großen SoC mit mehreren Arten von IPs, auf den gleichen Herstellungsprozess vermeidet. Eine Ermöglichung der Verwendung mehrerer Prozesstechnologien verbessert die Produkteinführungszeit und bietet einen kostengünstigen Weg, mehrere Produkt-SKUs zu erzeugen. Darüber hinaus sind die getrennten IPs besser geeignet, unabhängig mit Energie angesteuert zu werden, Komponenten, die bei einer bestimmten Arbeitslast nicht in Verwendung sind, können ausgeschaltet werden, was den Gesamtenergieverbrauch reduziert.
Die Hardwarelogik-Einzelchips können Sonder-Hardwarelogik-Einzelchips 1172, Logik- oder E/A-Einzelchips 1174 und/oder Arbeitsspeicher-Einzelchips 1175 enthalten. Die Hardwarelogik-Einzelchips 1172 und Logik- oder E/A-Einzelchips 1174 können zumindest teilweise in konfigurierbarer Logik oder Logikhardware mit fester Funktionalität implementiert sein und können einen oder mehrere Abschnitte eines der Prozessoren(e), Grafikprozessor(en), Parallelprozessoren oder anderer hierin beschriebenen Beschleunigervorrichtungen enthalten. Die Arbeitsspeicher-Einzelchips 1175 können DRAM-Arbeitsspeicher (z. B. GDDR, HBM) oder Zwischenspeicher (SRAM) sein.
Jeder Einzelchip kann als ein getrennter Halbleiterchip gefertigt sein und über eine Zwischenverbindungsstruktur 1173 an das Substrat 1180 gekoppelt sein. Die Zwischenverbindungsstruktur 1173 kann ausgelegt sein, um elektrische Signale zwischen den verschiedenen Einzelchips und Logik innerhalb des Substrats 1180 zu leiten. Die Zwischenverbindungsstruktur 1173 kann Zwischenverbindungen wie unter anderem Lötperlen oder Säulen enthalten. In einigen Ausführungsformen kann die Zwischenverbindungsstruktur 1173 konfiguriert sein, elektrische Signale wie beispielsweise Eingabe/Ausgabe(E/A)-Signale und/oder Energie- oder Erdungssignale zu leiten, die mit dem Betrieb der Logik-, E/A- und Arbeitsspeicher-Einzelchips assoziiert sind.
In einigen Ausführungsformen ist das Substrat 1180 ein Laminatsubstrat auf Epoxidbasis. Das Substrat 1180 kann in anderen Ausführungsformen andere geeignete Typen von Substraten enthalten. Die Gehäuseanordnung 1190 kann über eine Gehäusezwischenverbindung 1183 mit anderen elektrischen Vorrichtungen verbunden sein. Die Gehäusezwischenverbindung 1183 kann an eine Oberfläche des Substrats 1180 gekoppelt sein, um elektrische Signale an andere elektrische Vorrichtungen zu leiten, wie eine Hauptplatine, einen anderen Chipsatz oder ein Mehrchipmodul.
In einigen Ausführungsformen können ein Logik- oder E/A-Einzelchip 1174 und ein Arbeitsspeicher-Einzelchip 1175 elektrisch über eine Brücke 1187 gekoppelt sein, die ausgelegt ist, elektrische Signale zwischen dem Logik- oder E/A-Einzelchip 1174 und einem Arbeitsspeicher-Einzelchip 1175 zu lenken. Die Brücke 1187 kann eine dichte Zwischenverbindungsstruktur sein, die eine Route für elektrische Signale bietet. Die Brücke 1187 kann ein Brückensubstrat enthalten, das aus Glas oder einem geeigneten Halbleitermaterial besteht. Elektrische Leitungselemente können auf dem Brückensubstrat gebildet werden, um eine Chip-zu-Chip-Verbindung zwischen der Logik oder dem E/A-Einzelchip 1174 und einem Arbeitsspeicher-Einzelchip 1175 bereitzustellen. Die Brücke 1187 kann auch als eine Siliziumbrücke oder eine Zwischenverbindungsbrücke bezeichnet werden. Die Brücke 1187 ist in einigen Ausführungsformen zum Beispiel eine Embedded Multi-Die Interconnect Bridge (EMIB). In einigen Ausführungsformen kann die Brücke 1187 einfach eine direkte Verbindung von einem Einzelchip zu einem anderen Einzelchip sein.
Das Substrat 1180 kann Hardwarekomponenten für E/A 1191, Zwischenspeicher 1192 und andere Hardwarelogik 1193 enthalten. Eine Fabric 1185 kann in das Substrat 1180 eingebettet sein, um eine Kommunikation zwischen den verschiedenen Logik-Einzelchips und der Logik 1191, 1193 innerhalb des Substrats 1180 zu ermöglichen. In einer Ausführungsform können die E/A 1191, Fabric 1185, der Zwischenspeicher, die Brücke und andere Hardwarelogik 1193 in einen Basischip integriert sein, der auf das Substrat 1180 geschichtet ist.
In verschiedenen Ausführungsformen kann eine Gehäuseanordnung 1190 weniger oder mehr Komponenten und Einzelkomponenten enthalten, die durch eine Fabric 1185 oder eine oder mehrere Brücken 1187 miteinander verbunden sind. Die Einzelchips innerhalb der Gehäuseanordnung 1190 können in einer 3D- oder 2,5D-Anordnung angeordnet sein. Im Allgemeinen können Brückenstrukturen 1187 verwendet werden, um eine Punkt-zu-Punkt-Zwischenverbindung beispielsweise zwischen Logik- oder E/A-Einzelchips und Arbeitsspeicher-Einzelchips zu ermöglichen. Die Fabric 1185 kann verwendet werden, um die verschiedenen Logik- und/oder E/A-Einzelchips miteinander zu verbinden (z. B. die Einzelchips 1172, 1174, 1191, 1193). mit anderen Logik- und/oder E/A-Einzelchips. In einer Ausführungsform kann der Zwischenspeicher 1192 innerhalb des Substrats als ein globaler Zwischenspeicher für die Gehäuseanordnung 1190, als Teil eins verteilten globalen Zwischenspeichers oder als ein dedizierter Zwischenspeicher für die Fabric 1185 fungieren.
11D veranschaulicht eine Gehäuseanordnung 1194, die austauschbare Einzelchips 1195 enthält, nach einer Ausführungsform. Die austauschbaren Einzelchips 1195 können in standardisierte Schlitze auf einem oder mehreren Basis-Einzelchips 1196, 1198 zusammengesetzt werden. Die Basis-Einzelchips 1196, 1198 können über eine Brücken-Zwischenverbindung 1197 gekoppelt sein, die den anderen hierin beschriebenen Brücken-Zwischenverbindungen ähnlich sein kann und beispielsweise eine EMIB sein kann. Arbeitsspeicher-Einzelchips können auch über eine Brücken-Zwischenverbindung mit Logik- oder E/A-Einzelchips verbunden sein. E/A- und Logik-Einzelchips können über eine Zwischenverbindungsfabric kommunizieren. Die Basis-Einzelchips können jeweils einen oder mehrere Schlitze in einem standardisierten Format für entweder Logik oder E/A oder Arbeitsspeicher/Zwischenspeicher unterstützen.
In einer Ausführungsform können SRAM- und Energieversorgungsschaltkreise in einen oder mehrere der Basis-Einzelchips 1196, 1198 gefertigt sein, die unter Verwendung einer relativ zu den austauschbaren Einzelchips 1195, die auf den Basis-Einzelchips gestapelt sind, verschiedenen Prozesstechnologie gefertigt sein können. Beispielsweise können die Basis-Einzelchips 1196, 1198 unter Verwendung einer größeren Prozesstechnologie gefertigt sein, während die austauschbaren Einzelchips unter Verwendung einer kleineren Prozesstechnologie hergestellt sein können. Einer oder mehrere der austauschbaren Einzelchips 1195 können Arbeitsspeicher-Einzelchips (z.B. DRAM-Einzelchips) sein. Unterschiedliche Arbeitsspeicherdichten können für die Gehäuseanordnung 1194 auf Grundlage der Energie und/oder Leistung ausgewählt werden, auf die für das Produkt abgezielt wird, das die Gehäuseanordnung 1194 verwendet. Darüber hinaus können Logik-Einzelchips mit einer unterschiedlichen Anzahl von Typen von funktionalen Einheiten zum Zeitpunkt des Zusammenbaus auf Grundlage der Energie und/oder Leistung ausgewählt werden, auf die für das Produkt abgezielt wird. Darüber hinaus können Einzelchips, die IP-Logikkerne verschiedener Typen beinhalten, in die austauschbaren Einzelchipschlitze eingesetzt werden, was Hybrid-Prozessordesigns ermöglicht, die IP-Blöcke unterschiedlicher Technologien frei kombinieren können.
Beispielhafter integrierter Ein-Chip-System-Schaltkreis
12 und 13A-13B veranschaulichen beispielhafte integrierte Schaltkreise und zugehörige Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne nach verschiedenen hierin beschriebenen Ausführungsformen gefertigt werden können. Zusätzlich zu den veranschaulichten können andere Logik und Schaltkreise enthalten sein, einschließlich zusätzlicher Grafikprozessoren/Kerne, peripherer Schnittstellensteuerungen oder Universalprozessorkeme.
12 ist ein Blockdiagramm, das einen beispielhaften integrierten Ein-Chip-System-Schaltkreis 1200 nach einer Ausführungsform veranschaulicht, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. Der beispielhafte integrierte Schaltkreis 1200 enthält einen oder mehrere Anwendungsprozessor(en) 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210 und kann zusätzlich einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen beliebige ein modularer IP-Kern von der gleichen oder mehreren verschiedenen Designanlagen sein können. Der integrierte Schaltkreis 1200 enthält periphere oder Buslogik, die eine USB-Steuerung 1225, eine UART-Steuerung 1230, eine SPI/SDIO-Steuerung 1235 und eine I2S/I2C-Steuerung 1240 enthält. Zusätzlich kann der integrierte Schaltkreis eine Anzeigevorrichtung 1245 enthalten, die entweder an eine High-Definition-Multimedia-Interface(HDMI)-Steuerung 1250 und/oder eine Mobile-Industry-Processor-Interface(MIPI)-Anzeigeschnittstelle 1255 gekoppelt ist. Speicher kann durch ein Flashspeicher-Subsystem 1260 bereitgestellt werden, das Flasharbeitsspeicher und eine Flashspeichersteuerung enthält. Eine Arbeitsspeicherschnittstelle kann über eine Arbeitsspeichersteuerung 1265 zum Zugriff auf SDRAM- oder SRAM-Arbeitsspeichervorrichtungen bereitgestellt werden. Einige integrierte Schaltkreise enthalten zusätzlich eine eingebettete Sicherheitsengine 1270.
13A-13B sind Blockdiagramme, die beispielhafte Grafikprozessoren zur Verwendung innerhalb eines SoC nach hierin beschriebenen Ausführungsformen veranschaulichen. 13A veranschaulicht einen beispielhaften Grafikprozessor 1310 eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. 13B veranschaulicht einen weiteren beispielhaften Grafikprozessor 1340 eines integrierten Ein-Chip-System-Schaltkreises nach einer Ausführungsform, der unter Verwendung eines oder mehrerer IP-Kerne gefertigt werden kann. 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, enthält der Grafikprozessor 1310 einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A-1315N (z.B. 1315A, 1315B, 1315C, 1315D bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann über separate Logik unterschiedliche Shaderprogramme ausführen, sodass der Vertexprozessor 1305 optimiert ist, um Operationen für Vertexshaderprogramme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A-1315N Fragmentschattierungsoperationen (z.B. Pixelschattierungsoperationen) für Fragment- oder Pixelshaderprogramme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsphase der 3D-Grafikpipeline durch und erzeugt Primitive und Vertexdaten. Der bzw. die Fragmentprozessor(en) 1315A-1315N verwendet bzw. verwenden die vom Vertexprozessor 1305 generierten Primitiven- und Vertexdaten, um einen Rahmenpuffer zu erzeugen, der auf einer Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist bzw. sind der bzw. die Fragmentprozessor(en) 1315A-1315N optimiert, um Fragmentshaderprogramme auszuführen, wie sie in der OpenGL-API vorgesehen sind, die verwendet werden können, um ähnliche Operationen wie ein Pixelshaderprogramm durchzuführen, wie es in der Direct3D-API vorgesehen ist.
Der Grafikprozessor 1310 enthält zusätzlich eine oder mehrere Arbeitsspeicherverwaltungseinheiten (MMUs) 1320A-1320B, Zwischenspeicher 1325A-1325B und Schaltkreiszwischenverbindung(en) 1330A-1330B. Die eine oder die mehreren MMU(s) 1320A-1320B stellen eine virtuelle auf physische Adressenabbildung für den Grafikprozessor 1310 bereit, einschließlich für den Vertexprozessor 1305 und/oder den bzw. die Fragmentprozessor(en) 1315A-1315N, die auf im Arbeitsspeicher gespeicherte Vertex- oder Bild-/Texturdaten Bezug nehmen können, zusätzlich zu in dem einen oder den mehreren Zwischenspeichern 1325A-1325B gespeicherten Vertex- oder Bild-/Texturdaten. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A-1320B mit anderen MMUs im System synchronisiert sein, einschließlich einer oder mehreren MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder dem Videoprozessor 1220 von 12 assoziiert sind, sodass jeder Prozessor 1205-1220 an einem gemeinsam genutzten oder vereinheitlichten virtuellen Arbeitsspeichersystem teilnehmen kann. Der eine oder die mehreren Schaltkreiszwischenverbindung(en) 1330A-1330B ermöglichen dem Grafikprozessor 1310, an andere IP-Kerne im SoC anzubinden, entweder über einen internen Bus des SoC oder über eine direkte Verbindung, nach Ausführungsformen.
Wie in 13B gezeigt, enthält der Grafikprozessor 1340 eine oder mehrere MMU(s) 1320A-1320B, Zwischenspeicher 1325A-1325B und Schaltkreiszwischenverbindungen 1330A-1330B des Grafikprozessors 1310 von 13A. Der Grafikprozessor 1340 enthält einen oder mehrere Shaderkern(e) 1355A-1355N (z. B. 1455A, 1355B, 1355C, 1355D, 1355E, 1355F bis 1355N-1 und 1355N), was eine einheitliche Shaderkernarchitektur bereitstellt, in der ein einzelner Kern oder Typ oder Kern alle Arten von programmierbarem Shadercode ausführen kann, einschließlich Shaderprogrammcode, um Vertexshader, Fragmentshader und/oder Rechenshader zu implementieren. Die genaue Anzahl der vorhandenen Shaderkerne kann zwischen Ausführungsformen und Implementierungen variieren. Zusätzlich enthält der Grafikprozessor 1340 eine Zwischenkern-Aufgabenverwaltung 1345, die als ein Thread-Dispatcher fungiert, um Ausführungsthreads an einen oder mehrere Shaderkerne 1355A-1355N und eine Kacheleinheit 1358 zur Beschleunigung von Kacheloperationen für kachelbasiertes Rendering zu verteilen, wobei Renderoperationen für eine Szene im Bildraum aufgeteilt werden, zum Beispiel, um eine lokale räumliche Kohärenz innerhalb einer Szene auszunutzen oder eine Verwendung von internen Zwischenspeichern zu optimieren.
Konfigurierbarer Umordnungspuffer
In einigen Systemen werden Arbeitsspeicher-Lesevorgänge auf Basis von 64 B (64 Bytes) durchgeführt, aber Eingaben in einen Dekomprimierer sind 128 B oder 256 B. Abhängig vom komprimierten Zustand kann der Dekomprimierer 1, 2, 3 oder 4 64-B-Zwischenspeicherzeilen mit Daten verarbeiten. Da Lesevorgänge aus dem Arbeitsspeicher nicht immer in Reihenfolge zurückgegeben werden, werden gelesene Daten im Umordnungspuffer (ROB) vor dem Verteilen in Reihenfolge an den Dekomprimierer gespeichert. Ein ROB wird zur Medien-Dekomprimierung verwendet, da mehrere Zwischenspeicherzeilen als eine Eingabe in den Dekomprimierer erforderlich sein können. Verschiedene Ausführungsformen bieten ein System, das einen Empfang von Daten in einen Puffer und einen Empfang eines letzten Datenabschnitts nachverfolgt, der mit einer Leseanforderung assoziiert ist, um sicherzustellen, dass Daten dem Dekomprimierer in Reihenfolge bereitgestellt werden. Nach verschiedenen Ausführungsformen kann eine Menge von Arbeitsspeicherplatz, der vom ROB verwendetem Arbeitsspeicher zugeteilt ist, ausgelegt werden, eine Menge von Arbeitsspeicherplatz, der zum Umordnen von Daten zugeteilt ist, zu reduzieren und eine Arbeitsspeicherverwendung für andere Zwecke zu erlauben.
Eine Anwendung, ein Treiber oder ein Betriebssystem (OS) kann einen Zeichenaufruf erteilen, um Bilddaten zu generieren. Zum Beispiel erzeugt eine von einer GPU ausgeführte Medienpipeline Untertitel (Text), ein Webkamera-Fenster, eine Video-Wiedergabe (z. B. MPEG, JPEG) in einer 3D-Szene oder Inhalte mit einem Muster oder einem Gradienten. Beispielsweise kann eine Bi-Modell-Komprimierung auf Rot-grünblau(RGB)-Pixelwerte oder Videodaten angewandt werden. Bilddaten können komprimiert werden, um eine Größe von Bilddaten zu reduzieren, und im Arbeitsspeicher gespeichert werden. Komprimierte Bilddaten können zur weiteren Verarbeitung durch eine Pipeline oder zur Anzeige abgerufen werden. Eine Renderpipeline verwendet Daten, die von einer Medienpipeline komprimiert wurden. Eine Renderpipeline generiert zusammengesetzte Bilder aus Grafiken und Bildern oder Video zur Ausgabe mit einer Framerate oder zur Anwendung von Hochskalierung auf das Anzeigeformat. Ein von einem Prozessor ausgeführter Treiber kann eine Verwendung von Komprimierung oder einen Zugriff auf komprimierte Daten ermöglichen.
14 zeigt ein Blockdiagramm eines Arbeitsspeicher- und Umordnungspuffer(ROB)-Systems. Ein ROB-System 1400 empfängt komprimierte Daten von einem Arbeitsspeicher 1450, speichert die Daten und stellt die Daten einem Dekomprimierer 1420 in Reihenfolge bereit. In einigen Beispielen werden komprimierte Daten als Reaktion auf eine Leseanforderung aus dem Arbeitsspeicher 1450 in mehreren Segmenten oder Einträgen gesendet und die komprimierten Daten werden vor einem Senden oder Kopieren in Reihenfolge an den Dekomprimierer 1420 in einem Datenpuffer 1410 gespeichert.
Eine verlustbehaftete oder verlustfreie Dekomprimierungseinheit (z. B. der Dekomprimierer 1420) kann zum Beispiel Leseanforderungen an den Arbeitsspeicher 1450 starten. Eine Leseanforderung kann einen Lesevorgang von einem oder mehreren Einträgen aus dem Arbeitsspeicher 1450 zur Speicherung im Datenpuffer 1410 bewirken. Der Datenpuffer 1410 kann unter Verwendung eines dynamischen Arbeitsspeichers mit wahlfreiem Zugriff (DRAM) oder eines anderen RAM implementiert sein. Daten können vom Arbeitsspeicher 1450 in einem komprimierten Format empfangen werden. Komprimierte Datensegmente oder Einträge aus dem Arbeitsspeicher 1450 können am Datenpuffer 1410 nicht in Reihenfolge empfangen werden, aber der Dekomprimierer 1420 decodiert Daten in Reihenfolge. Falls beispielsweise eine Datenanforderung für 256 Bytes von Daten erfolgt, die auf 128 Bytes komprimiert sind, aber nur 64 Bytes in einem Taktzyklus unter Verwendung einer Arbeitsspeicherschnittstelle an den Datenpuffer 1410 übertragen oder kopiert werden, dann werden zwei 64-Byte-Segmente über zwei Taktzyklen an den Datenpuffer 1410 übertragen. Das ROB-System 1400 stellt sicher, dass eine Zuteilungsreihenfolge so bewahrt wird, dass das ROB-System 1400 Daten in der Reihenfolge der Zuteilung an den Dekomprimierer 1420 kopiert, sodass der Dekomprimierer 1420 die Daten in Reihenfolge decodieren kann. Aus dem Arbeitsspeicher 1450 gelesene Daten müssen möglicherweise umgeordnet werden, da Daten aus dem Arbeitsspeicher 1450 nicht in Reihenfolge bereitgestellt werden (auch falls Daten aus der gleichen Seite gelesen werden).
Falls ein 64-Byte-Segment, das einer ersten Zuteilung entspricht, nach einem 64-Byte-Segment empfangen wird, das einer zweiten Zuteilung entspricht, wartet das ROB-System 1400 bis zum Empfang des 64-Byte-Segments, das der ersten Zuteilung entspricht, bevor es dem Dekomprimierer 1420 die 64-Byte-Segmente bereitstellt, die der ersten und der zweiten Zuteilung entsprechen. Nachdem jedoch ein 64-Byte-Segment, das einer ersten Zuteilung entspricht, empfangen wird, wird das 64-Byte-Segment, das der ersten Zuteilung entspricht, dem Dekomprimierer nach dem Empfang im ROB-System 1400 bereitgestellt.
In einigen Beispielen, falls eine Arbeitsspeicherbusschnittstelle zwischen dem Arbeitsspeicher 1450 und dem ROB-System 1400 einen Transfer von 64 Bytes in einem Taktzyklus unterstützt, dann können auf 64 Bytes oder weniger komprimierte Daten in einem einzigen Taktzyklus an den Dekomprimierer 1420 übertragen werden und müssen nicht im Datenpuffer 1410 gespeichert werden. 14 zeigt eine derartige Übertragung als eine „Umgehung“ vom Arbeitsspeicher 1450 zum Dekomprimierer 1420 unter Verwendung einer Schnittstelle, wie zum Beispiel einer Zwischenverbindung.
Eine Lesesteuerung 1402 verwaltet eine Zuteilung von Einträgen im ROB-System 1400. Eine Leseanforderung kann ein Lesen von einem oder mehreren Einträgen aus dem Arbeitsspeicher 1450 abhängig von Arbeitsspeicherbusgröße und Komprimierungszustand bewirken. Leseanforderungen an den Arbeitsspeicher 1450 von einem Client (z. B. einem Dekomprimierer oder einer Renderpipeline, die einen Dekomprimierer verwendet) können der Lesesteuerung 1402 bereitgestellt werden. Die Lesesteuerung 1402 empfängt eine Leseanforderung und schlägt einen Komprimierungszustand aus einem Datenkomprimierungszustandszwischenspeicher 1412 (z. B. einem Arbeitsspeicher oder Zwischenspeicherbereich) nach, der zu lesende Daten (aus der Leseanforderung) mit einer Komprimierungsmenge assoziiert. Für eine Leseanforderung ermittelt die Lesesteuerung 1402 eine Anzahl von Einträgen, die zuzuteilen sind, auf Grundlage einer abzurufenden Datenmenge und eines Komprimierungszustand oder -pegels der Daten. Für eine Leseanforderung teilt die Lesesteuerung 1402 den Nachverfolgungs-FIFO 1404, Steuerinformationen 1406, den Indikator für vorhandene Daten 1408 und den Datenpuffer 1410 auf Grundlage einer Größe von aus dem Arbeitsspeicher 1450 zu lesenden Daten und eines Komprimierungszustands oder -pegels der Daten vorab zu.
Die Lesesteuerung 1402 initialisiert zum Beispiel alle der zugeteilten Einträge auf ein Rückgesetzt im Indikator für vorhandene Daten 1408, um anzuzeigen, dass keine der mit der Leseanforderung assoziierten Daten im Datenpuffer 1410 gespeichert sind. Die Steuerinformationen 1406 enthalten Komprimierungsinformationen für einen oder mehrere Einträge, die im Datenpuffer 1410 zu speichern sind. Die Komprimierungsinformationen können einen Komprimierungszustand (z. B. 256 B auf 96 B, 256 B auf 64 B und so weiter), ein Oberflächenformat (16 Bits pro Pixel, 32 Bits pro Pixel, 64 Bits pro Pixel und so weiter), ein Komprimierungsformat (z. B. Bitmaps, Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), QuickTime, Portable Network Graphic (PNG)) und andere Metadaten enthalten. Die Komprimierungsinformationen können an den Dekomprimierer 1420 zur Verwendung zum Dekomprimieren von Daten aus dem Datenpuffer 1410 bereitgestellt werden. Komprimierungsinformationen können von einem Client, aus dem Komprimierungszustandszwischenspeicher 1412 und anderen von der Lesesteuerung 1402 durchgeführten Arbeitsspeicherlesevorgängen empfangen werden.
Eine Leseanforderung nach an den Arbeitsspeicher 1450 gesendeten Daten wird mit einem oder mehreren Einträgen markiert oder assoziiert. Die Anzahl der zugeteilten Einträge kann einer Anzahl von komprimierten Zwischenspeicherleitungen entsprechen, die aus dem Arbeitsspeicher 1450 abgerufen werden. Eine Zwischenspeicherleitung kann eine beliebige Größe haben, wie zum Beispiel 32 B, 64 B oder ein beliebiges Vielfaches von 32 B.
Der Indikator für vorhandene Daten 1408 speichert Informationen pro Eintrag darüber, ob Daten für den Eintrag im Datenpuffer 1410 vorhanden sind oder nicht. Der Indikator für vorhandene Daten 1408 ist auf ein Rückgesetzt für alle Einträge initialisiert. Wenn ein Eintrag im Datenpuffer 1410 gespeichert wird, wird der assoziierte Rückgesetzt-/Gesetzt-Indikator pro Eintrag auf Gesetzt geändert. Wenn ein Dateneintrag im Datenpuffer 1410 empfangen wird, wird der Indikator im Indikator für vorhandene Daten 1408 für den Eintrag auf Gesetzt geändert. Wenn sich der Indikator für vorhandene Daten 1408 für einen Kopfzeileneintrag in einem gesetzten Zustand befindet und der Kopfzeileneintrag auch vom Lesezeiger von Nachverfolgungs-FIFO 1404 identifiziert wird, werden zugehörige Inhalte der Steuerinformationen 1406 und des Datenpuffers 1410 gelesen und die Transaktion wird an den Dekomprimierer 1420 gesendet. Die Kopfzeilendaten und zugehörige Komprimierungsinformationen werden zum Beispiel an den Dekomprimierer 1420 gesendet.
Die Nachverfolgungs-First-In-First-Out(FIFO)-Steuerung 1404 bewirkt, dass Dateneinträge aus dem Datenpuffer 1410 kopiert werden oder vom Datenpuffer 1410 an den Dekomprimierer 1420 in der Reihenfolge der Zuteilung gesendet werden. Die Nachverfolgungs-FIFO-Steuerung 1404 kann Schreib- und Lesezeiger verwenden, um im Datenpuffer 1410 gespeicherte Daten nachzuverfolgen und zu bewirken, dass Daten an den Dekomprimierer 1420 in der Reihenfolge der Eintragszuteilung ausgegeben werden. Darüber hinaus kann die Nachverfolgungs-FIFO-Steuerung 1404 identifizieren, ob ein beliebiger Eintrag ein zuletzt empfangener Eintrag ist. Ein Indikator für zuletzt empfangene Einträge für alle Einträge kann auf False initialisiert sein.
Die Nachverfolgungs-FIFO-Steuerung 1404 kann einen Indikator für zuletzt empfangene Einträge verwenden, um zu identifizieren, wann ein zuletzt zugeteilter Eintrag in einer Leseanforderung empfangen wird. Ein oder mehrere Bits können von der Nachverfolgungs-FIFO-Steuerung 1404 verwendet werden, um anzuzeigen, dass ein Eintrag von der letzten Zwischenspeicherzeile empfangen wird, der den Daten entspricht, die einer Dekomprimierung unterzogen werden. Der Indikator für den zuletzt zugeteilten Eintrag oder die letzte empfangene Zwischenspeicherzeile kann anzeigen, dass der letzte Eintrag in einer gereihten Folge von Einträgen im Datenpuffer 1410 gespeichert ist oder dass alle mit einer Leseanforderung assoziierten Einträge im Datenpuffer 1410 gespeichert worden sind.
Daten können vom Datenpuffer 1410 auf Grundlage eines Werts eines Lesezeigers des Nachverfolgungs-FIFO 1404 in den Dekomprimierer 1420 kopiert werden (oder zum Zugriff durch den Dekomprimierer 1420 durch Bereitstellen eines Zeigers verfügbar gemacht werden). Der Lesezeiger schreitet sequenziell vom ersten zugeteilten Eintrag (Kopf der Zeile) zum letzten zugeteilten Eintrag (z. B. Eintrag0 bis EintragN) im Datenpuffer 1410 fort, obwohl Daten im Datenpuffer 1410 nicht in Reihenfolge gespeichert oder empfangen werden. Ein Kopfzeileneintrag kann auf einen Eintrag verweisen, der nicht zur Dekomprimierung bereitgestellt wurde und vor einem anderen Eintrag bereitzustellen ist, wenn Einträge dem Dekomprimierer 1420 in Reihenfolge bereitzustellen sind.
Der Dekomprimierer 1420 kann unter Verwendung einer Schnittstelle wie einem Bus oder einer anderen Zwischenverbindung Steuerinformationen und Einträge aus dem Datenpuffer empfangen. Der Dekomprimierer 1420 kann den Puffer 1414 verwenden, um einen oder mehrere Einträge zu speichern. Der Puffer 1414 kann 256 B groß (oder eine andere Größe) sein und kann als Teil eines Arbeitsspeichers oder Zwischenspeichers implementiert sein. Der Dekomprimierer 1420 kann eine Dekomprimierung starten, wenn alle Eintragsdaten in Reihenfolge verfügbar sind oder wenn der Dekomprimierer 1420 einen Kopfzeilen-Dateneintrag in einer Folge von einem oder mehreren Dateneinträgen empfängt. Der Dekomprimierer 1420 kann einen Zwischenspeicher (z. B. Level-1, Level-2, Level-3 oder Last-Level-Zwischenspeicher) (nicht gezeigt) verwenden, um Daten vom Datenpuffer 1410 zu speichern. Der Dekomprimierer 1420 kann einen beliebigen Typ von verlustbehaftetem oder verlustfreiem Dekomprimierschema einschließlich Dekomprimierung eines beliebigen von Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), QuickTime oder Portable Network Graphics (PNG) durchführen.
15A zeigt ein Beispiel von Inhalten von Nachverfolgungs-FIFO, Steuerinformationen, Indikatoren für vorhandene Daten und Datenpuffern, die verschiedenen Leseanforderungen zugeteilt sind. Für eine beliebige Leseanforderung wird ein SchreibZeiger verwendet, um anzuzeigen, welcher Eintragsschlitz im Datenpuffer beschrieben wird, und ein LeseZeiger wird verwendet, um anzuzeigen, welcher Eintragsschlitz im Datenpuffer ein Zeilenkopf ist und aus welchem Eintragsschlitz im Datenpuffer zu lesen ist.
Beispielsweise eine Lese_Anforderung0 kann eine Zuteilung mehrerer Einträge 0 bis N auslösen, wobei für eine Leseanforderung N ≥ 2. IstLetzterEintrag0 bis IstLetzterEintragN von Nachverfolgungs-FIFO sind für jeweilige Einträge 0 bis N zugeteilt. Steuerinformationen können Eigenschaften eines oder mehrerer Einträge der komprimierten Daten enthalten (z. B. Komprimierungstyp, Datenformat und andere Metadaten). Datenpräsenz kann durch Hinweis auf eine Festlegung anzeigen, ob ein beliebiger Eintrag 0 bis N im Datenpuffer gespeichert ist. Der Umordnungspuffer kann verwendet werden, um Einträge 0 bis N einem Dekomprimierer in Reihenfolge bereitzustellen, auch wenn sie nicht in Reihenfolge in einem Datenpuffer empfangen wurden. Nachverfolgungs-FIFO kann identifizieren, wenn ein letzter Eintrag empfangen wird (LetzterEintragEmpf), ob der Eintrag in oder nicht in Reihenfolge empfangen wurde.
In diesem Beispiel weist Lese_Anforderung1 nur einen Eintrag auf, der mit einer Leseanforderung assoziiert ist. IstLetzterEintrag0 von Nachverfolgungs-FIFO ist dem einen Eintrag, Eintrag0, zugeteilt. Darüber hinaus können die Steuerinformationen und Datenpräsenz auf einen einzelnen Eintrag verweisen. Ein einzelner Eintrag ist im Datenpuffer zugeteilt. Es ist anzumerken, dass in einigen Beispielen, falls nur ein Eintrag zuzuteilen ist und die Größe der Daten des Eintrags an den Dekomprimierer in einem Taktzyklus gesendet werden kann, dann der Umordnungspuffer umgangen wird und Daten dem Dekomprimierer direkt bereitgestellt werden.
In diesem Beispiel weist Lese_AnforderungM zwei Einträge auf, die mit einer Leseanforderung assoziiert sind. IstLetzterEintrag0 und IstLetzterEintrag1 von Nachverfolgungs-FIFO sind für jeweilige Einträge 0 und 1 zugeteilt. Darüber hinaus sind Steuerinformationen und Datenpräsenz für beide Einträge zugeteilt. Zwei Einträge sind im Datenpuffer zugeteilt.
15B-1 bis 15B-3 zeigen ein Beispiel einer Verwendung von Nachverfolgungs-FIFO und Indikatoren für vorhandene Daten, um einem Dekomprimierer Einträge in Reihenfolge bereitzustellen. Genauer zeigt 15B-1 ein Beispiel zum Zuteilen von Einträgen im Nachverfolgungs-FIFO, Steuerinformationen, Datenpräsenz und Datenpuffer für drei Einträge. In diesem Beispiel bewirkt eine Leseanforderung, dass Einträge 0 bis 2 zugeteilt werden. Bei 1502 wird SchreibZeiger auf Eintrag1 gesetzt und LeseZeiger wird auf Eintrag0 gesetzt. Nachverfolgungs-FIFO wird zugeteilt, um IstLetzterEintrag0 = FALSE anzuzeigen, was bedeutet, dass Eintrag0 kein letzter Eintrag ist. Steuerinformationen enthalten Komprimierungsinformationen von Eintrag0 (als Merkmal0 gezeigt). Datenpräsenz zeigt durch Anzeigen eines Zustands von Rückgesetzt0 an, dass Eintrag0 nicht vorhanden ist. Der Datenpuffer ist leer, da keine Daten empfangen wurden.
Bei 1504 wird SchreibZeiger auf Eintrag2 gesetzt und LeseZeiger bleibt auf Eintrag0 gesetzt. Nachverfolgungs-FIFO wird zugeteilt, um IstLetzterEintrag1 = FALSE hinzuzufügen, was bedeutet, dass Eintrag1 kein letzter Eintrag ist. Steuerinformationen werden aktualisiert, sodass sie Komprimierungsinformationen von Eintrag1 enthalten (als Merkmal1 gezeigt). Datenpräsenz wird aktualisiert, um durch Anzeigen eines Zustands von Rückgesetzt1 anzuzeigen, dass Eintrag1 nicht vorhanden ist. Der Datenpuffer ist leer, da keine Daten empfangen wurden.
Bei 1506 wird SchreibZeiger auf Eintrag3 gesetzt und LeseZeiger bleibt auf Eintrag0 gesetzt. Nachverfolgungs-FIFO wird zugeteilt, um IstLetzterEintrag2 = TRUE hinzuzufügen, was bedeutet, dass Eintrag2 ein letzter Eintrag für eine Leseanforderung ist. Steuerinformationen werden aktualisiert, sodass sie Komprimierungsinformationen von Eintrag2 enthalten (als Merkmal2 gezeigt). Datenpräsenz wird aktualisiert, um durch Anzeigen eines Zustands von Rückgesetzt2 anzuzeigen, dass Eintrag2 nicht vorhanden ist. Der Datenpuffer ist leer, da keine Daten empfangen wurden.
15B-2 zeigt ein Beispiel eines Datenempfangs nicht in Reihenfolge. LeseZeiger ist auf Eintrag0 gesetzt, der der Kopf des Zeileneintrags ist. SchreibZeiger wird auf Eintrag3 zum Schreiben von Einträgen einer anderen Leseanforderung gesetzt. Bei 1510 wird Eintrag 1 empfangen und im Datenpuffer gespeichert. In Datenpräsenz wird Rückgesetzt1 auf Gesetzt1 geändert, um anzuzeigen, dass Eintrag 1 im Datenpuffer vorhanden ist. Bei 1512 wird Eintrag2 empfangen und im Datenpuffer gespeichert. In Datenpräsenz wird Rückgesetzt2 auf Gesetzt2 geändert, um anzuzeigen, dass Eintrag2 im Datenpuffer vorhanden ist. Bei 1514 wird Eintrag0 empfangen und im Datenpuffer gespeichert. In Datenpräsenz wird Rückgesetzt0 auf Gesetzt0 geändert, um anzuzeigen, dass Eintrag0 im Datenpuffer vorhanden ist. Da IstLetzterEintrag2 = TRUE und Datenpräsenz Gesetzt0 bis Gesetzt2 enthält, um anzuzeigen, dass alle Einträge im Datenpuffer vorhanden sind, kann ein Verteilen der Einträge an den Dekomprimierer weitergehen.
Es ist anzumerken, dass, wenn Eintrag0 vor 1512 empfangen worden wäre, Eintrag0 und Eintrag 1 dem Dekomprimierer bereitgestellt werden könnten und der Lesezeiger würde von Eintrag0 zu Eintrag 1 und zu Eintrag2 vorrücken.
15B-3 zeigt ein Beispiel einer Eintragsverteilung in Reihenfolge. Bei 1520 ermöglicht LeseZeiger, dass Eintrag0 an den Dekomprimierer verteilt wird und LeseZeiger rückt zu Eintrag1 vor. Die Zuteilungen von IstLetzterEintrag0 im Nachverfolgungs-FIFO, Gesetzt0 in Datenpräsenz, Merkmal0 in den Steuerinformationen und Eintrag0 im Datenpuffer werden aufgehoben (wie durch die gestreiften Linien angezeigt).
Bei 1522 ermöglicht LeseZeiger, dass Eintrag1 an den Dekomprimierer verteilt wird und LeseZeiger rückt zu Eintrag2 vor. Die Zuteilungen von IstLetzterEintrag1 im Nachverfolgungs-FIFO, Gesetzt1 in Datenpräsenz, Merkmal1 in den Steuerinformationen und Eintrag 1 im Datenpuffer werden aufgehoben (wie durch die gestreiften Linien angezeigt).
Bei 1524 ermöglicht LeseZeiger, dass Eintrag2 an den Dekomprimierer verteilt wird und LeseZeiger rückt zu Eintrag3 vor. Die Zuteilungen von IstLetzterEintrag2 im Nachverfolgungs-FIFO, Gesetzt2 in Datenpräsenz, Merkmal2 in den Steuerinformationen und Eintrag2 im Datenpuffer werden aufgehoben (wie durch die gestreiften Linien angezeigt). Die Aufhebung der Zuteilung von Einträgen kann ermöglichen, dass die Einträge von einer anderen Leseanforderung verwendet werden oder die zugrunde liegenden Arbeitsspeicherressourcen für andere Einsätze verwendet werden.
Verschiedene Ausführungsformen stellen eine Art und Weise zum Ermitteln einer Arbeitsspeichermenge bereit, die einem Datenpuffer in Verbindung mit einem Umordnen von mit einem Datenlesevorgang assoziierten Einträgen zuzuteilen sind. Zum Beispiel kann eine Ermittlung einer Datenkomprimierung erfolgen, die komprimierte Daten ergibt, die größer als eine Datenmenge sind, die ein Arbeitsspeicherbus in einem Taktzyklus übertragen kann. Ein Prozentsatz von Taktzyklen, in denen Daten eines derartigen Datenkomprimierungspegels angewandt werden, kann ermittelt werden und verwendet werden, um eine Arbeitsspeichermenge zu ermitteln, die zur Verwendung beim Umordnen von Daten zu reservieren ist.
Falls ein Arbeitsspeicherbus zum Beispiel 64 Bytes in einem einzigen Taktzyklus übertragen kann, erfolgt eine Ermittlung in Bezug auf einen Prozentsatz von Zeit eines Zeitfensters, zu dem mehr als 64 Bytes übertragen wurden. Beispielsweise erfolgt eine Ermittlung, dass in 25 % der Taktzyklen Daten von 256 B (oder einer anderen Größe) auf 96 B oder höher komprimiert wird. Beispielsweise können für 128 Taktzyklen, die verwendet werden, um Daten abzurufen, wobei 50 % der Daten komprimiert sind und 12,5 % der komprimierten Daten von 256 B auf 96 B oder mehr komprimiert sind, 16 Taktzyklen Latenz vom Umordnungspuffern beobachtet werden. Ein Bemessen eines Datenpuffers zum Speichern von mindestens 16 Einträgen kann möglicherweise eine Latenz von Arbeitsspeicherabrufen zur Verfügbarkeit am Dekomprimierer vor einer Verwendung eines ROB verdecken oder reduzieren, da es eine hinreichende Arbeitsspeicherzuteilung im Arbeitsspeicherpuffer gibt, um alle Einträge zu speichern, auf die eine Latenz zurückgeführt werden kann.

Verschiedene Ausführungsformen passen eine Menge des Arbeitsspeichers an, die dem Datenpuffer zugeteilt ist, der beim Umordnen verwendet wird, auf Grundlage eines Betriebsmodus, wie entweder eines Arbeitslasttyps und/oder einer angewandten Komprimierung. Eine Menge von Arbeitsspeicher, die dem Datenpuffer zum Umordnen zugeteilt ist, kann pro Leseanforderung oder für eine Gruppe von Leseanforderungen geändert werden. Mindestens eine Iteration wird beobachtet, wo der Datenpuffer, um ein Profil für unterschiedliche Arbeitslasten zu lernen. Ein Hardwareprofil-Benchmark (z. B. Manhattan, Car Chase) kann zum Beispiel verwendet werden. Das Folgende stellt nicht einschränkende Beispiele einer Datenpuffer-Größenbemessung für verschiedene Arbeitslasttypen (Anwendungstypen) bereit.

Anwendung	Profil
Spiel1	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 25 % der komprimierten Daten 256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,25 = 32 Einträge in einem Datenpuffer zur Umordnung zugeteilt werden.
Spiel2	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 30 % der komprimierten Daten
	256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,30 = 39 Einträge in einem Datenpuffer zur Umordnung zugeteilt werden. Falls eine Latenz zur Anzeige von vormals komprimierten Daten für ein Spiel zu groß ist, kann dieses Profil verwendet werden.
Spiel3	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 35 % der komprimierten Daten 256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,35 = 45 Einträge in einem Datenpuffer zur Umordnung zugeteilt werden. Falls eine Latenz zur Anzeige von vormals komprimierten Daten für ein Spiel zu groß ist, kann dieses Profil verwendet werden.
Powerpoint®	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 20 % der komprimierten Daten 256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,2 = 26 Einträge in einem Datenpuffer zur Umordnung zugeteilt werden.
Videostreaming (z. B. Netflix®, YouTube®, Hulu®)	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 50 % der komprimierten Daten 256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,5 = 64 Einträge in einem Datenpuffer zur Umordnung zugeteilt werden.
Videostreaming2	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 60 % der komprimierten Daten 256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,6 = 77 Einträge im Datenpuffer zur Umordnung zugeteilt werden. Falls eine Latenz zur Anzeige von vormals komprimierten Daten für ein Spiel zu groß ist, kann dieses Profil verwendet werden.
Desktop- Aufbau (Windows®, Linux®, Android®, MacOS®)	Für 128 Taktzyklen, in denen 100 % der Datenübertragungen komprimierte Daten sind, sind 70 % der komprimierten Daten 256 B -> 96 B oder mehr. Dementsprechend können mindestens 128 * 0,7 = 90 Einträge im Datenpuffer zur Umordnung zugeteilt werden.

16A zeigt einen Prozess, der verwendet werden kann, um einen Empfang von Einträgen nachzuverfolgen, die mit einer Leseanforderung aus einem Arbeitsspeicher assoziiert sind, und Puffern von Daten vor einem Bereitstellen der Daten in Reihenfolge zum Zugriff durch einen Dekomprimierer oder einer anderen Vorrichtung oder Software. Bei 1602 werden ein oder mehrere Einträge, die mit einer Leseanforderung assoziiert sind, in einem Umordnungspuffer zugeteilt. Der Umordnungspuffer kann einen Empfang und Merkmale des einen oder der mehreren Einträge in einem Puffer nachverfolgen. Es kann zum Beispiel ein Nachverfolgen von Einträgen stattfinden, die mit der im Puffer empfangenen Leseanforderung assoziiert sind. Die Einträge können einem komprimierten Abschnitt bzw. komprimierten Abschnitten von Daten entsprechen, deren Lesen angefordert wurde, und die Einträge werden im Puffer vor der Übertragung oder dem Zugriff durch einen Dekomprimierer gespeichert. Die Merkmale von empfangenen Einträgen können Informationen wie unter anderem einen Komprimierungszustand (z. B. 256 B auf 96 B, 256 B auf 64 B und so weiter), ein Oberflächenformat (16 Bits pro Pixel, 32 Bits pro Pixel, 64 Bits pro Pixel und so weiter), ein Komprimierungsformat (z. B. Bitmaps, Graphics Interchange Format (GIF), Joint Photographic Experts Group (JPEG), QuickTime, Portable Network Graphics (PNG)) und andere Metadaten enthalten. Merkmale können für jeden Eintrag oder nur für eine Leseanforderung unabhängig von der Anzahl von Einträgen gespeichert werden. Merkmale können aus einer Nachschlagetabelle geladen werden, die Komprimierungsinformationen von im Arbeitsspeicher gespeicherten Daten identifiziert.
Bei 1604 erfolgt eine Ermittlung, ob ein Eintrag in einem Datenpuffer empfangen wird. Falls ein Eintrag empfangen wird, wird bei 1606 eine Nachverfolgungseinheit für den Eintrag aktualisiert, um anzuzeigen, dass der Eintrag empfangen wurde. Darüber hinaus, falls ein empfangener Eintrag ein erster Eintrag in einer Gruppe von einem oder mehreren Einträgen, ein Eintrag, der in Reihenfolge hinter einem anderen Eintrag folgt, der dem Dekomprimierer bereits bereitgestellt wurde, oder ein alleiniger Eintrag ist, der mit einer Leseanforderung assoziiert ist, ist der Eintrag zur Verarbeitung durch einen Dekomprimierer verfügbar. Falls kein neuer Eintrag empfangen wird, wird 1604 wiederholt, um einen Empfang eines Eintrags in einem Datenpuffer zu erkennen.
Bei 1608 erfolgt eine Ermittlung, ob ein letzter Eintrag, der mit einer Leseanforderung assoziiert ist, empfangen wird. Falls zum Beispiel ein letzter Eintrag als empfangen identifiziert wird, dann wird bei 1610 der Indikator für den Empfang eines letzten Eintrags auf positiv gesetzt und es wird ermöglicht, dass alle Einträge, die dem Dekomprimierer nicht vorher bereitgestellt wurden, in Reihenfolge zur Verarbeitung durch den Dekomprimierer bereitgestellt werden. Falls nicht alle Einträge empfangen wurden, kehrt der Prozess zu 1604 zurück.
16B zeigt einen Prozess, der verwendet werden kann, um eine Menge von zur Verwendung zum Umordnen von Einträgen zugeteiltem Arbeitsspeicherraum vor einem Verfügbarmachen von Daten zur Verarbeitung durch einen Dekomprimierer zuzuteilen. Bei 1650 kann eine anfängliche Ressourcenreservierung von Arbeitsspeicher zur Verwendung beim Umordnen von Daten auf Grundlage von Anfangsparametern festgelegt werden. Einem Dekomprimierer, einer Renderpipeline oder einem anderen Arbeitsspeicherclient kann auf Grundlage einer Prioritätsstufe und nicht verwendeten Arbeitsspeicherressourcen eine bestimmte Menge an Arbeitsspeicherressourcen zugeteilt werden. Bei 1652 erfolgt eine Ermittlung, ob reservierte Arbeitsspeicherressourcen zu ändern sind. Es kann zum Beispiel eine Ermittlung erfolgen, ob ein Betriebsmodus wie geändert. Ein Betriebsmodus kann eine Änderung einer aktiven Anwendung und/oder eine Änderung einer Menge von komprimierten Daten enthalten, die zur Dekomprimierung angefordert wurde. Beispielsweise kann ein Anwendungstyp ein Spiel, eine Tabellenkalkulation, Videostreaming, eine Textverarbeitung, ein Desktop-Aufbau und so weiter sein. Falls sich ein Anwendungstyp, der eine Dekomprimierung von Daten anfordert, ändert oder sich eine zur Dekomprimierung angeforderte Menge an komprimierten Daten über eine Zeitspanne erhöht, dann kann der Prozess mit 1654 fortfahren. Falls die reservierten Arbeitsspeicherressourcen nicht zu ändern sind, kehrt der Prozess zu 1652 zurück.
Bei 1654 legt der Prozess eine Menge an Arbeitsspeicherressourcen fest, die für Umordnungspuffern zu reservieren ist. Eine Menge an Arbeitsspeicherressourcen, die für Umordnungspuffern zu reservieren ist, kann auf einer oder mehreren beruhen von: Typ von Anwendung, die aktiv ist und eine Generierung von Bildern anfordert oder eine Menge von Arbeitsspeicher, die beim Umordnungspuffern verwendet wird (z. B. auf Grundlage einer Menge von komprimierten Daten, die vor umzuordnen sind, bevor sie dem Dekomprimierer bereitgestellt werden). Eine zu reservierende Menge an Arbeitsspeicherressourcen kann beispielsweise auf Grundlage des neu aktiven Typs von Anwendung, die eine Generierung von Bildern anfordert, eines jüngsten Trends zu einer anderen Menge von komprimierten Daten, die umzuordnen sind, bevor sie dem Dekomprimierer bereitgestellt werden, festgelegt werden. Eine Nachschlagetabelle kann verwendet werden, um eine Arbeitsspeicherressourcenreservierung mit einem Typ von Anwendung zu assoziieren. Wie oben beschrieben können Berechnungen verwendet werden, um eine Menge an Einträgen anzuzeigen, die in einer Arbeitsspeicherressource für Umordnungspuffern auf Grundlage von Komprimierungsgraden und einer Menge von komprimierten Daten, die über eine Spanne von Taktzyklen übertragen wurden, zuzuteilen sind.
Kommerzielle Vorgänger-Lösungen verwenden eine statische Zuteilung von ROB-Schlitzen zu mehreren Arbeitsspeicherclients (MCs). Es wurden ein paar Techniken zur dynamischen Zuteilung von ROB-Einträgen vorgeschlagen, aber sie dienen hauptsächlich zur Zuteilung von ROB-Einträgen zwischen mehreren Threads in einem Out-of-Order(OOO)-Prozessor mit Simultaneous Multithreading (SMT) mit Problemen bei ungereihter Reihenfolge und einer Festschreibung von Anweisungen in einem Thread. Einige davon verwenden mehrere Kopfzeiger und Schwanzzeiger (einen pro anforderndem Client/Thread) zur dynamischen Zuteilung von ROB-Einträgen. Eine der Techniken teilt die Zuteilung von ROB-Einträgen auf Paare von Threads auf, wobei jedes Paar von Threads seinen zugeteilten Satz von ROB-Einträgen gemeinsam nutzen kann.
Im Fall von statischen ROB-Zuteilungslösungen kann jeder Arbeitsspeicherclient nur n/m-ROB-Einträge, wobei n die Gesamtanzahl an ROB-Einträgen ist, die im System verfügbar sind, und m die Anzahl von Arbeitsspeicherclients ist, oder eine feste Zuteilung verwenden, die in der Prozessordesignphase vor Produktisierung des Prozessors ermittelt wird. Für Beispiele einer statischen Zuteilung von ROB-Einträgen siehe: „Design of an 8-wide Superscalar RISC Microprocessor with Simultaneous Multithreading“, Ronald P. Preston et al. ISSCC 2002 / SESSION 20 / MICROPROCESSORS; „Hyper-Threading Technology Architecture and Microarchitecture“, Deborah T. Marr et al. Intel Technology Journal Q1, 2002; und „The Impact of Resource Partitioning on SMT Processors“, Steven E. Raasch und Steven K. Reinhardt - 12th International Conference on Parallel Architectures and Compilation Techniques (PACT), 2003; und „Improving Memory Latency Aware Fetch Policies for SMT Processors“, Francisco J. Cazorla et al. ISHPC 2003, LNCS 2858, S. 70-85, 2003.
Dynamische ROB-Zuteilungs-/Partitionierungslösungen können in anderen Verarbeitungsszenarien wie ein gemeinsames Nutzen von mehreren Ressourcen durch Threads in einem SMT-OOO-Mikroprozessor angewandt werden, aber können nicht leicht auf eine Zuteilung von ROB-Einträgen zu mehreren Arbeitsspeicherclients angepasst werden, wenn der ROB zum Reihen von Arbeitsspeicher-Lesezugriffen für jeden Arbeitsspeicherclient verwendet wird. Die meisten dieser dynamischen Techniken weisen in ihren Zuteilungsrichtlinien einen eingeschränkten Dynamismus (oder eine eingeschränkte gemeinsame Nutzung) auf, die weiterhin Platz für Leistungsengpässe lassen können und in einigen Fällen mehr Leistungsengpässe als statische Zuteilungsschemata erzeugen können. Für Beispiele einer dynamischen Zuteilung von ROB-Einträgen siehe: „The Impact of Resource Partitioning on SMT Processors“, Steven E. Raasch und Steven K. Reinhardt - 12th International Conference on Parallel Architectures and Compilation Techniques (PACT), 2003; „Adaptive Reorder Buffers for SMT Processors“, Joseph Sharkey et al. PACT'06, 16.-20. September 2006; „Paired ROBs: A Cost-Effective Reorder Buffer Sharing Strategy for SMT Processors“, R. Ubal et al, Euro-Par Parallel Processing, S. 309-320, 2009; „Utilization-Based Resource Partitioning for Power-Performance Efficiency in SMT Processors“, Huaping Wang et al. TPDS 2011; „An Adaptive Resource Partitioning Algorithm for SMT Processors“, Huaping Wang et al. PACT'08, 25.-29. Oktober 2008; „Exploiting Choice: Instruction Fetch and Issue on an Implementable Simultaneous Multithreading Processor“, Dean M. Tullsen et al. ISCA '96 23rd Annual International Symposium on Computer Architecture, Philadelphia, PA, USA, Mai 1996; „Dynamically Controlled Resource Allocation in SMT Processors“, Francisco J. Cazorla et al. 37th International Symposium on Microarchitecture (MICR037 2004); „Transparent Threads: Resource Sharing in SMT Processors for High Single Thread Performance“, Gautham K. Dorai und Donald Yeung - 2002 International Conference on Parallel Architectures and Compilation Techniques (PACT'02); und „Learning-Based SMT Processor Resource Distribution via Hill-Climbing“, Seungryul Choi, Donald Yeung - 2006 International Symposium on Computer Architecture (ISCA-XXXIII), Boston, MA, USA.
In einem auf Kopfzeiger und Schwanzzeiger beruhenden dynamischen Zuteilungsansatz, falls sich der Schwanzzeiger von ROB-Zuteilungseinträgen eines ersten Threads neben den Kopfzeiger von ROB-Zuteilungseinträgen eines zweiten Threads bewegt und falls der erste Thread mehr ROB-Zuteilungsanforderungen erhält, dann muss die ROB-Zuteilung des ersten Threads anhalten, obwohl es viele leere ROB-Einträge nach dem Schwanzzeiger des zweiten Threads geben kann. Im Fall einer festen Zuteilung zu einem Paar von Threads, wobei das Paar von Threads ihre Zuteilung von ROB-Einträgen gemeinsam nutzen kann, falls die ROB-Zuteilung des ersten Paars erschöpft ist, während die ROB-Zuteilung des zweiten Paars viele leere ROB-Einträge aufweist, und falls das erste Paar mehr ROB-Zuteilungsanforderungen stellt, dann muss die ROB-Zuteilung des ersten Paars anhalten, obwohl es leere ROB-Einträge in der ROB-Zuteilung des zweiten Paars gibt.
Um eine Leistung für zumindest einige dieser Clients zu verbessern und um Leistungsengpässe im Arbeitsspeicherzugriffspfad zu vermeiden, wird eine effektive Nutzung von verfügbaren ROB-Einträgen für mehrere Arbeitsspeicherclients benötigt. Eine effektive Nutzung kann durch eine optimale Zuteilung von ROB-Einträgen zu mehreren Clients erreicht werden, auf Grundlage von Arbeitsspeicherzugriffsanforderungen jedes Clients. Abgesehen vom Reihen der Arbeitsspeicherleserückgaben kann eine Zuteilungslogik die Anforderungen zwischen mehreren Clients priorisieren. Die Zuteilung von ROB-Einträgen kann statischer (eine feste Anzahl von ROB-Einträgen pro Client) oder dynamischer (eine Anzahl von Einträgen pro Client kann auf Grundlage der Client-Arbeitsspeicherleseanforderungen und des Leserückgabeverkehrsmusters erhöht oder verringert werden) Natur sein.
Verschiedene Ausführungsformen stellen eine dynamische ROB-Zuteilungstechnik bereit, um eine bessere Leistung für die Arbeitsspeicherclients sicherzustellen und in einem gewissen Ausmaß Arbeitsspeicherzugriffspfad-Leistungsengpässe zu vermeiden. Verschiedene Ausführungsformen bieten ein dynamisches ROB-Zuteilungsschema, das eine Unterauslastung vermeidet, die von statischen Zuteilungsrichtlinien wahrgenommen wird. Verschiedene Ausführungsformen können möglicherweise eine bessere Nutzung von ROB-Einträgen im Vergleich zu akademischen dynamischen ROB-Zuteilungslösungen sicherstellen, um zu versuchen, Leistungsengpässe zu reduzieren. Verschiedene Ausführungsformen können möglicherweise weniger Leistungsengpässe im Vergleich zu statischen Zuteilungslösungen und akademischen dynamischen ROB-Zuteilungslösungen erzielen, zumindest da verschiedene Ausführungsformen ermöglichen, dass ein Anhalten von Arbeitsspeicherclients stattfindet, falls der gesamte Satz von ROB-Einträgen zugeteilt (oder ausgeliehen) sind, wohingegen aktuell statische Zuteilungslösungen Arbeitsspeicherclients anhalten, falls eine beliebige statische ROB-Zuteilung eines Arbeitsspeicherclients erschöpft ist und dynamische Zuteilungslösungen können Arbeitsspeicherclients anhalten, bevor der gesamte Satz von ROB-Einträgen erschöpft ist.
Verschiedene Ausführungsformen können auf mehrere Arbeitsspeicherclients angewandt werden, die einen Arbeitsspeicherzugriff aus Arbeitsspeicher oder Zwischenspeicher in einer gereihten Weise in einem Mikroprozessor oder einer GPU anfordern, wohingegen die meisten der bestehenden Lösungen für mehrere Threads anwendbar sind, die gemeinsam genutzte ROB-Einträge in einem SMT-OOO-Mikroprozessor anfordern. Ein Arbeitsspeicherclient kann Arbeitsspeicherzugriffsanforderungen nach komprimierten oder nicht komprimierten Daten stellen. Ein Beispiel eines Arbeitsspeicherclients kann ein Dekomprimierer, eine Renderpipeline, eine Grafikverarbeitungseinheit, eine Zentralverarbeitungseinheit, ein fester Funktionsbeschleuniger, eine programmierbare Logikvorrichtung und so weiter sein.
17 zeigt mehrere Arbeitsspeicherclients (z. B. Clients 1 bis 4), die Arbeitsspeicherzugriffanforderungen stellen und denen ROB-Einträge aus den ROB-Zuteilungseinträgen zugeteilt werden, die für die Nutzung jedes Arbeitsspeicherclients geparkt sind. Mehrere Arbeitsspeicherclients können Arbeitsspeicherleseanforderungen durch gemeinsam genutzten Zwischenspeicher (z. B. DRAM) stellen. Anfänglich entscheidet ein Vermittler (nicht gezeigt), welche Arbeitsspeicherleseanforderung welches Arbeitsspeicherclients während eines aktuellen Taktzyklus anzunehmen ist. Vor Stellen der Anforderung an den Zwischenspeicher/Arbeitsspeicher wird der Arbeitsspeicherleseanforderung dieses Arbeitsspeicherclients (MC_i) ein ROB-Eintrag aus den ROB-Einträgen (m_i) zugeteilt, die für die Nutzung von MC_i verfügbar sind. Diese Einträge werden der Reihe nach zugeteilt. Leseanforderungen an den Zwischenspeicher/Arbeitsspeicher können durch Zwischenspeicher/Arbeitsspeicher oder den Arbeitsspeicherzugriffspfad auf ungereihte Weise bedient werden. Wenn die Leseanforderung mit Daten aus dem Zwischenspeicher/Arbeitsspeicher zurückkehrt, erfolgt eine Überprüfung im ROB-Eintrag des bestimmten Arbeitsspeicherclients, um zu sehen, ob er sich oben in der Reihenfolge zur Rückgabe an den Arbeitsspeicherclient MC_i befindet. Falls er sich nicht oben in der Reihenfolge befindet, wartet er, bis alle Antworten (Lesedaten) für ROB-Einträge für den MC_i die im Vergleich zu diesem ROB-Eintrag oberhalb in der Reihenfolge stehen, zu MC; zurückgegeben wurden.
Falls es beispielsweise 4 Arbeitsspeicherclients und 64 ROB-Einträge gibt, kann eine Prozessorimplementierung eine statische ROB-Zuteilung aufweisen, wobei 24 ROB-Einträge Client 1 zugeteilt sind, 12 ROB-Einträge Client 2 zugeteilt sind, 16 ROB-Einträge Client 3 zugeteilt sind und 12 ROB-Einträge Client 4 zugeteilt sind. Auch falls einige der Arbeitsspeicherclients während einer bestimmten Zeitspanne keine Arbeitsspeicherzugriffsanforderungen stellen, können einigen des Rests der Arbeitsspeicherclients, die möglicherweise mehr ROB-Einträge als ihre feste Zuteilung benötigen (n/m oder feste Zuteilung in der Prozessordesignphase), nicht mehr ROB-Einträge als ihre feste Zuteilung zugewiesen werden und diese können anhalten. Daher kann der ROB während derartiger Zeitspannen nicht ausgenutzt sein und die zuteilenswerten Arbeitsspeicherclients, die möglicherweise eine größere ROB-Zuteilung als seine feste Grenze erfordern, können angehalten werden.
Verschiedene Ausführungsformen bieten eine dynamische Zuteilung von ROB-Einträgen an mehrere Arbeitsspeicherclients. Anfänglich werden einem Arbeitsspeicherclient MC_i m_i ROB-Einträge zur Verwendung zugeteilt $(\sum_{i = 1}^{k} m_{i} = n,$
m_i = n, wobei n = Gesamtanzahl an ROB-Einträgen und k = Gesamtanzahl an Arbeitsspeicherclients). Der Wert von m_i kann auf Grundlage der Priorität jedes MC_i ermittelt werden, wie sie durch Ausführen von Simulationen über mehrere Arbeitslasten unter Verwendung eines zeitgebungsgenauen Softwareleistungssimulators für den Prozessor oder die GPU und Identifizieren eines optimalen m_i für jeden MC_i für eine insgesamt beste durchschnittliche Leistung über Arbeitslasten hinweg ermittelt wird.
Wenn MC; beginnt, Arbeitsspeicherzugriffsanforderungen zu stellen, wird jeweils einer der ROB-Einträge von m_i zu einem Zeitpunkt zugeteilt. Wenn alle m_i erschöpft sind (oder falls eine Erschöpfung von m_i nahe ist, was durch einen Schwellenwert m_i-T4_i angezeigt werden kann, wobei T4_i später definiert wird) und falls es keine weiteren Arbeitsspeicherzugriffsanforderungen von MC; während des Wartens auf Aufhebung der Zuteilungen von seinen zugeteilten m_i Einträgen gibt, dann kann MC; e Einträge von m_j ROB-Einträgen ausleihen, die zur Nutzung durch MC_j geparkt sind, falls MC_j T3_j+T4_j (später definiert) noch nicht zugeteilte oder bereits zuteilungsaufgehobene Einträge aufweist und die geringste Wachstumsrate (später definiert) aufweist.
Nachdem die m_j Einträge von MC_j erschöpft sind, kann MC_j von m_k Einträgen von MC_k ausleihen und so weiter, um ein kettenartiges Leihschema zu erzeugen. Es ist anzumerken, dass MC_i bei Bedarf von mehreren anderen MC_S ausleihen kann. Sobald der letzte Arbeitsspeicherclient in der Kette (MC_letzter) seine m₁ Einträge erschöpft und falls er weitere Arbeitsspeicherzugriffsanforderungen stellt, kann er anfordern, dass der Arbeitsspeicherclient mit der geringsten Wachstumsrate e Einträge zurückgibt (ein Beispiel einer ROB-Wachstumsrate ist unten definiert). Falls der Arbeitsspeicherclient mit der geringsten Wachstumsrate MC_gw keine freien T3_gw + T4_gw Einträge (noch nicht zugeteilt oder Zuteilung aufgehoben) aufweist, sollte er aufhören, weitere Arbeitsspeicherleseanforderungen zu akzeptieren (Anhalten von MC_gw) und auf eine Aufhebung der Zuteilung von e Einträgen warten und dann die e Einträge MC_letzter zurückgeben.
Als Nächstes wird eine beispielhafte Terminologie für unterschiedliche ROB-Zuteilungsschwellenwerte beschrieben. Schwellenwerte T1, T2, T3 und T4 repräsentieren mehrere Schwellenwerte bei Zuteilung von ROB-Einträgen für einen Arbeitsspeicherclient. T1, T2, T3, T4 können für unterschiedliche Arbeitsspeicherclients unterschiedlich sein. Deshalb sind Tx_i und T_xj nicht notwendigerweise gleich (wobei x = 1, 2, 3 oder 4). Unterschiedliche Schwellenwerte wie T1_i, T2_i, T3_i, T4_i, AT_{min_i}, AT_{wm_i} und AT_{max_i} sind unten definiert.
T1_i = AT_{min_i} = minimaler Zuteilungsschwellenwert eines beliebigen Arbeitsspeicherclients MC_i, wobei andere Clients nicht von T1_i für MC_i reservierte Einträge ausleihen können.
T1_j + T2_j = AT_{wm_i} = Zuteilungsschwellenwert von Arbeitsspeicherclient MC_j, über den hinaus ein beliebiger Arbeitsspeicherclient MC; nicht MC_j zum Ausleihen von dessen ROB-Einträgen anfordern kann. Damit MC_j ein Verleiher sein kann, muss er mindestens T3_j + T4_j freie Einträge aufweisen (noch nicht zugeteilt oder bereits Zuteilung aufgehoben).
T1_i + T2_i + T3_i = AT_{max_i} = Zuteilungsschwellenwert, bei dem der Arbeitsspeicherclient MC_i ein Ausleihen von ROB-Einträgen aus m_j anfordert, die für die Nutzung durch andere Clients (MC_j) geparkt sind. Die Zuteilung von MC_j sollte AT_wm nicht überschritten haben.
T1_i + T2_i + T3_i + T4_i = m_i für Arbeitsspeicherclient MC_i = zur Nutzung durch Arbeitsspeicherclient MC_i geparkte Gesamtanzahl von ROB-Einträgen.
Eine ROB-Wachstumsrate (RGR_i) für einen Arbeitsspeicherclient MC_i kann eine Wachstumsrate von ROB-Zuteilungen für MC_i während eines angegebenen Zeitintervalls sein (das hierin nachfolgend als Epoche bezeichnet wird, wobei eine Epoche c Taktzyklen ist). Es ist anzumerken, dass die ROB-Wachstumsrate von MC_i höher ist, falls die Zuteilung von ROB-Einträgen zu MC; mit einer schnelleren Rate als eine Aufhebung der Zuteilung von ROB-Einträgen von MC; während einer Epoche ansteigt. Die ROB-Wachstumsrate kann durch mehrere Ansätze geprüft werden, und zwei unterschiedliche beispielhafte Ansätze sind unten aufgeführt.
Ein ROB-Zuteilung-Zuteilungsaufhebungs-Differenz-Ansatz kann verwendet werden, um eine ROB-Wachstumsrate zu bestimmen. Eine Wachstumsrate für einen Arbeitsspeicherclient (MC_i) als die Differenz (d_i) von zugeteilten ROB-Einträgen und ROB-Einträgen, deren Zuteilung aufgehoben wurde, während einer Epoche. Es erfolgt eine Prüfung, welche der Clients die höchste Wachstumsrate d_max und die niedrigste Wachstumsrate d_min aufweisen. Der Client, dessen Wachstumsrate am höchsten ist (d_max) und einen maximalen Schwellenwert von zugeteilten ROB-Einträgen (m_i - T4_i für MC;) überschritten hat, kann vom Client mit der geringsten Wachstumsrate (d_min) ausleihen, der hinreichende ROB-Einträge zu verleihen hat (was dadurch angezeigt wird, dass mindestens T4_j + T3_j für MC_j noch nicht zugeteilt sind oder deren Zuteilung aufgehoben wurde). Es ist anzumerken, dass mehrere Clients, die ihren maximalen Schwellenwert von zugeteilten ROB-Einträgen überschreiten, von mehreren anderen Clients ausleihen können, aber die obigen Regeln gelten. Die d_i können zum Vergleich der aktuellen Epoche über mehrere Clients über h vorhergehende Epochen gemittelt werden (um eine Hysterese einzuführen), sodass die Arbeitsspeicherclients mit der höchsten Wachstumsrate und der niedrigsten Wachstumsrate eine höchste bzw. niedrigste Wachstumsrate für mehrere Epochen aufweisen und es sich nicht um ein Spitzenverhalten höherer oder niedrigerer Wachstumsraten handelt.
Ein ROB-Belegungssummen-Ansatz kann verwendet werden, um eine ROB-Wachstumsrate zu bestimmen. Eine Summe (S_i) der ROB-Belegung jedes ROB-Eintrags für den Arbeitsspeicherclient (MC_i) während der Epoche kann stattfinden. Die Belegung eines ROB-Eintrags kann zu irgendeiner Anzahl von Taktzyklen zwischen Zuteilung und Aufhebung der Zuteilung ermittelt werden, falls sowohl Zuteilung als auch Aufhebung der Zuteilung des ROB-Eintrags in einer aktuellen Epoche stattfanden (oder Zyklen von Zuteilung bis zum Ende der aktuellen Epoche, falls in der aktuellen Epoche noch keine Aufhebung der Zuteilung stattgefunden hat). Die Belegung eines ROB-Eintrags kann zu irgendeiner Anzahl von Zyklen von einem Beginn einer aktuellen Epoche bis zur Aufhebung der Zuteilung ermittelt werden, falls eine Zuteilung in einer vorangehenden Epoche stattfand und eine Aufhebung der Zuteilung in einer aktuellen Epoche stattfand. Die Belegung eines ROB-Eintrags kann zu irgendeiner Anzahl von Zyklen von einem Beginn zu einem Ende einer aktuellen Epoche ermittelt werden, falls eine Zuteilung in einer vorangehenden Epoche stattfand und noch keine Aufhebung der Zuteilung stattgefunden hat.
Die ROB-Belegungssumme S_i für MC_i wird durch eine Anzahl von zugeteilten Einträgen (a_i) in einer Epoche dividiert, um den ROB-Belegungsgrad des Clients zu erhalten (ROR_i; = S_i / a_i). Es ist anzumerken, dass a_i aus allen ROB-Einträgen des Clients besteht, die sich zumindest für 1 Taktzyklus in der Epoche in einem zugeteilten Zustand befanden. Hier enthält a_i keine ROB-Einträge, die sich während der Epoche gar nicht in einem zugeteilten Zustand befanden.
Der Client, dessen ROR am höchsten ist (ROR_max), weist die größte ROB-Wachstumsrate (RGR_max) auf, und der Client, dessen ROR am geringsten ist (ROR_min), weist die niedrigste ROB-Wachstumsrate (RGR_min) auf. Der Client, dessen Wachstumsrate am höchsten ist (RGR_max) und einen maximalen Schwellenwert von zugeteilten ROB-Einträgen (m_i - T4_i für MC_i) überschritten hat, kann vom Client mit der geringsten Wachstumsrate (RGR_min) ausleihen, der hinreichende ROB-Einträge zu verleihen hat (was dadurch angezeigt wird, dass mindestens T4_j + T3_j für MC_j noch nicht zugeteilt sind oder deren Zuteilung aufgehoben wurde). Die RGR_i können zum Vergleich der aktuellen Epoche über mehrere Clients über h vorhergehende Epochen gemittelt werden (um eine Hysterese einzuführen), sodass die Arbeitsspeicherclients mit der höchsten Wachstumsrate und der niedrigsten Wachstumsrate eine höchste bzw. niedrigste Wachstumsrate für mehrere Epochen aufweisen und es sich nicht um ein Spitzenverhalten höherer oder niedrigerer Wachstumsraten handelt.
18 zeigt ein Beispiel eines ROB vor einem Ausleihen und nach einem Ausleihen durch MC₁ (Client 1) vom Verleiher MC₃. MC₁ leiht nach Empfangen einer neuen Zuteilungsanforderung e Einträge von MC₃ aus (der vor dem Verleihen T3₃+T4₃ freie Einträge aufweist) und bedient dann die neue Zuteilungsanforderung. Ein neuer T3 von MC₁ ist als T3_{1_neu} = T3_{1_alt} + e gegeben. Ein neuer T3 von MC₃ ist als T3_{3_neu} = T3_{3_alt} - e gegeben.
19A-19C zeigen ein kettenartiges Ausleihschema zum Ausleihen von ROB-Einträgen durch mehrere Arbeitsspeicherclients von einer ROB-Zuteilung für mehrere Arbeitsspeicherclients. In diesem Beispiel leiht MC₁ von MC₂, MC₂ leiht von MC₃ und MC₃ leiht von MC₄. Sobald die m_j Einträge von MC_j erschöpft sind (nachdem er beginnt, seine freien ROB-Einträge an MC; auszuleihen, der ebenfalls seine m_i Einträge erschöpft hat), kann MC_j von m_k Einträgen von MC_k und so weiter ausleihen, um ein Kettenleihschema zu erzeugen. Es ist anzumerken, dass MC_i bei Bedarf von mehreren anderen MCs ausleihen kann. Sobald der letzte MC₁ in der Kette seine m_i Einträge erschöpft und falls MC_letzter weitere Arbeitsspeicherzugriffsanforderungen stellt, kann er anfordern, dass der Arbeitsspeicherclient mit der geringsten Wachstumsrate e Einträge zurückgibt. Falls der Arbeitsspeicherclient mit der geringsten Wachstumsrate MC_gw keine freien T3_gw + T4_gw Einträge (noch nicht zugeteilt oder Zuteilung aufgehoben) aufweist, wird er aufhören, weitere Arbeitsspeicherleseanforderungen zu akzeptieren (wodurch MC_gw angehalten wird) und auf eine Aufhebung der Zuteilung von e Einträgen warten und dann die e Einträge MC_letzter zurückgeben, bevor er weitere Arbeitsspeicherleseanforderungen akzeptiert.
20A und 20B zeigen ein Anhalten des Ausleihens, wobei MC₁ versucht, von MC₂ auszuleihen, bis T3_gw+T4_gw Einträge in MC_gw nach einer Aufhebung der Zuteilung von Einträgen in MC_gw (in diesem Fall MC₂) frei sind. Ein Anhalten des Ausleihens durch Arbeitsspeicherclients kann stattfinden, wenn der Arbeitsspeicherclient MC_gw mit der geringsten Wachstumsrate (in diesem Fall MC₂) keine freien T3_gw+T4_gw Einträge aufweist und ein Entleiher (in diesem Fall MC₁) ein Ausleihen von ROB-Einträgen von MC_gw anfordert. MC_gw hört auf, weitere Arbeitsspeicherleseanforderungen anzunehmen (wodurch MC_gw angehalten wird) und wartet auf eine Aufhebung der Zuteilung von e Einträgen und danach eine Rückgabe der e Einträge an den Entleiher (in diesem Fall MC₁), bevor er irgendwelche weitere Arbeitsspeicherleseanforderungen annimmt.
21 zeigt einen Prozess. Der Prozess kann von einem Arbeitsspeicherclient, einem Betriebssystem (OS), einem Treiber oder einer Arbeitsspeichersteuerung verwendet werden, um Umordnungspuffer-Arbeitsspeicherressourcen unter Arbeitsspeicherclients gemeinsam zu nutzen. Bei 2102 erfolgt eine Zuteilung eines oder mehrerer Einträge in einem Umordnungspuffer an einen Arbeitsspeicherclient. Zuteilungen können für mehrere Arbeitsspeicherclients erfolgen. Zuteilungen können auf Grundlage einer Priorität eines Arbeitsspeicherclients nach hierin beschriebenen Beispielen erfolgen. Bei 2104 können für beliebige empfangene Daten, die in einem oder mehreren Einträgen eines Umordnungspuffers zu speichern sind, ein oder mehrere Einträge des Umordnungspuffers zur Verwendung durch die empfangenen Daten zugeteilt werden.
Bei 2106 erfolgt eine Ermittlung, ob ein Arbeitsspeicherclient hinreichend verfügbare Einträge in einem Umordnungspuffer aufweist, um von Arbeitsspeicherzugriffsanforderungen empfangene Daten zu handhaben. Falls die Arbeitsspeicherressourcen des Arbeitsspeicherclients unter einem Schwellenwert von verfügbaren Einträgen liegen oder der Arbeitsspeicherclient keine Einträge mehr hat, dann kann 2108 folgen. Beispiele dafür, dass die Arbeitsspeicherressourcen des Arbeitsspeicherclients unter einem Schwellenwert von verfügbaren Einträgen liegen oder der Arbeitsspeicherclient keine Einträge mehr hat, sind in Bezug auf irgendeine der 17, 18, 19A-19C, 20A oder 20B beschrieben. Falls der Arbeitsspeicherclient über hinreichende Einträge verfügt, fährt der Prozess mit 2104 fort.
Bei 2108, falls es während des Wartens auf Aufhebungen von Zuteilungen von seinen zugeteilten Einträgen weitere Arbeitsspeicherzugriffsanforderungen von einem Arbeitsspeicherclient gibt, kann ein Arbeitsspeicherclient einen oder mehrere Einträge von einem anderen Arbeitsspeicherclient ausleihen. Der Arbeitsspeicherclient, von dem ausgeliehen wird, kann zum Beispiel eine Schwellenanzahl von verfügbaren Einträgen aufweisen und eine niedrigste Wachstumsrate von neuen Eintragszuteilungen aufweisen. Ein oder mehrere ausgeliehene Einträge können verwendet werden, um Daten zu speichern, die von Arbeitsspeicherzugriffsanforderungen empfangen werden. Beispiele von ausleihenden Ressourcen sind in Bezug auf beliebige von 17, 18, 19A-19C, 20A oder 20B beschrieben.
Bei 2110 kann ein Arbeitsspeicherclient, von dem ausgeliehen wurde, auf Grundlage von unzureichenden Arbeitsspeicherressourcen einen oder mehrere Einträge von einem anderen Arbeitsspeicherclient anfordern, von dem ausgeliehen wurde. Sobald zum Beispiel ein letzter Arbeitsspeicherclient in einer Kette seine Einträge erschöpft und weitere Arbeitsspeicherzugriffsanforderungen stellt, kann der letzte Arbeitsspeicherclient anfordern, dass der Arbeitsspeicherclient mit der geringsten Wachstumsrate einen oder mehrere Einträge teilt, und dann diesen einen oder diese mehreren Einträge verwenden, um Daten von den Arbeitsspeicherzugriffsanforderungen zu speichern. Falls kein Eintrag zur gemeinsamen Nutzung verfügbar ist, kann der letzte Arbeitsspeicherclient in einer Kette Arbeitsspeicherzugriffsanforderungen pausieren, bis ein Eintrag in seinem Umordnungspuffer oder zur gemeinsamen Nutzung verfügbar ist. Beispiele von ausleihenden Ressourcen sind in Bezug auf beliebige von 17, 18, 19A-19C, 20A oder 20B beschrieben.
Das Auftreten der Phrase „ein einziges Beispiel“ oder „ein Beispiel“ bezieht sich nicht notwendigerweise immer auf das gleiche Beispiel oder die gleiche Ausführungsform. Jeder hierin beschriebene Gesichtspunkt kann mit jedem anderen hierin beschriebenen Gesichtspunkt oder einem ähnlichen Gesichtspunkt kombiniert werden, unabhängig davon, ob die Gesichtspunkte in Bezug auf dieselbe Figur oder dasselbe Element beschrieben sind.
Einige Beispiele können unter Verwendung des Ausdrucks „gekoppelt“ und „verbunden“ zusammen mit deren Ableitungen beschrieben werden. Diese Begriffe sind nicht notwendigerweise als Synonyme füreinander gedacht. Zum Beispiel können Beschreibungen unter Verwendung der Ausdrücke „verbunden“ und/oder „gekoppelt“ anzeigen, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander stehen. Der Ausdruck „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander stehen, aber dennoch miteinander zusammenarbeiten oder wechselwirken.
Die Begriffe „erster/erste/erstes“, „zweiter/zweite/zweites“ und dergleichen bezeichnen hierin keine Reihenfolge, Menge oder Wichtigkeit, sondern werden vielmehr verwendet, um ein Element von einem anderen zu unterscheiden. Die Begriffe „einer“, \„eine‟ und „eines“ bezeichnen hierin keine Beschränkung der Menge, sondern bezeichnen die Anwesenheit von mindestens einem der genannten Elemente. Der hierin in Bezug auf ein Signal verwendete Begriff „festgestellt“ bezeichnet einen Zustand des Signals, in dem das Signal aktiv ist und der durch Anlegen eines beliebigen Logikpegels, entweder logische 0 oder logische 1, auf das Signal erzielt werden kann. Die Begriffe „folgen“ oder „nach“ können unmittelbar folgend oder nach einem anderen Ereignis oder anderen Ereignissen folgend bezeichnen. In Ablaufdiagrammen können andere Abfolgen von Schritten auch nach alternativen Ausführungsformen durchgeführt werden. Ferner können zusätzliche Schritte hinzugefügt oder entfernt werden, abhängig von den bestimmten Anwendungen. Eine beliebige Kombination von Änderungen kann verwendet werden und Durchschnittsfachleute mit dem Vorteil dieser Offenbarung würden die vielen Variationen, Modifikationen und alternativen Ausführungsformen davon verstehen.
Disjunktive Sprache wie der Ausdruck „mindestens eines von X, Y oder Z“ wird, sofern nicht ausdrücklich anders angegeben, im Kontext anders verstanden, als allgemein verwendet, um darzustellen, dass ein Element, ein Begriff usw. entweder X, Y oder Z oder eine beliebige Kombination davon (z. B. X, Y und/oder Z) sein können. Deshalb soll und sollte eine derartige disjunktive Sprache im Allgemeinen nicht implizieren, dass bestimmte Ausführungsformen erfordern, dass jeweils mindestens eines von X, mindestens eines von Y oder mindestens eines von Z vorhanden ist. Darüber hinaus sollte Konjunktivsprache wie der Ausdruck „mindestens eines von X, Y und Z“, sofern nicht ausdrücklich anders angegeben, auch als X, Y, Z oder eine beliebige Kombination davon verstanden werden, einschließlich „X, Y und/oder Z“.
Ausführungsformen der Erfindung können verschieden Schritte beinhalten, die oben beschrieben worden sind. Die Schritte können in maschinenausführbaren Anweisungen ausgeführt sein, die verwendet werden können, um einen universellen oder speziellen Prozessor zum Durchführen der Schritte zu veranlassen. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, die fest verdrahtete Logik zum Durchführen der Schritte haben, oder durch eine beliebige Kombination aus programmierten Computerkomponenten und maßgeschneiderten Hardwarekomponenten durchgeführt werden.
Wie hierin beschrieben, können sich Anweisungen auf spezifische Auslegungen von Hardware, wie anwendungsspezifische integrierte Schaltungen (Application Specific Integrated Circuits, ASICs), die dazu ausgelegt sind, bestimmte Operationen durchzuführen, oder die eine vorher festgelegte Funktionalität aufweisen, oder Softwareanweisungen, die in einem Arbeitsspeicher gespeichert sind, der in einem nicht-flüchtigen computerlesbaren Medium ausgeführt ist, beziehen. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten umgesetzt werden, die auf einer oder mehreren elektronischen Vorrichtungen (z. B. einer Endstation, einem Netzwerkelement usw.) gespeichert und ausgeführt werden. Derartige elektronische Vorrichtungen speichern und kommunizieren (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netzwerk) Code und Daten unter Verwendung von computer-maschinenlesbaren Medien, wie nicht transitorischen computer-maschinenlesbaren Speichermedien (z. B. magnetischen Platten; optischen Platten; Arbeitsspeicher mit wahlfreiem Zugriff; schreibgeschütztem Arbeitsspeicher; Flashspeichervorrichtungen; Phasenwechselspeicher) und transitorischen computer-maschinenlesbaren Kommunikationsmedien (z. B. elektrischen, optischen, akustischen oder einer anderen Form von propagierten Signalen - wie Trägerwellen, Infrarotsignalen, Digitalsignalen usw.).
Außerdem enthalten diese elektronischen Vorrichtungen üblicherweise einen Satz von einem oder mehreren Prozessoren, die an eine oder mehrere andere Komponenten, wie eine oder mehrere Speichervorrichtungen (nichtflüchtige maschinenlesbare Speichermedien), Benutzereingabe/-ausgabevorrichtungen (z. B. eine Tastatur, ein Touchscreen und/oder eine Anzeige), gekoppelt sind, und Netzwerkverbindungen. Das Koppeln des Satzes von Prozessoren und anderen Komponenten erfolgt üblicherweise durch eine/n oder mehrere Busse und Brücken (auch als Bussteuerungen bezeichnet). Die Speichervorrichtung bzw. die Signale, die den Netzwerkverkehr tragen, stellen ein oder mehrere maschinenlesbare Speichermedien und maschinenlesbare Kommunikationsmedien dar. Somit speichert die Speichervorrichtung einer gegebenen elektronischen Vorrichtung typischerweise Code und/oder Daten zur Ausführung auf dem Satz von einem oder mehreren Prozessoren dieser elektronischen Vorrichtung. Natürlich können ein oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung unterschiedlicher Kombinationen von Software, Firmware und/oder Hardware implementiert sein. In dieser ausführlichen Beschreibung sind zur Erklärung durchweg zahlreiche spezifische Details dargelegt worden, um ein gründliches Verständnis der vorliegenden Erfindung bereitzustellen. Es ist jedoch für Fachleute ersichtlich, dass die Erfindung ohne einige dieser spezifischen Details ausgeführt werden kann. In bestimmten Fällen wurden hinlänglich bekannte Strukturen und Funktionen nicht in ausführlichem Detail beschrieben, um zu verhindern, dass der Gegenstand der vorliegenden Erfindung unverständlich wird. Entsprechend sind der Geltungsbereich und der Gedanke der Erfindung mittels der nachfolgenden Ansprüche zu beurteilen.
Beispiel 1 enthält eine Grafikverarbeitungseinrichtung, die enthält: eine Schnittstelle mit einer Arbeitsspeichervorrichtung; ein Umordnungs-Puffersystem, das an die Schnittstelle mit der Arbeitsspeichervorrichtung gekoppelt ist, wobei das Umordnungs-Puffersystem einen Arbeitsspeicher mit wahlfreiem Zugriff und eine Nachverfolgungseinheit umfasst; und eine Schnittstelle, um das Umordnungs-Puffersystem an einen Dekomprimierer zu koppeln, wobei: der Arbeitsspeicher mit wahlfreiem Zugriff Daten vor einer Ausgabe an die an den Dekomprimierer gekoppelte Schnittstelle zu speichern hat, die Nachverfolgungseinheit zu bewirken hat, dass der Schnittstelle mit dem Dekomprimierer Daten in einer Reihenfolge der Zuteilung bereitgestellt werden, und eine Menge von Arbeitsspeicherressourcen im Arbeitsspeicher mit wahlfreiem Zugriff, die zugeteilt wird, um empfangene Daten umzuordnen, auf Grundlage eines Betriebsmodus konfigurierbar ist.
Beispiel 2 enthält ein beliebiges Beispiel, wobei das Umordnungs-Puffersystem einen Steuerpuffer umfasst, um Komprimierungseigenschaften von in der Arbeitsspeichervorrichtung gespeicherten Daten anzuzeigen.
Beispiel 3 enthält ein beliebiges Beispiel, wobei die Komprimierungseigenschaften eines oder mehrere umfassen von: Komprimierungszustand, Oberflächenformat, Komprimierungsformat und anderen Metadaten.
Beispiel 4 enthält ein beliebiges Beispiel, wobei der Betriebsmodus auf einem Typ von Anwendung beruht, die eine Verwendung der Dekomprimierung anfordert.
Beispiel 5 enthält ein beliebiges Beispiel, wobei der Typ von Anwendung ein Spiel, eine Präsentationssoftware, eine Tabellenkalkulation oder einen Videoplayer umfasst.
Beispiel 6 enthält ein beliebiges Beispiel, wobei der Betriebsmodus auf einer Menge von Taktzyklen beruht, die verwendet werden, um komprimierte Daten zumindest mit einem ersten Komprimierungsverhältnis zu übertragen, das mehrere Taktzyklen involviert, um mit einer Leseanforderung assoziierte Daten zu übertragen.
Beispiel 7 enthält ein beliebiges Beispiel, wobei der Betriebsmodus auf einem Verstecken einer Latenz aus der Verwendung des Arbeitsspeichers mit wahlfreiem Zugriff zum Speichern von Daten zum Umordnen von Daten beruht.
Beispiel 8 enthält ein beliebiges Beispiel, wobei der Arbeitsspeicher mit wahlfreiem Zugriff Arbeitsspeicherressourcen für einen ersten Client und Arbeitsspeicherressourcen für einen zweiten Client zuzuteilen hat.
Beispiel 9 enthält ein beliebiges Beispiel und enthält eine Steuerung, die dem ersten Client zu erlauben hat, sich Arbeitsspeicherressourcen vom zweiten Client auszuleihen.
Beispiel 10 enthält ein beliebiges Beispiel, wobei der zweite Client verfügbare Arbeitsspeicherressourcen und eine zugehörige langsamste Wachstumsrate bei der Arbeitsspeicherzuteilung aufweist.
Beispiel 11 enthält ein beliebiges Beispiel, wobei der Arbeitsspeicher mit wahlfreiem Zugriff Arbeitsspeicherressourcen für einen dritten Client zuzuteilen hat und wobei die Steuerung Arbeitsspeicherressourcen für den zweiten Client durch Ausleihen von Arbeitsspeicherressourcen vom dritten Client zuzuteilen hat und die Steuerung Arbeitsspeicherressourcen für den ersten Client durch ein Ausleihen von Arbeitsspeicherressourcen vom zweiten Client zuzuteilen hat.
Beispiel 12 enthält ein Verfahren, das von einem Umordnungspuffer durchgeführt wird, der von einem Dekomprimierer verwendet wird, um komprimierte Dateneinträge umzuordnen, wobei das Verfahren umfasst: Zuteilen eines oder mehrerer Einträge auf Grundlage eines Betriebsmodus zur Verwendung beim Umordnen von empfangenen Einträgen, die mit einer Leseanforderung assoziiert sind; Speichern von empfangenen Daten, die mit der Leseanforderung assoziiert sind, in den zugeteilten einen oder den zugeteilten mehreren Einträgen; auf Grundlage eines Empfangs eines Eintrags, der dem Dekomprimierer nicht bereitgestellt wurde und ganz vorne ist, Bereitstellen des Eintrags in Reihenfolge an den Dekomprimierer; und auf Grundlage einer Identifikation eines Empfangs eines letzten Eintrags des gesamten einen oder der gesamten mehrerer Einträge, die mit der Leseanforderung assoziiert sind, Bereitstellen des gesamten einen oder der gesamten mehreren Einträge, die dem Dekomprimierer nicht vorher bereitgestellt wurden, in Reihenfolge an den Dekomprimierer.
Beispiel 13 enthält ein beliebiges Beispiel und enthält: Bereitstellen von Komprimierungsinformationen für einen oder mehrere Einträge an den Dekomprimierer.
Beispiel 14 enthält ein beliebiges Beispiel, wobei die Komprimierungsinformationen eines oder mehrere umfassen von: Komprimierungszustand, Oberflächenformat, Komprimierungsformat und anderen Metadaten.
Beispiel 15 enthält ein beliebiges Beispiel und enthält: Zuteilen von Arbeitsspeicherressourcen zur Speicherung von einem oder mehreren Einträgen zumindest teilweise auf Grundlage eines Typs von Anwendung, die eine Verwendung von Dekomprimierung oder von Taktzyklen anfordert, die verwendet werden, um komprimierte Daten zu übertragen, die mindestens eine Schwellengröße aufweisen.
Beispiel 16 enthält ein beliebiges Beispiel, wobei der Typ von Anwendung ein Spiel, eine Präsentationssoftware, eine Tabellenkalkulation oder einen Videoplayer umfasst.
Beispiel 17 enthält ein beliebiges Beispiel und enthält: Zuteilen von Arbeitsspeicherressourcen für den Dekomprimierer und Arbeitsspeicherressourcen für einen anderen Arbeitsspeicherclient.
Beispiel 18 enthält ein beliebiges Beispiel und enthält: Erlauben, dass sich der Dekomprimierer Arbeitsspeicherressourcen von dem anderen Arbeitsspeicherclient ausleiht.
Beispiel 19 enthält ein beliebiges Beispiel, wobei der andere Arbeitsspeicherclient verfügbare Arbeitsspeicherressourcen und eine zugehörige langsamste Wachstumsrate bei der Arbeitsspeicherzuteilung aufweist.
Beispiel 20 enthält ein computerlesbares Medium, das darauf gespeicherte Anweisungen aufweist, die bei Ausführung durch einen Prozessor bewirken, dass der Prozessor: bewirkt, dass ein Arbeitsspeicher mit wahlfreiem Zugriff Daten vor einer Ausgabe an die an einen Dekomprimierer gekoppelte Schnittstelle ausgibt, bewirkt, dass der Schnittstelle mit dem Dekomprimierer Daten in einer Reihenfolge der Zuteilung bereitgestellt werden, und eine Menge von Arbeitsspeicherressourcen im Arbeitsspeicher mit wahlfreiem Zugriff modifiziert, um empfangene Daten auf Grundlage eines Betriebsmodus umzuordnen.
Beispiel 21 enthält ein beliebiges Beispiel, wobei der Betriebsmodus auf einem Typ von Anwendung beruht, die eine Verwendung der Dekomprimierung anfordert.
Beispiel 22 enthält ein beliebiges Beispiel, wobei der Typ von Anwendung ein Spiel, eine Präsentationssoftware, eine Tabellenkalkulation oder einen Videoplayer umfasst.
Beispiel 23 enthält ein beliebiges Beispiel und enthält darauf gespeicherte Anweisungen, die bei Ausführung durch einen Prozessor bewirken, dass der Prozessor: Arbeitsspeicherressourcen für den Dekomprimierer und Arbeitsspeicherressourcen für einen anderen Arbeitsspeicherclient zuteilt.
Beispiel 24 enthält ein beliebiges Beispiel und enthält darauf gespeicherte Anweisungen, die bei Ausführung durch einen Prozessor bewirken, dass der Prozessor: Arbeitsspeicherressourcen für den Dekomprimierer von dem anderen Arbeitsspeicherclient zugeteilten Arbeitsspeicherressourcen zuteilt.
Beispiel 25 enthält ein beliebiges Beispiel und enthält darauf gespeicherte Anweisungen, die bei Ausführung durch einen Prozessor bewirken, dass der Prozessor: dem Dekomprimierer Komprimierungsinformationen für einen oder mehrere Einträge bereitstellt, wobei die Komprimierungsinformationen eines oder mehrere umfassen von: Komprimierungszustand, Oberflächenformat, Komprimierungsformat und anderen Metadaten.

Claims

Grafikverarbeitungseinrichtung, umfassend: eine Schnittstelle mit einer Arbeitsspeichervorrichtung; ein Umordnungs-Puffersystem, das an die Schnittstelle mit der Arbeitsspeichervorrichtung gekoppelt ist, wobei das Umordnungs-Puffersystem einen Arbeitsspeicher mit wahlfreiem Zugriff und eine Nachverfolgungseinheit umfasst; und eine Schnittstelle, um das Umordnungs-Puffersystem an einen Dekomprimierer zu koppeln, wobei: der Arbeitsspeicher mit wahlfreiem Zugriff Daten vor einer Ausgabe an die an den Dekomprimierer gekoppelte Schnittstelle zu speichern hat, die Nachverfolgungseinheit zu bewirken hat, dass der Schnittstelle mit dem Dekomprimierer Daten in einer Reihenfolge der Zuteilung bereitgestellt werden, und eine Menge von Arbeitsspeicherressourcen im Arbeitsspeicher mit wahlfreiem Zugriff, die zugeteilt wird, um empfangene Daten umzuordnen, auf Grundlage eines Betriebsmodus konfigurierbar ist.
Grafikverarbeitungseinrichtung nach Anspruch 1, wobei das Umordnungs-Puffersystem einen Steuerpuffer umfasst, um Komprimierungseigenschaften von in der Arbeitsspeichervorrichtung gespeicherten Daten anzuzeigen und wobei die Komprimierungseigenschaften eines oder mehrere umfassen von: Komprimierungszustand, Oberflächenformat, Komprimierungsformat und anderen Metadaten.
Grafikverarbeitungseinrichtung nach Anspruch 1, wobei der Betriebsmodus auf einem Typ von Anwendung beruht, die eine Verwendung der Dekomprimierung anfordert, und wobei der Typ von Anwendung ein Spiel, eine Präsentationssoftware, eine Tabellenkalkulation oder einen Videoplayer umfasst.
Grafikverarbeitungseinrichtung nach Anspruch 1, wobei der Betriebsmodus auf einer Menge von Taktzyklen beruht, die verwendet werden, um komprimierte Daten zumindest mit einem ersten Komprimierungsverhältnis zu übertragen, das mehrere Taktzyklen involviert, um mit einer Leseanforderung assoziierte Daten zu übertragen.
Grafikverarbeitungseinrichtung nach Anspruch 1, wobei der Arbeitsspeicher mit wahlfreiem Zugriff Arbeitsspeicherressourcen für einen ersten Client und Arbeitsspeicherressourcen für einen zweiten Client zuzuteilen hat und eine Steuerung umfasst, die dem ersten Client zu erlauben hat, Arbeitsspeicherressourcen vom zweiten Client auszuleihen.
Grafikverarbeitungseinrichtung nach Anspruch 5, wobei der zweite Client verfügbare Arbeitsspeicherressourcen und eine zugehörige langsamste Wachstumsrate bei der Arbeitsspeicherzuteilung aufweist.
Grafikverarbeitungseinrichtung nach Anspruch 5, wobei der Arbeitsspeicher mit wahlfreiem Zugriff Arbeitsspeicherressourcen für einen dritten Client zuzuteilen hat und wobei die Steuerung Arbeitsspeicherressourcen für den zweiten Client durch Ausleihen von Arbeitsspeicherressourcen vom dritten Client zuzuteilen hat und die Steuerung Arbeitsspeicherressourcen für den ersten Client durch ein Ausleihen von Arbeitsspeicherressourcen vom zweiten Client zuzuteilen hat.
Grafikverarbeitungseinrichtung nach einem der Ansprüche 1-7, wobei der Betriebsmodus auf einem Verstecken einer Latenz aus der Verwendung des Arbeitsspeichers mit wahlfreiem Zugriff zum Speichern von Daten zum Umordnen von Daten beruht.
Verfahren, das von einem Umordnungspuffer durchgeführt wird, der von einem Dekomprimierer verwendet wird, um komprimierte Dateneinträge umzuordnen, wobei das Verfahren umfasst: Zuteilen eines oder mehrerer Einträge auf Grundlage eines Betriebsmodus zur Verwendung beim Umordnen von empfangenen Einträgen, die mit einer Leseanforderung assoziiert sind; Speichern von empfangenen Daten, die mit der Leseanforderung assoziiert sind, in den zugeteilten einen oder die zugeteilten mehreren Einträge; auf Grundlage eines Empfangs eines Eintrags, der dem Dekomprimierer nicht bereitgestellt wurde und ganz vorne ist, Bereitstellen des Eintrags in Reihenfolge an den Dekomprimierer; und auf Grundlage einer Identifikation eines Empfangs eines letzten Eintrags von allen von einem oder mehreren Einträgen, die mit der Leseanforderung assoziiert sind, Bereitstellen eines oder mehrerer Einträge, die dem Dekomprimierer nicht vorher bereitgestellt wurden, in Reihenfolge an den Dekomprimierer.
Verfahren nach Anspruch 9, ferner umfassend: Bereitstellen von Komprimierungsinformationen für einen oder mehrere Einträge an den Dekomprimierer.
Verfahren nach Anspruch 10, wobei die Komprimierungsinformationen eines oder mehrere umfassen von: Komprimierungszustand, Oberflächenformat, Komprimierungsformat und anderen Metadaten.
Verfahren nach Anspruch 9, ferner umfassend: Zuteilen von Arbeitsspeicherressourcen zur Speicherung von einem oder mehreren Einträgen zumindest teilweise auf Grundlage eines Typs von Anwendung, die eine Verwendung von Dekomprimierung oder von Taktzyklen anfordert, die verwendet werden, um komprimierte Daten zu übertragen, die mindestens eine Schwellengröße aufweisen.
Verfahren nach Anspruch 12, wobei der Typ von Anwendung ein Spiel, eine Präsentationssoftware, eine Tabellenkalkulation oder einen Videoplayer umfasst.
Verfahren nach einem der Ansprüche 9-13, umfassend: Zuteilen von Arbeitsspeicherressourcen für den Dekomprimierer und Arbeitsspeicherressourcen für einen anderen Arbeitsspeicherclient und Erlauben, dass sich der Dekomprimierer Arbeitsspeicherressourcen von dem anderen Arbeitsspeicherclient ausleiht, wobei der andere Arbeitsspeicherclient verfügbare Arbeitsspeicherressourcen und eine zugehörige langsamste Wachstumsrate bei der Arbeitsspeicherzuteilung aufweist.
Computerlesbares Medium, das darauf gespeicherte Anweisungen umfasst, die, falls sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, ein Verfahren nach einem der vorhergehenden Ansprüche zu implementieren oder eine Einrichtung nach einem der vorhergehenden Ansprüche zu realisieren.