DE112017004246T5

DE112017004246T5 - Cache- und komprimierungsinteroperabilität in einer grafikprozessorpipeline

Info

Publication number: DE112017004246T5
Application number: DE112017004246.1T
Authority: DE
Inventors: Tomas G. Akenine-Moller; Prasoonkumar Surti; Altug Koker; David Puffer; Jim K. Nilsson
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-09-26
Filing date: 2017-07-26
Publication date: 2019-05-23
Also published as: US10719447B2; CN109643443A; CN109643443B; US20180089091A1; WO2018057109A1

Abstract

Hierin beschrieben sind mehrere Ausführungsformen, die verbessertes Datencachen in Kombination mit adaptiver und dynamischer Komprimierung bereitstellen, um die Speichereffizienz zu erhöhen und die Übertragungsbandbreite der Daten während der Ein- und Ausgabe aus einer GPU verringern. Die hierin beschriebenen Techniken können die Notwendigkeit des Zugriffs auf Speicher außerhalb des Chips verhindern, was zu verbesserter Leistung und verringerter Energie für die GPU-Operationen führt. Eine Ausführungsform sieht eine Grafikverarbeitungsvorrichtung vor, die eine Shader-Engine; einen oder mehrere Cachespeicher; Cachesteuerlogik zur Steuerung von mindestens einem des einen oder der mehreren Cachespeicher; und eine Codec-Einheit, die mit dem einen oder den mehreren Cachespeichern verbunden ist, umfasst, wobei die Codec-Einheit konfigurierbar ist, nach dem Speichern auf oder der Auslagerung von dem einen oder den mehreren Cachespeichern eine verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff auszuführen.

Description

TECHNISCHER BEREICH
Ausführungsformen beziehen sich allgemein auf eine Logik zum Durchführen von Grafikverarbeitungsoperationen. Genauer gesagt, beziehen sich Ausführungsformen auf eine Cache- und Komprimierungslogik für einen Grafikprozessor.
ALLGEMEINER STAND DER TECHNIK
In einer Grafikprozessoreinheit (GPU) können Transaktionen über Speicherbusse mehrere Größenordnung an Energie und Latenz mehr kosten, als die Berechnung. Daher enthalten Grafikverarbeitungsarchitekturen zahlreiche Ausgleiche zwischen der Durchführung weiterer Berechnungen zum Verringern der Datenmenge, die über den Speicherbus übertragen wird, was die Motivation hinter den Pufferkomprimierungsalgorithmen ist, die häufig in Grafikverarbeitungseinheiten (GPUs) verwendet werden.
Komprimierungsalgorithmen können verwendet werden, um Daten vor der Übertragung über einen Bus zu komprimieren, und können außerdem verwendet werden, um Daten zu komprimieren, die in einem oder mehreren Cachespeichern gespeichert werden. Während die Durchführung der Komprimierungsalgorithmen weitere Logik oder weitere Berechnungszyklen verlangen kann, kann einer Verringerung des Energieverbrauchs und der Latenz durch die verringern Speicherbusbandbreite, die die zum Senden von Daten benötigt wird, und die erhöhte Speichereffizienz der Cachespeicher entstehen. Daher kann die Umsetzung der Komprimierung innerhalb einer GPU-Pipeline die Energie verringern und die Leistung erhöhen, wenn weiter Logikoperationen in dem Ablauf durchgeführt werden.
Figurenliste
Die verschiedenen Vorteile der Ausführungsformen sind für den Fachmann offensichtlich, wenn er die folgenden Vorgaben und die beiliegenden Ansprüche liest, und durch Verweis auf die folgenden Zeichnungen, wobei:

1 ein Blockdiagramm einer Ausführungsform eines Computersystems mit einem Prozessor ist, der einen oder mehrere Prozessorkerne und Grafikprozessoren aufweist;
2 ein Blockdiagramm einer Ausführungsform eines Prozessors ist, der einen oder mehrere Prozessorkerne, einen integrierten Speichercontroller und einen integrierten Grafikprozessor aufweist;
3 ein Blockdiagramm einer Ausführungsform eines Grafikprozessors ist, der eine diskrete Grafikverarbeitungseinheit oder ein Grafikprozessor, der mit mehreren Prozessorkernen integriert ist, sein kann;
4 ein Blockdiagramm einer Ausführungsform einer Grafikverarbeitungs-Engine für einen Grafikprozessor ist;
5 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist;
6 ein Blockdiagramm einer Threadausführungslogik ist, das ein Array von Verarbeitungselementen umfasst;
7 ein Anweisungsformat für eine Grafikprozessorausführungseinheit nach einer Ausführungsform illustriert;
8 ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors ist, der eine Grafikpipeline, eine Medienpipeline, eine Anzeige-Engine, Thread-Ausführungslogik und eine Render-Ausgabepipeline umfasst;
9A ein Blockdiagramm ist, das ein Grafikprozessorbefehlsformat nach einer Ausführungsform illustriert;
9B ein Blockdiagramm ist, das eine Grafikprozessorbefehlssequenz nach einer Ausführungsform illustriert;
10 eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem nach einer Ausführungsform illustriert;
11 ein Blockdiagramm ist, das ein IP-Kernentwicklungssystem illustriert, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Funktionen nach einer Ausführungsform auszuführen;
12 ein Blockdiagramm ist, das ein beispielhaftes System auf einem chipintegrierten Schaltkreis nach einer Ausführungsform illustriert, das unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann;
13 ein Blockdiagramm ist, das einen beispielhaften Grafikprozessor eines in ein System auf einem Chip integrierten Schaltkreis umfasst;
14 ein Blockdiagramm ist, das einen weiteren beispielhaften Grafikprozessor eines in ein System auf einem Chip integrierten Schaltkreis umfasst;
15 ein Blockdiagramm des Grafikprozessors nach einer Ausführungsform ist;
16 ein Blockdiagramm eines Grafikverarbeitungssystems nach einer Ausführungsform ist;
17A bis 17B eine beispielhafte Logik für verlustlose Komprimierung von Oberflächendaten mit reinem Lesezugriff illustrierten ist;
18A bis 18B ein Beispiel der Kombination von verlustfreier und verlustbehafteter Komprimierung illustrieren;
19 ein Blockdiagramm einer Cacheflächenverringerung unter Verwendung von Komprimierung mit garantierte Rate nach einer Ausführungsform ist;
20 ein Blockdiagramm einer beispielhaften Cachehierarchie ist, in der kontextsensitive Cacheersetzung aktiviert ist;
21 ein Ablaufdiagram, einer kontextsensitiven Cacheersetzungslogik nach einer Ausführungsform ist;
22 ein Blockdiagramm einer Hardwaremultiplikatoreinheit zur Verwendung in effizienter Deltacodierung nach einer Ausführungsform ist; und
23 ein Blockdiagramm eines Grafiksystems nach einer Ausführungsform ist.

BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Hierin beschrieben sind mehrere Ausführungsformen, die verbessertes Datencachen in Kombination mit adaptiver und dynamischer Komprimierung bereitstellen, um die Speichereffizienz zu erhöhen und die Übertragungsbandbreite der Daten während der Ein- und Ausgabe aus einer GPU verringern. Die hierin beschriebenen Techniken können die Notwendigkeit des Zugriffs auf Speicher außerhalb des Chips verhindern, was zu verbesserter Leistung und verringerter Energie für die GPU-Operationen führt. Zum Zweck der Erklärung zahlreiche spezifische Details dargelegt, um ein ausführliches Verständnis der verschiedenen nachfolgend beschriebenen Ausführungsformen bereitzustellen. Es ist jedoch für einen Fachmann offensichtlich, dass die Ausführungsformen ohne einige dieser spezifischen Details ausgeführt werden können. In anderen Fällen werden bekannte Strukturen und Vorrichtungen in Form eines Blockdiagramms dargestellt, um die zugrundeliegenden Grundsätze nicht zu verschleiern und ein genaueres Verständnis der Ausführungsformen zu ermöglichen. Wenn auch einige der folgenden Ausführungsformen mit Verweis auf einen Grafikprozessor beschrieben sind, können die Techniken und Offenbarungen, die hierin beschrieben sind, auf verschiedene Arten von Schaltkreisen oder Halbleitervorrichtungen angewendet werden, einschließlich Mehrzweck-Verarbeitungsvorrichtungen oder Grafikverarbeitungsvorrichtungen. Verweise hierin auf „eine Ausführungsform“ oder „an Ausführungsform“ weisen darauf hin, dass ein bestimmtes Merkmal, eine Struktur oder Eigenschaft, die in Verbindung oder Assoziation mit der Ausführungsform beschrieben ist, in mindestens einer solchen Ausführungsformen enthalten sein kann. Das Auftreten der Bezeichnung „in einer Ausführungsform“ an unterschiedlichen Stellen der Spezifikation bezieht sich jedoch nicht notwendigerweise immer auf dieselbe Ausführungsform.
In der folgenden Beschreibung und den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ zusammen mit ihren Ableitungen verwendet werden. Es sollte verstanden werden, dass diese Begriffe nicht als synonym zueinander vorgesehen sind. „Gekoppelt“ wird verwendet, um anzuzeigen, dass zwei oder mehrere Elemente, die in direktem physischen oder elektrischen Kontakt miteinander stehen können, zusammenarbeiten oder miteinander interagieren. „Verbunden“ wird verwendet, um anzuzeigen, dass eine Kommunikation zwischen zwei oder mehr Elementen aufgebaut wird, die miteinander gekoppelt sind.
In der folgenden Beschreibung stellen die 1 bis 14 einen Überblick über ein beispielhaftes Datenverarbeitungssystem und eine Grafikprozessorlogik, die die verschiedenen Ausführungsformen integriert oder sich darauf bezieht. 15 bis 23 stellen spezifische Details der verschiedenen Ausführungsformen dar. Einige Aspekte der folgenden Ausführungsformen sind mit Verweis auf einen Grafikprozessor beschrieben, während andere Aspekte mit Verweis auf einen Mehrzweckprozessor, wie etwa eine zentrale Prozessoreinheit (CPU) beschrieben sind. Ähnliche Techniken und Offenbarungen können auch auf andere Arten von Schaltkreisen oder Halbleitervorrichtungen angewendet werden, einschließlich, aber nicht beschränkt auf einen vielkernintegrierten Prozessor, einen GPU-Cluster oder eine oder mehrere Instanzen eines im Feld programmierbaren Arrays (FPGA). Allgemein gelten die Offenbarungen für jeden Prozessor oder jede Maschine, der/die Bild- (z. B. Sample, Pixel), Vertexdaten oder Geometriedaten manipuliert oder verarbeitet.
Systemüberblick
1 ist ein Blockdiagramm eines Verarbeitungssystems 100 nach einer Ausführungsform. In verschiedenen Ausführungsformen umfasst das System 100 einen oder mehrere Prozessoren 102 und einen oder mehrere Grafikprozessoren 108 und kann ein einzelnes Prozessor-Desktopsystem, ein Multiprozessor-Workstationsystem oder ein Serversystem sein, das eine große Anzahl Prozessoren 102 oder Prozessorkerne 107 aufweist. In einer Ausführungsform ist das System 100 eine Verarbeitungsplattform, die in einem Schaltkreis, der zur Verwendung in mobilen, tragbaren oder eingebetteten Vorrichtungen in einem System-on-a-Chip (SoC) integriert ist, eingeschlossen ist.
Eine Ausführungsform von System 100 kann innerhalb einer serverbasierten Spieleplattform eine Spielekonsole, einschließlich einer Spiele- und Medienkonsole, einer mobilen Spielekonsole, einer tragbaren Spielekonsole oder einer Online-Spielekonsole, umfassen oder darin eingeschlossen sein. In einigen Ausführungsformen ist das System 100 ein Handy, ein Smartphone, eine Tabletcomputervorrichtung oder eine mobile Internetvorrichtung. Das Datenverarbeitungssystem 100 kann außerdem eine tragbare Vorrichtung, wie etwa eine tragbare Vorrichtung in Form einer Smart Watch, eine Vorrichtung für Augmented Reality oder eine Vorrichtung für Virtual Reality umfassen, sich damit koppeln oder darin integriert sein. In einigen Ausführungsformen ist das Datenverarbeitungssystem 100 eine Fernseh- oder Set-Top-Box-Vorrichtung, die einen oder mehrere Prozessoren 102 und eine grafische Oberfläche aufweist, die durch einen oder mehrere Grafikprozessoren 108 erzeugt wird.
In einigen Ausführungsformen umfassen der eine oder die mehreren Prozessoren 102 jeweils einen oder mehrere Prozessorkerne 107 zur Verarbeitung von Anweisungen, die bei Ausführung Funktionen für System- und Benutzersoftware durchführen. In einigen Ausführungsformen ist jeder der einen oder mehreren Prozessorkerne 107 konfiguriert, einen spezifischen Anweisungssatz 109 auszuführen. In einigen Ausführungsformen kann der Anweisungssatz 109 „Complex Instruction Set Computing“ (CISC), „Reduced Instruction Set Computing“ (RISC) oder Rechenvorgänge über eine „Very Long Instruction Word“ (VLIW) ermöglichen. Mehrere Prozessorkerne 107 können jeweils einen unterschiedlichen Anweisungssatz 109 verarbeiten, der Anweisungen enthalten kann, die die Emulierung anderer Anweisungssets zu ermöglichen. Der Prozessorkern 107 kann auch andere Verarbeitungsvorrichtungen umfassen, wie etwa einen digitalen Signalprozessor (DSP).
In einigen Ausführungsformen umfasst der Prozessor 102 einen Cachespeicher 104. Abhängig von der Architektur kann der Prozessor 102 einen einzelnen internen Cache oder mehrere Levels eines internen Cache aufweisen. In einigen Ausführungsformen wird der Cachespeicher von verschiedenen Bauteilen des Prozessors 102 geteilt. In einigen Ausführungsformen verwendet der Prozessor 102 außerdem einen externen Cache (z. B. einen Level-3-(L3) Cache oder Last-Level-Cache (LLC)) (nicht dargestellt), der von den Prozessorkernen 107 unter Verwendung bekannter Cache-Kohärenztechniken geteilt werden kann. Eine Registerdatei 106, die unterschiedliche Arten von Registern zum Speichern unterschiedlicher Arten von Daten enthalten kann (z. B. ganzzahlige Register, Fließkommaregister, Statusregister und ein Anweisungsanzeigeregister), ist außerdem in dem Prozessor 102 enthalten. Einige Register können Register zu allgemeinen Zwecken sein, während sich andere Register speziell auf das Design des Prozessors 102 beziehen.
In einigen Ausführungsformen ist der Prozessor 102 mit einem Prozessorbus 110 gekoppelt, um Kommunikationssignale wie Adresse, Daten oder Steuersignale zwischen dem Prozessor 102 und anderen Bestandteilen in dem System 100 zu senden. In einer Ausführungsform verwendet das System 100 eine beispielhafte ‚Hub-‘ Systemarchitektur, einschließlich eines Speichercontrollerhubs 116 und eines Eingabe-Ausgabe- (E/A) Controllerhubs 130. Ein Speichercontrollerhub 116 ermöglicht die Kommunikation zwischen einer Speichervorrichtung und anderen Bestandteilen des Systems 100, während ein E/A bis Controllerhub (ICH) 130 Verbindungen zu E/A bis Vorrichtungen über einen lokalen E/A bis Bus bereitstellt. In einer Ausführungsform ist die Logik des Speichercontrollerhubs 116 in den Prozessor integriert.
Die Speichervorrichtung 120 kann eine dynamische Random-Access-Speichervorrichtung (DRAM), eine statische Random-Access-Speichervorrichtung (SRAM), eine Flashspeichervorrichtung, eine Phase-Change-Speichervorrichtung oder eine andere Speichervorrichtung sein, deren Leistung sich eignet, um als Prozessspeicher zu dienen. In einer Ausführungsform kann die Speichervorrichtung 120 als Systemspeicher für das System 100 dienen, um das Daten 122 und die Anweisungen 121 zur Verwendung, wenn der eine oder die mehreren Prozessoren 102 eine Anwendung oder einen Prozess ausführen, zu speichern. Der Speichercontrollerhub 116 koppelt sich außerdem mit einem optionalen externen Grafikprozessor 112, der mit dem einen oder den mehreren Grafikprozessoren 108 in den Prozessoren 102 kommunizieren kann, um Grafik- und Medienfunktionen durchzuführen.
In einigen Ausführungsformen ermöglicht der ICH 130 den Peripheriegeräten die Verbindung mit der Speichervorrichtung 120 und dem Prozessor 102 über einen Hochgeschwindigkeits-E/A bis Bus. Die E/A bis Peripheriegeräte umfassen, sind jedoch nicht beschränkt auf einen Audiocontroller 146, eine Firmware-Schnittstelle 128, einen Drahtlosempfänger 126 (z. B. Wi-Fi, Bluetooth), eine Datenspeichervorrichtung 124 (z. B. Festplattenlaufwerk, Flash-Speicher usw.) und einen Altsystem-E/A bis Controller 140 zur Koppelung von Altsystem- (z. B. Personal System 2 (PS/2)) Vorrichtungen mit dem System. Ein oder mehrere „Universal Serial Bus“- (USB) Controller 142 verbinden Kombinationen von Eingabevorrichtungen, wie etwa eine Tastatur und Maus 144. Ein Netzwerkcontroller 134 kann sich ebenfalls mit dem ICH 130 koppeln. In einigen Ausführungsformen koppelt sich ein Hochleistungs-Netzwerkcontroller (nicht dargestellt) mit dem Prozessorbus 110. Es ist zu erkennen, dass das dargestellte System 100 beispielhaft und nicht einschränkend ist, da auch andere Arten von Datenverarbeitungssystemen, die unterschiedlich konfiguriert sind, verwendet werden können. Beispielsweise kann der E/A bis Controllerhub 130 in den einen oder die mehreren Prozessoren 102 integriert sein oder der Speichercontrollerhub 116 und E/A bis Controllerhub 130 können in einen diskreten externen Grafikprozessor wie etwa den externen Grafikprozessor 112 integriert sein.
2 ist ein Blockdiagramm einer Ausführungsform eines Prozessors 200, der einen oder mehrere Prozessorkerne 202A bis 202N, einen integrierten Speichercontroller 214 und einen integrierten Grafikprozessor 208 aufweist. Die Element aus 2, die dieselben Referenznummern (oder Namen) wie die Elemente einer anderen Figur hierein aufweisen, können in einer Weise arbeiten oder funktionieren, die der anderswo hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt. Der Prozessor 200 kann weitere Kerne bis einschließlich einen weiteren Kern 202N umfassen, die durch die Kästen mit gestrichelten Linien dargestellt sind. Jeder der Prozessorkerne 202A bis 202N umfasst eine oder mehrere interne Cacheeinheiten 204A bis 204N. In einigen Ausführungsformen hat außerdem jeder Prozessorkern Zugriff auf eine oder mehrere geteilte gecachte Einheiten 206.
Die internen Cacheeinheiten 204A bis 204N und die geteilten Cacheeinheiten 206 stellen eine Cachespeicherhierarchie innerhalb des Prozessors 200 dar. Die Cachespeicherhierarchie kann mindestens ein Level eines Anweisungs- und Datencaches innerhalb jedes Prozessorkerns und ein oder mehrere Levels eines geteilten Mid-Level-Caches, wie etwa eine Level 2 (L2), Level 3 (L3), Level 4 (L4) oder andere Levels des Caches enthalten, wobei der höchste Level des Caches vor dem externen Speicher als LLC klassifiziert ist. In einigen Ausführungsformen erhält die Cache-Kohärenzlogik die Kohärenz zwischen den verschiedenen Cacheeinheiten 206 und 204A bis 204N.
In einigen Ausführungsformen kann der Prozessor 200 auch einen Satz einer oder mehrerer Buscontrollereinheiten 216 und einen System-Agent-Kern 210 enthalten. Die eine oder die mehreren Buscontrollereinheiten 216 verwalten einen Satz peripherer Busanschlüsse, wie etwa einen oder mehrere „Peripheral Component Interconnect“-Busanschlüsse (z. B. PCI, PCI Express). Der System-Agent-Kern 210 stellt eine Managementfunktion für die verschiedenen Prozessorbestandteile zur Verfügung. In einigen Ausführungsformen enthält der System-Agent-Kern 210 einen oder mehrere integrierte Speichercontroller 214 zur Verwaltung des Zugriffs auf verschiedene externe Speichervorrichtungen (nicht dargestellt).
In einigen Ausführungsformen umfassen der eine oder die mehreren Prozessorkerne 202A bis 202N eine Unterstützung für simultanes Multi-Threading. In dieser Ausführungsform umfasst der System-Agent-Kern 210 Bestandteile für Koordination und Betrieb der Kerne 202A bis 202N während der Multi-Threaded-Verarbeitung. Der System-Agent-Kern 210 kann weiterhin eine Leistungssteuereinheit (PCU) enthalten, die die Logik- und Bestandteile zum Regeln des Leistungszustands der Prozessorkerne 202A bis 202N und des Grafikprozessors 208 umfasst.
In einigen Ausführungsformen umfasst der Prozessor 200 weiterhin einen Grafikprozessor 208 zur Ausführung von Grafikverarbeitungsfunktionen. In einigen Ausführungsformen koppelt sich der Grafikprozessor 208 mit dem Satz geteilter Cacheeinheiten 206 und dem System-Agent-Kern 210, einschließlich des einen oder der mehreren integrierten Speichercontroller 214. In einigen Ausführungsformen ist ein Anzeigecontroller 211 mit dem Grafikprozessor 208 gekoppelt, um die Grafikprozessorausgabe an eine oder mehrere verbundene Anzeigen zu betreiben. In einigen Ausführungsformen kann der Anzeigecontroller 211 ein separates Modul sein, das mit dem Grafikprozessor über mindestens eine Verbindung gekoppelt ist, oder er kann in den Grafikprozessor 208 oder den System-Agent-Kern 210 integriert sein.
In einigen Ausführungsformen wird eine ringbasierte Verbindungseinheit 212 verwendet, um die internen Bestandteile des Prozessors 200 zu koppeln. Eine alternative Verbindungseinheit kann jedoch verwendet werden, wie etwa eine Punkt-zu-Punkt-Verbindung, eine geschaltete Verbindung oder andere Techniken, einschließlich Techniken, die auf dem Stand der Technik bekannt sind. In einigen Ausführungsformen koppelt sich der Grafikprozessor 208 mit der Ringverbindung 212 über einen E/A bis Link 213.
Der beispielhafte E/A bis Link 213 stellt mindestens eine der mehreren Variationen der E/A bis Verbindungen dar, einschließlich einer E/A bis Verbindung am Paket, die die Kommunikation zwischen verschiedenen Prozessorbestandteilen und einem eingebetteten Hochleistungs-Speichermodul 218, wie etwa einem eDRAM-Modul, ermöglicht. In einigen Ausführungsformen verwenden jeder der Prozessorkerne 202 bis 202N und der Grafikprozessor 208 eingebettete Speichermodule 218 als geteilten Last-Level-Cache.
In einigen Ausführungsformen sind die Prozessorkerne 202A bis 202N homogene Kerne, die dieseln Anweisungssatzarchitektur ausführen. In einer anderen Ausführungsform sind die Prozessorkerne 202A bis 202N bezüglich der Anweisungssatzarchitektur (ISA) heterogen, wobei einer oder mehrere der Prozessorkerne 202A bis N einen ersten Anweisungssatz ausführen, während mindestens einer der anderen Kerne einen Untersatz des ersten Anweisungssatzes oder einen anderen Anweisungssatz ausführen. In einer Ausführungsform sind die Prozessorkerne 202A bis 202N heterogen bezüglich der Mikroarchitektur, wobei sich ein oder mehrere Kerne, die einen relativ höheren Leistungsverbrauch aufweisen, mit einem oder mehreren Leistungskernen koppeln, die einen geringeren Leistungsverbrauch aufweisen. Weiterhin kann der Prozessor 200 auf einem oder mehreren Chips oder als SoC-integrierter Schaltkreis umgesetzt werden, der neben anderen Bestandteilen die illustrierten Bestandteile aufweist.
3 ist ein Blockdiagramm eines Grafikprozessors 300, der eine diskrete Grafikverarbeitungseinheit oder ein Grafikprozessor, der mit mehreren Prozessorkernen integriert, sein kann. In einigen Ausführungsformen kommuniziert der Grafikprozessor über eine speicherzugeordnete E/A bis Schnittstelle mit Registern auf dem Grafikprozessor und mit Befehlen, die in dem Prozessorspeicher abgelegt werden. In einigen Ausführungsformen umfasst der Grafikprozessor 300 eine Speicherschnittstelle 314 für den Zugriff auf den Speicher. Die Speicherschnittstelle 314 kann eine Schnittstelle mit einem örtlichen Speicher, einem oder mehreren internen Caches, einem oder mehreren geteilten externen Caches und/oder dem Systemspeicher sein.
In einigen Ausführungsformen umfasst der Grafikprozessor 300 auch einen Anzeigecontroller 302 zur Übergabe der Anzeigeausgabedaten an eine Anzeigevorrichtung 320. Der Anzeigecontroller 302 umfasst Hardware für eine oder mehrere Overlay-Ebenen für die Anzeige und Zusammensetzung mehrerer Lagen von Video oder Benutzerschnittstellenelementen. In einigen Ausführungsformen umfasst der Grafikprozessor 300 eine Videocodec-Engine 306 zum Codieren, Decodieren oder Transcodieren von Medien in, aus oder zwischen einem oder mehreren Mediencodierungsformaten, einschließlich, aber nicht beschränkt auf Formate der Moving Picture Experts Group (MPEG) wie MPEG-2, Formate des Advanced Video Coding (AVC) wie H.264/MPEG-4 AVC, sowie Formate der Society of Motion Picture & Television Engineers (SMPTE) 421 M/VC-1 und Joint Photographic Experts Group (JPEG), wie JPEG und Motion-JPEG- (MJPEG) Formate.
In einigen Ausführungsformen umfasst der Grafikprozessor 300 eine Blockbildübertragungs- (BLIT) Engine 304 zur Ausführung von zweidimensionalen (2D) Rasterisierungsfunktionen einschließlich beispielsweise Bitgrenzblockübergängen. In einer Ausführungsform werden jedoch die 2D-Grafikfunktionen unter Verwendung einer oder mehrerer Bestandteile der Grafikverarbeitungs-Engine (GPE) 310 ausgeführt. In einigen Ausführungsformen ist die Grafikverarbeitungs-Engine 310 eine Berechnungs-Engine zur Durchführung von Grafikfunktionen, einschließlich dreidimensionaler (3D) Grafikfunktionen und Medienfunktionen.
In einigen Ausführungsformen umfasst die GPE 310 eine 3D-Pipeline 312 zur Durchführung von 3D-Funktionen, wie etwa dem Rendern von dreidimensionalen Bildern und Szenen unter Verwendung von Verarbeitungsfunktionen, die auf primitive 3D-Formen wirken (z. B. Rechteck, Dreieck usw.). Die 3D-Pipeline 312 umfasst programmierbare und feste Funktionselemente, die verschiedene Aufgaben innerhalb des Elements ausführen und/oder Ausführungsthreads für ein 3D/Medien-Untersystem 315 spawnen. Während die 3D-Pipeline 312 verwendet werden kann, um Medienfunktionen auszuführen, umfasst eine Ausführungsform der GPE 310 ebenfalls eine Medienpipeline 316, die speziell verwendet wird, um Medienfunktionen auszuführen, wie etwa eine Videonachverarbeitung und Bildverbesserung.
In einigen Ausführungsformen umfasst die Medienpipeline 316 feste Funktions- oder programmierbare Logikeinheiten zur Ausführung einer oder mehrerer spezialisierter Medienfunktionen wie Beschleunigung der Videodecodierung, Video-Deinterlacing und Beschleunigung der Videocodierung anstelle oder für die Videocodec-Engine 306. In einigen Ausführungsformen umfasst die Medienpipeline 316 weiterhin eine Threadspawning-Einheit, die Threads für die Ausführung auf dem 3D/Medien-Untersystem 315 spawnt. Die gespawnten Threads führen Berechnungen für die Medienfunktionen auf einer oder mehreren Grafikausführungseinheiten aus, die in 3D/Medienuntersystem 315 enthalten sind.
In einigen Ausführungsformen umfasst das 3D/Medienuntersystem 315 eine Logik zur Ausführung von Threads, die durch die 3D-Pipeline 312 und Medienpipeline 316 gespawnt wurden. In einer Ausführungsform senden die Pipelines Threadausführungsanfragen an das 3D/Medienuntersystem 315, das eine Thread-Sendelogik für die Vermittlung und das Versenden der verschiedenen Anfragen an verfügbare Thread-Ausführungsressourcen umfasst. Die Ausführungsressourcen umfassen eine Array aus Grafikausführungseinheiten zur Verarbeitung der 3D- und Medienthreads. In einigen Ausführungsformen umfasst das 3D/Medienuntersystem 315 einen oder mehrere interne Caches für Threadanweisungen und Daten. In einigen Ausführungsformen umfasst das Untersystem außerdem einen geteilten Speicher, einschließlich Registern und adressierbarem Speicher, zum Teilen von Daten zwischen Threads und zum Speichern von Ausgangsdaten.
D/Medienverarbeitung
4 ist ein Blockdiagramm einer Grafikverarbeitungs-Engine 410 eines Grafikprozessors nach einigen Ausführungsformen. In einer Ausführungsform ist die GPE 410 eine Version der GPE 310 aus 3. Elemente aus 4, die dieselben Referenznummern (oder Namen) wie die Elemente jeder anderen Figur hierein aufweisen, können in einer Weise arbeiten oder funktionieren, die der anderswo hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen koppelt sich die GPE 410 mit einem Befehlsstreamer 403, der einen Befehlsstream an die GPE-3D- und Medienpipelines 412, 416 bereitstellt. In einigen Ausführungsformen ist der Befehls-Streamer 403 mit dem Speicher gekoppelt, der ein Systemspeicher oder ein interner Cachespeicher und/oder ein geteilter Cachespeicher sein kann. In einigen Ausführungsformen empfängt der Befehlsstreamer 403 Befehle aus dem Speicher und sendet die Befehle an die 3D-Pipeline 412 und/oder Medienpipeline 416. Die Befehle sind Anweisungen, die von einem Ringpuffer abgerufen werden, der Befehle für die 3D- und Medienpipelines 412, 416 speichert. In einer Ausführungsform kann der Ringpuffer weiterhin Batchbefehlspuffer enthalten, die Batches mehrerer Befehle speichern. Die 3D- und Medienpipelines 412, 416 verarbeiten die Befehle durch Ausführung von Funktionen über eine Logik innerhalb der jeweiligen Pipelines oder durch Versenden einer oder mehrerer Ausführungsthreads an eine Ausführungseinheiten-Array 414. In einigen Ausführungsformen ist die Ausführungseinheiten-Array 414 skalierbar, sodass die Array eine variable Anzahl von Ausführungseinheiten auf Grundlage der Zielenergie- und Leistungsebene der GPE 410 enthält.
In einigen Ausführungsformen koppelt sich eine Sampling-Engine 430 mit einem Speicher (z. B. Cachespeicher oder Systemspeicher) und der Ausführungseinheiten-Array 414. In einigen Ausführungsformen stellt die Sampling-Engine 430 einen Speicherzugriffsmechanismus für die Ausführungseinheiten-Array 414 bereit, die die Ausführung von Array 414 zum Lesen der Grafik- und Mediendaten vom Speicher erlaubt. In einigen Ausführungsformen umfasst die Sampling-Engine 430 eine Logik zum Ausführen spezialisierter Bildsamplingfunktionen für Medien.
In einigen Ausführungsformen umfasst die spezialisierte Mediensamplinglogik in der Sampling-Engine 430 ein Rauschunterdrückungs-/Deinterlacingmodul 432, ein Bewegungsschätzungsmodul 434 und ein Bildskalierungs- und Filtermodul 436. In einigen Ausführungsformen umfasst das Rauschunterdrückungs-/Deinterlacingmodul 432 eine Logik zur Ausführung einer oder mehrerer Rauschunterdrückungs- oder Deinterlacing-Algorithmen auf decodierte Videodaten. Die Deinterlacinglogik kombiniert abwechselnde Felder von interlaceten Videoinhalten in einen einzelnen Videorahmen. Die Rauschunterdrückungs-Logik verringert oder entfernt Datenrauschen aus den Video- und Bilddaten. In einigen Ausführungsformen sind die Rauschunterdrückungs-Logik und die Deinterlacing-Logik bewegungsadaptiv und verwenden räumliche oder temporale Filterung auf Grundlage der in den Videodaten erkannten Bewegungsmenge. In einigen Ausführungsformenumfasst das Rauschunterdrückungs-/Deinterlacingmodul 432 eine eigene Bewegungserkennungslogik (z. B. innerhalb der Bewegungsschätzungs-Engine 434).
In einigen Ausführungsformen stellt die Bewegungsschätzungs-Engine 434 eine Hardwarebeschleunigung für Videofunktionen bereit, indem sie Beschleunigungsfunktionen wie Bewegungsvektorschätzung und Vorhersage auf Videodateien anwendet. Die Bewegungsschätzungs-Engine bestimmt die Bewegungsvektoren, die die Transformation der Bilddaten zwischen aufeinanderfolgenden Videoframes beschreiben. In einigen Ausführungsformen verwendet ein Grafikprozessor-Mediencodec die Videobewegungsschätzungs-Engine 434 zur Ausführung von Funktionen auf ein Video auf Makroblockebene, die andernfalls zu rechenintensiv sein kann, um sie mit einem Prozessor für allgemeine Zwecke auszuführen. In einigen Ausführungsformen ist die Bewegungsschätzungs-Engine 434 allgemein für Grafikprozessor-Bestandteile verfügbar, um bei Decodierungs- und Verarbeitungsfunktionen von Videos zu helfen, die auf die Richtung oder Größe der Bewegung innerhalb der Videodateien reagieren oder sich daran anpassen.
In einigen Ausführungsformen führt das Bildskalierungs- und Filtermodul 436 Bildverarbeitungsfunktionen aus, um die visuelle Qualität der erzeugten Bilder und Videos zu verbessern. In einigen Ausführungsformen verarbeitet das Skalierungs- und Filtermodul 436 während der Samplingfunktion Bild- und Videodaten, bevor es die Daten an die Ausführungseinheiten-Array 414 bereitstellt.
In einigen Ausführungsformen umfasst die GPE 410 einen Datenport 444, der einen weiteren Mechanismus für Grafikuntersysteme bereitstellt, um auf den Speicher zuzugreifen. In einigen Ausführungsformen ermöglicht der Datenport 444 einen Speicherzugriff auf Funktionen, einschließlich Schreibvorgängen für Renderingsziele, ständiges Lesen eins Puffers, Lese-/Schreibvorgänge in Scratch-Speicher und Medienoberflächenzugriffe. In einigen Ausführungsformen umfasst der Datenport 444 Cachespeicherplatz um Zugriffe auf den Speicher zu cachen. Der Cachespeicher kann ein einziger Datencache sein oder in mehrere Caches für die mehreren Untersysteme aufgeteilt sein, die auf den Speicher über den Datenport zugreifen (z. B. ein Rendering-Puffercache, ein ständiger Puffercache usw.). In einigen Ausführungsformen kommunizieren Threads, die auf einer Ausführungseinheit in der Ausführungseinheiten-Array 414 aufgeführt werden, sich mit dem Datenport durch Austausch von Meldungen über eine Datenverteilungsverbindung, die jedes der Untersysteme der GPE 410 koppelt.
Ausführungseinheiten
5 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 500. Elemente aus 5, die dieselben Referenznummern (oder Namen) wie die Elemente jeder anderen Figur hierein aufweisen, können in einer Weise arbeiten oder funktionieren, die der anderswo hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen umfasst Grafikprozessor 500 eine Ringverbindung 502, ein Pipeline-Frontend 504, eine Medien-Engine 537 und Grafikkerne 580A bis 580N. In einigen Ausführungsformen koppelt die Ringverbindung 502 den Grafikprozessor mit anderen Verarbeitungseinheiten, einschließlich anderen Grafikprozessoren oder einem oder mehreren Prozessorkernen für allgemeine Zwecke. In einigen Ausführungsformen ist der Grafikprozessor einer von mehreren Prozessoren, die in ein Mehrkernverarbeitungssystem integriert sind.
In einigen Ausführungsformen empfängt der Grafikprozessor 500 Befehlsbatches über die Ringverbindung 502. Die eingehenden Befehle werden durch einen Befehlsstreamer 503 im Pipeline-Frontend 504 interpretiert. In einigen Ausführungsformen umfasst der Grafikprozessor 500 eine skalierbare Ausführungslogik zur Ausführung von 3D-Geometrieverarbeitung und Medienverarbeitung über den/die Grafikkern(e) 580A bis 580N. Für 3D-Geometrieverarbeitungsbefehle liefert der Befehlsstreamer 503 Befehle an die Geometriepipeline 536. Für mindestens einige Medienverarbeitungsbefehle liefert der Befehlsstreamer 503 die Befehle an ein Videofrontend 534, das sich mit einer Medien-Engine 537 koppelt. In einigen Ausführungsformen umfasst die Medien-Engine 537 eine Video Quality Engine (VQE) 530 für Video- und Bild-Nachverarbeitung und eine Multiformat-Codierungs-/Decodierungs- (MFX) 533 Engine, um die hardwarebeschleunigte Codierung und Decodierung von Mediendaten bereitzustellen. In einigen Ausführungsformen erzeugen die Geometriepipeline 536 und die Medien-Engine 537 jeweils Ausführungsthreads für die Thread-Ausführungsressourcen, die durch mindestens einen Grafikkern 580A bereitgestellt sind.
In einigen Ausführungsformen umfasst der Grafikprozessor 500 skalierbare Thread-Ausführungsressourcen mit modularen Kernen 580A bis 580N (gelegentlich bezeichnet als Kern-Slices), die jeweils mehrere Unterkerne 550A bis 550N, 560A bis 560N (gelegentlich als Kern-Unterslices bezeichnet) aufweisen. In einigen Ausführungsformen kann der Grafikprozessor 500 eine Reihe von Grafikkernen 580A bis 580N umfassen. In einigen Ausführungsformen umfasst der Grafikprozessor 500 einen Grafikkern 580A, der mindestens einen ersten Unterkern 550A und einen zweiten Kern-Unterkern 560A aufweist. In anderen Ausführungsformen ist der Grafikprozessor ein Prozessor mit niedriger Leistung und einem einzigen Unterkerb (z. B. 550A). In einigen Ausführungsformen umfasst der Grafikprozessor 500 umfasst mehrere Grafikkerne 580A bis 580N, von denen jeder einen Satz erster Unterkerne 550A bis 550N und einen Satz zweiter Unterkerne 560A bis 560N umfasst. Jeder Unterkern in dem Satz erster Unterkerne 550A bis 550N umfasst mindestens einen ersten Satz Ausführungseinheiten 552A bis 552N und Medien-/Textursampler 554A bis 554N. Jeder Unterkern in dem Satz zweiter Unterkerne 560A bis 560N umfasst mindestens einen zweiten Satz Ausführungseinheiten 562A bis 562N und Sampler 564A bis 564N. In einigen Ausführungsformen teilt jeder Unterkern 550A bis 550N, 560A bis 560N einen Satz geteilter Ressourcen 570A bis 570N. In einigen Ausführungsformen enthalten die geteilten Ressourcen geteilte Cachespeicher und eine Pixelausführungslogik. Andere geteilte Ressourcen können auch in den verschiedenen Ausführungsformen des Grafikprozessors enthalten sein.
6 illustriert eine Thread-Ausführungslogik 600, die eine Array mit Verarbeitungselementen enthält, die in einigen Ausführungsformen einer GPE eingesetzt wird. Elemente aus 6, die dieselben Referenznummern (oder Namen) wie die Elemente jeder anderen Figur hierein aufweisen, können in einer Weise arbeiten oder funktionieren, die der anderswo hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen umfasst die Thread-Ausführungslogik 600 einen Pixelshader 602, einen Threaddispatcher 604, einen Anweisungscache 606, eine skalierbare Ausführungseinheiten-Array einschließlich mehrerer Ausführungseinheiten 608A bis 608N, einen Sampler 610, einen Datencache 612 und einen Datenport 614. In einer Ausführungsform sind die enthaltenen Bestandteile über ein Verbindungsgewebe verbunden, das mit jedem der Bestandteile verlinkt ist. In einigen Ausführungsformen umfasst die Thread-Ausführungslogik 600 eine oder mehrere Verbindungen mit dem Speicher, wie etwa einem Systemspeicher oder Cachespeicher, durch ein oder mehrere der Elemente Anweisungscache 606, Datenport 614, Sampler 610 und Ausführungseinheiten-Array 608A bis 608N. In einigen Ausführungsformen ist jede Ausführungseinheit (z. B. 608A) ein einzelner Vektorprozessor, der in der Lage ist, mehrere simultane Threads auszuführen und mehrere Datenelemente für jeden Thread parallel zu verarbeiten. In einigen Ausführungsformen, umfasst die Ausführungseinheiten-Array 608A bis 608N eine Anzahl einzelner Ausführungseinheiten.
In einigen Ausführungsformen wird die Ausführungseinheiten-Array 608A bis 608N verwendet, um „Shader“-Programme auszuführen. In einigen Ausführungsformen führen die Ausführungseinheiten in Array 608A bis 608N einen Anweisungssatz aus, der native Unterstützung für viele Standard-3D-Grafikshader-Anweisungen umfasst, sodass Shaderprogramme von Grafikbibliotheken (z. B. Direct 3D und OpenGL) mit einer minimalen Übersetzung ausgeführt werden. Die Ausführungseinheiten unterstützen Vertex- und Geometrieverarbeitung (z. B. Vertexprogramme, Geometrieprogramme, Vertexshader), Pixelverarbeitung (z. B. Pixelshader, Fragmentshader) und Verarbeitung zu allgemeine Zwecken (z. B. Berechnungs- und Medienshader) .
Jede Ausführungseinheit in der Ausführungseinheiten-Array 608A bis 608N wirkt auf 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 zur Ausführung für Datenelementzugriff, Maskierung und Flusskontrolle innerhalb der Anweisungen. Die Anzahl der Kanäle kann unabhängig von der Anzahl physischer arithmetischer Logikeinheiten (ALUs) oder Fließkommaeinheiten (FPUs) für einen bestimmten Grafikprozessor sein. In einigen Ausführungsformen unterstützen die Ausführungseinheiten 608A bis 608N ganzzahlige und Fließkomma-Datentypen.
Der Anweisungssatz der Ausführungseinheit umfasst „Single Instruction Multiple Data“- (SI MD) oder „Single Instruction Multiple Thread“- (SIMT) Anweisungen. Die verschiedenen Datenelemente können als gepackter Datentyp in einem Register gespeichert werden und die Ausführungseinheit verarbeitet die verschiedenen Elemente basierend auf der Datengröße der Elemente. Beispielsweise werden bei der Verwendung auf einem 256 Bit breiten Vektor die 256 Bits des Vektors in einem Register gespeichert und die Ausführungseinheit arbeitet auf dem Vektor in Form von vier separaten 64-Bit-gepackten Datenelementen (Quad-Word -(QW) Größendatenelemente), acht separaten 32-Bit-gepackten Datenelementen (Double Word- (DW) Größendatenelemente), sechzehn separaten 16-Bit-gepackten Datenelementen (Word- (W) Größendatenelemente) oder zweiunddreißig separaten 8-Bit Datenelementen (Byte- (B) Größendatenelemente). Verschiedene Vektorbereiten und Registergrößen sind jedoch möglich.
Ein oder mehrere interne Anweisungscaches (z. B. 606) sind in der Thread-Ausführungslogik 600 enthalten, um Threadanweisungen für die Ausführungseinheiten zu cachen. In einigen Ausführungsformen sind ein oder mehrere Datencaches (z. B. 612) eingeschlossen, um Threaddaten während der Threadausführung zu cachen. In einigen Ausführungsformen ist der Sampler 610 eingeschlossen, um das Textursampling für 3D-Funktionen und Mediensampling für Medienfunktionen bereitzustellen. In einigen Ausführungsformen umfasst der Sampler 610 eine spezialisierte Textur- oder Mediensampling-Funktion zum Verarbeitung von Textur- oder Mediendaten während des Samplingablaufs vor dem Bereitstellen der gesampelten Daten an eine Ausführungseinheit.
Während der Ausführung senden die Grafik- und Medienpipelines Threadeinleitungsanfragen an die Thread-Ausführungslogik 600 über die Threadspawning und Versandlogik. In einigen Ausführungsformen umfasst die Thread-Ausführungslogik 600 einen örtlichen Thread-Versender 604, der die Thread-Einleitungsanfragen von den Grafik- und Medienpipelines vermittelt und die angeforderten Threads auf der einen oder den mehreren Ausführungseinheiten 608A bis 608N einsetzt. Beispielsweise versendet die Geometriepipeline (z. B. 536 von 5) Vertex-Verarbeitungs-, Tessellierungs- oder Geometrieverarbeitungsthreads an die Thread-Ausführungslogik 600 (6). In einigen Ausführungsformen kann der Thread-Versender 604 auch Runtime-Threadspawninganfragen aus den ausführenden Shaderprogrammen verarbeiten.
Wenn eine Gruppe geometrischer Objekte verarbeitet und in Pixeldaten rasterisiert wurde, wird der Pixelshader 602 aufgerufen, um ferner Ausgabeinformationen zu berechnen und Ergebnisse auf Ausgabeflächen schreiben zu lassen (z. B. Farbpuffer, Tiefenpuffer, Schablonenpuffer usw.). In einigen Ausführungsformen berechnet der Pixelshader 602 die Werte der verschiedenen Vertex-Attribute, die über das rasterisierte Objekt interpoliert werden sollen. In einigen Ausführungsformen führt der Pixelshader 602 dann ein von einer Anwendungsprogrammierungsschnittstelle (API) bereitgestelltes Pixelshaderprogramm aus. Um das Pixelshaderprogramm auszuführen, versendet der Pixelshader 602 Threads über den Thread-Versender 604 an eine Ausführungseinheit (z. B. 608A). In einigen Ausführungsformen verwendet der Pixelshader 602 eine Texturesamplinglogik im Sampler 610 für Zugriff auf Texturdaten in Texturkarten, die im Speicher gespeichert sind. Arithmetische Funktionen auf Texturdaten und Eingabegeometriedaten berechnen Pixelfarbdaten für jedes geometrische Fragment oder verwerfen ein oder mehrere Pixel aus der weiteren Verarbeitung.
In einigen Ausführungsformen stellt der Datenport 614 einen Speicherzugriffsmechanismus für die durch die Thread-Ausführungslogik 600 verarbeiteten Daten an den Speicher zur Verarbeitung auf einer Grafikprozessorausgabepipeline bereit. In einigen Ausführungsformen umfasst oder koppelt der Datenport 614 einen oder mehrere Cachespeicher (z. B. Datencache 612) mit den Cachedaten für Speicherzugriff über den Datenport.
7 ist ein Blockdiagramm, das Grafikprozessoranweisungsformate 700 nach einigen Ausführungsformen illustriert. In einer oder mehreren Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten einen Anweisungssatz, der Anweisungen in mehreren Formaten aufweist. Die Kästen mit durchgezogenen Linien illustrieren die Bestandteile, die allgemein in einer Ausführungseinheiten-Anweisung enthalten sind, während die gestrichelten Linien Bestandteilen enthalten, die optional sind oder die nur in einem Untersatz von Anweisungen enthalten sind. In einigen Ausführungsformen sind das beschriebene und illustrierte Anweisungsformat 700 Makroanweisungen, wobei im Gegensatz zu Mikrofunktionen, die aus der Decodierung von Anweisungen entstehen, wenn die Anweisung verarbeitet wird, Anweisungen sind, die an die Ausführungseinheit geliefert werden.
In einigen Ausführungsformen unterstützen die Grafikprozessor-Ausführungseinheiten nativ Anweisungen in einem 128-Bit-Anweisungsformat 710. Ein 64-bit verdichtetes Anweisungsformat 730 ist für einige Anweisungen auf Grundlage der gewählten Anweisung, Anweisungsoptionen und Anzahl Operanden verfügbar. Das native 128-Bit-Anweisungsformat 710 stellt einen Zugriff auf alle Anweisungsoptionen bereit, während einige Optionen und Funktionen im 64-Bit-Anweisungsformat 730 eingeschränkt sind. Die nativen Anweisungen, die im 64-Bit-Anweisungsformat 730 bereitstehen, variieren je nach Ausführungsform. In einigen Ausführungsformen ist die Anweisung teilweise unter Verwendung eines Satzes von Indexwerten in einem Indexfeld 713 verdichtet. Die Ausführungseinheiten-Hardware verweist auf einen Satz Verdichtungstabellen auf Grundlage der Indexwerte und verwendet die Verdichtungstabellenausgaben zur Rekonstruktion einer nativen Anweisung in dem 128-bit-Anweisungsformat 710.
Für jedes Format definiert der Anweisungs-Opcode 712 die Funktion, die die Ausführungseinheit ausführen soll. Die Ausführungseinheiten führen jede Anweisung parallel über die mehreren Datenelemente jedes Operanden hinweg aus. Beispielsweise führt die Ausführungseinheit in Reaktion auf eine Addierungsanweisung eine simultane Addierungsfunktion über jeden Farbkanal hinweg, der ein Texturelement oder Bildelement darstellt, aus. Standardmäßig führt die Ausführungseinheit jede Anweisung über alle Datenkanäle der Operanden hinweg aus. In einigen Ausführungsformen ermöglicht das Anweisungskontrollfeld 714 die Kontrolle über bestimmte Ausführungsoptionen, wie etwa die Kanalauswahl (z. B. Vorhersage) und Datenkanalreihenfolge (z. B. Swizzle). Für 128-Bit-Anweisungen 710 begrenzt ein Exec-Größenfeld 716 die Anzahl Datenkanäle, die parallel ausgeführt werden. In einigen Ausführungsformen steht das Exec-Größenfeld 716 nicht zur Verwendung im 64-Bit-Kompaktanweisungsformat 730 bereit.
Einige Ausführungseinheitenanweisungen haben bis zu drei Operanden, einschließlich zwei Quelloperanden, src0 720, src1 722, und ein Ziel 718. In einigen Ausführungsformen unterstützen die Ausführungseinheiten duale Zielanweisungen, wobei eines der Ziele impliziert ist. Datenmanipulierungsanweisungen können einen dritten Quelloperanden (z. B. SRC2 724) aufweisen, wo der Anweisungs-Opcode 712 die Anzahl der Quelloperanden bestimmt. Der letzte Quelloperand einer Anweisung kann ein sofortiger (z. B. hartcodierte) Wert sein, der mit den Anweisungen weitergegeben wird.
In einigen Ausführungsformen, das 128-bit Anweisungsformat 710 umfasst eine Zugriffs-/Adressmodusinformation 726, die beispielsweise vorgibt, ob ein direkter Registeradressierungsmodus oder ein indirekter Registeradressierungsmodus verwendet wird. Wenn ein Direktregister-Adressierungsmodus verwendet wird, wird die Registeradresse des einen oder der mehreren Operanden direkt durch Bits in der Anweisung 710 bereitgestellt.
In einigen Ausführungsformen umfasst das 128-Bit-Anweisungsformat 710 ein Zugriffs-/Adressmodusfeld 726, das einen Adressmodus und/oder einen Zugriffsmodus für die Anweisung vorgibt. In einer Ausführungsform der Zugriffsmodus zur Definition einer Datenzugriffsausrichtung für die Anweisung. Einige Ausführungsformen unterstützen Zugriffsmodi, einschließlich eines 16-Byte ausgerichteten Zugriffsmodus und eines 1-Byte ausgerichteten Zugriffsmodus, wobei die Byteausrichtung des Zugriffsmodus die Zugriffsausrichtung der Anweisungsoperanden bestimmt. Beispielsweise kann die Anweisung 710 in einem ersten Modus eine byteausgerichtete Adressierung für Quell- und Zieloperanden verwenden und in einem zweiten Modus die Anweisung 710 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 indirekte Adressierung verwendet. Wenn der direkte Registeradressierungsmodus verwendet wird, stellen die Bits in der Anweisung 710 direkt die Registeradresse des einen oder der mehreren Operanden bereit. Wenn der indirekte Registeradressierungsmodus verwendet wird, kann die Registeradresse eines oder mehrerer Operanden basierend auf einem Adressregisterwert und einem direkten Adressfeld in der Anweisung berechnet werden.
In einigen Ausführungsformen sind die Anweisungen auf Grundlage von Opcode 712-Bit-Feldern gruppiert, um die Opcode-Decodierung 740 zu vereinfachen. Für einen 8-Bit-Opcode erlauben die Bits 4, 5 und 6 der Ausführungseinheit die Bestimmung der Art des Opcode. Die spezielle dargestellte Opcode-Gruppierung ist nur ein Beispiel. In einigen Ausführungsformen umfasst eine Bewegungs- und Logik-Opcodegruppe 742 Datenbewegungs- und Logikanweisungen (z. B. bewegen (mov), vergleichen (cmp)). In einigen Ausführungsformen teilt die Bewegungs- und Logikgruppe 742 die fünf wichtigsten Bits (MSB), wobei Bewegungs- (mov) Anweisungen die Form von 0000xxxxb und Logikanweisungen die Form von 0001xxxxb annehmen. Eine Gruppe 744 Flusskontrollanweisungen (z. B. Aufrufen, Sprung (jmp)) umfasst Anweisungen in Form von 0010xxxxb (z. B. 0x20). eine Gruppe 746 verschiedener Anweisungen umfasst eine Mischung aus Anweisungen, einschließlich Synchronisierungsanweisungen (z. B. Warten, Senden) in Form von 0011xxxxb (z. B. 0x30). Eine Gruppe 748 paralleler Rechenanweisungen enthält bauteilspezifische arithmetische Anweisungen (z. B. Addieren, Multiplizieren (mul)) in Form von 0100xxxxb (z. B. 0x40). Die Gruppe 748 paralleler Rechnungen führt die arithmetischen Operationen parallel über die Datenkanäle hinweg aus. Die Vektorrechnungsgruppe 750 umfasst arithmetische Anweisungen (z. B. dp4) in Form von 0101xxxxb (z. B. 0x50). Die Vektorrechnungsgruppe führt arithmetische Anweisungen wie Punktproduktrechnungen auf Vektoroperanden aus.
Grafik-Pipeline
8 ist ein Blockdiagramm einer anderen Ausführungsform eines Grafikprozessors 800. Elemente aus 8, die dieselben Referenznummern (oder Namen) wie die Elemente jeder anderen Figur hierein aufweisen, können in einer Weise arbeiten oder funktionieren, die der anderswo hierin beschriebenen ähnlich ist, sind jedoch nicht darauf beschränkt.
In einigen Ausführungsformen umfasst der Grafikprozessor 800 eine Grafikpipeline 820, eine Medienpipeline 830, eine Anzeige-Engine 840, eine Thread-Ausführungslogik 850, und eine Render-Ausgabepipeline 870. In einigen Ausführungsformen ist der Grafikprozessor 800 ein Grafikprozessor innerhalb eines Mehrkernverarbeitungssystems, das eine oder mehrere Prozessorkerne zu allgemeinem Zweck umfasst. Der Grafikprozessor wird durch Registerschreibvorgänge auf ein oder mehrere Steuerregister (nicht dargestellt) oder über Befehle, die über eine Ringverbindung 802 an den Grafikprozessor 800 ausgegeben werden, gesteuert. In einigen Ausführungsformen koppelt die Ringverbindung 802 den Grafikprozessor 800 mit anderen Verarbeitungsbestandteilen, wie etwa mit anderen Grafikprozessoren oder Prozessoren für allgemeine Zwecke. Befehle von der Ringverbindung 802 werden durch einen Befehlsstreamer 803 interpretiert, der Anweisungen für einzelne Bestandteile der Grafikpipeline 820 oder Medienpipeline 830 bereitstellt.
In einigen Ausführungsformen weist der Befehlsstreamer 803 die Funktion eines Vertex-Fetchers 805 an, der Vertexdaten vom Speicher ausliest und Vertex-Verarbeitungsbefehle ausführt, die durch den Befehlsstreamer 803 bereitgestellt werden. In einigen Ausführungsformen stellt der Vertex-Fetcher 805 Vertexdaten an einen Vertexshader 807 bereit, der Koordinatenraumtransformations- und Beleuchtungsfunktionen für jeden Vertex ausführt. In einigen Ausführungsformen führen der Vertex-Fetcher 805 und Vertexshader 807 Vertex-Verarbeitungsanweisungen aus, indem sie über einen Thread-Versender 831 Ausführungsthreads an Ausführungseinheiten 852A, 852B senden.
In einigen Ausführungsformen sind die Ausführungseinheiten 852A, 852B Array Vektorprozessoren, die einen Anweisungssatz für die Ausführung von Grafik- und Medienfunktionen aufweisen. In einigen Ausführungsformen haben die Ausführungseinheiten 852A, 852B einen angehängten L1-Cache 851, der spezifisch für jede Array oder zwischen den Arrays geteilt ist. Der Cache kann als Datencache, Anweisungscache oder einzelner Cache konfiguriert sein, der partitioniert ist, um Daten und Anweisungen in unterschiedlichen Partitionen zu enthalten.
In einigen Ausführungsformen umfasst die Grafikpipeline 820 Tessellierungsbestandteile zur Ausführung von hardwarebeschleunigter Tessellierung von 3D-Objekten. In einigen Ausführungsformen konfiguriert ein programmierbarer Hüllenshader 811 die Tessellierungsfunktionen. Ein programmierbarer Domainshader 817 stellt eine Backend-Bewertung der Tessellierungsausgabe bereit. Ein Tessellierer 813 arbeitet auf Anweisung eines Hüllenshaders 811 und enthält eine Logik für einen speziellen Zweck zum Erzeugen eines Satzes detaillierter geometrischer Objekte basierend auf einem groben geometrischen Modell, das als Eingabe für die Grafikpipeline 820 bereitgestellt ist. In einigen Ausführungsformen können die Tessellierungsbestandteile 811, 813, 817 umgangen werden, wenn die Tessellierung nicht verwendet wird.
In einigen Ausführungsformen könne die vollständigen geometrischen Objekte durch einen Geometrieshader 819 über einen oder mehrere Threads verarbeitet werden, die an die Ausführungseinheiten 852A, 852B gesendet werden, oder direkt mit dem Clipper 829 fortfahren. In einigen Ausführungsformen wirkt der Geometrieshader auf die gesamten geometrischen Objekte, statt auf Vertizes oder Vertexpatches wie in den vorherigen Stufen der Grafikpipeline. Wenn die Tessellierung deaktiviert ist, empfängt der Geometrieshader 819 Eingaben von dem Vertexshader 807. In einigen Ausführungsformen ist der Geometrieshader 819 durch ein Geometrieshaderprogramm programmierbar, um die Geometrietessellierung auszuführen, wenn die Tessellierungseinheiten deaktiviert sind.
Vor der Rasterisierung verarbeitet ein Clipper 829 die Vertexdaten. Der Clipper 829 kann ein Clipper mit einer festen Funktion oder ein programmierbarer Clipper mit Clipping- und Geometrieshaderfunktionen sein. In einigen Ausführungsformen setzen ein Rasterisierer und ein Tiefentestbestandteil 873 in der Renderingausgabepipeline 870 Pixelshader zum Umwandeln der geometrischen Objekte in die Darstellungen pro Pixel ein. In einigen Ausführungsformen ist die Pixelshaderlogik in der Thread-Ausführungslogik 850 enthalten. In einigen Ausführungsformen kann eine Anwendung den Rasterisierer 873 umgehen und auf nicht rasterisierte Vertexdaten über eine Stream-Out-Einheit 823 zugreifen.
Der Grafikprozessor 800 hat einen Verbindungsbus, ein Verbindungsgewebe oder einen anderen Verbindungsmechanismus, der die Übermittlung von Daten und Meldungen unter den wichtigen Bestandteilen des Prozessors zu ermöglicht. In einigen Ausführungsformen verbinden sich die Ausführungseinheiten 852A, 852B und der/die verbundenen Cache(s) 851, Textur- und Mediensampler 854 und der Textur-/Samplercache 858 über einen Datenport 856, um den Speicherzugriff auszuführen mit den Bestandteilen des Prozessors für die Renderingausgabepipeline zu kommunizieren. In einigen Ausführungsformen haben der Sampler 854, die Caches 851, 858 und die Ausführungseinheiten 852A, 852B jeweils eigene Speicherzugriffswege.
In einigen Ausführungsformen enthält die Renderingausgabepipeline 870 eine Tiefentestkomponente und einen Rasterisierer 873, die vertexbasierte Objekte in eine entsprechende pixelbasierte Darstellung umwandeln. In einigen Ausführungsformen enthält die Renderingausgabepipeline 870 eine Fenster-/Maskierungseinheit zur Durchführung einer Dreiecks- und Linienrasterisierung mit fester Funktion. Ein entsprechender Rendercache 878 und Tiefencache 879 sind in einigen Ausführungsformen ebenfalls verfügbar. Eine Pixelfunktionskomponente 877 führt pixelbasierte Funktionen auf die Daten aus, wobei jedoch in einigen Fällen Pixelfunktionen, die mit 2D-Funktionen verbunden sind (z. B. Bitblock-Bildübertragungen mit Blending), durch die 2D-Engine 841 ausgeführt oder zum Anzeigezeitpunkt durch den Anzeigecontroller 843 unter Verwendung von Overlayanzeigeebenen ersetzt werden. In einigen Ausführungsformen steht ein geteilter L3-Cache 875 für alle Grafikbestandteile bereit, was das Teilen der Daten ohne Verwendung des Hauptsystemspeichers ermöglicht.
In einigen Ausführungsformen umfasst die Grafikprozessor-Medienpipeline 830 eine Medien-Engine 837 und ein Videofrontend 834. In einigen Ausführungsformen empfängt das Videofrontend 834 Pipelinebefehle von dem Befehlsstreamer 803. In einigen Ausführungsformen umfasst die Medienpipeline 830 einen separaten Befehlsstreamer. In einigen Ausführungsformen verarbeitet das Videofrontend 834 Medienbefehle vor dem Versand des Befehls an die Medien-Engine 837. In einigen Ausführungsformen enthält die Medien-Engine 837 eine Threadspawning-Funktion, die Threads für den Versand an die Thread-Ausführungslogik 850 über den Thread-Versender 831 spawnt.
In einigen Ausführungsformen umfasst der Grafikprozessor 800 eine Anzeige-Engine 840. In einigen Ausführungsformen ist die Anzeige-Engine 840 von dem Prozessor 800 getrennt und koppelt sich mit dem Grafikprozessor über die Ringverbindung 802, oder einen anderen Verbindungsbus oder ein Verbindungsgewebe. In einigen Ausführungsformen umfasst die Anzeige-Engine 840 eine 2D-Engine 841 und einen Anzeigecontroller 843. In einigen Ausführungsformen enthält die Anzeige-Engine 840 eine Logik für einen speziellen Zweck, die in der Lage ist, unabhängig von der 3D-Pipeline zu funktionieren. In einigen Ausführungsformen koppelt sich der Anzeigecontroller 843 mit einer Anzeigevorrichtung (nicht dargestellt), die eine in ein System, wie etwa in einem Laptopcomputer, integrierte Anzeigevorrichtung oder eine extern Anzeigevorrichtung, die über einen Anzeigevorrichtungsanschluss verbunden ist, sein kann.
In einigen Ausführungsformen sind die Grafikpipeline 820 und die Medienpipeline 830 konfigurierbar, Funktionen auf Grundlage mehrerer Grafik- und Medienprogrammierungsschnittstellen auszuführen und nicht spezifisch für eine Anwendungsprogrammierschnittstelle (API). In einigen Ausführungsformen übersetzt die Treibersoftware für den Grafikprozessor API-Aufrufe, die spezifisch für eine bestimmte Grafik- oder Medienbibliothek sind, in Befehle, die durch den Grafikprozessor verarbeitet werden können. In einigen Ausführungsformen wird Unterstützung für die Open Graphics Library (OpenGL) und Open Computing Language (OpenCL) der Khronos Group, die Direct3D-Bibliothek der Microsoft Corporation bereitgestellt, es kann eine Unterstützung für OpenGL und D3D gleichermaßen bereitgestellt werden. Außerdem kann eine Unterstützung für die Open Source Computer Vision Library (OpenCV) bereitgestellt werden. Eine künftige API mit einer kompatiblen 3D-Pipeline würde außerdem unterstützt, wenn eine Zuordnung von der Pipeline einer künftigen API zur Pipeline des Grafikprozessor möglich ist.
Grafik-Pipelineprogrammierung
9A ist ein Blockdiagramm, das ein Grafikprozessorbefehlsformat 900 nach einigen Ausführungsformen illustriert. 9B ist ein Blockdiagramm, das eine Grafikprozessorbefehlssequenz 910 nach einer Ausführungsform illustriert. Die Kästen mit durchgezogenen Linien in 9A illustrieren die Bestandteile, die allgemein in einem Grafikbefehl enthalten sind, während die gestrichelten Linien Bestandteile enthalten, die optional sind oder die nur in einem Untersatz von Grafikbefehlen enthalten sind. Das beispielhafte Grafikprozessor-Befehlsformat 900 der 9A umfasst Datenfelder zur Identifizierung eines Zielclient 902 eines Befehls, eines Befehlsoperationscodes (Opcode) 904, und der relevanten Daten 906 für den Befehl. Ein Unter-Opcode 905 und eine Befehlsgröße 908 sind ebenfalls in einigen Befehlen enthalten. In einigen Ausführungsformen spezifiziert der Client 902 die Clienteinheit der Grafikvorrichtung, die die Befehlsdaten verarbeitet. In einigen Ausführungsformen untersucht ein Grafikprozessor-Befehlsparser das Client-Feld jedes Befehls zur Festlegung der Bedingungen für die weitere Verarbeitung des Befehls und Weiterleitung der Befehlsdaten an die entsprechend Clienteinheit. In einigen Ausführungsformen umfassen die Grafikprozessor-Clienteinheiten eine Speicherschnittstelleneinheit, eine Rendereinheit, eine 2D-Einheit, eine 3D-Einheit und eine Medieneinheit. Jede Clienteinheit weist eine entsprechende Verarbeitungspipeline auf, die die Befehle verarbeitet. Wenn der Befehl durch die Clienteinheit empfangen wird, liest die Clienteinheit den Opcode 904 und, wenn vorhanden, den Unter-Opcode 905 aus, um die auszuführende Operation zu bestimmen. Die Clienteinheit führt den Befehl unter Verwendung von Informationen im Datenfeld 906 aus. Für einige Befehle wird eine ausdrückliche Befehlsgröße 908 erwartet, um die Größe des Befehls anzugeben. In einigen Ausführungsformen bestimmt der Befehlsparser automatisch die Größe von mindestens einigen der Befehle auf Grundlage des Befehls-Opcodes. In einigen Ausführungsformen werden die Befehle über Mehrfache eines Doppelworts ausgerichtet.
Das Ablaufdiagramm in 9B zeigt einen beispielhaften Grafikprozessor-Befehlsablauf 910. In einigen Ausführungsformen verwendet die Software oder Firmware eines Datenverarbeitungssystems, das eine Ausführungsform eines Grafikprozessors besitzt, eine Version des Befehlsablaufs, der dargestellt ist, zum Einrichten, Ausführen und Beenden eines Satzes Grafikfunktionen. Ein Beispielbefehlsablauf ist ausschließlich zu Beispielzwecken darstellt und beschrieben, da die Ausführungsformen nicht auf diese spezifischen Befehle oder auf diesen Befehlsablauf beschränkt sind. Weiterhin können die Befehle als Befehlsbatch in einem Befehlsablauf ausgegeben werden, sodass der Grafikprozessor die Befehlssequenz in mindestens teilweiser Übereinstimmung ausführen kann.
In einigen Ausführungsformen kann der Grafikprozessor-Befehlsablauf 910 mit einem Befehl 912 zum Leeren der Pipeline beginnen, um eine aktive Grafikpipeline zu veranlassen, die aktuell ausstehenden Befehle für die Pipeline auszuführen. In einigen Ausführungsformen funktionieren die 3D-Pipeline 922 und die Medienpipeline 924 nicht gleichzeitig. Die Pipelineleerung erfolgt, um die aktiven Grafikpipeline zu veranlassen, ausstehende Befehle abzuschließen. In Reaktion auf das Leeren einer Pipeline pausiert der Befehlsparser für den Grafikprozessor die Befehlsverarbeitung, bis die aktiven Zeichnungs-Engines ausstehende Funktionen abschließen und die relevanten Lesefunktions-Caches ungültig werden. Optional können Daten in dem Rendercache, der als „unsauber“ markiert ist, in den Speicher geleert werden. In einigen Ausführungsformen kann der Befehl 912 zum Leeren der Pipeline zur Synchronisierung der Pipeline oder vor dem Schalten des Grafikprozessors in einen Zustand mit geringer Leistung verwendet werden.
In einigen Ausführungsformen wird ein Befehl 913 zur Auswahl der Pipeline verwendet, wenn ein Befehlsablauf verlangt, dass der Grafikprozessor ausdrücklich zwischen Pipelines umschaltet. In einigen Ausführungsformen ist ein Befehl 913 zur Auswahl der Pipeline nur einmal innerhalb eines Ausführungszusammenhangs erforderlich, bevor Pipelinebefehle ausgegeben werden, sofern der Kontext nicht die Ausgabe von Befehlen für beide Pipelines ist. In einigen Ausführungsformen ist ein Befehl ist 912 zum Leeren der Pipeline direkt vor dem Umschalten der Pipelines über den Befehl 913 zur Auswahl der Pipeline erforderlich.
In einigen Ausführungsformen konfiguriert ein Befehl 914 zum Steuern der Pipeline eine Grafikpipeline für den Betrieb und wird verwendet, um die 3D-Pipeline 922 und die Medienpipeline 924 zu programmieren. In einigen Ausführungsformen konfiguriert der Befehl 914 zum Steuern der Pipeline den Pipeline-Zustand für die aktive Pipeline. In einer Ausführungsform wird der Befehl 914 zum Steuern der Pipeline zur Pipelinesynchronisierung und zum Löschen von Daten aus einem oder mehreren Cachespeichern innerhalb der aktiven Pipeline verwendet, bevor ein Befehlsbatch verarbeitet wird.
In einigen Ausführungsformen werden Befehle für den Rücklaufpufferzustand 916 verwendet, um einen Satz Rücklaufpuffer für die jeweiligen Pipelines zum Schreiben von Daten einzustellen. Einige Pipelineoperationen verlangen die Zuweisung, Auswahl oder Konfiguration von einem oder mehreren Rücklaufpuffern, in die die Operationen bei der Verarbeitung Zwischendaten schreiben. In einigen Ausführungsformen verwendet der Grafikprozessor außerdem einen oder mehrere Rücklaufpuffer zum Speichern von Ausgabedaten und Ausführen von threadübergreifender Kommunikation. In einigen Ausführungsformen enthält die Konfigurierung des Rücklaufpufferzustands 916 die Auswahl der Größe und Anzahl der Rücklaufpuffer zur Verwendung für einen Satz Pipelineoperationen.
Die verbleibenden Befehle in dem Befehlsablauf unterscheiden sich je nach aktiver Pipeline für Funktionen. Auf Grundlage einer Pipelinebestimmung 920 ist der Befehlsablauf auf die 3D-Pipeline 922 zugeschnitten, beginnend mit dem 3D Pipeline-Zustand 930, oder auf die Medienpipeline 924, beginnend mit dem Medienpipeline-Zustand 940.
Die Befehle für den 3D Pipeline-Zustand 930 umfassen 3D-Zustandseinstellbefehle für den Vertex-Pufferzustand, den Vertex-Elementzustand, den konstanten Farbzustand, den Tiefenpuffer-Zustand und andere Zustandsvariablen, die vor der Verarbeitung 3D-Primitivbefehle konfiguriert werden sollen. Die Werte dieser Befehle werden mindestens teilweise basierend auf der jeweils verwendeten 3D API berechnet. In einigen Ausführungsformen können die Befehle für den 3D-Pipeline-Zustand 930 auch in der Lage sein, bestimmte Pipelineelemente selektiv zu deaktivieren oder zu umgehen, wenn diese Elemente nicht verwendet werden.
In einigen Ausführungsformen wird der Befehl für die 3D-Primitive 932 verwendet, um 3D-Primitive zur Verarbeitung durch die 3D-Pipeline zu übermitteln. Befehle und entsprechende Parameter, die über den Befehl für 3D-Primitive 932 an den Grafikprozessor weitergegeben werden, werden an die Vertex-Fetch-Funktion in der Grafikpipeline weitergeleitet. Die Vertex-Fetch-Funktion verwendet die Befehlsdaten für die 3D-Primitive 932 zur Erzeugung von Vertexdatenstrukturen. Die Vertexdatenstrukturen werden in einem oder mehreren Rücklaufpuffern gespeichert. In einigen Ausführungsformen wird der Befehl für die 3D-Primitive 932 verwendet, um Vertexfunktionen auf 3D-Primitive über den Vertexshader auszuführen. Um den Vertexshader zu verarbeiten, versendet die 3D-Pipeline 922 Shaderausführungsthreads an die Grafikprozessorausführungseinheiten.
In einigen Ausführungsformen wird die 3D-Pipeline 922 über einen Befehl zur Ausführung 934 oder ein Ereignis ausgelöst. In einigen Ausführungsformen löst ein Schreibvorgang im Register die Ausführung des Befehls aus. In einigen Ausführungsformen wird die Ausführung über einen ‚Go‘ - oder ‚Kick‘-Befehl im Befehlsablauf ausgelöst. In einer Ausführungsform wird die Befehlsausführung unter Verwendung eines Pipelinesynchronisierungsbefehls ausgelöst, um den Befehlsablauf durch die Grafikpipeline zu löschen. Die 3D-Pipeline führt eine Geometrieverarbeitung für 3D-Primitive aus. Wenn die Funktionen abgeschlossen sind, werden die daraus entstehenden geometrischen Objekte rasterisiert und die Pixel-Engine färbt die daraus entstehenden Pixel ein. Weitere Befehle zur Steuerung der Pixelfärbung und Pixel-Backend-Funktionen können für diese Funktionen ebenfalls enthalten sein.
In einigen Ausführungsformen folgt der Grafikprozessor-Befehlsablauf 910 dem Pfad der Medienpipeline 924 bei der Durchführung der Medienfunktionen. Allgemein hängt die spezifische Benetzung und Art der Programmierung für die Medienpipeline 924 von den auszuführenden Medien oder Berechnungsfunktionen ab. Spezifische Mediendecodierungsfunktionen können während der Decodierung der Medien auf die Medienpipeline entladen werden. In einigen Ausführungsformen kann die Medienpipeline auch umgangen und die Mediendecodierung ganz oder teilweise unter Verwendung von Ressourcen ausgeführt werden, die durch eine oder mehrere Prozessorkerne zu allgemeinen Zwecken bereitgestellt werden. In einer Ausführungsformumfasst die Medienpipeline auch Elemente für Funktionen einer Grafikprozessoreinheit für allgemeine Zwecke (GPGPU), wobei der Grafikprozessor verwendet wird, um SIMD-Vektorfunktionen mit Rechnershaderprogrammen auszuführen, die nicht ausdrücklich mit dem Rendern von Grafikprimitiven verbunden sind.
In einigen Ausführungsformen ist die Medienpipeline 924 in einer ähnlichen Weise konfiguriert, wie die 3D-Pipeline 922. Ein Satz Befehle zum Konfigurieren des Medienpipeline-Zustands 940 wird versendet oder in eine Befehlswarteschlange vor den Medienobjektbefehlen 942 eingestellt. In einigen Ausführungsformen enthalten die Befehle für den Medienpipeline-Zustand 940 Daten zum Konfigurieren der Medienpipeline-Elemente, die verwendet werden, um die Medienobjekte zu verarbeiten. Dies umfasst Daten zur Konfiguration der Videodecodierung und Videocodierungslogik innerhalb der Medienpipeline, wie etwa dem Codierungs- oder Decodierungsformat. In einigen Ausführungsformen unterstützen Befehle für den Medienpipeline-Zustand 940 auch die Verwendung eines oder mehrerer Pointer auf Elemente im „indirekten“ Zustand, die einen Batch von Zustandseinstellungen enthalten.
In einigen Ausführungsformen liefern Medienobjektbefehle 942 Pointer auf Medienobjekte zur Verarbeitung durch die Medienpipeline. Die Medienobjekte umfassen Speicherpuffer, die Videodaten enthalten, die Verarbeitet werden sollen. In einigen Ausführungsformen müssen alle Medienpipelinezustände gültig sein, bevor ein Medienobjektbefehl 942 ausgegeben wird. Wenn der Pipeline-Zustand konfiguriert ist und die Medienobjektbefehle 942 in die Warteschlange eingereiht sind, wird die Medienpipeline 924 über einen Ausführungsbefehl 944 oder ein entsprechendes Ausführungsereignis ausgeführt (z. B. Registerschreibvorgang). Die Ausgabe aus der Medienpipeline 924 kann dann durch Funktionen nachbearbeitet werden, die durch die 3D-Pipeline 922 oder die Medienpipeline 924 bereitgestellt werden. In einigen Ausführungsformen sind GPGPU-Funktionen in ähnlicher Weise wie Medienfunktionen konfiguriert und ausgeführt.
Grafiksoftwarearchitektur
10 illustriert eine beispielhafte Grafiksoftwarearchitektur für ein Datenverarbeitungssystem 1000 nach einigen Ausführungsformen. In einigen Ausführungsformen umfasst die Softwarearchitektur eine 3D-Grafikanwendung 1010, ein Betriebssystem 1020 und mindestens einen Prozessor 1030. In einigen Ausführungsformen umfasst der Prozessor 1030 einen Grafikprozessor 1032 und einen oder mehrere Prozessorkern(e) 1034 mit allgemeinem Zweck. Die Grafikanwendung 1010 und das Betriebssystem 1020 führen jeweils im Systemspeicher 1050 des Datenverarbeitungssystems aus.
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 High-Level-Shadersprache geschrieben sein, wie etwa der High Level Shader Language (HLSL) oder der OpenGL Shader Language (GLSL). Die Anwendung umfasst außerdem ausführbare Anweisungen 1014 in einer Maschinensprache, die sich für die Ausführung durch den Prozessorkern(e) 1034 für allgemeine Zwecke eignet. Die Anwendung umfasst außerdem Grafikobjekte 1016, die durch Vertexdaten definiert sind.
In einigen Ausführungsformen ist das Betriebssystem 1020 ein Microsoft® Windows® Betriebssystem der Microsoft Corporation, ein proprietäres UNIX-ähnliches Betriebssystem oder ein Open-Source UNIX-ähnliches Betriebssystem, das eine Variante des Linux-Kernels verwendet. Das Betriebssystem 1020 kann eine Grafik-API 1022 wie die Direct3D API oder die OpenGL API unterstützen. Wenn die Direct3D API verwendet wird, verwendet das Betriebssystem 1020 einen Frontend-Shadercompiler 1024 zum Kompilieren aller Shaderanweisungen 1012 in HLSL in eine Shadersprache eines tieferen Levels. Die Kompilierung kann eine Justin-Time- (JIT) Kompilierung sein, oder die Anwendung kann eine Shader-Vorkompilierung ausführen. In einigen Ausführungsformen werden die High-Level Shader bei der Kompilierung der 3D-Grafikanwendung 1010 in Low-Level-Shader kompiliert.
In einigen Ausführungsformen enthält der BenutzermodusGrafiktreiber 1026 einen Backend-Shadercompiler 1027 zum Umwandeln der Shader-Anweisungen 1012 in eine hardwarespezifische Darstellung. Wenn die OpenGL API verwendet wird, werden Shader-Anweisungen 1012 in der GLSL High-Level-Sprache an einen Benutzermodusgrafiktreiber 1026 zur Kompilierung übergeben. In einigen Ausführungsformen, verwendet der Benutzermodusgrafiktreiber 1026 die Betriebssystem-Kernelmodusfunktionen 1028 zur Kommunikation mit einem Kernelmodusgrafiktreiber 1029. In einigen Ausführungsformen kommuniziert der Kernelmodusgrafiktreiber 1029 mit dem Grafikprozessor 1032 zum Versenden der Befehle und Anweisungen.
IP-Kern-Umsetzungen
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentativen Code umgesetzt werden, der auf einem maschinenlesbaren Medium gespeichert wird, das eine Logik innerhalb eines integrierten Schaltkreises wie etwa einem Prozessor darstellt und/oder definiert. Beispielsweise kann das maschinenlesbare Medium Anweisungen umfassen, die eine unterschiedliche Logik innerhalb des Prozessors darstellen. Beim Auslesen durch eine Maschine können die Anweisungen dazu führen, dass die Maschine die Logik so herstellt, dass die darin beschriebenen Techniken ausgeführt werden. Solche Darstellungen, die als „IP-Kerne“ bekannt sind, sind wiederverwendbare Logikeinheiten der Logik für einen integrierten Schaltkreis, die auf einem greifbaren maschinenlesbaren Medium als Hardwaremodell gespeichert werden kann, das die Struktur des integrierten Schaltkreises beschreibt. Das Hardwaremodell kann an die verschiedenen Kunden oder Herstellungseinrichtungen geliefert werden, die das Hardwaremodell auf Herstellungsmaschinen laden, die den integrierten Schaltkreis herstellen. Der integrierte Schaltkreis kann so hergestellt sein, dass der Schaltkreis Operationen ausführt, die in Zusammenhang mit einer der hierin beschriebenen Ausführungsformen beschrieben sind.
11 ist ein Blockdiagramm, das ein IP-Kernentwicklungssystem 1100 illustriert, das verwendet werden kann, um einen integrierten Schaltkreis herzustellen, um Funktionen nach einer Ausführungsform auszuführen. Das IP-Kernentwicklungssystem 1100 kann verwendet werden, um modulare wiederverwendbare Designs zu erzeugen, die in ein größeres Design eingebaut werden können oder verwendet werden können, um einen gesamten integrierten Schaltkreis zu erzeugen (z. B. einen SOC-integrierten Schaltkreis). Eine Designeinrichtung 1130 kann eine Softwaresimulation 1110 eines IP-Kerndesigns in einer High-Levelprogrammiersprache (z. B. C/C++) erzeugen. Die Softwaresimulation 1110 kann verwendet werden, um unter Verwendung Simulationsmodells 1112 das Verhalten des IP-Kerns zu designen, zu prüfen und zu verifizieren. Das Simulationsmodell 1112 kann Funktions-, Verhaltens- und/oder Timingsimulationen enthalten. Ein Design für einen Register-Transferlevel (RTL) 1115 kann dann aus dem Simulationsmodell 1112 erzeugt oder synthetisiert werden. Das RTL-Design 1115 ist eine Abstraktion des Verhaltens des integrierten Schaltkreises, der den Fluss digitaler Signale zwischen Hardwareregistern modelliert, einschließlich der entsprechenden Logik, die unter Verwendung der modellierten digitalen Signale ausgeführt wird. Neben einem RTL-Design 1115 können auch Lower-Level-Designs auf Logik-Ebene oder Transistor-Ebene erzeugt, entworfen oder synthetisiert werden. So können die genauen Details des anfänglichen Designs und der Simulierung variieren.
Das RTL-Design 1115 oder etwas Entsprechendes können weiter durch die Designeinrichtung in ein Hardwaremodell 1120 synthetisiert werden, das in einer Hardware-Beschreibungssprache (HDL) oder einer anderen Darstellung physischer Designdaten erstellt sein kann. Die HDL kann ferner simuliert oder geprüft werden, um das IP-Kerndesign zu verifizieren. Das IP-Kerndesign kann zur Lieferung an eine Drittherstellungseinrichtung 1165 unter Verwendung eines nichtflüchtigen Speichers 1140 (z. B. Festplatte, Flash-Speicher oder ein anderes nichtflüchtiges Speichermedium) gespeichert sein. Alternativ kann das IP-Kerndesign (z. B. über das Internet) über eine verkabelte Verbindung 1150 oder drahtlose Verbindung 1160 übermittelt werden. Die Herstellungseinrichtung 1165 kann dann einen integrierten Schaltkreis herstellen, der mindestens teilweise auf dem IP-Kerndesign basiert. Der fabrizierte integrierte Schaltkreis kann konfiguriert werden, Funktionen nach mindestens einer hierin beschriebenen Ausführungsform auszuführen.
Beispielhafter in einem System auf einem Chip integrierte Schaltkreis
12 bis 14 illustrieren beispielhafte integrierte Schaltkreise und assoziierte Grafikprozessoren, die unter Verwendung eines oder mehrerer IP-Kerne nach verschiedenen hierin beschriebenen Ausführungsformen hergestellt werden können. Neben den illustrierten können auch eine andere Logik und andere Schaltkreise enthalten sein, einschließlich weitere Grafikprozessoren/-kerne, Peripherieschnittstellencontroller oder Mehrzweckprozessorkerne.
12 ist ein Blockdiagramm, das ein beispielhaftes System auf einem chipintegrierten Schaltkreis 1200 nach einer Ausführungsform illustriert, das unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. Der beispielhafte integrierte Schaltkreis 1200 enthält einen oder mehrere Anwendungsprozessoren 1205 (z. B. CPUs), mindestens einen Grafikprozessor 1210 und kann weiterhin einen Bildprozessor 1215 und/oder einen Videoprozessor 1220 enthalten, von denen jeder ein modularer IP-Kern von derselben oder mehreren verschiedenen Designeinrichtungen sein kann. Der integrierte Schaltkreis 1200 umfasst eine periphere oder Buslogik, einschließlich eines USB-Controllers 1225, UART-Controllers 1230, eines SPI/SDIO-Controllers 1235 und eines I²S/I²C-Controllers 1240. Weiterhin kann der integrierte Schaltkreis eine Anzeigevorrichtung 1245 umfassen, die mit einer oder mehreren der Elemente eines High-Definition-Multimediaschnittstellen- (HDMI) Controllers 1250 und einer mobilen Industrieprozessor-Schnittstellen- (MIPI) Anzeigeschnittstelle 1255 gekoppelt ist. Der Speicher kann durch ein Flashspeicheruntersystem 1260 einschließlich eines Flashspeichers und eines Flashspeichercontrollers bereitgestellt werden. Die Speicherschnittstelle kann über einen Speichercontroller 1265 bereitgestellt werden, um auf SDRAM oder SRAM-Speichervorrichtungen zuzugreifen. Einige integrierte Schaltkreise enthalten weiterhin eine eingebettete Sicherheits-Engine 1270.
13 ist ein Blockdiagramm nach einer Ausführungsform, das einen beispielhaften Grafikprozessor 1310 eines Systems auf einem chipintegrierten Schaltkreis illustriert, das unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. Der Grafikprozessor 1310 kann eine Variante des Grafikprozessors 1210 aus 12 sein. Der Grafikprozessor 1310 enthält einen Vertexprozessor 1305 und einen oder mehrere Fragmentprozessor(en) 1315A bis 1315N (z. B. 1315A, 1315B, 1315C, 1315D, bis 1315N-1 und 1315N). Der Grafikprozessor 1310 kann verschiedene Shaderprogramme über eine separate Logik ausführen, sodass der Vertexprozessor 1305 optimiert ist, Operationen für Vertexshaderprogramme auszuführen, während der eine oder die mehreren Fragmentprozessor(en) 1315A bis 1315N Fragment- (z. B. Pixel-) Shadingoperationen für Fragment- oder Pixelshaderprogramme ausführen. Der Vertexprozessor 1305 führt die Vertexverarbeitungsstufe der 3D-Grafik-Pipeline durch und erzeugt die Primitiven- und Vertexdaten. Der oder die Fragmentprozessor(en) 1315A bis 1315N verwenden die durch den Vertexprozessor 1305 erzeugten Primitiven- und Vertexdaten zur Herstellung eines Framepuffers, der auf der Anzeigevorrichtung angezeigt wird. In einer Ausführungsform ist der oder sind die Fragmentprozessor(en) 1315A bis 1315N optimiert, Fragmentshaderprogramme auszuführen, wie in der OpenGL API vorgesehen, die verwendet werden können, um ähnliche Operationen wie ein Pixelshaderprogramm auszuführen, wie in der Direct 3D API vorgesehen.
Der Grafikprozessor 1310 enthält weiterhin eine oder mehrere Speichermanagementeinheiten (MMUs) 1320A bis 1320B, Cache(s) 1325A bis 1325B, und Schaltkreisverbindung(en) 1330A bis 1330B. Die eine oder mehreren MMU(s) 1320A bis 1320B sehen eine virtuell-zu-physische Adresszuordnung für den Grafikprozessor 1310 vor, einschließlich für den Vertexprozessor 1305 und/oder den oder die Fragmentprozessor(en) 1315A bis 1315N, die sich auf Vertex- oder Bild-/Texturdaten beziehen können, die im Speicher gespeichert sind, sowie auf Vertex- oder Bild-/Texturdaten, die in dem einem oder den mehreren Cache(s) 1325A bis 1325B gespeichert sind. In einer Ausführungsform können die eine oder die mehreren MMU(s) 1320A bis 1320B mit anderen MMUs innerhalb des Systems synchronisiert sein, einschließlich einer oder mehrerer MMUs, die mit dem einen oder den mehreren Anwendungsprozessor(en) 1205, dem Bildprozessor 1215 und/oder Videoprozessor 1220 von 12 assoziiert sind, sodass jeder Prozessor 1205 bis 1220 an einem geteilten oder vereinten virtuellen Speichersystem beteiligt sein kann. Die eine oder mehrere Schaltkreisverbindung(en) 1330A bis 1330B ermöglichen dem Grafikprozessor 1310 nach Ausführungsformen die Verbindung mit anderen IP-Kernen innerhalb des SoC, entweder über einen internen Bus des SoC oder über eine direkte Verbindung.
14 ist ein Blockdiagramm nach einer weiteren Ausführungsform, das einen beispielhaften Grafikprozessor 1410 eines Systems auf einem chipintegrierten Schaltkreis illustriert, das unter Verwendung von einem oder mehreren IP-Kernen hergestellt werden kann. Der Grafikprozessor 1410 kann eine Variante des Grafikprozessors 1210 aus 12 sein. Grafikprozessor 1410 enthält die eine oder mehreren MMU(s) 1320A bis 1320B, Cache(s) 1325A bis 1325B und Schaltkreisverbindung(en) 1330A bis 1330B des integrierten Schaltkreises 1300 von 13.
Grafikprozessor 1410 enthält einen oder mehrere Shaderkern(e) 1415A bis 1415N (z. B. 1415A, 1415B, 1415C, 1415D, 1415E, 1415F, bis 1315N-1 und 1315N), was eine vereinheitlichte Shaderkernarchitektur bereitstellt, in der ein einzelner Kern oder Kerntyp alle Typen von programmierbarem Shadercode ausführen kann, einschließlich Shaderprogrammcode zum Umsetzen von Vertexshaders, Fragmentshaders und/oder Rechnershaders. Die genaue Anzahl von vorliegenden Shaderkernen kann unter Ausführungsformen und Umsetzungen variieren. Weiterhin enthält der Grafikprozessor 1410 einen Zwischenkerntaskmanager 1405, der als Threadsender dient, um Ausführungsthreads an einen oder mehrere Shaderkern(e) 1415A bis 1415N zu senden. Der Grafikprozessor 1410 enthält weiterhin eine Kacheleinheit 1418, um die Kabeloperationen für kabelbasiertes Rendern zu beschleunigen, bei denen Operationen für eine Szene in Bildraum unterteilt sind. Kachelbasiertes Rendern kann verwendet werden, um örtliche räumliche Kohärenz innerhalb einer Szene zu nutzen oder um die Verwendung interner Caches zu optimieren.
Komprimierung von Daten innerhalb eines Grafikprozessors
Es ist üblich, einen Grafikprozessor (z. B. GPU) zu verwenden, um ein zweidimensionales Bild aus einem dreidimensionalen (3D) Modell zu erstellen, insbesondere, wenn komplexe 3D-Modelle verwendet werden. Die Speicherübertragungsbandbreite und Speichergrößen sind oft sehr wertvolle Ressourcen beim Rendern eines Bilds, da es teuer ist, ausreichend schnellen Speicher in der Nähe der GPU anzuordnen (z. B. Caches und örtlicher Grafikspeicher), und die Bandbreite in Zusammenhang mit dem Zugriff auf Daten aus dem Systemspeicher verringert wird. Komprimierung mit und ohne Verlust kann eingesetzt werden, um die Übertragungsbandbreite verringern und erhöhte Speichereffizienz für Daten, die im Cachespeicher oder einem anderen On-Die-, On-Package- oder On-Board-Speicher, oder anderweitig einem Speicher ‚Nahe‘ der GPU in Bezug auf den Zugriff auf Latenz und&/oder Bandbreite zu erreichen.
Der Ausgleich zwischen verlustbehafteter und verlustfreier Komprimierung stellt einen Ausgleich zwischen Speichereffizient und Ausgabequalität für komprimierte Daten dar. Dies umfasst die relative Bildqualität (z. B. Fehler) für das komprimierte Bild oder den assoziierten Verlust der Rechnerpräzision für andere komprimierte Daten. unter einigen Umständen wird ein gewisser Grad an Datenverlust als annehmbar akzeptiert. Beispielsweise werden verlustbehaftete Texturkomprimierungsalgorithmen in vielen GPUs umgesetzt, um die Speicher- und Übertragungseffizienz mit Texturkarten zu verbessert, da ein gewisser Grad des Verschmelzens oder Filterns bei Texturverarbeitung üblich ist. Unter anderen Umständen ist eine verlustfreie Komprimierung stark vorzuziehen, wie etwa im Fall der Rahmenpufferkomprimierung. Eine verlustbehaftete Rahmenpufferkomprimierung wird üblicherweise vermieden, da sie Fehler verstärken kann, die über die mehrfache Anwendung verlustbehafteter Komprimierung auftreten können, wenn keine Obergrenze für den gesammelten Fehler festgelegt werden kann. In anderen Fällen, und insbesondere für Daten, die durch die GPU verbraucht werden sollen, ist jede Datenkomprimierung auszuführen, die Komprimierung muss verlustfrei sein. Beispielsweise kann die verlustbehaftete Komprimierung von Vertexpuffer- oder Tiefenpufferdaten wesentliche Fehler in die gerenderte Ausgabe einführen.
Hierin beschrieben sind mehrere Ausführungsformen, die verbessertes Datencachen in Kombination mit adaptiver und dynamischer Komprimierung bereitstellen, um die Speichereffizienz zu erhöhen und die Übertragungsbandbreite der Daten während der Ein- und Ausgabe aus einer GPU verringern. Die hierin beschriebenen Techniken können die Notwendigkeit des Zugriffs auf Speicher außerhalb des Chips verhindern, was zu verbesserter Leistung und verringerter Energie für die GPU-Operationen führt.
15 ein Blockdiagramm des Grafikprozessors 1500 nach einer Ausführungsform ist. Der Grafikprozessor 1500 enthält eine Komprimierungs-/Dekomprimierungslogik 1528, die nach verschiedenen Ausführungsformen verschiedene Typen und Formate von GPU-Daten an verschiedenen Stellen enthält der Grafikprozessor-Renderingpipeline komprimieren und dekomprimieren kann. Der Grafikprozessor 1500 stellt einen Grafikprozessorkern dar. In verschiedenen Ausführungsformen kann eine GPU einen einzelnen Kern oder mehrere Grafikkerne beinhalten. Der Grafikprozessor 1500 enthält einen oder mehrere Grafikprozessor-Unterkerne 1510A bis 1510B, die konfiguriert sein können, verschiedene Grafikverarbeitungsoperationen auszuführen. Während zwei Unterkerne 1510A bis 1510B illustriert sind, sind die Ausführungsformen nicht darauf beschränkt, da der Grafikprozessor einen einzigen Unterkern oder drei oder mehr Unterkerne enthalten kann. Jeder der Grafikprozessor-Unterkerne 1510A bis 1510B enthält eine Grafikverarbeitungslogik wie den Grafikverarbeitungsunterkern 550A und/oder Unterkern 560A wie in 5. Die Grafikunterkerne 1510A bis 1510B teilen einen Satz geteilte Ressourcen 1520, die Komponenten enthalten, die beispielsweise in den geteilten Ressourcen 570A aus 5 gefunden werden.
Der Grafikkern enthält weiterhin ein Level-Drei- (L3) Cache 1530, das Speichertransaktionen zwischen Caches in der geteilten Ressource 1520 und einem Last-Level-Cache oder dem Systemspeicher cachen kann. Der L3-Cache 1530 verbindet sich mit den geteilten Ressourcen 1520 über einen Speicherbus 1529.
In einer Ausführungsform enthalten die geteilten Ressourcen 1520 einen Rasterisierer 1521, einen Sampler 1522, einen Cachecontroller 1523, ein Rendercache 1524, ein Opfercache 1526, und eine Komprimierungs-/Dekomprimierungslogik 1528. Der Rasterisierer 1521 enthält eine Fenster-/Maskierungseinheit, die in einer Ausführungsform eine feste Funktionsdreiecks- und Zeilenrasterisierung durchführt und eine Variante des Rasterisierers und der Tiefentestkomponenten 873 wie in 8 dargestellt ist. Der Rasterisierer 1521 analysiert Daten, die ein geometrisches Objekt darstellen, das durch Durchlaufen, oder Gehen, einer Primitiven und Erzeugen von Pixeldaten für jedes Pixel gerendert werden soll, das Teil einer geometrischen Primitiven ist, die gerendert werden soll. Der Grafikprozessor 1500 kann auf einen fortgeschritteneren und/oder konfigurierbaren Rasterisierer enthalten oder kann zusätzlich eine Strahlenverfolgungsbeschleunigungslogik enthalten, um die Strahlenverfolgung oder Hybridrasterisierung zu beschleunigen. In einer Ausführungsform ist der Rasterisierer 1521 ein kachelbasierter Rasterisierer, wobei Pixel auf der Granularität eines Bildraumgitters von Pixeln gerendert werden. Kachelbasierte Rasterisierung kann auf Daten ausgeführt werden, die in Kachelcaches gespeichert sind, um die Anzahl von Speicherzugriffen außerhalb des Chips zu verringern.
Der Sampler 1522 stellt das Textursampling für 3D-Funktionen und Mediensampling für Medienfunktionen bereit. In einer Ausführungsform ist der Sampler eine Variante des Samplers 610 aus 6. Der Sampler 1522 kann auf Renderzieldaten zugreifen, die in dem Rendercache 1524 gespeichert sind, beispielsweise, wenn dynamisch gerenderte Texturen verwendet werden, oder wenn der Grafikprozessor anderweitig Daten von einem Renderziel für seine Operation sampeln muss.
Der Rendercache 1524 speichert Renderzieldaten, die über die Anzeige-Engine angezeigt werden sollen, oder die verwendet werden sollen, um nachfolgende Bilder für die Anzeige zu rendern. Daten, die durch die Grafikunterkerne 1510A bis 1510B erzeigt werden, können auf das Rendercache 1524 geschrieben werden, wo auf diese Daten leicht durch andere Grafikprozessorkomponenten zugegriffen werden kann, wie etwa die Anzeige-Engine oder den Sampler 1522. Der Speicher in dem Rendercache ist in Cachezeilen unterteilt. Während die Größe der Cachezeilen unter den Ausführungsformen variieren kann, sieht eine Ausführungsform 128-Byte-Cachezeilen vor. In einer Ausführungsform kann der Rendercache 1524 als Multisample-Rendercache konfiguriert sin, und mehrere Samples von Farbdaten pro Pixel speichern.
In einer Ausführungsform wird der Rendercache 1524 durch einen Cachecontroller 1523 gesteuert. Der Cachecontroller 1523 verwaltet die Zeilenallokation für Daten, die in dem Rendercache 1524 und/oder dem Opfercache 1526 gespeichert werden sollen, und erhält Statusinformationen für die Cachezeilen des Rendercache 1524. Komponenten innerhalb des Grafikprozessorkerns können den Cachecontroller 1523 abfragen, um festzustellen, ob Daten für ein bestimmtes Pixel oder eine Gruppe von Pixeln in dem Rendercache 1524 und/oder dem Opfercache 1526 gespeichert sind, und festzustellen, welche Cachezeilen diese Daten speichern. In einer Ausführungsform ist der Cachecontroller 1523 auch am Erhalt der Cachekohärenz zwischen dem Rendercache 1524 und anderen Caches im Grafikprozessor beteiligt.
In einer Ausführungsform koppelt sich ein Opfercache 1526 mit dem Rendercache 1524, um Daten zurückzuschreiben, die aus dem Rendercache entfernt werden. Die Größe des Opfercache 1526 kann relativ zu dem Rendercache 1524 sein. In einer Ausführungsform sind der Rendercache 1524 und der Opfercache 1526 vollständig assoziativ (z. B. in einem M-Wege-Satz assoziativ). In einer Ausführungsform kann der Opfercache 1526 ein satzassoziativer Cache sein. Wenn Daten aus dem Rendercache 1524 zugunsten neu gespeicherten Daten entfernt werden, statt beispielsweise in den L3-Cache 1530 geschrieben zu werden, werden die Daten zumindest zeitweise in dem Opfercache 1526 gespeichert. Wenn der Rendercache 1524 nachfolgend die ausgelagerten Daten benötigt, können die Daten von dem Opfercache 1526 zurückgeholt werden, statt von der höheren Hierarchieebene, in die die ausgelagerten Daten sonst geschrieben worden wären.
Eine Komprimierungsgrenze für komprimierte Daten kann konfiguriert sein, sodass Daten komprimiert oder dekomprimiert werden, bevor sie eine bestimmte Grenzlinie in der Speicherhierarchie überqueren. Beispielsweise können Daten in einem Rendercache 1524 in komprimiertem Format gespeichert werden oder dekomprimiert werden, bevor sie in den Rendercache 1524 geschrieben werden. In einer Ausführungsform, Daten, die aus dem Rendercache und/oder dem Opfercache entfernt werden, kann eine Komprimierungsoperation durch die Komprimierungs-/Dekomprimierungslogik 1528 durchgeführt werden, um die ausgelagerten Daten zu komprimieren, bevor die Daten über den Speicherbus 1529 in den L3-Cache 1530 und/oder Systemspeicher geschrieben werden. Ob Daten an einem bestimmten Ort in einem komprimierten oder unkomprimierten Format gespeichert werden, kann darauf basierend bestimmt werden, ob Grafikprozessorkomponenten, die Daten die Daten aus einer bestimmten Speichereinheit verbrauchen, das Lesen von Daten in einem komprimierten Format unterstützen.
In einer Ausführungsform wird eine kachelbasierte Komprimierung verwendet, bei der Pixeldaten für eine N-x-M-Kachel Pixel sind, in einem komprimierten Zustand im Cache oder im Speicher gespeichert werden. Es können verschiedene Kachelgrößen verwendet werden, unter anderem einschließlich einer 8x4-Kachel oder einer 4x4-Kachel von Pixeln. Zu den komprimierten Daten gehören Komprimierungsmetadaten, die einen Komprimierungsstatus für eine bestimmte Cachezeile oder Kachel erhält. Die Komprimierungsmetadaten können ein oder mehrere Bit pro Kachel, Cachezeile, Cacheblock usw. enthalten, um den Status anzuzeigen, wie etwa komprimiert oder unkomprimiert, oder um eine bestimmte Form von verwendeter Komprimierung anzuzeigen. In vielen verlustfreien Komprimierungsumsetzungen können, wenn die Eingabedaten nicht ohne Datenverlust auf das gewünschte Komprimierungsverhältnis komprimiert werden können, die Daten in einem unkomprimierten Zustand auszugegeben oder gespeichert werden.
Verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff
Viele Komprimierungstechniken sind angewendete Daten wie Farbdaten, Tiefen- (z. B. Z) Daten oder andere Puffer, die über die GPU geschrieben oder anderweitig ausgegeben werden, wie etwa bezüglich 15 beschrieben. Neben den von der GPU erzeugten Daten verbraucht die GPU während der Renderingoperationen einige statische Daten. Diese statischen Daten sind Daten mit reinem Lesezugriff aus Sicht der GPU und enthalten unter anderem statische Texturpuffer, Vertexpuffer, konstante Puffer, einheitliche Puffer oder andere statische oder konstante Eingabepuffer der GPU. Die statischen Daten mit reinem Lesezugriff können auch konstante Daten sein, die durch einen Rechnershader oder eine andere Mehrzweck-Parallelrechnerlogik innerhalb der GPU verwendet werden können. Speicheroberflächen, die solche Daten enthalten, können einmal komprimiert und in mehreren Rahmen oder mehreren Shaderinstanzen verwendet werden, wenn die Daten ohne Datenverlust komprimiert werden können. Metadaten können mit den komprimierten Daten assoziiert sein, um einen Komprimierungsstatus für die Daten anzuzeigen (z. B. komprimiert oder unkomprimiert). Wenn eine statische (z. B. nur Lesezugriff) Ressource an eine GPU-Pipeline gebunden ist, sind auch die entsprechenden Metadaten gebunden. In einer Ausführungsform wird das Bilden der Metadaten über einen bindungslosen Ressourcenplan ausgeführt. In einer Ausführungsform können Metadaten über Altsystemressourcenbindung gebunden werden.
Die Komprimierung und Dekomprimierung der Daten kann im laufenden Betrieb und in Echtzeit erfolgen, was die Speicherbandbreite verringert, die erforderlich ist, um statische Datenstreams oder Datenstreams mit einem Lesezugriff zu laden und zu speichern.
In einer Ausführungsform kann die verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff so konfiguriert sein, dass für alle Oberflächen mit reinem Lesezugriff der Farbcodec verwendet wird, um eine verlustfreie Komprimierung auszuführen. Die Oberfläche wird nachfolgend als eine verlustfrei komprimierte Oberfläche behandelt. Wenn ein Shaderkernel auf Daten mit reinem Lesezugriff zugreift, wird auf die Daten über einen Farbdatencache (z. B. Rendercache) unter Verwendung verlustfreier Dekomprimierungslogik zugegriffen, die mit dem Cache assoziiert ist, oder über eine andere Dekomprimierungslogik, die in der Architektur eingesetzt werden kann, wo dies angemessen ist.
16 ist ein Blockdiagramm eines Grafikverarbeitungssystems 1600 nach einer Ausführungsform. Das Grafikverarbeitungssystem kann unter Verwendung der Grafikverarbeitungslogik umgesetzt werden, wie etwa des Grafikprozessors 1500 aus 15.
Wie illustriert, enthält das Grafikverarbeitungssystem 1600 eine Grafikpipeline 1620, die einen Vertexprozessor 1621, einen Pixelprozessor 1622, einen Cachecontroller 1623 und einen Cache 1624 enthält. In einer Ausführungsform ist der Cache 1624 ein Renderzielcache, der eine Dekomprimierungs- 1626 und Komprimierungs- 1628 Logik enthält oder damit assoziiert ist. Die Grafikpipeline 1620 kann sich mit einem weiteren Speicher 1610 verbinden, der einen Cachespeicher einer höheren Ebene, örtlichen Speicher, Systemspeicher, oder anderen Speicher enthalten kann, in dem eine Oberfläche zur Verwendung durch den Grafikprozessor gespeichert werden kann.
In Reaktion auf eine Anfrage für die Assoziierung eines Datenobjekts mit reinem Lesezugriff 1602 (R/O-Datenobjekt) mit der Grafikpipeline 1620, kann ein Grafikprozessor das Datenobjekt mit reinem Lesezugriff 1602 im Speicher 1610 erstellen oder dorthin kopieren. In einer Ausführungsform werden die Daten für das Datenobjekt mit reinem Lesezugriff 1602 an den Speicher 1610 durch den Cache 1624 übertragen (1603). In einer Ausführungsform werden Daten für das Datenobjekt mit reinem Lesezugriff 1602 auf den Cache 1624 geschrieben und können durch die Komprimierungs- 1628 Logik verarbeitet werden, wenn sie in den Speicher 1610 geschrieben (1607) wurden. In einer Ausführungsform werden Daten für das Datenobjekt mit reinem Lesezugriff vor oder während des Schreibvorgangs auf den Cache 1624 vor Schreiben (1607) der Daten in den Speicher 1610 durch die Komprimierungs- 1628 Logik verarbeitet.
Die Komprimierungs- 1628 Logik kann versuchen, die Daten für das Datenobjekt mit reinem Lesezugriff 1602 über einen verlustfreien Farbkomprimierungsalgorithmus verlustfrei zu komprimieren, wie etwa über einen Deltafarbkomprimierungsalgorithmus oder einen anderen verlustfreien Komprimierungsalgorithmus, der sich für die Komprimierung von Farbdaten eignet. Ein Block aus einem potenziell komprimierten Datenobjekt mit reinem Lesezugriff und Metadaten 1612 kann in dem Speicher 1610 gespeichert werden, wenn die verlustfreie Komprimierung erfolgreich ist. Die Metadaten eines Blocks aus einem Datenobjekt mit reinem Lesezugriff und Metadaten 1612 zeigt den Komprimierungszustand von Daten an, die mit dem Datenobjekt mit reinem Lesezugriff 1602 assoziiert sind. Wenn die Komprimierungs- 1628 Logik in der Lage ist, eine Datenkachel des Datenobjekts mit reinem Lesezugriff 1602 ohne Datenverlust zu komprimieren, speichert die Kachel des Datenobjekts mit reinem Lesezugriff und dessen Metadaten 1612 im Speicher komprimierte Daten und eine oder mehrere Metadatenflags oder Bits, die den Komprimierungszustand der Daten anzeigen. Wenn die Komprimierungs- 1628 Logik nicht in der Lage ist, eine Kachel des Datenobjekts mit reinem Lesezugriff 1602 verlustfrei zu komprimieren, werden die unkomprimierten Daten der Kachel in dem Datenobjekt mit reinem Lesezugriff und den Metadaten 1612 gespeichert und eine oder mehrere Metadatenflags oder Bits können eingestellt werden, um anzuzeigen, dass die Daten unkomprimiert sind. Als Ergebnis weist das gesamte Objekt mit reinem Lesezugriff einige Datenkacheln auf, die komprimiert sind, und einige, die unkomprimiert sind, und in nachfolgenden Zugriffen auf dieses Objekt mit reinem Lesezugriff laufen alle Zugriffe durch diese komprimierte und unkomprimierte Version des Objekts mit reinem Lesezugriff. Die Daten, die in dem Datenobjekt mit reinem Lesezugriff 1602 gespeichert sind, müssen nicht den Typ der Daten haben, die normalerweise in dem Cache 1624 gespeichert sind. Wenn beispielsweise der Cache 1624 ein Rendercache ist, würden Vertexdaten normalerweise nicht in dem Cache 1624 gespeichert. Ein Abschnitt des Cache 1624 kann konfiguriert sein, um Streamingkomprimierung von Nichtfarbpufferdaten während eines Schreibvorgangs in den Speicher 1610 zu ermöglichen. Weiterhin können in einigen Umsetzungen Daten, die in dem Cache 1624 gespeichert sind, wie Farbpufferdaten (z. B. Rahmen Pufferdaten oder Renderzieldaten), die von einer vorherigen Szene übrig sind, geflusht oder verworfen werden, wenn die Daten für den aktuellen Rahmen nicht relevant sind, und der gesamte Cache 1624 verwendet werden kann, um die Daten von dem Datenobjekt mit reinem Lesezugriff 1602 zu komprimieren. Abhängig von dem Typ der zu komprimierenden Daten können die Daten von dem Datenobjekt mit reinem Lesezugriff 1602 dann automatisch über den Cachecontroller 1623 verworfen oder invalidiert werden, wenn die Komprimierungsoperationen abgeschlossen sind.
Wenn auch das Datenobjekt mit reinem Lesezugriff and Metadaten 1612 als ein einziger Block illustriert ist, sind die Ausführungsformen nicht darauf eingeschränkt. In einer Ausführungsform wird eine separate Komprimierungssteuerungsoberfläche erhalten, die Komprimierungszustandsmetadaten für verschiedene Datenblocks in dem Speicher 1610 verfolgt. Die Komprimierungssteueroberfläche kann ein Speicherblock sein, der an einem beliebigen Speicherort gespeichert ist, der für die Grafikpipeline 1620 zugänglich ist. Die Komprimierungssteueroberfläche kann Metadaten für mehrere Speicherblocks speichern und anzeigen, ob jeder Block komprimiert oder unkomprimiert ist, sowie alle anderen Informationen, die für die Verwaltung dieser Daten relevant sein können. In einer Ausführungsform kann der Cachecontroller 1623 auf die Komprimierungssteueroberfläche zugreifen, um zu bestimmen, ob gecachte Daten, die mit einem Speicherblock assoziiert sind, komprimiert werden sollten, bevor gecachte Daten, die mit dem Speicherblock assoziiert sind, entfernt werden. Andere Abschnitte eines Grafikprozessors können auf die Komprimierungssteueroberfläche zugreifen, bevor sie auf verschiedene Chunks von Daten zugreifen, die in Speicher 1610 gespeichert sind.
In einer Ausführungsform speichert sein Komprimierungssteueroberfläche Daten, die den Daten ähneln, die in den beispielhaften Komprimierungsmetadaten 1630 illustriert sind, wenn auch die Komprimierungsmetadaten 1630 ebenfalls mit oder in assoziiert mit dem Datenobjekt mit reinem Lesezugriff und den Metadaten 1612 gespeichert werden kann. Die Komprimierungsmetadaten 1630 enthalten, sind aber nicht beschränkt auf Adress-, Status- und Codecinformationen. Eine Adresse 1631A, die mit einem Block komprimiertem Speicher bekannter oder vorgegebener Granularität assoziiert sein kann (z. B. Seite usw.), sodass Komprimierungsinformationen für mehrere Datenblocks erhalten bleiben können. Beispielsweise kann die Komprimierungssteuerung für die Adresse 1631A getrennt die Adresse 1631 B bilden gehalten werden. Status- und Codecinformationen können für die Adresse gehalten werden, und die genaue Verwendung dieser Felder kann unter den unterschiedlichen Ausführungsformen variieren. In einer Einbettung kann der Status 1632A für die Adresse 1631A anzeigen, ob die Daten bei Adresse 1631A komprimiert oder unkomprimiert sind, und der Codec 1633A kann die Art der Komprimierung anzeigen, die für die Daten verwendet werden, wie etwa beispielsweise verlustfreie Farbkomprimierung. Alternativ kann das Statusfeld verwendet werden, um andere Informationen zu speichern, und das Codecfeld kann anzeigen, ob Daten komprimiert oder unkomprimiert sind, sowie die Art der verwendeten Komprimierung. Beispielsweise und in einer Ausführungsform kann die Adresse 1631 B einen Datenblock, der im Speicher gespeichert ist, verfolgen, und der Status 1632 kann einen Status speichern, wie etwa Kohärenzdaten (z. B. Cachekohärenz usw.) während Codec 1633B eine Anzeige speichert, ob die Daten bei Adresse 1631B komprimiert oder unkomprimiert sind, sowie den Typ oder Grad der verwendeten.
Ohne Beachtung der verschiedenen Arten und Formen der Komprimierungsmetadaten 1630, die in Zusammenhang mit dem Objekt mit reinem Lesezugriff und den Metadaten 1612 oder anderweitig gespeichert sind, kann zugegriffen werden, um festzustellen, wie die Grafikpipeline 1620 auf die Daten mit reinem Lesezugriff zugreifen soll. In einer Ausführungsform kann diese Feststellung automatisch durch die Dekomprimierungs- 1626 Logik des Cache 1624 erfolgen, wenn die potenziell komprimierten Daten, die gelesen werden, über die Dekomprimierungs- 1626 Logik, die mit dem Cache 1624 assoziiert ist, gelesen (1607) werden. Die Grafikpipeline 1620 kann über den Vertexprozessor 1621 oder den Pixelprozessor 1622 auf Daten, die mit dem Datenobjekt mit reinem Lesezugriff assoziiert sind, über den Cache 1624 zugreifen (1609), der basierend auf dem Komprimierungszustand der Daten die Daten die Daten dekomprimieren oder durch die unkomprimierten Daten geben kann.
17A bis 17B ist eine beispielhafte Logik für verlustlose Komprimierung von Oberflächendaten mit reinem Lesezugriff illustrierten. Die illustrierte Logik kann durch Komponenten der Grafikpipeline 1620 aus 16 in unter der Kontrolle einer oder mehrerer 3D APIs durchgeführt werden. Wie in 17A gezeigt ist, kann die Logik 1700, die konfiguriert, Daten mit reinem Lesezugriff zu komprimieren, wie etwa unter anderem statische Texturen, Vertexpuffer, konstante Puffer oder andere statische Eingabepuffer, eine Eingabe empfangen, die die Logik 1700, wie in 1702 dargestellt, veranlasst, eine Puffer nur für Lesezugriff durch eine Grafik- oder Medienpipeline zu konfigurieren, wie etwa die Grafikpipeline 1620 aus 16, die Grafikpipeline 820 oder die Medienpipeline 830 aus 8, oder eine andere Grafikpipeline, wie etwa die 3D-Pipeline 922 oder die Medienpipeline 924 aus 9B. Die Eingabe kann in Reaktion auf einen API-Befehl, wie etwa unter anderem einen Befehl zum Binden einer statischen Textur an einen Grafikkontext, erfolgen.
In dem Verfahren des Zugänglichmachens des Puffers für einen Grafikprozessor (z. B. über Kopieren oder Zuordnen der Daten zu dem GPU-Speicher), kann die Logik 1700 Pufferdaten einer verlustfreien Renderzielkomprimierungslogik bereitstellen, die mit einem Grafikpipelinecache assoziiert ist, wie in 1704 gezeigt. Die Logik 1700 kann dann versuchen, eine verlustfreie Komprimierung für eine Dateneinheit aus dem Puffer durchzuführen, wie gezeigt in 1706. In einer Ausführungsform kann die Dateneinheit als eine Datenkachel oder eine andere Dateneinheit konfiguriert sein, auf die die Farbkomprimierungslogik angewendet wird, wenn die Komprimierungsoperationen durchgeführt werden. Die Datenkachel ist daher eine potenziell dekomprimierbare N-x-M-Dateneinheit in derselben Weise, wie die N-x-M-Kachel von Pixeln eine potenziell komprimierbare Dateneinheit in dem Kontext der Farbdatenkomprimierung ist.
Wenn eine Dateneinheit verlustfrei komprimiert werden kann (z. B. verlustfreie Komprimierung, die bei 1707 erreicht wird), kann die Logik 1700 die komprimierte Dateneinheit speichern und eine oder mehrere Metadatenflags setzen, um anzuzeigen, dass die Dateneinheit komprimiert ist, wie in 1708 dargestellt. Wenn die Dateneinheit nicht verlustfrei komprimiert werden kann, kann die Logik 1700 die unkomprimierte Dateneinheit speichern und eine oder mehrere Metadatenflags setzen, um anzuzeigen, dass die Dateneinheit unkomprimiert ist, wie in 1710 dargestellt.
Nachdem die Dateneinheit in einem komprimierten oder unkomprimierten Format gespeichert werden kann, führt die Logik 1700 bei 1711 ein Ende einer Pufferfeststellung aus. Wenn weitere potenziell komprimierbare Dateneinheiten in dem Puffer zur Verfügung stehen, kann die Logik 1700 die nächste Einheit bei 1712 wählen. Wenn die letzte Dateneinheit in dem Puffer gespeichert wurde, kann die Logik 1700 den nächsten Puffer (wenn vorhanden) bei 1713 wählen oder diese Phase der Logikoperationen beenden.
17B illustriert Logik 1710 zum Zugriff auf Daten mit reinem Lesezugriff, die in einem komprimierten Format gespeichert werden können. Wie in 1712 gezeigt kann die Logik 1700, wenn die Pipelineoperationen beginnen, Pufferdaten für verlustfreie Farbdekomprimierungslogik bei 1714 bereitstellen. Wie in 1716 gezeigt, kann die verlustfreie Farbdekomprimierungslogik Metadaten für eine Einheit von Pufferdaten lesen, die Metadaten sein können, die in einer Komprimierungssteueroberfläche gespeichert sind, Metadaten, die in Zusammenhang mit der Einheit von Pufferdaten gespeichert sind, oder eine separate Bitmap oder Datenstruktur, die einen Komprimierungszustand für jede Datenkachel anzeigt, oder eine andere Dateneinheit, in der die Pufferdaten gespeichert sind. Die Logik 1710 kann bei 1717 feststellen, ob die Einheit von Pufferdaten ein komprimierter Puffer ist. Wenn die Einheit von Pufferdaten komprimiert ist, kann die Logik 1710 die Einheit von Pufferdaten beim Lesen dekomprimieren, wie in 1718 gezeigt. Wenn die Einheit von Pufferdaten nicht komprimiert ist, kann die Logik 1710 die Dekomprimierung für die Pufferdaten umgehen, wie in 1720 gezeigt. Die Logik 1710 kann die unkomprimierten (z. B. dekomprimierten oder unkomprimierbaren) Pufferdaten an die Grafikpipeline streamen, wie in 1722 gezeigt, während aufeinanderfolgende Einheiten von Pufferdaten verarbeitet werden. In einer Ausführungsform kann die Grafikpipeline einen weiteren Puffer oder Cachespeicher enthalten, um den Datenstream mit reinem Lesezugriff aus der Dekomprimierungslogik zu speichern.
Kombination von verlustbehafteter und verlustfreier Komprimierung
Grafikprozessoren nutzen allgemein verlustfreie Komprimierung von Renderzieldaten wie etwa unter anderem dynamischen Texturen oder Tiefenpuffern (z. B. Z-Puffern), was die Schreibe- und Lesebandbreitenanforderungen durch aufeinanderfolgenden Verbrauch der komprimierten Daten verringert. In einer Ausführungsform können die verlustfreien Komprimierungstechniken, die verwendet werden, um die Bandbreite zu verringern, während die Bildqualität erhalten bleibt, mit verlustbehafteter Komprimierung kombiniert werden, wenn Bereiche einer Szene gerendert werden, die weniger Details enthalten. Beispielsweise können Abschnitte eines Renderziels, die in einem Tiefensichtfeld verschwommen erscheinen, Objekte, die durch Bewegung verschwimmen oder eine periphere Ansicht unter Foveated Rendering unter Verwendung von verlustbehafteten Komprimierungsalgorithmen komprimiert werden, um ohne einen merklichen Verlust der Bildqualität weitere Bandbreite des Speichersystems zu sparen.
In einer Ausführungsform können verschiedene Formen verlustbehafteter oder verlustfreier Komprimierung auf Basis pro Kachel durchgeführt werden, sodass eine erste Kachel Daten enthalten kann, die verlustfreie komprimiert sind, während eine zweite Kachel Daten enthalten kann, die über einen verlustbehafteten Komprimierungsalgorithmus komprimiert sind. Wo verlustbehaftete Komprimierungsalgorithmen verwendet werden, können Techniken angewendet werden, um eine Obergrenze auf den Sammelfehler für eine Kachel anzuwenden, sodass die Datenqualität der Kachel erhalten bleiben kann, wenn eine verlustbehaftete Komprimierung vorliegt. Für jede Kachel kann eine Kaskade von Komprimierungstechniken von hoher Qualität zu niedrigerer Qualität angewendet werden, um Bild- oder Datenqualität und raumeffizient der entstehenden komprimierten Daten auszugleichen. In einer Ausführungsform kann die Bildqualität auf Grundlage einer Fehlergrenze, die mit der Kachel, dem Block oder einer anderen definierten Pixelgruppe assoziiert ist, glatt verringert werden. Ein Zielkomprimierungsrang kann teilweise über eine API-definierte Richtlinie oder ein Profil bestimmt werden, die/das eine Ziel- oder Mindestbildqualität vorgeben kann. Eine Komprimierungsrichtlinie kann definiert werden, wobei die Komprimierungslogik versuchen kann, ein Komprimierungsverhältnisziel zu erreichen, das mit der Richtlinie assoziiert ist. Auf Grundlage der Richtlinie wird, wenn eine Kachel nicht verlustfrei auf ein Zielkomprimierungsverhältnis komprimiert werden kann, eine verlustbehaftete Komprimierung mit dem Zielkomprimierungsverhältnis versucht. Wenn die verlustbehafteter Komprimierung nicht durchgeführt werden kann, ohne eine definierte Fehlertoleranz zu überschreiten, kann ein geringeres Komprimierungsverhältnisziel für die verlustfreie Komprimierung versucht werden, bevor die verlustbehaftete Komprimierung mit dem geringeren Komprimierungsverhältnisziel erreicht wird. In einer Ausführungsform kann ein Bandbreiteneinsparprofil durch die Komprimierungsziele gehen, wie in Tabelle 1 unten dargestellt. Tabelle 1: Hierarchie verlustfreie zu verlustbehaftete Komprimierung

Rang Komprimierungsverhältnis Verlustbehaftet/verlustfrei

1 4:1 Verlustfrei

2 4:1 HQ-verlustbehaftet

3 2:1 Verlustfrei

4 2:1 Verlustbehaftet

5 1:1 Verlustfrei
Das Bandbreite einsparende Komprimierungsprofil kann auf eine Kachel, einen Block oder eine Gruppe von Pixeln angewendet werden, und ein Ablauf von höchsten möglichen Bandbreiteneinsparungen zu der niedrigsten Ebene der Bandbreiteneinsparungen kann versucht Grundlage auf der Komprimierbarkeit der zu komprimierenden Daten basiert werden. Wie in Tabelle 1 zu sehen, können die höchsten Bandbreiteneinsparungen durch 4:1 verlustfreie Komprimierung, gefolgt von 4:1 hochqualitative verlustbehaftete Komprimierung erreicht werden. Bei der hochqualitativen verlustbehafteten Komprimierung kann eine Untergrenze der Bildqualität angewendet werden, um die Komprimierungsfehlermenge einzuschränken, die für eine Kachel angesammelt werden kann. Geringere Bandbreiteneinsparungen können mit 2:1 verlustfreier Komprimierung und 2:1 verlustbehafteter Komprimierung umgesetzt werden, während ein 1:1 verlustfreies (z. B. unkomprimiertes) Format für Daten verwendet werden kann, die nicht verlustfrei komprimiert werden können oder die den Datenverlust, der mit verlustbehafteter Komprimierung assoziiert ist, nicht tolerieren können.
In einer Ausführungsform kann die Richtlinie oder das Profil auch die hierarchische Rangordnung ändern, um verlustfreie Komprimierung verlustbehafteter Komprimierung vorzuziehen. Ein Profil ‚verlustfrei vorziehen‘ kann definiert werden, wobei die bevorzugte Hierarchie wie nachfolgend in Tabelle 2 illustriert ist. Tabelle 2: Hierarchie mit Vorzug für verlustfreie Komprimierung

Rang Komprimierungsverhältnis Verlustbehaftet/verlustfrei

1 4:1 Verlustfrei

2 2:1 Verlustfrei

3 4:1 HQ-verlustbehaftet

4 2:1 Verlustbehaftet

5 1:1 Verlustfrei
Auf Grundlage des Profils oder der Richtlinie, die für eine Kachel oder einen Block von Pixeln angewendet wird, können verschiedene Formen von Komprimierung angewendet werden. In einer Ausführungsform können basierend auf der Komprimierbarkeit der Pixeldaten mehrere Formen von Komprimierung (z. B. verlustbehaftete oder verlustfreie) bei verschiedenen Komprimierungsverhältnissen für eine bestimmte Kachel oder einen Block von Pixeln versucht werden. Beispielsweise kann eine Kachel, ein Block oder eine andere Gruppierung von Pixeln, die als geringere Qualitätsanforderungen aufweisend definiert wurde, unter Verwendung verlustbehafteter Komprimierung komprimiert werden, während eine Kachel, ein Block oder eine andere Gruppierung von Pixeln, die eine höhere Qualitätsanforderung aufweisen, unter Verwendung verlustfreier Komprimierung komprimiert werden können. Die Komprimierungslogik kann dann versuchen, ein Komprimierungsziel basierend auf der Komprimierbarkeit der Daten zu erreichen. Wenn beispielsweise eine Kachel von Pixeln Farbdaten aufweist, die beispielsweise bei einem 4:1-Komprimierungsverhältnis nicht verlustfrei komprimiert werden können, kann ein 2:1-Komprimierungsverhältnis versucht werden. Die Logik kann so konfiguriert sein, dass sie auf die verlustbehaftete Komprimierung zurückfällt, wenn ein gegebener Block Farbdaten nicht verlustfrei komprimiert werden kann, oder kann konfiguriert werden, nur verlustfreie Komprimierung zu verwenden. In einer Ausführungsform werden Komprimierungsmetadaten für jede Kachel gespeichert, die den daraus entstehenden Komprimierungstyp (z. B. verlustbehaftet oder verlustfrei) und das entsprechende Komprimierungsverhältnis anzeigen. Die Komprimierungsmetadaten können dann in der Dekomprimierung und Decodierung der Kachel verwendet werden. Während spezifische Komprimierungsverhältnisse für beispielhafte Zwecke verwendet werden (z. B. 4:1, 2:1, 1:1) sind die spezifischen Komprimierungsverhältnisse, die illustriert sind, beispielhaft für eine Ausführungsform, aber nicht einschränkend für alle Ausführungsformen, da höhere Komprimierungsverhältnisse verwendet werden können.
18A bis 18B illustrieren ein Beispiel der Kombination von verlustfreier und verlustbehafteter Komprimierung. 18A zeigt eine Komprimierungskarte 1800, die bei Foveated Rendering verwendet werden kann. Foveated Rendering kann in einer Umsetzung verwendet werden, wenn Daten für eine am Kopf getragene Anzeige gerendert werden. Eine Augenverfolgungslogik kann verwendet werden, um die Augenposition eines Benutzers zu bestimmen und die Szenen, die für die Anzeige gerendert werden, können mit einer unterschiedlichen Qualität an unterschiedlichen Abschnitten derselben Szene gerendert werden, darauf basierend, ob die Szene durch die foveale oder die periphere Sicht des Benutzers gesehen wird. Wenn eine Augenverfolgungslogik bei am Kopf getragenen Anzeigen nicht verwendet wird, können diese Techniken ebenfalls auf Grundlage der verschiedenen Stufen radialer oder chromatischer Abweichungen angewendet werden, die durch Verzerrung verursacht werden können, die durch Linsen verursacht werden, die in einer am Kopf getragenen Anzeige verwendet werden.
In einer Ausführungsform ist die Komprimierungskarte 1800 eine Bitmap oder eine andere Datenstruktur, die für eine Szene definiert ist, die das Komprimierungsprofil anzeigt, das für jede Kachel oder Gruppe von Kacheln gelten soll. Auf Grundlage des definierten Komprimierungsprofils kann die Farbkomprimierungslogik versuchen, die Bandbreiteneinsparungen bei der Farbpufferkomprimierung zu maximieren, oder die Bildqualität zu maximieren, und dabei so viel Bandbreite wie möglich einzusparen, ohne die Bildqualität zu verringern. Beispielsweise können Kacheln am oder in der Nähe des Fokuspunkts des Blicks auf eine Szene (z. B. Kachel 1802, Kachel 1804) nur mit verlustfreier Komprimierung komprimiert werden, um die Bildqualität zu erhalten. Wenn ein erstes verlustfreies Komprimierungsverhältnis (z. B. 4:1) nicht erreicht werden kann, wird ein geringeres verlustfreies Komprimierungsverhältnis (2:1) versucht. Wenn eine verlustfreie Komprimierung nicht auf die Daten angewendet werden kann, werden die Daten unkomprimiert gespeichert. Für Kacheln, die weiter vom Fokuspunkt entfernt sind (z. B. Kachel 1806), kann die verlustfreie Komprimierung bevorzugt werden, aber die verlustbehaftete Komprimierung kann verwendet werden, um die Bandbreite zu erhalten. Für Kacheln in der Nähe der Peripherie des Blicks (z. B. Kachel 1808, Kachel 1810), kann ein Bandbreitenerhaltungsprofil verwendet werden, das versucht, höhere Komprimierungsverhältnisse zu bevorzugen, auch auf Kosten eines gewissen Verlusts der Bildqualität. Foveated Rendering wird nur als ein Beispiel beschrieben, in dem verlustbehaftete und verlustfreie Komprimierungstechniken für Daten innerhalb einer Szene kombiniert werden können. Solche Techniken können an jeder Stelle in einer Grafikpipeline angewendet werden, an der Farbdaten und/oder Renderzielkomprimierung ausgeführt wird. Solche Techniken können auch verwendet werden, wenn eine Farbkomprimierungslogik verwendet wird, um Eingabedaten mit reinem Lesezugriff für eine Grafikpipeline, wie etwa für statische Texturen, Vertexpuffer, konstante Puffer oder andere statische Eingabepuffer der GPU, wie oben bezüglich 16 und 17A bis 17B beschrieben, zu komprimieren.
18B ist ein Ablaufdiagramm für einen allgemeinen Fall der Kombination von verlustbehafteter und verlustfreier Komprimierung nach einer Ausführungsform.
Wie in 1822 gezeigt, kann die Komprimierungslogik 1820 eine Komprimierungskarte lesen, die ein Komprimierungsprofil pro Kachel für ein Renderziel anzeigt. Die Komprimierungslogik 1820 kann dann jede Kachel innerhalt eines Renderziels basierend auf dem Komprimierungsprofil, das mit der Kachel assoziiert ist, komprimieren. Das Komprimierungsprofil kann die Serie der Komprimierungsalgorithmen bestimmen, die für die Kachel angewendet werden, um zu versuchen, die Farbdaten der Kachel zu komprimieren, um das Komprimierungsverhältnis zu maximieren, oder ob die Kachel komprimiert werden sollte, um die Bildqualität zu maximieren. Beispielsweise kann ein Profil ‚verlustfrei vorziehen‘ angewendet werden, das die Verwendung verlustfreier Komprimierungsalgorithmen vorzieht, um Verlust der Bildqualität zu verhindern, auch, wenn ein geringeres Komprimierungsverhältnis erreicht wird. Andere Profile können verwendet werden, die verlustbehaftete Komprimierungsalgorithmen anwenden, um ein höheres Komprimierungsverhältnis auf Kosten der Bildqualität zu erreichen, wobei in einer Ausführungsform ein hochqualitativer, fehlerbeschränkter verlustbehafteter Komprimierungsalgorithmus angewendet werden kann, um den Verlust der Bildqualität zu minimieren, bevor aggressivere Komprimierungstechniken oder geringere Komprimierungsverhältnisziele versucht werden.
Beispielsweise kann, wie in 1824 gezeigt, die Komprimierungslogik 1820 ein Komprimierungsprofil für eine Kachel von Pixeln bestimmen. Das Komprimierungsprofil kann angeben, dass die Bildqualität über das Komprimierungsverhältnis erhalten bleiben soll, wie etwa bei einem Profil ‚verlustfrei vorziehen‘. Das Profil ‚verlustfrei vorziehen‘ kann ein niedrigeres Komprimierungsverhältnis mit verlustfreier Komprimierung versuchen, wenn das höhere Komprimierungsverhältnis mit verlustfreier Komprimierung fehlschlägt, im Gegensatz zu dem Versuch eines höheren Komprimierungsverhältnisses unter Verwendung verlustbehafteter Komprimierung. Bei 1825 kann die Komprimierungslogik bestimmen, ob etwa ein Profil ‚verlustfrei vorziehen‘ für die erste Kachel von Pixeln vorliegt. Wenn ein solches Profil nicht vorliegt, wenn etwa die erste Kachel ein Profil ‚Bandbreite erhalten‘ aufweist, kann die Komprimierungslogik 1820 in 1826 ein erstes Komprimierungsprofil auf die erste Kachel anwenden. Das erste Komprimierungsprofil ist konfiguriert, das Komprimierungsverhältnis zu priorisieren, etwa durch Anwendung von verlustbehafteten Algorithmen mit höherem Komprimierungsverhältnis komprimiert werden können, wobei die Reihenfolge der Tabelle 1 oben entspricht. Die Komprimierungslogik 1820 kann dann die erste Kachel in einem komprimierten Format speichern, das dem ersten Komprimierungsprofil bei 1830 entspricht.
Wenn die Komprimierungslogik 1820, die in 1825 festgestellt hat, dass ein Komprimierungsprofil wie das Profil ‚verlustfrei vorziehen‘ vorliegt, kann die Komprimierungslogik in 1828 ein zweites Komprimierungsprofil auf die erste Kachel anwenden. Das zweite Komprimierungsprofil ist konfiguriert, die Bildqualität zu priorisieren, etwa durch Anwendung von verlustfreien Algorithmen mit niedrigerem Komprimierungsverhältnis komprimiert werden können, wobei die Reihenfolge der Tabelle 2 oben entspricht. Die Komprimierungslogik 1820 kann dann die erste Kachel in einem komprimierten Format speichern, das dem zweiten Komprimierungsprofil bei 1832 entspricht.
Das Speichern der ersten Kachel in einem komprimierten Format, das den jeweiligen Komprimierungsprofilen entspricht, kann das Speichern der ersten Kachel bei einem entstehenden Komprimierungsverhältnis entsprechen, das dem Profil entspricht, wie etwa einem verlustbehafteten Format mit höhere, Komprimierungsverhältnis oder einem verlustfreien Format mit niedrigerem Komprimierungsverhältnis. Weiterhin können die Komprimierungsmetadaten für jede Kachel aktualisiert werden, um das entstehende Komprimierungsverhältnis und Format für jede Kachel zu verfolgen.
Basierend auf der Komprimierbarkeit der Daten kann die Anwendung verschiedener Komprimierungsprofile auf verschiedene Daten dazu führen, dass die entstehenden Daten in ein ähnliches Format komprimiert werden. Beispielweise und in einer Ausführungsform kann jedes Profil der Komprimierungslogik 1820 anzeigen, dass eine bestimmte Kachel auf Komprimierung mit verlustfreier Komprimierung in eine höheren Komprimierungsverhältnis bewertet werden soll. Wenn die Kachel bei einem hohen Komprimierungsverhältnis verlustfrei komprimierbar ist, werden die entstehenden Daten verlustfrei mit dem hohen Komprimierungsverhältnis komprimiert. Wenn die Kachel mit dem hohen Komprimierungsverhältnis nicht verlustfrei komprimiert werden kann, kann die Kachel unter Verwendung einer Fallback-Komprimierung komprimiert werden, die im Fall des ersten Profils eine verlustbehaftete Komprimierung mit höherem Komprimierungsverhältnis oder im Fall des zweiten Profils eine verlustfreie Komprimierung mit niedrigerem Komprimierungsverhältnis. Wenn die Fallback-Komprimierung nicht durchgeführt werden kann, etwa durch Übersteigen der Fehlergrenzen für hochqualitative verlustbehaftete Komprimierung oder Unkomprimierbarkeit der Daten bei Verwendung verlustfreier Algorithmen bei einem niedrigeren Komprimierungsverhältnis, können weitere Fallbackkomprimierungstechniken angewendet werden, die Tabelle 1 und Tabelle 2 oben entsprechen, abhängig von dem Profil, das mit der Kachel assoziiert ist.
Unter Verwendung dieser Techniken kann verlustbehaftete und verlustfreie Komprimierung Kachel für Kachel auf ein Renderziel angewendet werden, um adaptiv die Bildqualität oder Bandbreite basierend auf den Bildqualitätsanforderungen zu für jede Kachel zu erhalten.
Cachegrößenverringerung mit Komprimierung mit garantierter Raten
In einigen Ausführungsformen können die hierin beschriebenen Komprimierungstechniken auf Cachemanagementrichtlinien angewendet werden, um die Cachegröße über eine Komprimierung mit garantierter Rate zu verringern. Die Cachehierarchie in einem Computersystem für CPUs und GPUs ist entscheidend für den Erhalt hoher Leistung und in einigen Fällen die Verringerung des Leistungsverbrauchs, der mit verschiedenen Speichern außerhalb des Chips assoziiert ist. Allgemein führen Caches mit höherer Kapazität zu höheren Leistungsfähigkeiten für einen Prozessor. Hierin beschriebene Ausführungsformen setzen jedoch Komprimierung mit Techniken mit garantierter Rate ein, um die Effizienz zu verbessern, ohne die physische Speicherkapazität eines Cache zu erhöhen. Solche Techniken können für jeden Cachespeicher angewendet werden, der hierin beschrieben ist, einschließlich, aber nicht beschränkt auf Renderzielcaches, Tiefenpuffercaches, Samplercaches, GPU L2-, L3- oder L4-Caches, oder jeden anderen Cachespeicher, der konfiguriert ist, GPU-Daten zu speichern, einschließlich Caches, die mit einer CPU geteilt werden.
In einer Ausführungsform kann eine API Befehle bereitstellen, um bestimmte Oberflächen zu markieren, immer mit einer festen Komprimierungsrate komprimiert zu werden. Die feste Komprimierungsrate kann für ein bestimmtes Zielkomprimierungsverhältnis verwendet werden, wie etwa unter anderem ein 2:1-Komprimierungsverhältnis. Bei einem 2:1-Komprimierungsverhältnis kann die doppelte Datenmenge in einem Cachespeicher gespeichert werden, und es ermöglicht weniger Übersetzungs-Lookaside-Puffer- (TLB) Übersetzungen für den komprimierten Speicher.
Das Zielkomprimierungsverhältnis kann unter Verwendung einer Kombination aus verlustfreier und verlustbehafteter Komprimierung erreicht werden, wie etwa einer verlustfreien Deltakomprimierung und/oder einer verlustbehafteten festen Komprimierungsrate. Im Fall verlustbehafteter Komprimierung kann ein verlustbehafteter fester Komprimierungsratealgorithmus verwendet werden, in dem Farbdaten unter Verwendung adaptiver Quantifizierung über jeden Farbkanal der Farbdaten hin komprimiert werden. Beispielsweise können Farbdaten unter Verwendung eines Rot-Grün-Blau-Alpha-(RGBA) Farbwerts mit vier Unterwerten komprimiert werden, die jedem der vier Farbkanäle (R, G, B und A) entsprechen. Farbdaten können auch unter Verwendung alternativer Farbraumdarstellungen dargestellt werden, wie beispielsweise als Pseudoleichtkraft/Intensitäts-Orange-Chrominanz-Grün-Chrominanz-Alpha- (YCoCgA) Farbraum, sodass die Farbwerte Unterwerte aufweisen, die den vier Farbkanälen Y, Co, Cg und A entsprechen.
Eine Begrenzungsbox kann für die Farbunterwerte bestimmt werden, sodass die Begrenzungsbox einen oder mehrere Begrenzungsbereiche für den einen oder die mehreren Farbkanäle umfasst. Die Begrenzungsbox kann eine beliebige Anzahl von Begrenzungsbereichen enthalten, wie etwa beispielsweise einen Begrenzungsbereich für jeden Farbkanal. In einigen Beispielen kann jeder Begrenzungsbereich einem Bereich von Werten von einem Mindestunterwert für den Farbkanal zu einem Höchstunterwert für den Farbkanal entsprechen. In einigen Beispielen können die Begrenzungsbereiche quantifiziert werden, um Sätze verfügbarer Werte zu erzeugen. Beispielsweise kann abhängig von einer Größe (z. B. einer „Breite“) des Begrenzungsbereichs eine Anzahl verfügbarer Werte innerhalb des Bereichs bestimmt werden. In einigen Beispielen kann die Anzahl verfügbarer Werte ein Faktor von 2 sein, sodass verfügbare Werte erzwungen werden können. Wenn ein Begrenzungsbereich nur einen Wert aufweist, ist beispielsweise keine Quantifizierung notwendig. In anderen Beispielen können 2, 4, 8, 16 oder 32, oder eine ähnliche Anzahl verfügbarer Werte abhängig von den Bandbreiteneinschränkungen wie hierin weiter besprochen zur Verfügung gestellt werden.
In einigen Beispielen kann der Begrenzungsbereich vollständig unter Verwendung der Quantifizierung beschreibbar sein. Wenn der Bereich beispielsweise acht Werte enthält, können acht verfügbare Werte den Begrenzungsbereich vollständig beschreiben. Die Anzahl verfügbarer Werte ist jedoch häufig weniger, als die Breite des Begrenzungsbereichs und die nachfolgende Codierung der Farbunterwerte kann eine verlustbehaftete Codierung sein, sodass ein Teil der Präzision der Breitendaten verloren geht. In einigen Beispielen kann die Breite auf eine tatsächliche Breite des Begrenzungsbereichs eingestellt werden. In einigen Beispielen kann die Anzahl der verfügbaren Werte nicht größer sein, als ein Grenzwert wie etwa 32 oder etwas Ähnliches.
In einigen Beispielen können die verfügbaren Werte des quantifizierten Begrenzungsbereichs mit Indexwerten assoziiert werden. In einigen Beispielen ist es möglicherweise notwendig, k-Bit-Indexwerte mit einem quantifizierten Begrenzungsbereiche zu assoziieren, der mit 2^k Indexwerten quantifiziert ist. Beispielsweise können 8 Indexwerte mit 3-Bit-Indexwerten codiert sein, 16 Indexwerten können mit 4-Bit-Indexwerten codiert sein und so weiter. In einigen Beispielen können die Farbunterwerte durch Assoziierung der Farbunterwerte mit einem Indexwert codiert sein, der einem verfügbaren Wert entspricht, der dem tatsächlichen Farbunterwert am nächsten kommt. Eine solche Codierung kann für einige oder alle der Farbkanäle durchgeführt werden, um codierte Indexwerte zu erzeugen, die die Unterwerte codieren. In einigen Beispielen können Grafikdaten, einschließlich der codierten Indexwerte und Daten, die mit der Begrenzungsbox assoziiert sind (z. B. Daten zum Beschreiben des/der Begrenzungsbereich(e) der Begrenzungsbox) im Speicher gespeichert werden. In einer Ausführungsform können Farbdaten zwischen verschiedenen Farbräumen zugeordnet werden, um die Komprimierbarkeit der Daten zu verbessern.
In einer Ausführungsform können Oberflächen markiert werden, sodass die markierten Oberflächen immer in mit dem Zielkomprimierungsverhältnis komprimierter Form gespeichert werden. Da markierte Oberflächen immer in komprimierter Form gespeichert werden, nehmen diese Oberflächen eine kleinere Menge des Cache in Anspruch. Weiter können, da Oberflächen eine feste Komprimierungsrate aufweisen, Cacheoptimierungen zum Speichern komprimierter Daten ausgeführt werden.
19 ist ein Blockdiagramm einer Cacheflächenverringerung unter Verwendung von Komprimierung mit garantierte Rate nach einer Ausführungsform. Ein erster Cachespeicher 1900 ist gezeigt, in dem vier Blocks Farbdaten (Block 0, Block 7, Block 3 und Block 2) in einem ersten Satz mit vier Cachezeilen 1901 gespeichert sind. Jeder Block kann einen Block Pixeldaten, darstellen, wie etwa eine N-x-M-Kachel mit Pixeldaten. Wenn die Pixeldatenblocks ohne Komprimierung gespeichert werden, kann jeder Block eine ganze Cachezeile belegen.
Ein zweiter Cachespeicher 1910 ist ebenfalls dargestellt, in dem die vier Blocks Pixeldaten, die in dem ersten Cache 1900 gespeichert sind, auf ein festes 2:1-Komprimierungsverhältnis komprimiert und in einem zweiten Satz von vier Cachezeilen 1911 gespeichert werden. Während die komprimierten Blocks eine kleinere Menge an Busbandbreite bei der Übertragung verbraucht und eine kleinere Speichergröße aufweisen kann, wird ein Teil des Cachespeichers (z. B. 50% bei einem festen 2:1-Komprimierungsverhältnis) nicht benutzt. In bestehenden Umsetzungen, in denen Farbdaten im Cache und/oder Speicher in einem komprimierten Format gespeichert werden, kann eine Kombination aus komprimierten und unkomprimierten Daten in dem Cache gespeichert werden, oder komprimierte Daten können mit verschiedenen Komprimierungsverhältnissen gespeichert werden. In Ausführungsformen, in denen die Komprimierung mit garantierter Rate verwendet wird, ermöglicht vorheriges Wissen über das Komprimierungsverhältnis Cacheoptimierungen wie in dem dritten Cachespeicher 1920 illustriert.
Der dritte Cachespeicher 1920 enthält eine Cachezeilenoptimierung zur Komprimierung mit garantierter Rate. Der dritte Cachespeicher 1920 ist für ein 2:1-Komprimierungsverhältnis optimiert, wobei jedoch auch andere Komprimierungsverhältnisse verwendet werden können. In einer Ausführungsform kann eine verlustfreie Komprimierung, z. B. mit einem festen 2:1-Komprimierungsverhältnis, für eine bestimmte Kachel oder Oberfläche verwendet werden. Wenn notwendig, können Renderziele und andere Farbpuffer unter Verwendung eines verlustbehafteten Komprimierungsalgorithmus mit adaptiver Quantifizierung komprimiert werden, ohne wesentlich an visueller Qualität zu verlieren. Egal, ob eine verlustbehaftete oder verlustfreie Komprimierung verwendet wird, kann die Speichereffizienz der Cachezeilen 1921 des dritten Cachespeichers 1920 in direktem Verhältnis mit dem Komprimierungsverhältnis erhöht werden, das durch die Komprimierung mit garantierter Rate verwendet wird. Beispielsweise kann mit einem festen 2:1-Komprimierungsverhältnis die Cachesteuerlogik eine Cachezeile nach dem festen Komprimierungsverhältnis partitionieren und mehrere aneinander angrenzende Speicherblocks, die mit einem Renderziel assoziiert sind, in jede Cachezeile speichern.
In einer Ausführungsform, in der mehrere aneinander angrenzende Blocks von virtuell adressiertem Speicher pro Cachezeile gespeichert werden, kann eine Verringerung der TLB-Übersetzungen erreicht werden. Wie im dritten Cache 1920 gezeigt, können Datenblocks in einer Konfiguration (Block N, Block N+1) pro Cachezeile gespeichert werden. In einer solchen Konfiguration, in der Block N eine erste virtuelle Speicheradresse aufweist und einen ersten virtuellen Speicheradressbereich abdeckt, kann Block N+1 mit dem der nächsten fortlaufenden virtuellen Speicheradresse und dem virtuellen Speicheradressbereich assoziiert sein. In einer solche Konfiguration kann ein einziger TLB-Lookup für Block N und Block N+1 ausgeführt werden. In einer Ausführungsform kann der dritte Cache 1920 konfiguriert werden, sodass eine Cachezeile auf einem geraden Datenblock beginnt, sodass Block N eine ein geradzahliger Block und Block N+1 ein ungeradzahliger Block ist, was die Hardwareumsetzung des dritten Cachespeichers 1920 vereinfachen kann.
Wenn Daten, die in dem dritten Cache 1920 gespeichert werden, auf den Grafik- oder Systemspeicher oder ein Cache ohne Unterstützung für Komprimierung mit garantierter Rate ausgelagert werden, können die Speicherblocks nach der Auslagerung dekomprimiert werden. In einer Ausführungsform kann das Lesen einer einzelnen Cachezeile durchgeführt werden, um die mehreren Datenblocks innerhalb der Cachezeile zu sammeln und die mehreren Datenblocks können dekomprimiert werden, bevor sie auf das höhere Level des Cache oder Speichers geschrieben werden.
Kontextsensitive Cacheersetzung
In einigen Ausführungsformen kann die Aktivierung einer kontextsensitiven Cacheersatzrichtlinien für Grafikprozessorcachespeicher weitere Verbesserungen der Cachespeicherleistung erlauben, vor allem, wenn Datenkomprimierung verwendet wird. In konventionellen Cachespeichern kann die Cacheersatzrichtlinie auf einer oder mehreren Variation der am längsten nicht mehr verwendeten (LRU), am längsten nicht mehr adressierten/aufgerufenen (LRA), Pseudo-LRU (z. B. Baum-PLRU, Bit-PLRU), oder anderen Cacheersetzungsrichtlinien oder Algorithmen basierend, die auf dem Stand der Technik bekannt sind. Beispielsweise kann eine am längsten nicht mehr abgerufene Richtlinie eine Cachezeile basierend auf Speicherzugriffen altern, die mit den Daten assoziiert sind, die in der Cachezeile gespeichert sind. Eine am längsten nicht mehr abgerufene oder am längsten nicht mehr verwendete Richtlinie kann Cachezeilendaten basierend auf der Anzahl und/oder Häufigkeit der Zugriffe (z. B. Lesevorhänge, Schreibvorhänge usw.) auf die Daten altern. Pseudo-LRU-Algorithmen kann ein baumbasiertes PLRU-Algorithmus oder ein Ein-Bit-PLRU-Algorithmus sein. Während die genaue Ersetzungsrichtlinie, die auf verschiedene Cachespeicher angewendet wird, variieren kann, wird in einem Konventions-Cachespeicher dieselbe Ersetzungsrichtlinie einheitlich auf die gespeicherten Daten anwenden.
In einigen Ausführungsformen kann eine kontextsensitive Cacheersetzung aktiviert sein, sodass die genaue Cacheersetzungsrichtlinie basierend auf der Art von Cache und/oder der Art der allokierten Cachezeile zugeordnet werden. Beispielsweise können verschiedene Cacheersetzungsrichtlinien für verschiedene Cachespeicher basierend auf Cacheeigenschaften aktiviert werden, wie etwa, ob der Cache bytemaskierte Schreibvorgänge unterstütz und basierend auf der Art der Allokation, die mit der Cachezeile assoziiert ist (z. B. Lesen/Schreiben, nur Lesen, nur Schreiben usw.).
In einer Ausführungsform kann eine kontextsensitive Cacheersetzungsrichtlinie umgesetzt werden, in der neben der Verwendung einer am längsten nicht mehr adressierten oder gemieteten kürzlich verwendeten Ersetzungsrichtlinie die Cacheersetzungsrichtlinie konfiguriert ist, die Auslagerung von Cachezeilen zu bevorzugen, die eine größere Anzahl von unsauberen Pixelblocks enthalten. Die Auslagerung von Cachezeilen mit einer größeren Anzahl unsauberer Pixelblocks kann den Overhead verringern, der mit teilweisen Cachezeile-Auslagerungen assoziiert ist. Teilweise Cachezeilenauslagerungen können die Verschmelzung von Overhead einführen, wenn Pixelblocks von einem Cache, der Bytemasken enthält, in einen Cache oder Speicher ausgelagert werden, der durch einen Cachecontroller oder Speichercontroller gesteuert wird, der keine Bytemasken umfasst. Bytemasken aktivieren markierte Schreibvorgänge in den Speicher, in dem nur Bits, die durch die Bytemaske beleuchtet (z. B. gewählt) werden, geschrieben werden, während nicht beleuchtete Bits nicht beschrieben werden. In Speicherarchitekturen, die durch die gesamte Speicherhierarchie keine Bytemasken tragen, können teilweise Cachezeilenauslagerungen einen Lesevorgang des Abschnitts der ausgelagerten Daten, die auf dem höheren Level der Speicherhierarchie gespeichert sind, eine Verschmelzung der gelesenen Daten mit den ausgelagerten Daten und ein Zurückschreiben der verschmolzenen Daten verlangen. Weiter kann, wenn Daten in dem Cache in einem komprimierten Format gespeichert werden, eine teilweise Cachezeilenauslagerung dazu führen, dass die Daten vor dem Verschmelzen dekomprimiert werden, und dann potenziell nach dem Verschmelzen rekomprimiert werden, wodurch weiterer Overhead auf die teilweise Cachezeilenauslagerung eingeführt wird.
In einer Ausführungsform wird für Cachezeilenzuordnungen für reine Schreibvorgänge (WO) ein unsauberes Bit pro Pixelblock hinzugefügt, mit mehreren Pixelblocks pro Cachezeile. Der Pixelblock kann jede Gruppierung von Pixeln sein, einschließlich einer Kachel von Pixeln, wie etwa eine N-x-M-Kachel von Pixeln einer Bildschirmraumpipeline. Für WO-Cachezeilenallokationen ist die Cachezeilenersetzungsrichtlinie konfiguriert, das Zurückschreiben teilweise gefüllter Zeilen zu vermeiden, was das Schreiben aus Cachezeilen in den Speicher, ohne, dass alle Bytes der Cachezeile aktiviert ist, beinhaltet. Wenn die höchste Anzahl unsauberer Blocks vorgezogen wird, besteht eine höhere Chance, dass Cachezeilen, die ausgelagert werden, vollständig beleuchtet sind (z. B. alle Bytes sind aktiviert). In einer Ausführungsform wird statt eines unsauberen Bits pro Pixelblock eine Zählung unsauberer Blocks innerhalb einer Cachezeile aufrechterhalten. Die Auslagerungsrichtlinie kann dann einen Satz Cachezeilen wählen, die die ältesten und/oder am längsten nicht mehr verwendeten, aufgerufenen oder adressierten sind, und dann die Cachezeile in dem Satz auslagern, die die höchsten Anzahl an unsauberen Pixelblocks aufweist.
In einer Ausführungsform unterscheiden sich WO-Cachezeilenallokationen von Lese-/Schreibe- (WR) Cachezeilenallokationen, indem die Bytemasken für WR-Allokationen alle durch Garantie beleuchtet sind. Wenn daher eine WR-Cachezeile geändert wird, werden alle Blocks als unsauber markiert und die gesamte Cachezeile wird ausgelagert.
20 ist ein Blockdiagramm einer beispielhaften Cachehierarchie 2000 ist, in der kontextsensitive Cacheersetzung aktiviert. In einer Ausführungsform enthält ein erster Cachespeicher 2010 mehrere Cachezeilen 2001, wobei jede Cachezeile mehrere Pixelblocks (z. B. Block 2008 (Block 0), Block 2018 (Block 1)) speichert. Eine Schreibmaske kann für jeden Block verwendet werden, wobei Maske 2006 mit Block 2008 assoziiert ist und Maske 2016 mit Block 2018 assoziiert ist. Jede der mehreren Cachezeilen 2001 kann die am längsten nicht mehr adressierten (LRA) Metadaten (z. B. LRA 2002 für Block 2008, LRA 2012 für Block 2018) sowie ein unsauberes Bit für jeden Speicherblock (z. B. unsauberes Bit 2004 für Block 2008, unsauberes Bit 2014 für Block 2018) enthalten. Auslagerungen von dem ersten Cachespeicher 2010 können in einem zweiten Cachespeicher 2020 gespeichert werden, dem die Schreibmaske fehlt die mit jedem Block assoziiert ist. Der zweite Cachespeicher 2020 enthält mehrere Cachezeilen 2021, die einen Supersatz der Daten in dem ersten Cachespeicher 2010 enthalten können, einschließlich Block 2008 (als Block 2028) und Block 2018 (als Block 2038).
In einer Ausführungsform aktivieren die Bytemasken das Verfolgen spezifischer Schreibvorgänge auf spezifische Bits in einem Pixelblock für die Allokationen reiner Schreibvorgänge. In einem Anwendungsfall ermöglichen die Bytemasken unterschiedliche Rechnereinheiten (z. B. Ausführungseinheiten, Streaming-Multiprozessoren usw.) eines Grafikprozessors zum Schreiben auf angrenzende Bytes in einem Puffer. Verschiedene Instanzen der Daten bei unterschiedlichen L1-Caches können aufgrund unterschiedlicher Schreibmasken unterschiedliche beleuchtete Bits aufweisen. Nach der Auslagerung von den L1-Caches können die verschiedenen Daten verschmolzen werden, wenn der Cache auf höherer Ebene keine Bytemasken enthält. Aufgrund des Overhead, der mit solchen Verschmelzungsoperationen assoziiert sein kann, kann der kontextsensitive Cacheersetzungsalgorithmus vorziehen, die am längsten nicht mehr adressierten Cachezeilen mit den meisten unsauberen Pixelblocks auszulagern. Weiter können Cachezeilenverschmelzungen verlangen, dass die Dekomprimierung und Rekomprimierung von Daten die gecachten Daten sind in einem komprimierten Format gespeichert werden.
In einer Ausführungsform wird eine kontextsensitive Cacheersetzung für den zweiten Cachespeicher konfiguriert, indem verschiede Cacheersetzungsalgorithmen basierend auf der Art der Allokation (z. B. nur schreiben, lesen/schreiben, nur lesen) und/oder die Art des Puffers, der mit der Allokation assoziiert ist (z. B. Farbpuffer, Tiefenpuffer, usw.) gewählt werden. Beispielsweise kann der Cachezeile, die Block 2028 und Block 2038 des zweiten Cachespeichers 2020 enthält, Lesen/Schreiben zugeordnet werden, und ein am längsten nicht mehr verwendeter (LRU) Algorithmus kann verwendet werden, um die Cachezeilenersetzung zu verwalten. So werden LRU 2022 Metadaten für Block 2028 gespeichert und LRU 2032 Metadaten werden für Block 2038 gespeichert. Alternativ kann die Cachezeile, die Block 2029 (Block N) und Block 2039 (Block N+1) enthält, als reine Schreibvorgänge allokiert werden, und einen anderen Cacheersetzungsalgorithmus verwenden, wie etwa einen Pseudo-LRU (PLRU) Algorithmus. In diesem Fall können PLRU 2023 Metadaten für Block 2029 gespeichert werden und PLRU 2033 Metadaten können für Block 2039 gespeichert werden.
21 ist ein Ablaufdiagram, einer kontextsensitiven Cacheersetzungslogik 2100 nach einer Ausführungsform. Die kontextsensitive Cacheersetzungslogik 2100 kann sich in einem Cachecontroller befinden, wie etwa dem Cachecontroller 1523 von 15. Die kontextsensitive Cacheersetzungslogik 2100 kann verwendet werden, um die Cacheersetzung für ein Cache zu verwalten, das Bytemasken erhält, wenn auf ein Cache ausgelagert wird, das keine Bytemasken erhält. In einer Ausführungsform ist die kontextsensitive Cacheersetzungslogik 2100 konfiguriert, Operationen auszuführen, die das Allokieren einer Cachezeile in einem GPU-Cache enthalten, wie in 2102 gezeigt. Die kontextsensitive Cacheersetzungslogik 2100 kann in Block 2103 bestimmen, ob die Cachezeilenallokation eine Nur-Schreiben-Cachezeile ist. Für eine Nur-Schreiben-Cachezeile werden unsaubere Bits auf Basis pro Block für die mehreren Pixelblocks erhalten, die für jede Cachezeile gespeichert sind, basierend auf der Bytemaske, die mit dem Schreiben assoziiert ist, sodass, wenn Pixeldaten innerhalb eines Pixelblocks geschrieben werden, die kontextsensitive Cacheersetzungslogik 2100 ein unsauberes Bit für jeden modifizierten Block markieren kann, wie in 2104 gezeigt. Für Cachezeilen, die nicht Nur-Schreiben sind, wie etwa einer Lese/Schreibe-Cachezeile, sind alle Bits in der Schreibmaske standardmäßig beleuchtet. In einer Ausführungsform kann für eine Lese/Schreibe-Cachezeile, die kontextsensitive Cacheersetzungslogik 2100 alle Pixelblocks in einer Cachezeile als unsauber markieren, wenn einer der Pixelblocks auf die Cachezeile geschrieben wird, wie in 2105 gezeigt. Wenn es notwendig wird, eine Cachezeile zu ersetzen, kann die kontextsensitive Cacheersetzungslogik 2100 einen Satz möglicher Opfer zur Auslagerung basierend auf einer primären Auslagerungsrichtlinie bestimmen, wie in 2106 dargestellt. Die primäre Auslagerungsrichtlinie kann eines der folgenden sein: am längsten nicht mehr aufgerufener, am längsten nicht mehr adressierter, am längsten nicht mehr verwendeter, Pseudo-am-längstennicht-mehr-verwendeter oder ein anderer Cacheersetzungsalgorithmus oder eine -richtlinie. Aus dem Satz potenzieller Opfer kann die kontextsensitive Cacheersetzungslogik 2100 das potenzielle Opfer auslagern, das die größte Anzahl unsauberer Blocks aufweist, wie in 2108 gezeigt.
Die kontextsensitive Cacheersetzungslogik 2100 ist beispielhaft für eine Ausführungsform und Ausführungsformen können in den Modifikationen, die an einer Cacheersetzungsrichtlinie vorgenommen wurden, und den Eigenschaften, aufgrund derer die Feststellung erfolgt, variieren. Beispielsweise kann in Cachespeichern, die keine Schreibmasken erhalten, die spezifische Cacheersetzungsrichtlinie auf Grundlage des Allokationstyps der Cachezeile oder des zugrundeliegenden Puffertyps (z. B. Farbe, Tiefe, Schablone usw.) variieren, für den Daten gecacht werden.
Effiziente Deltacodierung
In den hierein beschriebenen Ausführungsformen wird in einigen Fällen eine verlustfreie Farbkomprimierungslogik verwendet, um die Übertragungsbandbreitenanforderungen für Farbdaten zu verringern. Eine solche Logik kann auch eingesetzt werden, um Daten mit reinem Lesezugriff zu komprimieren, um in eine Grafikpipeline eingestellt zu werden. Damit die Farbpufferkomprimierung nützlich ist, sollte der Komprimierungsalgorithmus in der Lage sein, erfolgreich Farbdaten für eine Kachel von Pixeln auf ein Grenzkomprimierungsverhältnis komprimieren. Beispielsweise wird für ein Zielkomprimierungsverhältnis von 2:1 eine Kachel, die 1024 Bits in unkomprimierter Form verwendet, auf 512 Bits des Zielkomprimierungsverhältnisses ist zu erreichen. Je mehr Kacheln auf das Zielkomprimierungsverhältnis komprimiert werden können, desto weniger Bandbreite wird auf einem Speicherbus verbraucht, um die Daten zu übertragen. Wie hierin beschrieben, können mehrere verschiedene Grenzwerte und Zielkomprimierungsverhältnisse für ein bestimmtes Farbpufferkomprimierungssystem vorliegen (z. B. Komprimierung von 2048 Bit auf Vielfache von 512 Bit: 1536 Bit oder 1024 Bit oder 512 Bit).
Ein typischer Farbpufferkomprimierungsalgorithmus kann die Mindestfarbkomponente in der Kachel finden und dann so wenige Bits wie möglich verwenden, um die Reste im Verhältnis zu der Mindestfarbkomponente pro Kanal zu komprimieren. Diese Schemata werden manchmal als Offsetkomprimierungsverfahren bezeichnet. Das Offsetkomprimierungsverfahren kann in Szenarios verwendet werden, in denen die Grafik-API (z. B. OpenGL, DirectX usw.) verlangen, dass die Farbpufferkomprimierung verlustfrei ausgeführt wird. Offsetkomprimierungsverfahren sind jedoch nicht effizient, wenn eine Kachel zwei oder mehr separate Farbgruppen enthält, wie etwa eine Gruppe bläulicher Farben und eine andere Gruppe gelblicher Farben.
Um bestehende verlustfreie Farbkomprimierungsverfahren zu verbessern, stellen die hierin beschriebenen Ausführungsformen eine verlustfreie Farbkomprimierungslogik bereit, auf der die Farben einer Kachel in separate Gruppen unterteilt werden, sodass die Variation der Farbe innerhalb jeder Gruppe verringert wird. Diese partitionierten Gruppen können dann effektiv codiert werden. Für jede Farbgruppe wird eine Mindestfarbe für eine Begrenzungsbox identifiziert, die in dem RGB-Farbraum definiert ist. Die Begrenzungsbox ist innerhalb eines Farbraums unter Verwendung von Farbdaten definiert; vieles aus der Art einer Bildschirmraumbegrenzungsbox kann unter Verwendung von Bildschirmraumkoordinaten definiert werden. Die Mindestfarbe innerhalb der Begrenzungsbox kann dann von allen Farben in der Gruppe abgezogen werden, um eine Restkomponente für jeden Farbkanal zu berechnen. Dann wird die größte Farbkomponente, L_R , L_G , L_B , der Reste jedes Kanals festgestellt. Die „Breiten“ jedes Kanals werden als W_R , W_G , W_B bezeichnet, wobei W_R = L_R + 1; W_G = L_G + 1; und W_B = L_B + 1.
Während die folgende Beschreibung bezüglich eines dreikanaligen RGB-Farbraums beschrieben ist, können die hierin beschriebenen Techniken allgemein auf eine beliebige Anzahl von Farbkanälen in jedem Farbraum generalisiert werden, wie etwa einem vierkanaligen RGBA.
In Komprimierungsalgorithmen, die auf dem Stand der Technik bekannt sind, wird allgemeine eine ganzzahlige Anzahl von Bits verwendet, um den Restwert pro Farbkanal zu speichern. Beispielweise wird für den roten Kanal, R, das kleinste k so bestimmt, dass W_R <= 2^k. Jeder Rest für R kann dann mit k Bits codiert werden. Diese Technik kann jedoch unter bestimmten Umständen sehr verschwenderisch werden. Wenn beispielsweise der größte Rest 32 beträgt, sind sechs Bit notwendig, um den Restwert zu codieren, da fünf Bit einen maximalen Wert von 2⁵-1 = 31 erlauben.
Stattdessen kann eine effizientere Codierungstechnik verwendet werden, in der die Farbdaten in Kosten mit einer einzigen ganzen Zahl umgewandelt werden. Für einen bestimmten Farbrestwerte r, g, b, wobei die Mindestfarbe wie oben beschrieben abgezogen wurde, ist r eine Zahl zwischen Null und W_R-1, g ist eine Zahl zwischen Null und W_G-1 und, und b ist eine Zahl zwischen Null und W_B-1. In diesem Beispiel kann die Codierung wie folgt in Kosten mit einer einzigen ganzen Zahl T umgewandelt werden: $T = r + g * W_{R} + b * W_{R} * W_{G}$
Die entstehende Zahl T liegt maximal zwischen 0 und (W_R * W_G * W_B -1). So wird die kleinste Zahl k gefunden, sodass (W_R * W_G * W_B -1) < 2^k und jede T ist mit k Bits codiert. Diese Codierung kann zu einer Einsparungen in der Anzahl Bits für jede Gruppe der codierten Werte führen. Weiterhin kann dieses Konzept auf vier Werte erweitert werden (z. B. RGBA) oder auf eine beliebige Anzahl von Werten. Weiterhin kann es effizienter sein, stattdessen vier rote Werte einer Kachel zu codieren.
Die Decodierung des codierten Werts kann wie in Gleichung 2 unten dargestellt ausgeführt werden. $b = T/ (W_{R} * W_{G})$
$g = (T - {b*W}_{R} {*W}_{G}) {I W}_{R} = (T % (W_{R} {*W}_{G})) {/W}_{R}$
$r = (T - {b*W}_{R} {*W}_{G}) {% W}_{R} = (T % (W_{R} {*W}_{G})) {% W}_{R}$

Hierin beschriebene Ausführungsformen verbessern die oben beschriebene Deltacodierungstechnik durch weiteres Verringern der Anzahl von Bits, die erforderlich sind, die codierten Farbwerte zu speichern. Speziell die Umsetzung der oben beschriebenen Technik verlangt das Speichern der Größe der Breiten der Farbkanäle. Die Breite eines Kanals kann jede Zahl von 0 bis 2^m-1 sein, wobei m die Zahl der Gesamtbits für unkomprimierte Farben ist. Die häufigsten Werte für m sind 8, 16 und 32. Um die Komprimierungstechnik in Hardware umzusetzen, muss die Hardwarelogik Mutiplikations- und Divisionsoperationen mit einer Zahl von 2 bis 2^m ausführen. Die Komplexität der Logik kann jedoch verringert werden, da nicht alle Werte zwischen 2 und 2^m erforderlich sind. Beispielsweise werden die Biteinsparungen, die aus der Codierung von 4 Werten entstehen, nachfolgend in Tabelle 3 dargestellt. Tabelle 3 - Bits, die über einzel-ganzzahlige Deltacodierung gespeichert werden

[1 max]	[2 Basis]	Compact-Num-Bits:	4	Sparse-Num-Bits: 4	Diff:	0
[2 max]	[3 Basis]	Compact-Num-Bits:	7	Sparse-Num-Bits: 8	Diff:	1
[3 max]	[4 Basis]	Compact-Num-Bits:	8	Sparse-Num-Bits: 8	Diff:	0
[4 max]	[5 Basis]	Compact-Num-Bits:	10	Sparse-Num-Bits: 12	Diff:	2
[5 max]	[6 Basis]	Compact-Num-Bits:	11	Sparse-Num-Bits: 12	Diff:	1
[6 max]	[7 Basis]	Compact-Num-Bits:	12	Sparse-Num-Bits: 12	Diff:	0
[7 max]	[8 Basis]	Compact-Num-Bits:	12	Sparse-Num-Bits: 12	Diff:	0
[8 max]	[9 Basis]	Compact-Num-Bits:	13	Sparse-Num-Bits: 16	Diff:	3
[9 max]	[10 Basis]	Compact-Num-Bits:	14	Sparse-Num-Bits: 16	Diff:	2
[10 max]	[11 Basis]	Compact-Num-Bits:	14	Sparse-Num-Bits: 16	Diff:	2
[11 max]	[12 Basis]	Compact-Num-Bits:	15	Sparse-Num-Bits: 16	Diff:	1
[12 max]	[13 Basis]	Compact-Num-Bits:	15	Sparse-Num-Bits: 16	Diff:	1
[13 max]	[14 Basis]	Compact-Num-Bits:	16	Sparse-Num-Bits: 16	Diff:	0
[14 max]	[15 Basis]	Compact-Num-Bits:	16	Sparse-Num-Bits: 16	Diff:	0
[15 max]	[16 Basis]	Compact-Num-Bits:	16	Sparse-Num-Bits: 16	Diff:	0
[16 max]	[17 Basis]	Compact-Num-Bits:	17	Sparse-Num-Bits: 20	Diff:	3
[17 max]	[18 Basis]	Compact-Num-Bits:	17	Sparse-Num-Bits: 20	Diff:	3
[18 max]	[19 Basis]	Compact-Num-Bits:	17	Sparse-Num-Bits: 20	Diff:	3
[19 max]	[20 Basis]	Compact-Num-Bits:	18	Sparse-Num-Bits: 20	Diff:	2
[20 max]	[21 Basis]	Compact-Num-Bits:	18	Sparse-Num-Bits: 20	Diff:	2
[21 max]	[22 Basis]	Compact-Num-Bits:	18	Sparse-Num-Bits: 20	Diff:	2
[22 max]	[23 Basis]	Compact-Num-Bits:	19	Sparse-Num-Bits: 20	Diff:	1
[23 max]	[24 Basis]	Compact-Num-Bits:	19	Sparse-Num-Bits: 20	Diff:	1
[24 max]	[25 Basis]	Compact-Num-Bits:	19	Sparse-Num-Bits: 20	Diff:	1
[25 max]	[26 Basis]	Compact-Num-Bits:	19	Sparse-Num-Bits: 20	Diff:	1
[26 max]	[27 Basis]	Compact-Num-Bits:	20	Sparse-Num-20 Bits:	Diff:	0
[27 max]	[28 Basis]	Compact-Num-Bits:	20	Sparse-Num-Bits: 20	Diff:	0
[28 max]	[29 Basis]	Compact-Num-Bits:	20	Sparse-Num-Bits: 20	Diff:	0
[29 max]	[30 Basis]	Compact-Num-Bits:	20	Sparse-Num-Bits: 20	Diff:	0
[30 max]	[31 Basis]	Compact-Num-Bits:	20	Sparse-Num-Bits: 20	Diff:	0
[31 max]	[32 Basis]	Compact-Num-Bits:	20	Sparse-Num-Bits: 20	Diff:	0
[32 max]	[33 Basis]	Compact-Num-Bits:	21	Sparse-Num-Bits: 24	Diff:	3
[33 max]	[34 Basis]	Compact-Num-Bits:	21	Sparse-Num-Bits: 24	Diff:	3
[34 max]	[35 Basis]	Compact-Num-Bits:	21	Sparse-Num-Bits: 24	Diff:	3
[35 max]	[36 Basis]	Compact-Num-Bits:	21	Sparse-Num-Bits: 24	Diff:	3
[36 max]	[37 Basis]	Compact-Num-Bits:	21	Sparse-Num-Bits: 24	Diff:	3
[37 max]	[38 Basis]	Compact-Num-Bits:	21	Sparse-Num-Bits: 24	Diff:	3

Die Werte von Tabelle 3 sind wie folgt. Vier Werte sind codiert, wobei [x max] anzeigt, dass x der größte Rest (L) ist und [x+1 Basis] anzeigt, dass x+1 die Breite ist, die für die Codierung verwendet wird. „Compact-Num-Bits: y“ zeigt die Anzahl Bits an, die verwendet wird, um ein kompaktes, einzel-ganzzahliges Delta zu speichern, das unter Verwendung von Gleichung 1 codiert ist. „Sparse-Num-Bits: z“ zeigt die Anzahl von Bits an, die eine deltacodierte Darstellung der Farbdaten ohne Verwendung von Gleichung 1 verbrauchen würde. Der Diff.-Wert zeigt die Biteinsparungen an, die durch Verwendung einer Codierung umgesetzt werden, die durch Gleichung 1. Beispielsweise zeigt „Diff: 3“ an, dass 3 Bits gespeichert werden, wenn vier Werte codiert werden, die mit einem Vierkanalfarbwerten für Vierkanalpixelfarbdaten assoziiert sind. Wenn drei Bits für jedes Pixel gespeichert werden, führt die Verwendung einer gemeinsamen Kachelgröße von 8x4 Pixeln zu Einsparungen von 96 Bits pro Kachel.
Es ist jedoch anzumerken, dass nicht alle möglichen Werte für eine Kanalbriete notwendig sind. Die wichtigen zahlen sind die mit den letzten in einem Satz identischer „Diff“-Zahlen assoziierten. Beispielsweise weist die Zeile, die mit „[25 max]“ beginnt, einen Diff.-Wert von eins auf, während der Diff.-Wert der Zeile, die mit „[26 max]“ beginnt, Null ist. Da die Änderung des Diff.-Bit nur bei bestimmten Zahlen auftritt (z. B. die fettgedruckten Zahlen aus Tabelle 3), müssen nur diese zahlen als Basiszahlen verwendet werden. Daher wird in einer Ausführungsform statt allen Zahlen von 2 bis 2^m als Basiszahlen nur ein Untersatz dieser zahlen verwendet. Speziell wird unter Annahme von m=8 der Satz der Basiszahlen von 2 bis 2⁸ (z. B. 2 bis 256) auf den folgenden Satz Basiswerte verringert:
[Kompakte Basis für m=8]
{2,3,4,5,6,8,9,11,13,16,19,22,26,32,38,45,53,64,76,90,1 07,128,152,181,215,256}
Der kompakte Satz der Basiswerte wird in mehreren Weisen ausgenutzt. Zuerst erfordert die Codierung der Daten das Speichern der Größe der Basis als Gewicht W_x , (z. B. W_R , W_G , W_O wie in der Gleichung 2 oben. Für m=8 enthält eine kompakte Basis 26 verschiedene Werte. Statt m Bit pro Kanal können die 26 verschiedenen Werte unter Verwendung von fünf Bits gespeichert werden, indem die Werte in einer indizierten Liste gespeichert werden, wobei drei Bits pro Kanal gespeichert werden. Die Codierung von vier Kanal-RGBA bis Farbdaten kann zu Einsparungen von 12 Bit pro Kachel führen.

Zweitens kann, da die Decodierungslogik nicht mit allen Zahlen zwischen 2 und 2^m multiplizieren und durch diese teilen muss, die Multiplikations- und Divisionslogik vereinfacht werden. Für m=8 beispielsweise kann der Satz der Zahlen in einer kompakten Basis wie in Tabelle 4 unten faktorisiert werden. Tabelle 4 - Kompaktbasisfaktorisierung

2 = 2

3 = 2+1

4 = 2*2

5 = 2*2+1

6 = 2* (2+1) = 2*2 + 2

8 = 2*2*2

9 = 2*2*2+1

11 = 2*2*2 + 2 + 1

13 = 2*2*2 + 2*2 +1

16 = 2*2*2*2

19 = 2*2*2*2 + 2 + 1

22 = 2* (2*2*2 + 2 + 1) = 2*2*2*2 + 2*2 +2

26 = 2* (2*2*2 + 2*2 +1) = 2*2*2*2 + 2*2*2 + 2

32 = 2*2*2*2*2

38 = 2* (2*2*2*2 + 2 + 1) = 2*2*2*2*2 + 2*2 + 2

45 = (2*2*2+1) * (2*2+1) = 2*2*2*2*2 + 2*2*2 + 2*2 +1

53 = 1 + 2*2* (2*2*2 + 2*2 +1) = 2*2*2*2*2 + 2*2*2*2 + 2*2 + 1

64 = 2*2*2*2*2*2

76 = 2*2* (2*2*2*2 + 2 + 1) = 2*2*2*2*2*2 + 2*2*2 + 2*2

90 = 2* (2*2*2+1) * (2*2+1) = 2*2*2*2*2*2 + 2*2*2*2 + 2*2*2 + 2

107 = 1+2* (1+2*2* (2*2*2+2*2+1)) =2*2*2*2*2*2 + 2*2*2*2*2 + 2*2*2 +2+ 1

128 = 2*2*2*2*2*2*2

152 = 2*2*2* (2*2*2*2 + 2 + 1) = 2*2*2*2*2*2*2 + 2*2*2*2 + 2*2*2

181 = 2*2*2*2*2*2*2 + 2*2*2*2*2 + 2*2*2*2 + 2*2 +1

215 = 2*2*2*2*2*2*2 + 2*2*2*2*2*2 + 2*2*2*2 + 2*2 + 2 + 1

256 = 2*2*2*2*2*2*2*2

Wie in Tabelle 4 angezeigt, kann jeder Wert der kompakten Basis als eine Reihe von Multiplikationen mit zwei (z. B. Verschiebung nach links) und Additionen dargestellt werden. Daher kann der Hardwaremultiplikator zur Umsetzung dieser Codierung wesentlich vereinfacht werden.
Beispielsweise kann ein Wert x mit einem Basiswert 76 unter Verwendung folgender Operationen multipliziert werden: x*76 = x* (2*2*2*2*2*2 + 2*2*2 + 2*2) = SL(x,6) + SL(x,3) + SL(x,2), was aus drei Verschiebungen nach links und zwei Additionsoperationen besteht. Die komplexeste Multiplikationsoperation für den Satz kompakter Basiswerte für m=8 ist der Wert 215. Eine Multiplikation mit 215 kann unter Verwendung folgender Operationen durchgeführt werden: x*215 = x*(2*2*2*2*2*2*2 + 2*2*2*2*2*2 + 2*2*2*2 +2*2+ 2 + 1) = SL(x,7) + SL(x,6) + SL(x,4) + SL(x,2) + SL(x,1) + x. So kann für m=8 eine wesentlich vereinfachte Multiplikatorlogik zur Verwendung in der Farbdeltakomprimierungshardware generalisierte Multiplikatorlogik ersetzen, die in der Lage ist, mit jeder Zahl zwischen 2 und 2^m zu multiplizieren.
22 ist ein Blockdiagramm einer Hardwaremultiplikatoreinheit 2200 zur Verwendung in effizienter Deltacodierung nach einer Ausführungsform. In einer Ausführungsform enthält die Hardwaremultiplikatoreinheit 2200 eine Eingabe 2201, um einen Multiplikatorwert zu empfangen und eine Steuerbitlogik 2202 zu berechnen, um einen Satz von Steuerbits zu berechnen, um die Verschiebungslogik zu konfigurieren, die verwendet wird, um die Multiplikation durchzuführen. Die Verschiebungslogik kann konfiguriert werden, einen eingabewert basierend auf einer Auswahl einer von einer oder mehreren möglichen Verschiebungen nach links zu verschieben. Die illustrierte Hardwaremultiplikatoreinheit 2200 enthält eine [SL7,8] Einheit 2204, eine [SL6] Einheit 2205, eine [SL4,5] Einheit 2208, eine [SL3,4] Einheit 2210 eine [SL1,2] Einheit 2212 und eine [SLO] Einheit 2214. Die Verschiebungslogik ist über mehrere Addierer 2216 gekoppelt. Jede Verschiebungseinheit ist mit einem oder zwei Verschiebungswerten vorkonfiguriert, die über das Steuerbit gewählt werden können. In einer Ausführungsform verschiebt ein Steuerbit von Ob01 (z. B. eins) Eingaben durch den ersten vorkonfigurierten Wert. während ein Steuerbit von Ob10 (z. B. zwei) eingaben um einen zweiten vorkonfigurierten Wert verschiebt. Ein Steuerbit von Ob00 (z. B. null) lässt die Verschiebungseinheit einen Nullwert ausgeben. Beispielsweise verursacht ein Steuerbitwert eins, der in die [SL7,8] Einheit 2204 eingegeben wird, eine Verschiebung der Eingabe um 7 nach links, während ein Steuerbitwert von zwei, der in die [SL7,8] Einheit 2204 eingegeben wird, eine Verschiebung des Eingabe um 8 nach links verursacht. Ein Steuerbitwert Null verursacht die Ausgabe eines Werts Null. Daher würde zur Durchführung einer Multiplikation um einen Wert 215 die Rechnersteuerbitlogik 2202 das Steuerbit ausgebe, um dann die Eingabe um 7, 6, 4, 2, 1, 0 zu verschieben. Zur Multiplikation mit 76 würde die Rechnersteuerbitlogik Ob00 an die [SL7,8] Einheit 2204 ausgeben (die Null ausgibt), Ob01 an die [SL6] Einheit 2206, die um 6 nach links verschiebt, Ob00 an die [SL4,5] Einheit 2208, die Null ausgibt, Ob01 an die [SL3,4] Einheit 2210, die um drei nach links verschiebt, Ob10 an die [SL1,2] Einheit 2212, die um zwei nach links verschiebt, und Ob00 an die [SLO] Einheit 2214, die Null ausgibt. Das spezifische Steuerbit, das für jeden eingabewert ausgegeben werden soll, kann in einer Hardware-Lookup-Tabelle gespeichert werden.
23 ist ein Blockdiagramm der Rechnervorrichtung 2300, die einen Grafikprozessor 2304 enthält nach einer Ausführungsform. Die Rechnervorrichtung 2300 kann eine Rechnervorrichtung wie das Datenverarbeitungssystem 100 wie in aus 1 sein. Die Rechnervorrichtung 2300 kann auch eine Kommunikationsvorrichtung wie einer Set-Top-Box (z. B. internetbasierter kabelbasierter Fernseh-Set-Top-Boxen usw.), Global-Positioning-System-(GPS) basierte Vorrichtungen usw. sein oder darin enthalten sein. Die Rechnervorrichtung 2300 kann auch mobile Rechnervorrichtungen wie Handys, Smartphones, Personal Digital Assistants (PDAs), Tabletcomputer, Laptopcomputer, E-Reader, Smart-Fernseher, Fernsehplattformen, tragbare Vorrichtungen (z. B. Brillen, Armbanduhren, Armbänder, Smartcards, Schmuck, Kleidungsstücke usw.), Mediaplayer usw. sein oder darin enthalten sein. Beispielsweise enthält die Rechnervorrichtung 2300 in einer Ausführungsform eine mobile Rechnervorrichtung, die einen integrierten Schaltkreis („IC“), enthält, wie etwa ein System auf einem Chip („SoC“ oder „SOC“), das verschiedene Hardware- und/oder Softwarekomponenten der Rechnervorrichtung 2300 auf einem einzelnen Chip enthält.
Die Rechnervorrichtung 2300 enthält einen Grafikprozessor 2304. Der Grafikprozessor 2304 stellt jeden Grafikprozessor dar, der hierin beschrieben ist. Der Grafikprozessor enthält eine oder mehrere Grafik(s), Grafikprozessorkerne und andere Grafikausführungsressourcen, wie hierin beschrieben. Solche Grafikausführungsressourcen können in den Formen vorliegen, die Ausführungseinheiten, Shader-Engines Fragmentprozessoren, Vertexprozessoren, Streamingmultiprozessoren, Grafikprozessorcluster oder jede Sammlung von Rechnerressourcen enthalten können, die sich für die Verarbeitung von Grafiken und Bildressourcen eigenen.
In einer Ausführungsform enthält der Grafikprozessor 2304 ein Cache 2314, des ein einzelner Cache sein oder in mehrere Segmente des Cachespeichers unterteilt sein kann, einschließlich, aber nicht beschränkt auf eine beliebige Anzahl von L1-, L2-, L3- oder L4-Caches, Rendercaches, Tiefencaches, Samplercaches und/oder Shadereinheitencaches. In einer Ausführungsform enthält der Grafikprozessor 2304 eine Codec-Einheit 2324, einen Cachecontroller 2334, eine Shader-Einheit 2344 und eine Rasterisierer-Einheit 2354. Die Codec-Einheit 2324 kann mehrere Formen von Komprimierungs- und Dekomprimierungslogik enthalten, wie hierin beschrieben, einschließlich der Durchführung verlustbehafteter und verlustfreier Komprimierung bei garantierten und/oder variablen Komprimierungsraten. In einer Ausführungsform kann die Codec-Einheit 2324 konfiguriert sein, verlustfrei komprimierte Daten unter Verwendung der effizienten Deltacodierungstechniken und vereinfachter Hardwarelogik, die mit 22 assoziiert ist, zu codieren und decodieren. Der Cachecontroller 2334 kann die Verwendung der verschiedenen Cachemanagement- und Ersetzungstechniken, die hierin beschrieben sind, konfigurieren und steuern, einschließlich kontextsensitive Cacheersetzung und Cachegrößenverringerung mit Komprimierung mit garantierter Raten. Die Shader-Einheit 2344 kann Vertex, Geometrie-, Tessellierungs-, Fragment- oder Pixelshaderprogramme für eine programmierbare Grafik- und Medienpipeline verarbeiten und ausführen. Die Rasterisierer-Einheit 2354 enthält eine konfigurierbare feste Funktion zur Durchführung einer Dreiecksrasterisierung, um eine Szene von einem Objektraum auf einen Bildschirmraum zu transformieren, und kann zusammen mit der Shader-Einheit 2344 funktionieren, um eine Hybridrasterisierung unter Verwendung von shaderbasierten Strahlenverfolgungstechniken auszuführen.
Wie illustriert kann die Rechnervorrichtung 2300 in einer Ausführungsform und neben dem Grafikprozessor 2304 ferner eine beliebige Anzahl von Hardwarekomponenten und/oder Softwarekomponenten enthalten, einschließlich, aber nicht beschränkt auf einen Anwendungsprozessor 2306, Speicher 2308 und Eingabe-/Ausgabe (E/A) Quellen 2310. Der Anwendungsprozessor 2306 kann mit einer Hardware-Grafikpipeline interagieren, wie mit Verweis auf 3 illustriert, um die Grafikpipeline-Funktion zu teilen. Verarbeitete Daten werden in einem Puffer in der Hardware-Grafikpipeline gespeichert und Zustandsinformationen werden in Speicher 2308 gespeichert. Die daraus entstehenden Daten können an einen Anzeigecontroller übertragen werden, um über eine Anzeigevorrichtung ausgegeben zu werden, wie etwa die Anzeigevorrichtung 323 von 3. Die Anzeigevorrichtung kann verschiedene Typen aufweisen, wie etwa Cathode Ray Tube (CRT), Thin Film Transistor (TFT), Liquid Crystal Display (LCD), Organic Light Emitting Diode (OLED) Array usw., und kann konfiguriert sein, dem Benutzer Informationen über eine grafische Benutzerschnittstelle anzuzeigen.
Der Anwendungsprozessor 2306 kann einen oder Prozessoren enthalten, wie etwa Prozessor(en) 102 aus 1, und kann die zentrale Prozessoreinheit (CPU) sein, die zumindest teilweise verwendet wird, um ein Betriebssystem (OS) 2302 für die Rechnervorrichtung 2300 auszuführen. Das OS 2302 kann als Schnittstelle zwischen Hardware und/der physischen Ressourcen der Computervorrichtung 2300 und einem oder mehreren Benutzern dienen. Das OS 2302 kann eine Treiberlogik 2322 für verschiedene Hardwarevorrichtungen in der Rechnervorrichtung 2300 enthalten. Die Treiberlogik 2322 kann eine Grafiktreiberlogik 2323 enthalten, wie etwa den Benutzermodusgrafiktreiber 1026 und/oder Kernelmodusgrafiktreiber 1029 aus 10.
Es wird in Betracht gezogen, dass in einigen Ausführungsformen der Grafikprozessor 2304 als Teil des Anwendungsprozessors 2306 existieren kann (wie etwa als Teil eines physischen CPU-Pakets) in welchem Fall mindestes ein Abschnitt des Speichers 2308 durch den Anwendungsprozessor 2306 und den Grafikprozessor 2304 geteilt werden kann, wenn auch mindestens ein Abschnitt des Speichers 2308 ausschließlich für den Grafikprozessor 2304 gelten kann, oder der Grafikprozessor 2304 ein separates Speichermedium aufweisen kann. Der Speicher 2308 kann eine vorallokierte Region (z. B. einen Rahmenpuffer) umfassen; es sollte jedoch von einem gewöhnlichen Fachmann verstanden werden, dass die Ausführungsformen nicht darauf beschränkt sind, und dass jeder Speicher, der für die untere Grafikpipeline zugänglich ist, verwendet werden kann. Der Speicher 2308 kann verschiedenen Formen von Direktzugriffsspeicher (RAM) (z. B. SDRAM, SRAM, usw.) enthalten, der eine Anwendung umfasst, die den Grafikprozessor 2304 verwendet, um eine Desktop- oder 3D-Grafikszene zu rendern. Ein Speichercontrollerhub wie etwa der Speichercontrollerhub 116 aus 1 kann auf Daten in dem Speicher 2308 zugreifen und sie zur Grafikpipelineverarbeitung an den Grafikprozessor 2304 weiterleiten. Der Speicher 2308 kann für andere Komponenten innerhalb der Rechnervorrichtung 2300 verfügbar gemacht werden. Beispielsweise können beliebige Daten (z. B. Eingabegrafikdaten), die von verschiedenen E/A bis Quellen 2310 der Rechnervorrichtung 2300 empfangen werden, temporär in den Speicher eingestellt werden 2308 bevor auf ihnen durch einen oder mehrere Prozessoren in der Umsetzung eines Softwareprogramms oder einer -anwendung gearbeitet wird (z. B. Anwendungsprozessor 2306). Ebenso werden Daten, von die ein Softwareprogramm bestimmt, dass sie von der Rechnervorrichtung 2300 durch der Rechnersystemschnittstellen an eine externe Entität gesendet oder in ein internes Speicherelement gespeichert werden sollten, oft temporär in Speicher 2308 eingestellt, bevor sie übertragen oder gespeichert werden.
Die E/A bis Quellen können Vorrichtungen wie Touchscreens, Touchpanels, Touchpads, virtuelle oder reguläre Tastaturen, virtuelle oder reguläre Mäuse, Ports, Anschlüsse, Netzwerkvorrichtungen oder ähnliches enthalten und können über einen Eingabe-/Ausgabe (E/A) Steuerhub (ICH) 130 wie in 1 bezeichnet angeschlossen werden. Weiterhin können die E/A bis Quellen 2310 eine oder mehrere E/A bis Vorrichtungen beinhalten, die für die Übertragung von Daten an und/oder von der Rechnervorrichtung 2300 (z. B. ein Netzwerkadapter); oder, für einen flüchtigen Speicher im großen Umfang innerhalb der Rechnervorrichtung 2300 (z. B. Festplattenlaufwerk) umgesetzt werden. Benutzereingabevorrichtungen, einschließlich alphanumerischer und anderer Tasten, können verwendet werden, um Informationen und Befehlsauswahlen an den Grafikprozessor 2304 zu kommunizieren. Eine andere Art von Benutzereingabevorrichtung, wie etwa eine Maus, ein Trackball, ein Touchscreen, ein Touchpad oder Cursorrichtungstasten zur Mitteilung von Richtungsinformationen und Befehlsauswahlen an die GPU und zum Steuern der Cursorbewegung auf der Anzeigevorrichtung. Kamera- und Mikrofonarrays der Rechnervorrichtung 2300 können verwendet werden, um Gesten zu beobachten, Ton- und Video aufzunehmen und Sicht- und Tonbefehle zu übertragen.
E/A bis Quellen 2310, die als Netzwerkschnittstellen konfiguriert sind, können Zugriff auf ein Netzwerk wie etwa ein LAN, ein Wide Area Network (WAN), ein Metropolitan Area Network (MAN), ein Personal Area Network (PAN), Bluetooth, ein Cloudnetz, ein zelluläres oder Mobilfunknetz (z. B. 3rd Generation (3G), 4th Generation (4G), usw.), ein Intranet, das Internet usw. bereitstellen. Eine oder mehrere Netzwerkschnittstelle(n) können beispielsweise eine Drahtlosnetzwerkschnittstelle enthalten, die eine oder mehrere Antennen aufweist. Die Netzwerkschnittstelle(n) kann/können auch beispielsweise eine verkabelte Netzwerkschnittstelle enthalten, um mit externen Vorrichtungen über ein Netzwerkkabel zu kommunizieren, was beispielsweise ein Ethernetkabel, ein Koaxialkabel, ein Glasfaserkabel, ein serielles Kabel oder ein paralleles Kabel sein kann.
Die Netzwerkschnittstelle(n) kann/können Zugriff auf ein LAN bereitstellen, beispielsweise durch Einhaltung der IEEE 802.11-Standards und/oder die drahtlose Netzwerkschnittstelle kann Zugriff auf ein Personal Area Network bereitstellen, etwa durch einhalten der Bluetooth-Standards. Andere drahtlose Netzwerkschnittstellen und/oder Protokolle, einschließlich vorheriger und nachfolgender Versionen der Standards, können ebenfalls unterstützt werden. Neben oder statt der Kommunikation über Drahtlos-LAN-Standards, können eine oder mehrere Netzwerkschnittstellen drahtlose Kommunikation unter Verwendung von beispielweise Time Division, Multiple Access (TDMA) Protokollen, Global Systems for Mobile Communications (GSM) Protokollen, Code Division, Multiple Access (CDMA) Protokollen und/oder einem anderen Typ von Drahtloskommunikationsprotokollen bereitstellen.
Es ist zu beachten, dass ein weniger oder umfangreicher ausgestattetes System als das oben beschriebene Beispiel für bestimmte Umsetzungen bevorzugt werden kann. Daher kann die Konfiguration der Rechnervorrichtung 2300 von Umsetzung zu Umsetzung variieren, abhängig von zahlreichen Faktoren, wie etwa Preisbegrenzungen, Leistungsanforderungen, technischen Verbesserungen oder anderen Umständen. Beispiele können (ohne Einschränkung) umfassen: eine mobile Vorrichtung, einen Personal Digital Assistant, eine mobile Rechnervorrichtung, ein Smartphone, ein Handy, ein Mobilteil, einen Einwege-Pager, einen Zweiwege-Pager, eine Nachrichtenvorrichtung, ein Computer, einen persönlichen Computer (PC), einen Desktopcomputer, einen Laptopcomputer, einen Notebookcomputer, einen tragbaren Computer, einen Tabletcomputer, einen Server, ein Serverarray oder eine Serverfarm, einen Webserver, einen Netzwerkserver, einen Internetserver, eine Arbeitsstation, einen Minicomputer, einen Mainframe-Computer, einen Supercomputer, eine Netzanwendung, eine Webanwendung, ein verteiltes Computersystem, Multiprozessorsysteme, prozessorbasierte Systeme, Verbraucherelektronik, programmierbare Verbraucherelektronik, einen Fernseher, einen Digitalfernseher, eine Settop-Box, drahtlose Zugriffspunkte, eine Basisstation, eine Teilnehmerstation, ein mobiles Teilnehmerzentrum, einen Funknetzcontroller, einen Router, einen Hub, ein Gateway, eine Brücke, einen Switch, eine Maschine oder Kombinationen daraus. Ausführungsformen können als eines oder eine Kombination der folgenden umgesetzt sein: ein oder mehrere Microchips oder integrierte Schaltkreise, die über eine Hauptplatine verbunden sind, fest verkabelte Logik, von einer Speichervorrichtung gespeicherte Software, die durch einen Mikroprozessor ausgeführt wird, Firmware, ein anwendungsspezifisch integrierter Schaltkreis (ASIC) und/oder ein im Feld programmierbarer Gatearray (FPGA). Der Begriff „Logik“ kann beispielsweise Software oder Hardware und/oder Kombinationen aus Software und Hardware enthalten.
Ausführungsformen können beispielsweise als ein Computerprogrammprodukt bereitgestellt werden, das ein oder mehrere maschinenlesbare Medien enthalten kann, auf denen von einer Maschine ausführbare Anweisungen gespeichert sind, die bei Ausführung durch eine oder mehrere Maschinen wie Computer, ein Computernetzwerk oder andere elektronische Vorrichtungen dazu führen kann, dass eine oder mehrere Maschinen Operationen nach den hierin beschriebenen Ausführungsformen ausführen. Ein maschinenlesbares Medium kann Floppy-Disketten, optische Scheiben, CD-ROMs (Compact Disc-Read Only Memories) und magnetoptische Scheiben, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetische oder optische Karten, Flash-Speicher oder andere Arten von Medien/maschinenlesbare Medien, die sich zum Speichern von maschinenausführbaren Anweisungen eigenen, enthalten, ist aber nicht darauf beschränkt.
Weiterhin können Ausführungsformen als Computerprogrammprodukt heruntergeladen werden, wobei das Programm von einem externen Computer (z. B. einem Server) auf einen anfragenden Computer (z. B. einen Client) mittels eines oder mehrerer Datensignale, die in einer Trägerwelle oder einem anderen Weiterleitungsmedium über eine Kommunikationsverbindung (z. B. eine Modem- und/oder Netzwerkverbindung) verkörpert und/oder moduliert werden, übertragen wird.
Die folgenden Klauseln und/oder Beispiele beziehen sich auf spezifische Ausführungsformen oder deren Beispiele. Einzelheiten in den Beispielen können überall in einer oder mehreren Ausführungsformen verwendet werden. Die verschiedenen Merkmale der verschiedenen Ausführungsformen oder Beispiel könne unterschiedlich kombiniert werden, wobei einige Merkmalen enthalten und andere nicht enthalten sind, um sich für eine Vielzahl verschiedener Anwendungen zu eignen. Beispiel können den Inhalt wie ein Verfahren, ein Mittel zur Durchführung von Handlungen des Verfahrens, mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die bei Ausführung durch die Maschine die Maschine veranlassen, Handlungen des Verfahrens auszuführen, oder eine Vorrichtung oder ein Systems nach den hierin beschriebenen Ausführungsformen und Beispielen enthalten. Verschiedene Komponente können ein Mittel zum Durchführen der beschriebenen Operationen und Funktionen enthalten.
Hierin beschrieben sind mehrere Ausführungsformen, die verbessertes Datencachen in Kombination mit adaptiver und dynamischer Komprimierung bereitstellen, um die Speichereffizienz zu erhöhen und die Übertragungsbandbreite der Daten während der Ein- und Ausgabe aus einer GPU verringern. Die hierin beschriebenen Techniken können die Notwendigkeit des Zugriffs auf Speicher außerhalb des Chips verhindern, was zu verbesserter Leistung und verringerter Energie für die GPU-Operationen führt. Eine Ausführungsform sieht eine Grafikverarbeitungsvorrichtung vor, die eine Shader-Engine; einen oder mehrere Cachespeicher; Cachesteuerlogik zur Steuerung von mindestens einem des einen oder der mehreren Cachespeicher; und eine Codec-Einheit, die mit dem einen oder den mehreren Cachespeichern verbunden ist, umfasst, wobei die Codec-Einheit konfigurierbar ist, nach dem Speichern auf oder der Auslagerung von dem einen oder den mehreren Cachespeichern eine verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff auszuführen. Eine Ausführungsform sieht ein Verfahren vor, das die Konfiguration eines Puffers für reinen Lesezugriff durch eine Grafikpipeline; die Bereitstellung von Pufferdaten für verlustfreie Farbkomprimierungslogik, die mit einem Cachespeicher der Grafikpipeline assoziiert ist; den Versuch der verlustfreien Komprimierung für eine erste Dateneinheit von dem Puffer; das Speichern der ersten Dateneinheit in einem komprimierten Format in Reaktion auf die verlustfreie Komprimierung der Dateneinheit; und die Markierung von Metadaten, die mit der ersten Dateneinheit assoziiert sind, um einen Komprimierungszustand für die erste Dateneinheit anzugeben, umfasst.
Eine Ausführungsform sieht ein Datenverarbeitungssystem vor, das eine Shader-Engine; eine Anzeigevorrichtung zum Anzeigen von Ausgaben, die über eine Shader-Engine erzeugt wurden; einen oder mehrere Cachespeicher; Cachesteuerlogik zur Steuerung von mindestens einem des einen oder der mehreren Cachespeicher; und eine Codec-Einheit, die mit dem einen oder den mehreren Cachespeichern verbunden ist, umfasst, wobei die Codec-Einheit konfigurierbar ist, nach dem Speichern auf oder der Auslagerung von dem einen oder den mehreren Cachespeichern eine verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff auszuführen.
Eine Ausführungsform sieht eine Grafikverarbeitungsvorrichtung vor, die eine Shader-Engine umfasst, um Renderzieldaten zu erzeugen, und eine Codec-Einheit, die mit der Shader-Engine gekoppelt ist, wobei die Codec-Einheit Renderzieldaten komprimiert, die durch die Shader-Engine erzeugt wurden, und die Renderzieldaten unter Verwendung verlustbehafteter oder verlustfreier Komprimierung basierend auf einem Profil, das mit den Renderzieldaten assoziiert ist, komprimiert werden sollen.
Eine Ausführungsform sieht eine Grafikverarbeitungsvorrichtung vor, die eine Shader-Engine umfasst, um Renderzieldaten zu erzeugen; eine oder mehrere Cachespeicher zum Speichern der Renderzieldaten; eine Codec-Einheit, die mit einem oder mehreren Cachespeichern gekoppelt ist, wobei die Codec-Einheit eine Komprimierung mit garantierter Rate auf die Renderzieldaten anwenden soll, um die Cachegröße, die mit den Renderzieldaten assoziiert ist, zu verringern; und eine Cachesteuerlogik zum Steuern von mindestens einem der einen oder mehreren Cachespeichern, wobei die Cachesteuerlogik die Komprimierung mit garantierter Rate ausnutzen soll, um die Speichereffizienz des Cache dem Komprimierungsverhältnis der Komprimierung mit garantierter Rate entsprechend zu erhöhen.
Eine Ausführungsform sieht eine Grafikverarbeitungsvorrichtung vor, die einen ersten Cachespeicher umfasst, um Grafikpipelinedaten zu speichern, wobei der erste Cachespeicher eine Bytemaske für maskiertes Schreiben auf den ersten Cachespeicher und ein unsauberes Bit für jeden Block der Pixeldaten innerhalb einer Cachezeile aufweist, wobei jede Cachezeile einen Speicher enthält, um mehrere Blocks von Pixeln zu speichern; einen zweiten Cachespeicher, wobei der zweite Cache teilweise Auslagerungen aus dem ersten Cache basierend auf der Bytemaske verschmelzen soll; einen Cachecontroller zum Veralten von mindestens dem ersten Cachespeicher, wobei der Cachecontroller einen Satz von Cachezeilen für die potenzielle Auslagerung basierend auf einer Hauptcache-Ersetzungsrichtlinie bestimmen soll, und die Cachezeile auslagern soll, die die größte Anzahl unsauberer Blocks aufweist.
Eine Ausführungsform sieht eine Grafikverarbeitungsvorrichtung vor, die einen oder mehrere Cachespeicher und eine Codec-Einheit umfasst, die mit dem einen oder den mehreren Cachespeichern gekoppelt ist. Die Codec-Einheit kann konfiguriert sein, Renderzieldaten beim Speichern in oder Auslagern aus dem einen oder den mehreren Cachespeichern verlustfrei zu komprimieren. Zum verlustfreien Komprimieren der Renderzieldaten soll die Codec-Einheit für eine Kachel von Pixeln innerhalb des Renderziels einen Mindestwert für jeden Farbkanal, einen Satz Restwerte für jeden Farbkanal und eine Breite für jeden Farbkanal bestimmen, und die breite für jeden Farbkanal über einen kompakten Satz von Basiswerten codieren, wobei der kompakte Satz der Basiswerte weniger als alle möglichen Werte einer Breite enthält.
Fachleute werden aus der vorstehenden Beschreibung erkennen, dass die breiten Techniken der Ausführungsformen in einer Vielzahl von Formen umgesetzt werden können. Daher wurden zwar die Ausführungsformen in Verbindung mit bestimmten Beispielen davon beschrieben, der wahre Umfang der Ausführungsformen sollte jedoch nicht so beschränkt werden, da andere Änderungen einem Fachmann bei Betrachten der Zeichnungen, Vorgaben und nachfolgenden Anspräche offensichtlich sein werden.

Claims

Grafikverarbeitungsvorrichtung, umfassend: eine Shader-Engine; einen oder mehrere Cachespeicher; eine Cachesteuerlogik zur Steuerung von mindestens einem des einen oder der mehreren Cachespeicher; und eine Codec-Einheit, die mit einem oder mehreren Cachespeichern gekoppelt ist, wobei die Codec-Einheit beim Speichern in oder der Auslagerung von dem einen oder den mehreren Cachespeichern eine verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff ausführen soll.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei der eine oder die mehreren Cachespeicher einen ersten Cachespeicher und einen zweiten Cachespeicher enthalten.
Grafikverarbeitungsvorrichtung nach Anspruch 2, wobei der erste Cachespeicher einen ersten Abschnitt der Daten von der Oberfläche mit reinem Lesezugriff erhalten soll, und die Codec-Einheit den ersten Abschnitt der Daten für die Komprimierung bearbeiten soll.
Grafikverarbeitungsvorrichtung nach Anspruch 3, wobei die Codec-Einheit bei der Auslagerung des ersten Abschnitts der Daten auf den zweiten Cachespeicher den ersten Abschnitt der Daten zur Komprimierung verarbeiten soll.
Grafikverarbeitungsvorrichtung nach Anspruch 3, wobei die Codec-Einheit für die Verarbeitung des ersten Abschnitts der Daten zur Komprimierung versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein Zielkomprimierungsverhältnis zu komprimieren und Metadaten, die mit dem ersten Abschnitt der Daten assoziiert sind, zu markieren, um einen Komprimierungszustand für den ersten Abschnitt der Daten anzuzeigen.
Grafikverarbeitungsvorrichtung nach Anspruch 5, wobei die Codec-Einheit versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein erstes Zielkomprimierungsverhältnis zu komprimieren, und versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein zweites Zielkomprimierungsverhältnis zu komprimieren, wenn der erste Abschnitt der Daten nicht ohne Datenverlust auf das erste Zielkomprimierungsverhältnis komprimierbar ist.
Grafikverarbeitungsvorrichtung nach Anspruch 5, wobei die Codec-Einheit den ersten Abschnitt der Daten auf ein erstes Komprimierungsverhältnis komprimieren soll und den Abschluss der Komprimierung eines zweiten Abschnitts der Daten von der Oberfläche mit reinem Lesezugriff umgehen soll, wenn der zweite Abschnitt der Daten nicht ohne Datenverlust auf das erste Komprimierungsverhältnis komprimiert werden kann.
Grafikverarbeitungsvorrichtung nach Anspruch 5, wobei die Codec-Einheit versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein erstes Zielkomprimierungsverhältnis zu komprimieren, und versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein zweites Zielkomprimierungsverhältnis zu komprimieren, wenn die Codec-Einheit nicht in der Lage ist, den ersten Abschnitt der Daten auf das erste Zielkomprimierungsverhältnis zu komprimieren.
Grafikverarbeitungsvorrichtung nach Anspruch 8, wobei der zweite Cachespeicher des einen oder der mehreren Cachespeicher den ersten Abschnitt der Daten bei einem ersten Komprimierungsverhältnis und einen zweiten Abschnitt der Daten bei einem 1:1-Komprimierungsverhältnis speichern soll.
Grafikverarbeitungsvorrichtung nach Anspruch 9, wobei das zweite Zielkomprimierungsverhältnis größer als ein 1:1-Komprimierungsverhältnis ist und der zweite Cachespeicher des einen oder der mehreren Cachespeicher einen dritten Abschnitt der Daten von der Oberfläche mit reinem Lesezugriff bei einem zweiten Zielkomprimierungsverhältnis speichern soll.
Grafikverarbeitungsvorrichtung nach Anspruch 1, wobei die Shader-Engine einen oder mehrere eines Vertexprozessors und eines Pixelprozessors enthält.
Grafikverarbeitungsvorrichtung nach Anspruch 11, wobei der Vertexprozessor oder der Pixelprozessor unkomprimierte Daten von der Oberfläche mit reinem Lesezugriff über den Codec erhält, und der Codec einen oder mehrere Abschnitte komprimierter Daten von der Oberfläche mit reinem Lesezugriff dekomprimieren soll.
Grafikverarbeitungsvorrichtung nach einem der Ansprüche 1 bis 12, wobei die Oberfläche mit reinem Lesezugriff Vertexdaten, Texturdaten oder andere konstante Daten enthält, die durch die Shader-Engine gelesen werden sollen.
Verfahren, umfassend: Konfiguration eines Puffers für reinen Lesezugriff durch eine Grafikpipeline; Bereitstellung von Pufferdaten an eine verlustfreie Farbkomprimierungslogik, die mit einem Cachespeicher der Grafikpipeline assoziiert ist; Versuch der verlustfreien Komprimierung für eine erste Dateneinheit von dem Puffer; Speichern der ersten Dateneinheit in einem komprimierten Format in Reaktion auf die verlustfreie Komprimierung der Dateneinheit; und Markierung der Metadaten, die mit der ersten Dateneinheit assoziiert sind, um einen Komprimierungszustand für die erste Dateneinheit anzugeben.
Verfahren nach Anspruch 14, wobei der Versuch der verlustfreien Komprimierung für eine erste Dateneinheit von dem Puffer den Versuch enthält, die erste Dateneinheit auf ein erstes Zielkomprimierungsverhältnis zu komprimieren.
Verfahren nach Anspruch 15, weiter umfassend: Versuch der verlustfreien Komprimierung für eine zweite Dateneinheit von dem Puffer; Speichern der zweiten Dateneinheit in einem unkomprimierten Format in Reaktion auf die Feststellung, dass die zweite Dateneinheit nicht verlustfrei auf das erste Zielkomprimierungsverhältnis komprimiert werden kann; Markierung der Metadaten, die mit der zweiten Dateneinheit assoziiert sind, um einen Komprimierungszustand für die zweite Dateneinheit anzugeben.
Verfahren nach Anspruch 15, weiter umfassend: Versuch der verlustfreien Komprimierung für eine zweite Dateneinheit von dem Puffer; in Reaktion auf die Feststellung, dass die zweite Dateneinheit nicht verlustfrei auf das erste Zielkomprimierungsverhältnis komprimiert werden kann, Versuch der verlustfreien Komprimierung für die zweite Dateneinheit bei einem zweiten Zielkomprimierungsverhältnis: Speichern der zweiten Dateneinheit in einem komprimierten Format in Reaktion auf die Komprimierung der zweiten Dateneinheit auf das zweite Zielkomprimierungsverhältnis; Markierung der Metadaten, die mit der zweiten Dateneinheit assoziiert sind, um einen Komprimierungszustand für die zweite Dateneinheit anzugeben.
Verfahren nach Anspruch 17, wobei der Komprimierungszustand für die zweite Dateneinheit ein Komprimierungsverhältnis für die zweite Dateneinheit anzeigt.
Verfahren nach einem der Ansprüche 14 bis 18, wobei der Puffer, der für reinen Lesezugriff konfiguriert ist, Vertexdaten, Texturdaten oder andere konstante Daten enthält, die durch die Grafikpipeline gelesen werden sollen.
Datenverarbeitungssystem, umfassend: eine Shader-Engine; eine Anzeigevorrichtung zur Anzeige von Ausgaben, die über die Shader-Engine erzeugt werden; einen oder mehrere Cachespeicher; eine Cachesteuerlogik zur Steuerung von mindestens einem des einen oder der mehreren Cachespeicher; und eine Codec-Einheit, die mit einem oder mehreren Cachespeichern gekoppelt ist, wobei die Codec-Einheit konfigurierbar ist, eine verlustfreie Komprimierung von Oberflächendaten mit reinem Lesezugriff beim Speichern in oder der Auslagerung von dem einen oder den mehreren Cachespeichern auszuführen.
Datenverarbeitungssystem nach Anspruch 20, wobei der eine oder die mehreren Cachespeicher einen ersten Cachespeicher und einen zweiten Cachespeicher enthalten, wobei der erste Cachespeicher einen ersten Abschnitt der Daten von der Oberfläche mit reinem Lesezugriff erhalten soll, und die Codec-Einheit den ersten Abschnitt der Daten für die Komprimierung bearbeiten soll.
Datenverarbeitungssystem nach Anspruch 21, wobei die Codec-Einheit den ersten Abschnitt der Daten bei der Auslagerung des ersten Abschnitts der Daten auf den zweiten Cachespeicher zur Komprimierung verarbeiten soll.
Datenverarbeitungssystem nach Anspruch 22, wobei die Codec-Einheit für die Verarbeitung des ersten Abschnitts der Daten zur Komprimierung versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein Zielkomprimierungsverhältnis zu komprimieren und Metadaten, die mit dem ersten Abschnitt der Daten assoziiert sind, zu markieren, um einen Komprimierungszustand für den ersten Abschnitt der Daten anzuzeigen.
Datenverarbeitungssystem nach Anspruch 23, wobei die Codec-Einheit versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein erstes Zielkomprimierungsverhältnis zu komprimieren, und versuchen soll, den ersten Abschnitt der Daten verlustfrei auf ein zweites Zielkomprimierungsverhältnis zu komprimieren, wenn die Codec-Einheit nicht in der Lage ist, den ersten Abschnitt der Daten auf das erste Zielkomprimierungsverhältnis zu komprimieren.
Grafikverarbeitungsvorrichtung nach einem der Ansprüche 21 bis 24, wobei der zweite Cachespeicher des einen oder der mehreren Cachespeicher einen ersten Abschnitt der Daten bei einem ersten Komprimierungsverhältnis und einen zweiten Abschnitt der Daten bei einem 1:1-Komprimierungsverhältnis speichern soll.